BS EN 14908-4:2014 BSI Standards Publication Open Data Communication in Building Automation, Controls and Building Management — Control Network Protocol Part 4: IP Communication BS EN 14908-4:2014 BRITISH STANDARD National foreword This British Standard is the UK implementation of EN 14908-4:2014 It supersedes BS EN 14908-4:2006 which is withdrawn The UK participation in its preparation was entrusted to Technical Committee RHE/16, Performance requirements for control systems A list of organizations represented on this committee can be obtained on request to its secretary This publication does not purport to include all the necessary provisions of a contract Users are responsible for its correct application © The British Standards Institution 2014 Published by BSI Standards Limited 2014 ISBN 978 580 79427 ICS 35.240.99; 91.140.01; 97.120 Compliance with a British Standard cannot confer immunity from legal obligations This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 May 2014 Amendments issued since publication Date Text affected BS EN 14908-4:2014 EN 14908-4 EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM April 2014 ICS 35.240.99; 91.140.01; 97.120 Supersedes EN 14908-4:2006 English Version Open Data Communication in Building Automation, Controls and Building Management - Control Network Protocol - Part 4: IP Communication Réseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Protocole de contrôle du réseau - Partie 4: Communication par IP Offene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude-Netzwerk-Protokoll Teil 4: Kommunikation mittels Internet Protokoll (IP) This European Standard was approved by CEN on 12 April 2013 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, 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: Avenue Marnix 17, B-1000 Brussels © 2014 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members Ref No EN 14908-4:2014 E BS EN 14908-4:2014 EN 14908-4:2014 (E) Contents Foreword Introduction Scope Normative references 3.1 3.2 Terms, definitions and abbreviations Terms and definitions Abbreviations Requirements 5.1 5.2 5.2.1 5.2.2 CNP/IP device specification IP Related device specifications CNP related device specifications Packet formats Addressing schemes 6.1 6.2 6.2.1 6.2.2 IP channel 10 Specification 10 IP transport mechanisms 12 General 12 Informative considerations 13 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.3 7.3.1 7.3.2 7.3.3 7.3.4 CNP/IP device 13 Configuration of a CNP/IP device 13 Configuration parameters 14 General 14 Channel definition parameters 14 Send List arameters 15 Device parameters 15 Configuration techniques 15 General 15 Manual configuration 16 BOOTP and DHCP 16 Configuration servers 16 8.1 8.2 8.3 8.3.1 8.3.2 8.3.3 8.4 8.4.1 8.4.2 8.4.3 8.4.4 8.5 CNP/IP messages 17 Definition of CNP/IP messages and modes of operation 17 Common message header 17 Packet segmentation 19 Overview 19 Segment exchange 20 Discussion 21 Data packet exchange 22 General 22 Out of order packets 23 Duplicate packet detection 24 Stale packet detection 24 Configuration server interactions 25 BS EN 14908-4:2014 EN 14908-4:2014 (E) 8.5.1 8.5.2 8.5.3 8.5.4 8.5.5 8.5.6 8.5.7 8.6 8.6.1 8.6.2 8.6.3 8.6.4 8.6.5 8.6.6 8.7 8.8 General device interaction 25 General protocol interaction 27 Packet Segmentation 27 Device Registration 28 Channel Membership 30 Send List 31 Channel Routing 32 Miscellaneous Status Messages 34 General 34 CNP/IP Device Status 34 Device Configuration 36 Device Send List 36 Channel Membership List 37 Channel routing information 37 Vendor Specific Messages 37 Authentication of CNP Packets 38 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 Packet formats 39 Packet Types 39 Common CNP/IP Header 40 Segment Packet 42 CNP Data Packets 43 CNP/IP Device Registration/configuration packets 44 Channel Membership Packet 48 Channel Routing Packet 49 Request Packet 52 Acknowledge Packet 54 Send List Packet 55 Node Status/Health/Statistics Response Message 55 Annex A (normative) Specifications for the CNP standard 59 Annex B (informative) Specifications for CNP 61 Bibliography 62 BS EN 14908-4:2014 EN 14908-4:2014 (E) Foreword This document (EN 14908-4:2014) has been prepared by 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 October 2014 and conflicting national standards shall be withdrawn at the latest by October 2014 Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights This document supersedes EN 14908-4:2006 This European Standard is part of a series of standards for open data transmission in building automation, control and in building management systems The content of this European Standard covers the data communications used for management, automation/control and field functions EN 14908-4 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: Implementation Part 6: Application elements 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom BS EN 14908-4:2014 EN 14908-4:2014 (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 standardised way It defines communication capabilities This European Standard will be used by all involved in design, manufacture, engineering, installation and commissioning activities BS EN 14908-4:2014 EN 14908-4:2014 (E) Scope This European Standard specifies the transporting of the Control Network Protocol (CNP) packets for commercial Building Automation, Controls and Building Management over Internet Protocol (IP) networks using a tunnelling mechanism wherein the CNP packets are encapsulated within IP packets It applies to both CNP nodes and CNP routers The purpose of this European Standard is to ensure interoperability between various CNP devices that wish to use IP networks to communicate using the CNP protocol The main body of this European Standard is independent of the CNP protocol being transported over the IP network The reader is directed to Annex A and Annex B for the normative and informative, respectively, aspects of this specification that are specific to EN 14908-1 Figure shows a possible configuration of such CNP devices and networks connected to an IP network Figure — Typical CNP/IP application Figure depicts two types of CNP devices: CNP nodes and CNP routers It should be noted that the routers shown can route packets between typical CNP channels (such as twisted pair or power line) and an IP channel or it can route CNP packets between two IP channels In this European Standard the IP channel will be defined in such a way to allow it to be used like any other CNP channel In the above diagram, the IP network can be considered to be one or more IP channels This European Standard covers only how CNP packets are transported over IP channels It does not cover how CNP packets are routed between standard CNP channels and IP channels This specification is not intended to cover the lower layers (physical, MAC and link layers) of either standard CNP or IP channels Normative references Not applicable BS EN 14908-4:2014 EN 14908-4:2014 (E) Terms, definitions and abbreviations 3.1 Terms and definitions For the purposes of this document, the following terms and definitions apply 3.1.1 tunnelling encapsulation of one protocol’s packet within the payload of another protocol’s packets 3.1.2 channel common communications transport mechanism that a specific collection of CNP devices share and communicate over without the use of a router Note to entry: Channels are used to transport CNP packets below the link layer of the CNP protocol stack Note to entry: Typically this refers to some type of physical media such as power line, RF, or twisted pair, but in the case of IP networks this channel is not physical, but a protocol tunnel 3.1.3 CNP device device that uses the CNP protocol to communicate with other CNP devices Note to entry: Specifically, a CNP/IP device is a CNP device that communicates with other CNP devices over an IP channel 3.1.4 CNP router special type of CNP device that routes CNP protocol packets between two or more channels Note to entry: Specifically, a CNP/IP router is a CNP router in which at least one of the channels it routes packets over is an IP channel 3.1.5 CNP node special type of CNP device that can send or receive CNP protocol packets, but does not route them between channels Note to entry: Specifically a CNP/IP node is a CNP node in which at least one of the channels it sends and receives packets over is an IP channel Note to entry: All CNP devices are either routers, nodes or both 3.1.6 CNP group collection of CNP devices that share a common multicast address 3.1.7 node ID logical network address that differentiates nodes within the same subnet or domain 3.1.8 Must Be Zero (MBZ) reserved field that may be used in the following versions of the protocol BS EN 14908-4:2014 EN 14908-4:2014 (E) Note to entry: Such fields will be sent as zero and ignored by the receiver in implementations conforming to the current version of the specification 3.2 Abbreviations CTP Channel Timeout Period CNP Control Network Protocol LFS Last Forwarded Sequence MBZ Must Be Zero NTP Network Time Protocol PSN Packet Sequence Number SA/DA Source Address / Destination Address SID Session Identifier SNTP Simple Network Time Protocol UDP User Datagram Protocol Requirements The following is a set of general requirements for the transporting of CNP packets over IP channels: — be as efficient as possible to allow quasi real-time operation; — be independent of the application level interface used to receive the packets For example the tunnelling protocol should not rely on the existence of a socket interface or how that interface may be used; — ensure that CNP packet ordering is preserved; — ensure that CNP packets that are “stale” (outside the maximum timeout characteristics of the IP channel) are not forwarded; — detect packets that get duplicated in the IP network; — support IP routing devices that prioritise IP packets; — optional security measures to prevent malicious users from tampering with devices; — scalable; — allow status information to be extracted from CNP/IP devices; — support the exchange of configuration information between CNP/IP devices and configuration servers BS EN 14908-4:2014 EN 14908-4:2014 (E) Table 17 — Channel Routing Packet formats Byte Byte Byte Byte Common packet header with packet type (0x08) | Datetime IP Multi-cast Port IP Unicast Port IP Mc Address IP Unicast Address IP Flags CNP Router Type CNP Flags Node Type Total Unique ID Bytes [U] MBZ Total SubnetNode Bytes [S] Total Domain Bytes [D] Unique Id [0] Unique Id [1] Unique Id [2] Unique Id [3] Unique Id [4] Unique Id [5] Unique Id [6] … [U-1] the following fields are repeated for each node address (CNP node addresses) Subnet Number [0] Node Number [0] Unique Id Index [0] Domain Index [0] Subnet Number [1] Domain Index [1] Subnet Number [S-1] Node Number [1] Unique Id Index [1] Node Number [S-1] Unique Id Index [S-1] Domain Index [S-1] … … The following fields are repeated once for each domain (CNP Domain List) SubnetMsk[0] SubnetMsk[1] SubnetMsk[2] SubnetMsk[3] SubnetMsk[4] SubnetMsk[5] SubnetMsk[6] SubnetMsk[7] … … … … SubnetMsk[28] SubnetMsk[29] SubnetMsk[30] SubnetMsk[31] GroupMsk[0] GroupMsk[1] GroupMsk[2] GroupMsk[3] … … … … GroupMsk[28] GroupMsk[29] GroupMsk[30] GroupMsk[31] Domain Length MBZ Domain[0] Domain[1] Domain[2] Domain[3] Domain[4] Domain[5] NOTE The squared brackets contain the index of a field in an array The following is a description of fields in this packet Datetime See 9.4 for a description of this field IP Multi-cast Port The port number the sending CNP/IP device resides on when listening for multi-cast packets IP Unicast Port 50 BS EN 14908-4:2014 EN 14908-4:2014 (E) The port number the sending CNP/IP device uses when listening for Unicast messages IP Multi-cast Address The multi-cast IP address of the CNP/IP device Zero if not supported The CNP/IP device will listen for incoming multi-cast IP packets on this address IP Unicast Address The unicast IP address of the CNP/IP device in network byte order The CNP/IP device will listen for incoming unicast IP packets on this address IP Flags This indicates the IP functionality supported See 9.5 CNP Router Type This indicates the type of router if the node type is a router See 9.5 CNP Flags CNP flags mask See 9.5 Node Type This indicates the type of the device See 9.5 Total Unique ID Bytes Number of bytes of unique IDs to follow Shall be a multiple of bytes - the size of a Unique ID Zero is allowed Total SubnetNode Bytes Total number of bytes for CNP Subnet Node elements to follow Shall be a multiple of bytes - the size of the Subnet Node element Zero is allowed Total Domain Bytes This indicates the size of domain elements in the message As many domains may be represented as required See 8.3 regarding passing packets longer than 548 bytes Each domain element is 32 + 32 + + = 72 bytes and is of fixed length Unique IDs Unique IDs are packed together, bytes each, expressed in CNP network byte order CNP Node Addresses This is a list of CNP Node addresses, each in a structure The fields are: 1) CNP Subnet Number (byte); 2) CNP Node Number (byte); 51 BS EN 14908-4:2014 EN 14908-4:2014 (E) 3) Index into the domain list to follow (16 bit word); 4) Index into the preceding Unique ID list (16 bit word) Note that each entry in the table shall be unique when all four parts are considered, but that any of the other parts may be duplicated among entries, if any part differs For example, a {Domain, Subnet, Node} may appear more than once, if the Unique ID index differs This shows that this CNP address has more than one Unique ID This is legal, but seldom used Entries with the same Unique ID index but differing D, S, N parts indicates multiple {Domain, Subnet, Node} addresses for the same Unique ID This is common CNP Domain list The list of domains follows Each domain is represented by a Subnet Mask, a Group Mask and a Domain Identifier The number of domains is indicated by the Total Domain Bytes field divided by the size of the domain structure (72 bytes) of the message There can be any number of domains in the message, subject to the size constraints of the packet See 8.3 regarding the segmentation of long messages Each domain is expressed in a fixed length structure of 72 bytes SubnetMsk (CNP Subnet Mask) The SubnetMsk array is an array of 256 bits [32 bytes] each corresponding to a CNP subnet If the bit is set in the array, the router forwards packets from the IP channel across itself to that subnet GroupMsk (CNP Group Mask) The GroupMsk array is an array of 256 bits each corresponding to a CNP group address If a bit is set in the array, the router forwards packets from the IP channel across itself to that group Domain Length (CNP Domain Length) Domain length is one of 0, 1, 3, or and corresponds to the length of the CNP domain identifier in bytes Domain (CNP Domain Identifier) The CNP Domain identifier is an array of bytes expressed in CNP network byte order If the domain length is less than bytes, the unused domain bytes following the identifier are padded to bytes with zero bytes 9.8 Request Packet Table 18 details the format of the Configuration Request Packet The Packet Type value in the Common Packet Header varies depending on which data structure is being requested 52 BS EN 14908-4:2014 EN 14908-4:2014 (E) Table 18 — Configuration Request Packet format Byte Byte Byte Byte Common Packet Header Datetime Reason Request ID Segment ID Since Datetime IP Unicast Address Datetime See 9.4 for a description of this field Flags Bits 1, 0: Reason The reason code modifies the request as shown in Table 19 Table 19 — Request Reason codes Reason Code Description Code REQUEST_NORMAL Normal Request 0x00 Data sent if newer or date is zero REQUEST_VERIFY Requested to verify data 0x01 Data always sent Bit 2: Request All The reason code modifies the request as shown in Table 20 Table 20 — Request Amount codes Reason Code Description Code REQUEST_ONE Request one segment if more than one segment is required 0x00 REQUEST_ALL Request all segments be sent immediately 0x01 Bit 3: Request and delete The reason code modifies the request as shown in Table 21 Table 21 — Request Action codes Reason Code Description Code REQUEST_COPY Copy the statistics 0x00 REQUEST_MOVE Copy and clear the statistics 0x01 Bits to 7: Reserved for future use 53 BS EN 14908-4:2014 EN 14908-4:2014 (E) Request ID A tag value applied by the source of this request so that it may uniquely distinguish the response to this request See 8.3 Segment ID Used in requesting information that may involve more than one response packet See 8.3.2 Since DateTime See 9.4 for a description of this field Indicates to the receiver to send the data if the data available is newer than this datetime Zero indicates to Always send the data requested IP Unicast Address Used only for Channel Routing Request messages MBZ otherwise Indicates that only the Channel Routing for this particular device is to be sent Zero indicates all channel routing information is to be sent (This option is only valid when TCP is used to communicate with the Configuration Server.) 9.9 Acknowledge Packet These messages are used by CNP/IP devices in response to messages received from other devices The acknowledge message has the format shown in Table 22 See 8.5.3.2 regarding use of ACKs over TCP connections Table 22 — Acknowledge Packet formats Byte Byte Byte Byte Common Packet Header with Packet Type Datetime Ack Type Request ID Segment ID The following is a description of fields in this packet Datetime See 9.4 for a description of this field Ack Type This parameter is used by CNP/IP devices to make further requests on the server Valid values include: — ACK_OK (0); — ACK_FIXED (1); — ACK_BAD_MESSAGE (2); — ACK_CANT_COMPLY (3); — ACK_DEVICE_REFUSED (4); — ACK_not_SUPPORTED (5); 54 BS EN 14908-4:2014 EN 14908-4:2014 (E) Request ID A tag value returned from request so that it may uniquely distinguish the response to this request See 8.3 Zero if none applies Segment ID Returned from the request to allow correlation in the requestor See 8.3 Zero if none applies 9.10 Send List Packet This message is sent by a Configuration Server on request of a device to obtain the send list in CNP/IP devices The Send List packet has the format shown in Table 23 Table 23 — Send List Packet format Byte Byte Byte Byte Common Packet Header Datetime Number IP Address Port Pairs MBZ MBZ The following fields are repeated once for each address/port pair IP Address IP Port MBZ The following is a description of fields in this packet Datetime See 9.4 Number IP Address Port Pairs The number of IP address / port pairs the CNP/IP device has in the send list Zero is allowed Both multicast and unicast addresses are represented here IP Address The IP address of a CNP/IP device or a multi-cast address The CNP/IP device will send packets to this address IP Port The port number the CNP/IP device uses when sending packets 9.11 Node Status/Health/Statistics Response Message The Status packet has the format shown in Table 24 55 BS EN 14908-4:2014 EN 14908-4:2014 (E) Table 24 — Node Status/Health/Statistics Response Message Byte Byte Byte Byte Common Packet Header 1) Time since last Counter Reset 2) Time of last Counter Reset In GMT 3) Number of members on the channel 4) Number of members on the channel to which messages were sent in the recent past 5) CNP packets received 6) CNP packets received but discarded due to selective forwarding 7) CNP total bytes received 8) CNP packets sent 9) CNP total bytes sent 10) CNP packets sent onto IP channel 11) CNP bytes sent onto IP channel 12) CNP packets received from IP channel 13) CNP bytes received from IP channel 14) IP packets containing LT packets onto IP network 15) IP packets containing LT packets from IP network 16) Average aggregation onto IP channel 17) Average aggregation from IP channel 18) Number of UDP packets sent 19) Number of TCP packets sent 20) Number of Multi-cast packets sent 21) Stale LT packets from IP dropped 22) Count of TCP Connection failures 23) Number of different hosts experiencing TCP Connection failures 24) Number of router configuration messages sent 25) Number of router configuration messages received 26) Number of configuration changes 27) Running average number of UDP packets/second sent 28) Running average number of UDP packets/second received 29) Running average number of TCP packets/second sent 30) Running average number of TCP packets/second received 1) Time since last Counter Reset (format 32 bit unsigned integer number of seconds) 2) Time of last Counter Reset In GMT (format datetime See 9.4.) 56 BS EN 14908-4:2014 EN 14908-4:2014 (E) 3) Number of members on the channel (format: 32 bit unsigned integer) 4) Number of members on the channel to which messages were sent in the recent past (Method of measurement is left undefined.) (format: 32 bit unsigned integer) 5) CNP packets received (Packets received from CNP channel.) (format: 32 bit unsigned integer) 6) CNP packets received but discarded due to selective forwarding (format: 32 bit unsigned integer) 7) CNP total bytes received (format: 32 bit unsigned integer) 8) CNP packets sent (Packets sent onto CNP channel.) (format: 32 bit unsigned integer) 9) CNP total bytes sent (format: 32 bit unsigned integer) 10) CNP packets sent onto IP channel (format: 32 bit unsigned integer) 11) CNP bytes sent onto IP channel (format: 32 bit unsigned integer) 12) CNP packets received from IP channel (format: 32 bit unsigned integer) 13) CNP bytes received from IP channel (format: 32 bit unsigned integer number) 14) IP packets containing LT packets onto IP network (format: 32 bit unsigned integer number) 15) IP packets containing LT packets from IP network (format: 32 bit unsigned integer number) 16) Average aggregation onto IP channel (Value is expressed as a pair of 32 bit unsigned integers Total LT packets / Total IP packets ) 17) Average aggregation from IP channel (Value is expressed as a pair of 32 bit unsigned integers Total LT packets / Total IP packets .) 18) Number of UDP packets sent (format: 32 bit unsigned integer) 19) Number of TCP packets sent (format: 32 bit unsigned integer) 20) Number of Multi-cast packets sent (format: 32 bit unsigned integer) 21) Stale LT packets from IP dropped (Stale means that the have been too long in the IP network.) (format: 32 bit unsigned integer) 22) Count of TCP Connection failures (format: 32 bit unsigned integer) 23) Number of different hosts experiencing TCP Connection failures (format: 32 bit unsigned integer) 24) Number of router configuration messages sent (format: 32 bit unsigned integer) 25) Number of router configuration messages received (format: 32 bit unsigned integer) 26) Number of configuration changes (format: 32 bit integer) 27) Running average number of UDP packets/second sent (format: 32 bit integer) 57 BS EN 14908-4:2014 EN 14908-4:2014 (E) 28) Running average number of UDP packets/second received (format: 32 bit integer) 29) Running average number of TCP packets/second sent (format: 32 bit integer) 30) Running average number of TCP packets/second received (format: 32 bit integer) 58 BS EN 14908-4:2014 EN 14908-4:2014 (E) Annex A (normative) Specifications for the CNP standard The format of the packets encapsulated by the IP tunnel include the L2Hdr field through the CRC field inclusively It does not include Preamble, BitSync or ByteSync fields or the Line Code Violation bits A specification for these packets can be found in EN 14809-1 The following addressing schemes as referenced in this specification are supported as defined in RFC 2131: — Unique device ID - Neuron ID; — Domain ID – Domain ID; — Subnet ID – Subnet ID; — Node ID – Node ID; — Group ID – Group ID The following is a selection of Synchronisation Considerations when using CNP: CNP is a communications protocol designed for real time control of devices As such, the expectation is that messages are delivered within a bounded amount of time (according to the application requirements) and with minimal time jitter around that bounded time As part of the error detection/recovery of the protocol, there is a duplicate message detection feature so that messages are only acted upon once, regardless of the number of messages received within the single messaging transaction Duplicate detection in CNP is an algorithm that runs on both the sender and receiver side The algorithm is fully described in that standard, but a high-level view of it is presented here to help explain the issue of time synchronisation When the sender composes a message, it looks at its configuration to determine the protocol service If the protocol service specifies duplicate detection, the sender allocates a transaction number that has not been recently used when communicating to the receiver’s address by this sender Then, the message is sent with that transaction number in it The sender also starts a timer, called the transaction timer that upon expiration of that timer, a retry of the message will occur unless either the configured retry count has been exhausted, or a response has been received Upon receipt of the message, the receiver looks to see if there is an existing transaction for that message, if so, the message is a duplicate and is responded to but not acted upon If not, a new transaction is allocated with a receive timer set When the receive timer expires, the transaction is deleted Once the transaction is deleted, any new message with the same transaction number as was in the deleted transaction will be considered as a new message IP networks were not designed with real time control in mind To support realtime sensitive applications such as voice over IP, the IP protocol has been extended with the QOS (quality of service) bits in the frame header Unfortunately, the meaning of the bits is not standardised and not all routers act upon the bits appropriately At this writing, one cannot reliably set the QOS bits in a packet and send that packet out over the public internet and get low latency, low time jitter service end to end 59 BS EN 14908-4:2014 EN 14908-4:2014 (E) If CNP packets are tunnelled over an IP network that imposes random time delay over some of the packets, CNP protocol failures will occur due to the delivery of stale packets being interpreted by the receiver as new packets rather than as duplicates These failures can be serious to the underlying application To prevent these protocol failures, the option of time synchronisation of all the CNP/IP nodes is possible according to the instructions in this document To determine how accurate the synchronisation has to be, one shall examine the CNP protocol timers in use across the IP segment that may provide random delay Table B.3 of CNP has the entire set of timer values for a CNP network The maximum jitter allowed is calculated by the following equation: (in use receive transaction timer value – (retries × transaction timer value)) Where all the pairs of nodes are examined that communicate across the IP channel are examined and the minimum jitter time that can be tolerated is determined by the setting of their configuration timers From this, one can determine how accurate time has to be across all the nodes in the network Performing this calculation requires knowledge of the configuration of all the CNP nodes that communicate across the jitter prone IP channel This implies some sort of network database with all the configuration information within it In absence of this information one can follow another approach to prevent the problem of stale packet detection If there is a time server on each LAN segment connected to the internet that gets atomic time from a satellite or radio source and serves it to the nodes on the LAN, each LAN segment can have a very precise view of time making this problem of undetected stale packets a non-issue 60 (1) BS EN 14908-4:2014 EN 14908-4:2014 (E) Annex B (informative) Specifications for CNP The CNP/IP device should use one of following port numbers, which have been assigned by the IANA: — 1628/tcp — 1628/udp — 1629/tcp — 1629/udp 61 BS EN 14908-4:2014 EN 14908-4:2014 (E) Bibliography [1] EN 14908-1:2014, Open Data Communication in Building Automation, Controls and Building Management — Control Network Protocol (CNP) — Part 1: Protocol Stack [2] ISO/IEC 9594 series, Information technology Open Systems Interconnection [3] RFC 768, Postel, J., “User Datagram Protocol”, STD 6, USC Information Sciences Institute, August 1980 [4] RFC 791, Postel, J., “Internet Protocol”, STD 5, USC Information Sciences Institute, Spetember 1981 [5] RFC 793, Postel, J., “Transmission Control Protocol”, STD 7, USC Information Sciences Institute, September 1981 [6] RFC 951, Croft, W.J., Gilmore, J., “Bootstrap Protocol” September 1985 [7] RFC 1112, Deering, S.E., “Host extensions for IP multi-casting”, STD 5, Stanford University, August 1989 [8] RFC 1305, Mills, D., “Network Time Protocol (Version 3) specification, implementation and analysis”, University of Delaware, March 1992 [9] RFC 1321, Rivest, R “The MD5 Message-Digest Algorithm”, April 1992 [10] RFC 2131, Droms, R., “Dynamic Host Configuration Protocol”, Bucknell University, March 1997 [11] RFC 2030, Mills, D., “Simple Network Time Protocol (SNTP) Version for IPv4, IPv6 and OSI”, University of Delaware, October 1996 [12] EIA/CEA-852, Tunnelling Component Network Protocols Over Internet Protocol Channels 62 This page deliberately left blank NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW British Standards Institution (BSI) BSI is the national body responsible for preparing British Standards and other standards-related publications, information and services BSI is incorporated by Royal Charter British Standards and other standardization products are published by BSI Standards Limited About us Revisions We bring together business, industry, government, consumers, innovators and others to shape their combined experience and expertise into standards -based solutions Our British Standards and other publications are updated by amendment or revision The knowledge embodied in our standards has been carefully assembled in a dependable format and refined through our open consultation process Organizations of all sizes and across all sectors choose standards to help them achieve their goals Information on standards We can provide you with the knowledge that your organization needs to succeed Find out more about British Standards by visiting our website at bsigroup.com/standards or contacting our Customer Services team or Knowledge Centre Buying standards You can buy and download PDF versions of BSI publications, including British and adopted European and international standards, through our website at bsigroup.com/shop, where hard copies can also be purchased If you need international and foreign standards from other Standards Development Organizations, hard copies can be ordered from our Customer Services team Subscriptions Our range of subscription services are designed to make using standards easier for you For further information on our subscription products go to bsigroup.com/subscriptions With British Standards Online (BSOL) you’ll have instant access to over 55,000 British and adopted European and international standards from your desktop It’s available 24/7 and is refreshed daily so you’ll always be up to date You can keep in touch with standards developments and receive substantial discounts on the purchase price of standards, both in single copy and subscription format, by becoming a BSI Subscribing Member PLUS is an updating service exclusive to BSI Subscribing Members You will automatically receive the latest hard copy of your standards when they’re revised or replaced To find out more about becoming a BSI Subscribing Member and the benefits of membership, please visit bsigroup.com/shop With a Multi-User Network Licence (MUNL) you are able to host standards publications on your intranet Licences can cover as few or as many users as you wish With updates supplied as soon as they’re available, you can be sure your documentation is current For further information, email bsmusales@bsigroup.com BSI Group Headquarters 389 Chiswick High Road London W4 4AL UK We continually improve the quality of our products and services to benefit your business If you find an inaccuracy or ambiguity within a British Standard or other BSI publication please inform the Knowledge Centre Copyright All the data, software and documentation set out in all British Standards and other BSI publications are the property of and copyrighted by BSI, or some person or entity that owns copyright in the information used (such as the international standardization bodies) and has formally licensed such information to BSI for commercial publication and use Except as permitted under the Copyright, Designs and Patents Act 1988 no extract may be reproduced, stored in a retrieval system or transmitted in any form or by any means – electronic, photocopying, recording or otherwise – without prior written permission from BSI Details and advice can be obtained from the Copyright & Licensing Department Useful Contacts: Customer Services Tel: +44 845 086 9001 Email (orders): orders@bsigroup.com Email (enquiries): cservices@bsigroup.com Subscriptions Tel: +44 845 086 9001 Email: subscriptions@bsigroup.com Knowledge Centre Tel: +44 20 8996 7004 Email: knowledgecentre@bsigroup.com Copyright & Licensing Tel: +44 20 8996 7070 Email: copyright@bsigroup.com