SIST EN ISO 22510:2020

SLOVENSKI STANDARD
01-maj-2020
Nadomešča:
SIST EN 13321-2:2013
Odprta izmenjava podatkov v avtomatizaciji stavb, regulaciji in upravljanju stavb -
Elektronski sistemi za stanovanja in stavbe - Komunikacijski protokol KNX net/IP
(ISO 22510:2019)
Open data communication in building automation, controls and building management -
Home and building electronic systems - KNXnet/IP communication (ISO 22510:2019)
Offene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement -
Elektrische Systemtechnik für Heim und Gebäude - Teil 2: KNXnet/IP-Kommunikation
(ISO 22510:2019)
Réseau ouvert de communication de données pour l'automatisation, la régulation et la
gestion technique du bâtiment - Systèmes électroniques pour les foyers domestiques et
les bâtiments - Communication KNX/IP (ISO 22510:2019)
Ta slovenski standard je istoveten z: EN ISO 22510:2020
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 22510
EUROPEAN STANDARD
NORME EUROPÉENNE
February 2020
EUROPÄISCHE NORM
ICS 35.240.67; 91.040.01 Supersedes EN 13321-2:2012
English Version
Open data communication in building automation, controls
and building management - Home and building electronic
systems - KNXnet/IP communication (ISO 22510:2019)
Réseau ouvert de communication de données pour Offene Datenkommunikation für die
l'automatisation, la régulation et la gestion technique Gebäudeautomation und Gebäudemanagement -
du bâtiment - Systèmes électroniques pour les foyers Elektrische Systemtechnik für Heim und Gebäude - Teil
domestiques et les bâtiments - Communication KNX/IP 2: KNXnet/IP-Kommunikation (ISO 22510:2019)
(ISO 22510:2019)
This European Standard was approved by CEN on 1 December 2019.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 22510:2020 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (EN ISO 22510:2020) has been prepared by Technical Committee ISO/TC 205 "Building
environment design" in collaboration with Technical Committee CEN/TC 247 “Building Automation,
Controls and Building Management” the secretariat of which is held by SNV.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by August 2020, and conflicting national standards shall
be withdrawn at the latest by August 2020.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 13321-2:2012.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
Endorsement notice
The text of ISO 22510:2019 has been approved by CEN as EN ISO 22510:2020 without any modification.

INTERNATIONAL ISO
STANDARD 22510
First edition
2019-11
Open data communication in building
automation, controls and building
management — Home and building
electronic systems — KNXnet/IP
communication
Réseau ouvert de communication de données pour l'automatisation,
la régulation et la gestion technique du bâtiment — Systèmes
électroniques pour les foyers domestiques et les bâtiments —
Communication KNX/IP
Reference number
ISO 22510:2019(E)
©
ISO 2019
ISO 22510:2019(E)
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

ISO 22510:2019(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Requirements . 5
5.1 Overview . 5
5.1.1 KNXnet/IP document parts . 5
5.1.2 Mandatory and optional implementation of IP protocols . 7
5.2 Core . 8
5.2.1 Use . 8
5.2.2 KNXnet/IP frames . 9
5.2.3 Host protocol independence.10
5.2.4 Discovery and self description .11
5.2.5 Communication channels .13
5.2.6 General implementation guidelines .15
5.2.7 Data Packet structures .19
5.2.8 IP Networks .38
5.2.9 Minimum supported services .47
5.3 Device management specification .48
5.3.1 Use .48
5.3.2 KNXnet/IP device management .48
5.3.3 Implementation rules and guidelines .59
5.3.4 Data packet structures .60
5.3.5 Minimum profiles .63
5.4 Tunnelling .64
5.4.1 Use .64
5.4.2 Tunnelling of KNX telegrams .64
5.4.3 Configuration and management .68
5.4.4 Frame structures.70
5.4.5 Minimum profiles .77
5.5 Routing .78
5.5.1 Use .78
5.5.2 KNXnet/IP routing of KNX telegrams .78
5.5.3 Implementation rules and guidelines .88
5.5.4 Configuration and management .91
5.5.5 Data packet structures .91
5.5.6 Minimum profiles .93
5.6 Remote diagnosis and configuration .94
5.6.1 Use .94
5.6.2 Remote diagnosis of KNXnet/IP devices .95
5.6.3 Configuration and management .95
5.6.4 Data packet structures .96
5.6.5 Certification .101
5.7 Secured communication .101
5.7.1 Use .101
5.7.2 Stack and communication .102
5.7.3 Management procedures .143
5.7.4 Synchronizing timers .146
Annex A (normative) List of codes .148
Annex B (informative) Binary examples of KNXnet/IP frames .155
ISO 22510:2019(E)
Annex C (normative) KNXnet/IP parameter object .175
Annex D (normative) Common external messaging interface (cEMI) .178
Annex E (normative) Coupler resources .210
Bibliography .221
iv © ISO 2019 – All rights reserved

ISO 22510:2019(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by the European Committee for Standardization (CEN) Technical
Committee CEN/TC 247, Building Automation, Controls and Building Management, in collaboration with
ISO Technical Committee TC 205, Building environment design, in accordance with the agreement on
technical cooperation between ISO and CEN (Vienna Agreement).
A list of all parts in the ISO 16484 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
ISO 22510:2019(E)
Introduction
This document is intended for the design of new buildings and the retrofit of existing buildings in terms
of acceptable indoor environment, practical energy conservation and efficiency.
KNXnet/IP is a protocol designed to transport KNX home and building electronic system (HBES) control
frames over an IP network. It is used as an infrastructure backbone for connecting KNX sub-networks,
as a communication medium for KNX-IP devices and to provide IP based services for clients (e.g.
connecting a tool software to a KNX installation). The main advantages of using IP for these purposes
are that IP network infrastructure is inexpensive, available almost everywhere and that the distance of
two communication parties on an IP network is virtually unlimited.
Widespread deployment of data networks using the Internet protocol (IP) presents an opportunity to
expand building control communication beyond the local KNX control bus, providing:
— remote configuration;
— remote operation (including control and annunciation);
— fast interface from LAN to KNX and vice versa;
— WAN connection between KNX systems (where an installed KNX system is at least one line);
— an interface to super ordinate building management and energy management systems.
A KNXnet/IP system contains at least these elements:
— one EIB line with up to 64 (255) EIB devices; or
one KNX segment (KNX-TP1, KNX-RF, KNX-PL110);
— a KNX-to-IP network connection device (called KNXnet/IP server); and typically
— additional software for remote functions residing on e.g. a workstation (may be data base application,
BACnet Building Management System, browser, etc.).
KNXnet/IP differentiates between unicast and multicast services. KNXnet/IP unicast services are used
to connect a single client to a single KNXnet/IP server (e.g. KNXnet/IP Tunnelling). KNXnet/IP multicast
services are mainly used to connect different KNX sub-networks using IP communication on the KNX
backbone. The KNXnet/IP routing services are defined for this purpose. KNXnet/IP multicast services
build on top of IP multicast.
Figure 1 — Unicast and multicast in the sense of KNX, KNXnet/IP and IP
Figure 1 shows a typical scenario where a KNXnet/IP client (e.g. running ETS) accesses multiple KNX
installed systems or KNX subnetworks via an IP network. The KNXnet/IP client may access one or more
KNXnet/IP servers at a time. For subnetwork, routing server-to-server communication is possible.
vi © ISO 2019 – All rights reserved

ISO 22510:2019(E)
Figure 2 — Device types and configuration examples
Figure 2 shows device types and configuration examples. This document defines the integration
of KNX protocol implementations within the Internet protocol (IP) named KNXnet/IP. It defines a
standard protocol, which is implemented within KNX devices, Engineering Tool Software (ETS) and
other implementations to support KNX data exchange over IP networks. In fact, KNXnet/IP provides
a general framework, which accommodates several specialised “Service Protocols” in a modular and
extendible fashion.
INTERNATIONAL STANDARD ISO 22510:2019(E)
Open data communication in building automation, controls
and building management — Home and building electronic
systems — KNXnet/IP communication
1 Scope
This document defines the integration of KNX protocol implementations on top of Internet protocol
(IP) networks, called KNXnet/IP. It describes a standard protocol for KNX devices connected to an
IP network, called KNXnet/IP devices. The IP network acts as a fast (compared to KNX twisted pair
transmission speed) backbone in KNX installations.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
backbone key
key used for encryption and message authentication of secure KNXnet/IP multicast communication in a
KNXnet/IP routing multicast group, configured by ETS and a shared secret between all members of the
secure KNXnet/IP routing multicast group
3.2
cipher
generic term that denotes the encrypted data
Note 1 to entry: Cipher is the opposite of plain (3.22).
3.3
common external message interface
generic structure for medium independent KNX (3.14) messages
Note 1 to entry: cEMI (common EMI) frames are used to encapsulate KNX messages within Internet protocol (IP)
packets.
3.4
communication channel
logical connection between a KNXnet/IP client (3.16) and a KNXnet/IP server (3.20) or, in case of routing,
between two or more KNXnet/IP servers
Note 1 to entry: A communication channel consists of one or more connections on the definition of the host
protocol used for KNXnet/IP.
ISO 22510:2019(E)
3.5
dynamic host configuration protocol
communication protocol for automatic assignment of IP address settings
3.6
domain name system
assigns Internet names to IP addresses
3.7
engineering tool software
software used to configure KNX (3.14) devices
3.8
european installation bus
predecessor protocol to KNX
Note 1 to entry: Standard for building controls (EN 50090).
3.9
host protocol address information
structure holding the IP host protocol address information used to address a KNXnet/IP endpoint on
another KNXnet/IP device (3.17)
3.10
individual address
unique KNX (3.14) address of a KNX device in a KNX system
3.11
IP channel
logical connection between two IP host/port endpoints
Note 1 to entry: IP channels are either a guaranteed, reliable TCP (transmission control protocol) or an unreliable
point-to-point or multicast (in case of routing) UDP (user datagram protocol) connection.
3.12
Internet control message protocol
extension to the Internet protocol (IP) for error, control, and informational messages
1)
Note 1 to entry: ICMP is defined by RFC 92 and supports packet containing error, control, and informational
messages. The PING command, for example, uses ICMP to test an Internet connection.
3.13
Internet group management protocol
extension to the Internet protocol (IP) for management of IP multicasting in the Internet
Note 1 to entry: IGMP is defined in RFC 1112 as the standard for IP multicasting in the Internet. It is used to
establish host memberships in particular multicast groups on a single network. By using Host Membership
Reports, the mechanisms of the protocol allow a host to inform its local router that it wants to receive messages
addressed to a specific multicast group. All hosts conforming to level 2 of the IP multicasting specification
require IGMP.
3.14
KNX
standard for building controls
Note 1 to entry: See EN 50090, ISO/IEC 14543-3-1 to ISO/IEC 14543-3-7.
1) Request for Comment: Internet standards defined by the Internet Engineering Task Force (IETF) are firstly
published as RFCs.
2 © ISO 2019 – All rights reserved

ISO 22510:2019(E)
3.15
KNX node
device implementing a KNX (3.14) protocol stack and fulfilling the requirements according to the KNX
standard
3.16
KNXnet/IP client
application using the KNXnet/IP client protocol to get access to a KNX (3.14) subnetwork over an IP
network channel
3.17
KNXnet/IP device
implementation of KNXnet/IP services on a KNX node (3.15) (KNXnet/IP server (3.20)) or any other
hardware (KNXnet/IP client (3.16))
3.18
KNX/IP domain
all KNXnet/IP devices (3.17) in the same network with the same multicast address and the same
backbone encryption (either no encryption or encryption with the same key)
3.19
KNXnet/IP router
special type of KNXnet/IP device (3.17) that routes KNX (3.14) protocol packets between KNX sub-
networks
3.20
KNXnet/IP server
KNX (3.14) device with physical access to a KNX network implementing the KNXnet/IP server protocol
to communicate with KNXnet/IP clients (3.16) or other KNXnet/IP servers (in case of routing) on an IP
network channel
Note 1 to entry: A KNXnet/IP server is by design always also a KNX node (3.15).
3.21
KNXnet/IP tunnelling
services for point-to-point exchange of KNX (3.14) telegrams over an IP network between a KNXnet/IP
device (3.17) acting as a server and a KNXnet/IP client (3.16)
3.22
plain
generic term that denotes unencrypted data, of which the content depends on the service and the user
and not of confidentiality and authentication
Note 1 to entry: Plain is the opposite of cipher (3.2).
3.23
secure session
authenticated, authorized and encrypted communication channel (3.4) between one KNXnet/IP client
(3.16) and one KNXnet/IP server (3.20) for unicast communication
3.24
session key
key used for encryption and message authentication in a secure session (3.23) between two KNXnet/IP
communication parties, created using ECDH in the secure session setup procedure (providing perfect
forward secrecy) and only valid for this individual session
3.25
subnet
portion of a network that shares a common address component known as the "subnet address"
Note 1 to entry: Different network protocols specify the subnet address in different ways.
ISO 22510:2019(E)
3.26
time to live
maximum number of IP routers a multicast UDP/IP datagram may be routed through
Note 1 to entry: Each IP router the datagram passes decrements the TTL by one; the local host adapter also does
this. When the TTL has reached zero, the router discards the datagram. When sending a datagram from the local
host adapter, a TTL of zero means that the datagram never leaves the host. A TTL of one means that the datagram
never leaves the local network (it is not routed).
3.27
transmission control protocol over Internet protocol
connection-oriented communication over the Internet
3.28
user datagram protocol over Internet protocol
connection-less communication over the Internet
4 Abbreviated terms
Abbreviated term Description
AddIL Length of additional information
AES Advanced Encryption Standard
Cn Conditions are specified under note “n”
CBC Cipher Block Chaining
CCM Counter with CBC-MAC
cEMI Common External Message Interface
CTR Counter Mode (of Operation)
DDoS Distributed Denial of Service
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DoS Denial of Service
ECDH Elliptic Curve Diffie–Hellman
EIB European Installation Bus
ETS Engineering Tool Software
FDSK Factory Default Setup Key
HPAI Host Protocol Address Information
IA Individual Address
ICMP Internet Control Message Protocol
IGMP Internet Group Management Protocol
IP Internet Protocol
IV Initialisation Vector
M Mandatory
MAC Message Authentication Code
MC Message Code
MiM Man-in-the-Middle
n/a Not applicable
O Optional
PBKDF2 Password-Based Key Derivation Function 2
R Required
SHA Secure Hash Algorithm
4 © ISO 2019 – All rights reserved

ISO 22510:2019(E)
Abbreviated term Description
TCP/IP Transmission Control Protocol over Internet Protocol
TTL Time To Live
X Not allowed
UDP/IP User Datagram Protocol over Internet Protocol
5 Requirements
5.1 Overview
5.1.1 KNXnet/IP document parts
5.1.1.1 General
This document defines the integration of KNX protocol implementations within the Internet protocol
(IP) named KNXnet/IP.
This document defines a standard protocol, which is implemented within KNX devices, Engineering
Tool Software and other implementations to support KNX data exchange over IP networks. In fact,
KNXnet/IP provides a general framework, which accommodates several specialised “Service Protocols”
in a modular and extendible fashion.
The KNXnet/IP specification consists of the following parts:
— Overview;
— Core specification;
— Device management;
— Tunnelling;
— Routing;
— Remote diagnosis and configuration;
— Secured communication.
KNXnet/IP supports different software implementations on top of the protocol. More specifically, these
software implementations can be Building Management, Facility Management, Energy Management, or
simply Data Base and SCADA (Supervision, Control and Data Acquisition) packages.
Most of these packages need be configured for the specific user application. In order to simplify this
process and cut costs for engineering, KNXnet/IP provides simple engineering interfaces, namely a
description “language” for the underlying KNX system. This may be done offline, for example generated
as an ETS export file, or online by a mechanism that self-describes the underlying KNX system (reading
data from the system itself).
KNXnet/IP supports:
— on-the-fly change-over between operational modes (configuration, operation);
— event driven mechanisms;
— connections with a delay time greater than t (e.g. network connection via satellite).
KNX_transfer_timeout
5.1.1.2 Overview
"Overview" is this clause.
ISO 22510:2019(E)
5.1.1.3 Core specification
“Core specification” defines a standard protocol, which is implemented within KNXnet/IP devices and
the Engineering Tool Software (ETS) to support KNX data exchange over IP networks.
This specific implementation of the protocol over the Internet protocol (IP) is called KNXnet/IP.
This specification addresses:
— definition of data packets sent over the IP host protocol network for KNXnet/IP communication;
— discovery and self-description of KNXnet/IP servers;
— configuration and establishment of a communication channel between a KNXnet/IP client and a
KNXnet/IP server.
5.1.1.4 Device management
“Device management” defines services for remote configuration and remote management of KNXnet/
IP servers.
5.1.1.5 Tunnelling
“Tunnelling” defines services for point-to-point exchange of KNX telegrams over an IP network
between a KNXnet/IP device acting as a server and a KNXnet/IP client. This point-to-point exchange
may be established by a super ordinate system for building automation or management functions or
by an Engineering Tool Software. It supports all ETS functions for download, test, and analysis of KNX
devices on KNX networks connected via KNXnet/IP servers. This includes changes of single KNX device
object properties.
Tunnelling assumes that a data transmission round-trip between ETS or a KNXnet/IP tunnelling client
and KNXnet/IP servers takes less than t .
KNX-transfer_timeouts
5.1.1.6 Routing
“Routing” defines services, which route KNX telegrams between KNXnet/IP servers through the IP
network.
5.1.1.7 Remote diagnosis and configuration
“Remote diagnosis and configuration” defines services for a point-to-point exchange of KNX telegrams
over an IP network between KNXnet/IP routers and/or KNX/IP devices. The services provide means
for diagnosing communication settings and for changing these remotely.
5.1.1.8 Secured communication
“Secured communication” defines services for a secured point-to-point exchange of KNX telegrams
over an IP network between a KNXnet/IP client and a KNX/IP server. The services provide means for
establishing secured communication sessions by authorized KNXnet/IP clients.
5.1.1.9 List of codes
Annex A gives a complete listing of all codes used by KNXnet/IP, to which KNXnet/IP implementations
shall conform, depending on the parts of this document supported.
5.1.1.10 Binary examples
Annex B gives binary examples of KNXnet/IP frames.
6 © ISO 2019 – All rights reserved

ISO 22510:2019(E)
5.1.2 Mandatory and optional implementation of IP protocols
5.1.2.1 General
KNXnet/IP uses existing IP protocols where possible unless their use implies an undue burden with
regard to memory and implementation requirements for the intended service.
The following table shows mandatory (M) and optional (O) implementation of IP protocols by KNXnet/
IP service types. Although this table refers to the KNXnet/IP server, it also indicates which IP protocols
shall be implemented by the KNXnet/IP client. Any non-applicable IP protocol is marked as “n/a”.
Table 1 shows KNXnet/IP service types and IP protocols.
Table 1 — KNXnet/IP service types and IP protocols
Service type
Secured
Remote
Device com-
IP protocol Core Tunnelling Routing diagnosis and
management muni-
configuration
cation
ARP M M M M M M
RARP O O O O O O
Support of fixed IP address M M M M M M
BootP (client) M M M M M M
DHCP (client) M M M M M M
UDP M M M M M M
TCP O O O n/a n/a M
ICMP M M M M M M
IGMP M M n/a M O M
It is essential that either BootP or DHCP is implemented by a KNXnet/IP device.
TCP is mandatory for tunnelling v2 required for secured communication.
Other Internet protocols like NTP (network time protocol), FTP (file transfer protocol), HTTP
(hypertext transfer protocol), SMTP (simple message transfer protocol), DNS (domain name system),
and SNMP (simple network management protocol) may be used but are not within the scope of the
KNXnet/IP protocol.
5.1.2.2 Minimum KNXnet/IP device requirements
KNXnet/IP service types as defined in this document require the implementation of a minimal set of IP
protocols for interworking.
KNXnet/IP servers shall implement these IP protocols: ARP, BootP, UDP, ICMP and IGMP. Other IP
protocols may be required for specific services.
A KNXnet/IP client shall not assume that a KNXnet/IP server supports KNXnet/IP frames with a total
length of more than 508.
5.1.2.3 Network environment
Because KNXnet/IP servers use IP, this document does not require any specific medium carrying the IP
datagrams.
It is recommended to use a medium, which carries at least twice the bit rate of all KNXnet/IP routers
connected to this medium. For a point-to-point connection, for example PPP, this would be at least
19 200 bit/s; for a network with up to 400 KNXnet/IP servers, this would be at least 8 Mbit/s.
ISO 22510:2019(E)
10BaseT is recommended as a minimum for KNXnet/IP servers using Ethernet as physical medium.
5.1.2.4 Addressing
KNXnet/IP servers are typically connected to one KNX subnetwork and to an IP network. Hence,
KNXnet/IP servers have one distinct address for each network they are connected to: one KNX
individual address and one IP address.
Additionally, KNXnet/IP servers are assigned to a KNXnet/IP project-installation using the same IP
multicast address for all KNXnet/IP servers in a KNXnet/IP project-installation.
5.1.2.5 KNXnet/IP device classes
A KNXnet/IP device can be a software implementation running on a PC. Hence, ETS or any other
software implementing KNXnet/IP services is viewed as a KNXnet/IP device.
Definition of KNXnet/IP device classes ensures interoperability between KNXnet/IP devices as well as
a minimum set of supported KNXnet/IP services for a given KNXnet/IP device class.
Table 2 lists mandatory and optional service types for device classes.
Device class A encompasses configuration and system maintenance tools. Except for object server
services, all other KNXnet/IP services shall be implemented. ETS is a member of this device class.
Device class B defines the minimum set of KNXnet/IP services for KNXnet/IP routers.
Device class C defines the minimum set of KNXnet/IP services for any other KNXnet/IP device. Building,
energy and facilities management systems are members of this KNXnet/IP device class. KNXnet/IP
device classes are shown in Table 2.
Table 2 — KNXnet/IP device classes
Service type
Core Device Tunnelling Routing Remote Secured
manage- diagnosis communi-
Device class
ment and con- cation
figuration
A  (Configuration and system M M M M M M
maintenance tools)
a a
B  (KNXnet/IP router) M M M M O O
C  (any other KNXnet/IP device) M M O O O O
a
If secure communication is supported, support of remote diagnosis and configuration is not allowed.
5.2 Core
5.2.1 Use
The "Core" of the KNXnet/IP specification provides a general host protocol-independent framework,
which accommodates several specialised “Service Protocols” in a modular and extendible fashion.
This specification addresses:
— definition of data packets sent over the non-KNX “host protocol” network for KNXnet/IP
communication;
— discovery and self-description of KNXnet/IP servers; and
— configuration, establishment and maintenance of a communication channel between a KNXnet/IP
client and a KNXnet/IP server.
8 © ISO 2019 – All rights reserved

ISO 22510:2019(E)
5.2.2 KNXnet/IP frames
5.2.2.1 General definitions
5.2.2.1.1 Data format
The KNXnet/IP frames described within this document are coded binary.
The data structure specifications are always noted in binary format.
5.2.2.1.2 Byte order
For binary structures, if not explicitly stated otherwise, the byte order shall be big endian mode
(Motorola, non-swapped). For plain text formats, the byte order and formatting shall be according to
the related protocol specifications.
5.2.2.1.3 Structures
All KNXnet/IP structures follow a common rule: the first octet is always the length of the complete
structure (as some structures may have fields of variable length, e.g. strings) and the second octet is
always an identifier that specifies the type of the structure. From the third octet on, the structure data
follows. If the amount of data exceeds 252 octets, the length octet shall be FFh and the next two octets
will contain the length as a 16 bit value. Then the structure data starts at the fifth octet.
5.2.2.2 Frame format
The communication between KNXnet/IP devices is based on KNXnet/IP frames. A KNXnet/IP frame
is a data packet sent over the non-KNX network protocol that consists of a header, comparable to the
IP header of an Internet protocol data packet and an optional body of variable length. Figure 3 shows
KNXnet/IP frame binary format.
Figure 3 — KNXnet/IP frame binary format
The type of KNXnet/IP frame is described by a KNXnet/IP service type identifier in the header.
KNXnet/IP services include, but are not limited to, information regarding discovery and description,
communication channel (connection) management and KNX data transfer.
5.2.2.3 Header
5.2.2.3.1 Description
Every KNXnet/IP frame, without any exception, consists at least of the common KNXnet/IP header that
contains information about the protocol version, the header and total packet length and the KNXnet/IP
service type identifier. The KNXnet/IP header may be followed by a KNXnet/IP body, depending on the
KNXnet/IP service.
Timestamp information and frame counters are not included in the common KNXnet/IP frame header
as this information is closely linked with certain KNXnet/IP service types and will therefore be
included in the body of these services as additional information for certain communication channel
types. Figure 4 shows the KNXnet/IP header binary format.
ISO 22510:2019(E)
Figure 4 — KNXnet/IP header binary format
5.2.2.3.2 Header length
Although the length of the header is always fixed, it is possible that the size of the header changes with
a new version of the protocol. The header length can be used as an index into the KNXnet/IP frame data
to find the beginning of the KNXnet/IP body.
5.2.2.3.3 Protocol version
The protocol version information states the revision of the KNXnet/IP protocol that the following
KNXnet/IP frame is subject to. It will be stored in binary coded decimal format. The only valid protocol
version at this time is 1.0 (represented as hexadecimal 10h).
5.2.2.3.4 KNXnet/IP service
The KNXnet/IP service type identifier defines the kind of action to be performed and the type of the
data payload contained in the KNXnet/IP body if applicable. The high octet of the KNXnet/IP service
type identifier denotes the service type family and the low octet the actual service type in that family.
For a detailed description of the services, see below.
5.2.2.3.5 Total length
The total length is expressing the total KNXnet/IP frame length in octets. The length includes the
complete KNXnet/IP frame, starting wi
...