SIST EN 14908-7:2020

SLOVENSKI STANDARD
oSIST prEN 14908-7:2018
01-oktober-2018
Odprta izmenjava podatkov pri avtomatizaciji stavb, regulaciji in upravljanju stavb
- Protokol regulacijske mreže - 7. del: Komunikacija preko spletnega protokola
Open communication in building automation, controls and building management - Control
Network Protocol - Part 7: Communication via internet protocols
Firmenneutrale Datenkommunikation für die Gebäudeautomation und
Gebäudemanagement - Gebäude-Netzwerk-Protokoll - Teil 7: Kommunikation über
Internetprotokolle
Réseau ouvert de communication de données pour l'automatisation, la régulation et la
gestion techniques du bâtiment - Protocol de bâtiment de réseau - Partie 7 :
Communication via des protocoles internet
Ta slovenski standard je istoveten z: prEN 14908-7:2018
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
91.140.01 Napeljave v stavbah na Installations in buildings in
splošno general
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
oSIST prEN 14908-7:2018 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 14908-7:2018

---------------------- Page: 2 ----------------------
oSIST prEN 14908-7:2018


DRAFT
EUROPEAN STANDARD
prEN 14908-7
NORME EUROPÉENNE

EUROPÄISCHE NORM

September 2018
ICS 35.240.67; 91.140.01; 97.120
English Version

Open communication in building automation, controls and
building management - Control Network Protocol - Part 7:
Communication via internet protocols
Réseau ouvert de communication de données pour Firmenneutrale Datenkommunikation für die
l'automatisation, la régulation et la gestion techniques Gebäudeautomation und Gebäudemanagement -
du bâtiment - Protocol de bâtiment de réseau - Partie 7 Gebäude-Netzwerk-Protokoll - Teil 7: Kommunikation
: Communication via des protocoles internet über Internetprotokolle
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 247.

If this draft becomes a European Standard, 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.

This draft European Standard was established by CEN 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.


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
© 2018 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 14908-7:2018:2018 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
Contents Page

European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Addressing . 9
4.1 Overview . 9
4.2 Network Address Mapping . 10
4.2.1 General . 10
4.2.2 IP-70 . 10
4.2.3 IP-100 . 11
4.3 Network Address Translation . 13
4.4 Network Address Assignment with DHCP and ISI . 13
4.5 Unique Node ID . 14
4.6 Non-unique ID . 14
5 Protocol Modes . 15
6 Packet Format . 15
6.1 CNP/IP-AN Packet Format . 15
6.2 CNP/IP-CN Packet Format . 20
6.2.1 General . 20
6.2.2 CNP/IP-CN Protocol Version 0 Packet Format . 20
6.2.3 CNP/IP-CN Protocol Version 1 Packet Format . 20
6.2.4 CNP/IP-CN Protocol Version 2 Packet Format . 21
7 Domain Configuration . 23
8 Network Management Messages . 23
8.1 General . 23
8.2 Expanded Network Management Messages . 24
8.2.1 General . 24
8.2.2 Query Network Management Command Version and Capabilities (Code 1) . 24
8.2.3 Join OMA Domain (Code 7) . 25
8.2.4 Query OMA Domain (Code 8) . 26
8.2.5 Query OMA Key (Code 9) . 27
8.2.6 Update OMA Key (Code 10). 27
8.2.7 Node NAT Announcement (Code 21). 28
8.2.8 Subnet NAT Announcement (Code 22) . 28
8.2.9 Set NAT Announcement Period (Code 23) . 29
8.2.10 Query NAT Announcement Period (Code 24) . 29
8.2.11 Query IP Address (Code 25) . 30
8.3.1 General . 31
8.3.2 Domain Resource Usage (ISI Code 0) . 31
8.3.3 Extended Domain Resource Usage (ISI Code 1) . 32
2

---------------------- Page: 4 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
8.3.4 Open Enrollment (ISI Code 2) . 33
8.3.5 Extended Open Enrollment (ISI Code 3) . 34
8.3.6 Automatic Enrollment (ISI Code 4) . 36
8.3.7 Extended Automatic Enrollment (ISI Code 5). 37
8.3.8 Automatic Enrollment Reminder (ISI Code 6) . 38
8.3.9 Extended Automatic Enrollment Reminder (ISI Code 7). 39
8.3.10 Domain ID Request (ISI Code 8) . 41
8.3.11 Domain ID Response (ISI Code 9) . 41
8.3.12 Domain ID Confirmation (ISI Code 10) . 42
8.3.13 Enrollment Cancellation (ISI Code 12) . 43
8.3.14 Enrollment Cancellation (ISI Code 12) . 43
8.3.15 Enrollment Confirmation (ISI Code 13) . 44
8.3.16 Enrollment Acceptance (ISI Code 14) . 44
8.3.17 Connection Deletion Request (ISI Code 15) . 45
8.3.18 Connection Status Information (ISI Code 16) . 46
8.3.19 Control Request (ISI Code 17) . 46
8.3.20 Control Response (ISI Code 18) . 47
8.3.21 Connection Table Read Request (ISI Code 19) . 48
8.3.22 Connection Table Read Success (ISI Code 20) . 48
8.3.23 Connection Table Read Failure (ISI Code 21) . 49


3

---------------------- Page: 5 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
European foreword
This document (prEN 14908-7:2018) has been prepared by Technical Committee CEN/TC 247
“Buildings automation, controls and building management”, the secretariat of which is held by SNV.
This document is currently submitted to the CEN Enquiry.
This publication is copyright under the Berne Convention and the Universal Copyright Convention. No
part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or
by means, electronic, mechanical, photocopying, recording, or otherwise, without the permission of the
European Committee for Standardization (CEN), the European Committee for Electrotechnical
Standardization (CENELEC), their National Standards Bodies and their Licensees to reproduce this
European Standard in full and including this copyright notice for the purposes of European
standardization.
CEN draws attention to the fact that it is claimed that compliance with this European Standard may
involve the use of patents. The patents that pertain to this European Standard are listed in Annex F.
CEN/TC 247 confirms that this European Standard contains patents and like rights claiming by Echelon
Corporation. The Echelon Corporation declared to CEN its willingness to negotiate licenses under
patents or rights with applicants throughout the world on reasonable terms and conditions without any
discrimination.
NOTE For licensing information, contact: Echelon Corporation, 2901 Patrick Henry Drive, Santa Clara,
CA 95054, USA, phone +1–408–938–5224, http://www.echelon.com.
This European Standard is part of a series of European Standards for open data transmission in building
automation, control and in building management systems. The content of this standard covers the data
communications used for management, automation/control and field functions. This European
Standard is based on the American standards EIA/CEA-709.1-B Control Network Protocol Specification.
The EN 14908-7 is part of a series of European Standards under the general title Control Network
Protocol (CNP), which comprises the following parts:
— Part 1: Protocol Stack
— Part 2: Twisted Pair Communication
— Part 3: Power Line Channel Specification
— Part 4: IP-Communication
— Part 5: Project Implementation Guideline
— Part 6: Application elements
4

---------------------- Page: 6 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
Introduction
This European Standard has been prepared to provide mechanisms through which various vendors of
building automation, control, and building management systems may exchange information in a
standardized way. It defines communication capabilities.
This European Standard is to be used by all involved in design, manufacture, engineering, installation
and commissioning activities.
This European Standard has been made in response to the essential requirements of the Constructive
Products Directive.
5

---------------------- Page: 7 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
1 Scope
This document specifies a communication protocol for networked control systems. The protocol
provides peer-to-peer communication for networked control using web-services. The document
describes services in layer 2 and layer 3.
The layer 2 (data link layer) specification also describes the MAC sub-layer interface to the physical
layer. The physical layer provides a choice of transmission media. The layer 3 (network layer), as
described in EN 14908-1, is integrated in UDP/IP communication using IPv4 and IPv6 protocols.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 14908-1, Open Data Communication in Building Automation, Controls and Building Management -
Control Network Protocol - Part 1: Protocol Stack
EN 14908-6, Open Data Communication in Building Automation, Controls and Building Management -
Control Network Protocol - Part 6: Application elements
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:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
NOTE For the purposes of this European Standard, the following subclause introduces the basic terminology
employed throughout this European Standard. Most of it is commonly used and the terms have the same meaning
in both the general and the standard context. However, for some terms, there are subtle differences. For example,
in general, bridges do selective forwarding based on the layer 2 destination address. There are no layer 2
addresses in this standard protocol, so bridges forward all packets, as long as the domain address in the packet
matches a domain of which the bridge is a member. Routers, in general, perform network address modification so
that two protocols with the same transport layer but different network layers can be connected to form a single
logical network. Routers of this standard may perform network address modification, but typically they only
examine the network address fields and selectively forward packets based on the network layer address fields,
and in some cases also do network address mapping or translation as described in 4.2 Network Address Mapping
and 4.3 Network Address Translation
3.1
channel
logical link between one or more communication nodes
Note 1 to entry: Usually used interchangeably with a link. However, multiple channels can be multiplexed on a
given link. For example, IP 70, IP 100, and IP 852 can be used to implement three different channels on the same
Ethernet link. Likewise, a single IP 70, IP 100, or IP 852 channel can span multiple native IP links.
3.2
CNP UDP
UDP messages on a CNP/IP channel that are not used for CNP/IP control services
6

---------------------- Page: 8 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
3.3
CNP/IP
control network protocol with control services defined by EN 14908-1 Layers 4 through 7, and
transport services based on the link protocol as defined in this standard
3.4
CNP/IP-AN
CNP/IP on a link that natively supports IP communication including Ethernet and Wi-Fi
Note 1 to entry: The CNP/IP-AN protocol is based on Layers 4 to 7 of the EN 14908-1 Control Network Protocol
on top of UDP and IPv4 or IPv6.
3.5
CNP/IP-CN
CNP/IP on a native CNP link such as a link hosting a TP/FT-10 channel defined by EN 14908-2, a PL-20
channel defined by EN 14908-3, or an IP-852 channel defined by EN 14908-4
3.6
CNP/IP control services
defined by EN 14908-1 Layers 4 through 7, including reliable transport, request/response, multicast,
authentication, and network variables
3.7
CNP/IP internetwork address
internetwork address as defined by IPv4 or IPv6
Note 1 to entry: A CNP/IP device shall have a CNP/IP internetwork address. If the internetwork address can be
mapped from the CNP/IP network address, the internetwork address is a mapped IP address. If not, it is a
translated IP address. The CNP/IP internetwork address may be the same as the host IP address, but it can be
different.
3.8
CNP/IP network address
network address as defined by the EN 14908-1 protocol
Note 1 to entry: All CNP/IP devices in a network domain have an EN 14908-1 network address and use CNP/IP
network addressing to communicate with other CNP/IP devices in the same domain.
3.9
CNP/IP transport services
layer 1 to 3 services for the CNP/IP protocol
Note 1 to entry: The transport services are defined based on the link protocol. For native IP channels such as
Ethernet and Wi-Fi, the transport services are defined by the RFC 768 User Datagram Protocol (UDP) and the
RFC 791/793 IPv4 protocol or RFC 2460 IPv6 protocol, and the CNP/IP protocol is referred to as CNP/IP-AN. For
EN 14908-1 native CNP channels such as the TP/FT 10 channel type defined by EN 14908-2, the layer 2 through 3
transport services are defined by the EN 14908-1 protocol standard and the protocol is referred to as CNP/IP CN.
7

---------------------- Page: 9 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
3.10
configuration
non-volatile information used by the device to customize its operation
Note 1 to entry: There is configuration data for the correct operation of the protocol in each device, and
optionally, for application operation. The network configuration data stored in each device has a checksum
associated with the data. Examples of network configuration data are node addresses, communication media
parameters such as priority settings, etc. Application configuration information is application specific.
3.11
domain
virtual network that is the network unit of management and administration
Note 1 to entry: Group and subnet (see below) addresses are assigned by the administrator responsible for the
domain, and they have meaning only in the context of that domain.
3.12
gateway
interconnects networks at their highest protocol layers (often two different protocols)
Note 1 to entry: Two domains can also be connected through an application gateway.
3.13
group
uniquely identifiable set of nodes within a domain
Note 1 to entry: Within this set, individual members are identified by their member number. Groups facilitate
one-to-many communication and support functional addressing.
3.14
link
physical layer 1 and 2 link
3.15
network variable
data value within a node with a value that is automatically propagated over the network whenever a
new value is assigned to it by the node application
3.16
node
abstraction for a physical communicating device that represents the highest degree of address
resolvability on a network
Note 1 to entry: A node is identified (addressed) within a subnet by its (logical) node identifier. A physical node
may belong to more than one subnet; when it does, it is assigned one (logical) node number for each subnet to
which it belongs. A physical node may belong to at most two subnets; these subnets shall be in different domains.
A node may also be identified (absolutely) within a network by its Unique Node ID (UNID).
8

---------------------- Page: 10 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
3.17
router
device that routes data packets to their respective destinations by selectively forwarding from subnet to
subnet; a router always connects two (sets of) subnets; routers may modify network layer address
fields
Note 1 to entry: Routers may be set to one of four modes: repeater mode, bridge mode, learning mode, and
configured mode. In repeater mode, packets are forwarded if they are received with no errors. In bridge mode,
packets are forwarded if they are received with no errors and match a domain that the router is a member of.
Routers in learning mode learn the topology by examining packet traffic, while routers that are set to configured
mode have the network topology stored in their memory and make their routing decisions solely upon the
contents of their configured tables.
3.18
service request message
network management message containing a node‘s Unique Node ID
Note 1 to entry: Used by a network management device that receives this message to install and configure the
node. May be generated by application or system code, or may be triggered by an external hardware event, e.g.
driving a service request input to a node low.
3.19
Standard Network Variable Types (SNVTs)
variable types with agreed-upon semantics
Note 1 to entry: Variables with these types are interpreted by all applications in the same way, and are the basis
for interoperability. SNVTs are defined in EN 14908-6.
3.20
subnet
set of nodes accessible through the same link layer protocol; a routing abstraction for a channel; in this
standard subnets are limited to a maximum of 127 nodes
3.21
transaction
sequence of messages that are correlated together
Note 1 to entry: For example, a request and the responses to the request are all part of a single transaction. A
transaction succeeds when all the expected messages from every node involved in the transaction are received at
least once. A transaction fails if any of the expected messages within the transaction are not received. Retries of
messages within a transaction are used to increase the probability of success of a transaction in the presence of
transient errors.
4 Addressing
4.1 Overview
A CNP/IP device shall use layer 3 network addresses as defined by EN 14908-1 to communicate with
other CNP/IP and native CNP devices. These network addresses are assigned by network management
tools in managed networks, and are assigned by the devices themselves in self-installed networks.
When communicating with network variables as defined by EN 14908-1, a CNP/IP device shall use layer
6 selectors as defined by EN 14908-1 combined with network addresses to exchange network variable
updates with other CNP/IP and native CNP devices. Network variables enable peer-to-peer data
exchanges between a pair of devices, a group of devices, all devices in a subnet, or all devices in a
network.
9

---------------------- Page: 11 ----------------------
oSIST prEN 14908-7:2018
prEN 14908-7:2018 (E)
A CNP/IP device may have one or more IPv4 or IPv6 CNP/IP internetwork addresses and one or more
IPv4 or IPv6 host IP addresses. If a CNP/IP internetwork address can be mapped to a host IP address as
described in 4.2 Network Address Mapping, it is called a mapped host IP address. If it cannot be mapped,
it is called a translated host IP address. Network address translation is described in 4.3 Network Address
Translation.
A CNP/IP message can be sent to a device with a mapped IP address by specifying the CNP/IP
internetwork address as the destination address. If the host IP address is translated, a CNP/IP message
shall be sent to the translated host IP address, and the IP address shall be translated to the CNP/IP
internetwork address by an intermediate router, making a mapped IP address more efficient than a
translated address. However, a device may be constrained to use a host IP address that cannot be
mapped to a CNP/IP internetwork address. For example a workstation may be installed in an
environment that requires assignment of its address by a DHCP server that is configured to assign IP
addresses in an IP subnet than is not compatible with the CNP/IP internetwork address, and as a result
a translated IP address is required.
4.2 Network Address Mapping
4.2.1 General
A CNP/IP device may have multiple EN 14908-1 layer 3 addresses. There are two types of CNP/IP
layer 3 addresses. They are unicast and multicast addresses. Unicast addresses are used to uniquely
identify an individual CNP/IP device. If a unicast address can be mapped to a host IP address as
described in this section, it is called a mapped IP address. If a unicast address cannot be mapped to a
host IP address, it shall be translated as described in 4.3 Network Address Translation. Multicast
addresses are used to identify a group of CNP/IP devices. Multicast addresses can always be mapped to
IP addresses.
The format of the IP address is channel-type dependent. For CNP/IP-AN IP-70 channels, a standard IPv4
network address format shall be used. For CNP/IP-AN IP-100 channels, a standard IPv6 network
address format shall be used. For CNP/IP-CN and native CNP channels, a standard EN 14908-1 network
address format shall be used. An address can be converted from CNP/IP-AN format to CNP/IP-CN
format and vice versa using a stateless algorithm as described in the next two sections. A CNP/IP-AN to
CNP/IP-CN router shall use this algorithm to route packets between the CNP/IP-AN and CNP/IP-CN
channels, automatically converting the addresses as required. Since the algorithm is stateless, CNP/IP
routers do not require special provisioning or configuration to perform the network address format
conversion. The following sections describe the formats and requirements for unicast and multicast
CNP/IP network addresses.
4.2.2 IP-70
4.2.2.1 In
...