BS EN 14908-4:2014 EN 14908-4:2014 (E)
-
Table 24 — Node Status/Health/Statistics Response Message
Byte 0 Byte 1 Byte 2 Byte 3
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.).
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 <10> / Total IP packets <14>).
17) Average aggregation from IP channel. (Value is expressed as a pair of 32 bit unsigned integers.
Total LT packets <12> / Total IP packets <15>.) <<Since all these parameters are optional, duplicate data forms is not necessarily a problem. One might elect not to support 12, 15, but might support 17 instead. >>.
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).
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).
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.
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:
min (in use receive transaction timer value – (retries × transaction timer value)) (1) 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.
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
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 4 for IPv4, IPv6 and OSI”,
University of Delaware, October 1996
[12] EIA/CEA-852, Tunnelling Component Network Protocols Over Internet Protocol Channels BS EN 14908-4:2014
EN 14908-4:2014 (E)