CLC/TS 50136-9:2013
(Main)Alarm systems - Alarm transmission systems and equipment - Part 9: Requirements for common protocol for alarm transmission using the Internet protocol
Alarm systems - Alarm transmission systems and equipment - Part 9: Requirements for common protocol for alarm transmission using the Internet protocol
This Technical Specification specifies a protocol for point-to-point transmission of alarms and faults, as well as communications monitoring, between a Supervised Premises Transceiver and a Receiving Centre Transceiver using the Internet protocol (IP). The protocol is intended for use over any network that supports the transmission of IP data. These include Ethernet, xDSL, GPRS, WiFi, UMTS and WIMAX. The system performance characteristics for alarm transmission are specified in EN 50136-1 and EN 50136-1-5. The performance characteristics of the supervised premises equipment should comply with the requirements of its associated alarm system standard and shall apply for transmission of all types of alarms including, but not limited to, fire, intrusion, access control and social alarms. Compliance with this Technical Specification is voluntary.
Alarmanlagen - Alarmübertragungsanlagen und –einrichtungen - Teil 9: Anforderungen an standardisierte Protokolle zur Alarmübertragung unter Nutzung des Internetprotokolls
Systèmes d’alarmes - Systèmes et équipements de transmission d’alarme - Partie 9 : Exigences pour le protocole commun de transmission d’alarme utilisant le protocole Internet
Alarmni sistemi - Sistemi in oprema za prenos alarma - 1-7. del: Zahteve za skupni protokol za prenos alarma po paketno komutiranem omrežju
Ta tehnična specifikacija opredeljuje protokol za prenos alarmov in okvar od točke do točke, kot tudi nadzor komunikacije, med oddajno-sprejemno napravo v nadzorovanih prostorih in oddajno-sprejemno napravo v sprejemnem središču z uporabo internetnega protokola (IP). Protokol je namenjen za uporabo prek katerega koli omrežja, ki podpira prenos podatkov internetnega protokola. To vključuje ethernet, xDSL, GPRS, WiFi, UMTS in WIMAX. Lastnosti delovanja sistema za prenos alarma so navedene v standardu EN 50136-1. Lastnosti delovanja opreme na varovanem območju morajo izpolnjevati vse zahteve standardov povezanih alarmnih sistemov in veljajo za prenos vseh vrst alarmov, vključno s, a ne omejeno na, požarnimi in vlomnimi alarmi, alarmi za nadzor dostopa in družbenimi alarmi. Skladnost s to tehnično specifikacijo je izbirna.
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-junij-2014
Alarmni sistemi - Sistemi in oprema za prenos alarma - 1-7. del: Zahteve za skupni
protokol za prenos alarma po paketno komutiranem omrežju
Alarm systems - Alarm transmission systems and equipment - Part 1-7: Requirements
for common protocol for alarm transmission using packet switched network
Alarmanlagen - Alarmübertragungsanlagen und -einrichtungen - Teil 1-7: Anforderungen
an standardisierte Protokolle zur Alarmübertragung in Paketvermittlungsnetzwerken
Systèmes d'alarme - Systèmes et équipements de transmission d'alarme - Partie 1-7:
Exigences pour le protocole commun de transmission d'alarme utilisant les réseaux à
commutation de paquets
Ta slovenski standard je istoveten z: CLC/TS 50136-9:2013
ICS:
13.320 Alarmni in opozorilni sistemi Alarm and warning systems
33.040.40 Podatkovna komunikacijska Data communication
omrežja networks
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
TECHNICAL SPECIFICATION
CLC/TS 50136-9
SPÉCIFICATION TECHNIQUE
January 2013
TECHNISCHE SPEZIFIKATION
ICS 13.320; 33.040.40
English version
Alarm systems -
Alarm transmission systems and equipment -
Part 9: Requirements for common protocol for alarm transmission using
the Internet protocol
Systèmes d’alarmes - Alarmanlagen -
Systèmes et équipements de transmission Alarmübertragungsanlagen und –
d’alarme - einrichtungen -
Partie 9 : Exigences pour le protocole Teil 9: Anforderungen an standardisierte
commun de transmission d’alarme Protokolle zur Alarmübertragung unter
utilisant le protocole Internet Nutzung des Internetprotokolls
This Technical Specification was approved by CENELEC on 2012-11-12.
CENELEC members are required to announce the existence of this TS in the same way as for an EN and to
make the TS available promptly at national level in an appropriate form. It is permissible to keep conflicting
national standards in force.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus,
the Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
Management Centre: Avenue Marnix 17, B - 1000 Brussels
© 2013 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. CLC/TS 50136-9:2013 E
Contents
Foreword . 4
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 5
3.1 Terms and definitions . 5
3.2 Abbreviations . 5
4 Objective . 6
5 Messaging . 6
5.1 General . 6
5.2 Message format overview . 7
5.3 Padding and message length .11
5.4 Hashing .12
5.5 Encryption .12
5.6 Timeouts and retries .13
5.7 Version number .13
5.8 Reverse commands .13
5.9 Initial values .14
6 Message types .14
6.1 General .14
6.2 Path supervision .14
6.3 Event reporting .15
6.4 Configuration messages .19
7 Commissioning and connection setup .27
7.1 Commissioning .27
7.2 Connection setup .31
Annex A (normative) Result codes .32
Annex B (normative) Protocol Identifiers .33
Annex C (normative) Shared secret .34
C.1 Formatting of the shared secret.34
C.2 Checksum for Shared Secret Formatting .34
C.3 Example of Secret Encoding and Formatting .34
Annex D (informative) Examples of messaging sequences .35
D.1 Commissioning .35
D.2 Connection setup .38
Annex E (informative) Examples of application protocols .41
E.1 SIA .41
E.2 Ademco Contact ID .41
E.3 Scancom Fast Format .42
E.4 VdS 2465 .42
Annex F (informative) Design principles .44
F.1 General .44
F.2 Information Security .44
F.3 Use of UDP signalling .44
Bibliography .45
- 3 - CLC/TS 50136-9:2013
Table 1 – Identifiers . 7
Table 2– Basic unencrypted format of messages . 7
Table 3 – Basic encrypted format of messages . 8
Table 4 – Message ID overview . 10
Table 5 – Flags . 11
Table 6 – Hashing ID’s . 12
Table 7 – Encryption ID’s . 12
Table 8 – Reverse commands . 14
Table 9 – Initial values . 14
Table 10 – Poll message SPT RCT . 15
Table 11 – Poll response RCT SPT . 15
Table 12 – Event message format – SPT RCT . 16
Table 13 – Event message format – Fields . 16
Table 14 – Event field . 16
Table 15 – Time event field . 17
Table 16 – Time message field. 17
Table 17 – Link field – IP Address . 17
Table 18 – Link field – IP Port number . 18
Table 19 – Link field – URL . 18
Table 20 – Link field – Filename . 18
Table 21 – Event response message format . 18
Table 22 – Connection handle request message format . 19
Table 23 – Connection handle response message format . 20
Table 24 – Device ID request message format. 20
Table 25 – Device ID request flags . 20
Table 26 – Device ID response message format . 21
Table 27 – Encryption selection request message format . 21
Table 28 – ‘Master Encryption Selection request’ flag . 21
Table 29 – Encryption selection response message format . 22
Table 30 – Encryption key exchange request message format . 22
Table 31 – ‘Master Key request’ flag . 22
Table 32 – Encryption key exchange response message format . 23
Table 33 – Hash selection request message format . 23
Table 34 – Hash selection response message format . 23
Table 35 – Path supervision request message format . 24
Table 36 – Path supervision response message format . 24
Table 37 – Set time command message format . 24
Table 38 – Set time response message format . 25
Table 39 – Protocol version request message format . 25
Table 40 – Protocol version response message format . 25
Table 41 – Transparent message format . 25
Table 42 – Transparent response format . 26
Table 43 – DTLS completed request message format . 26
Table 44 – DTLS completed response message format . 26
Table 45 – RCT IP parameter request message format . 27
Table 46 – RCT IP parameter response message format . 27
Table 47 – Message flow during the commissioning of a new SPT . 28
Table 48 – Message flow during connection setup . 31
Table A.1 – Result codes . 32
Table B.1 – Protocol identifiers . 33
Foreword
This document (CLC/TS 50136-9:2013) has been prepared by CLC/TC 79 "Alarm systems".
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such
patent rights.
- 5 - CLC/TS 50136-9:2013
1 Scope
This Technical Specification specifies a protocol for point-to-point transmission of alarms and faults, as
well as communications monitoring, between a Supervised Premises Transceiver and a Receiving
Centre Transceiver using the Internet protocol (IP).
The protocol is intended for use over any network that supports the transmission of IP data. These
include Ethernet, xDSL, GPRS, WiFi, UMTS and WIMAX.
The system performance characteristics for alarm transmission are specified in EN 50136-1.
The performance characteristics of the supervised premises equipment should comply with the
requirements of its associated alarm system standard and shall apply for transmission of all types of
alarms including, but not limited to, fire, intrusion, access control and social alarms.
Compliance with this Technical Specification is voluntary.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
EN 50136-1:2012, Alarm systems — Alarm transmission systems and equipment — Part 1: General
requirements for alarm transmission systems
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 50136-1:2012 apply.
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
AES Advanced Encryption Standard
ARC Alarm Receiving Centre
ATS Alarm Transmission System
CA X.509 Certificate Authority
CBC Cipher Block Chaining
CRC Cyclic redundancy check
DNS Domain Name System
DTLS Datagram Transport Layer Security
HL Header Length
IP Internet Protocol
IV Initialization Vector
MAC Media Access Control
MTU Maximum Transmission Unit
NAT Network Address Translation
NIST National Institute of Standards and Technology
NTP Network Time Protocol
NVM Non-Volatile Memory
P-MTU Path Maximum Transmission Unit
RCT Receiver Centre Tranceiver
RX Receive
SCTP Stream Control Transmission Protocol
SNTP Simple Network Time Protocol
SPT Supervised Premises Transceiver
TFTP Trivial File Transfer Protocol
TX Transmit
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTC Coordinated Universal Time
WS Window Size
4 Objective
The object of this Technical Specification is to specify the protocol details (transport and application
layers) for alarm transmission systems using Internet Protocol (IP), to ensure interoperability between
SPTs and RCTs supplied by different manufacturers. Mechanisms to commission SPT and RCT and
build mutual trust between the communicating parties are also described.
As compliance with this Technical Specification is voluntary, any other alarm transmission protocol or
equipment not covered by this Technical Specification may be used, provided that the requirements of
EN 50136-1 are met.
This protocol is designed to run on top of UDP and is designed to support both IPv4 and IPv6.
NOTE For further discussion of IP and UDP in alarm transmission please see F.3.
5 Messaging
5.1 General
This clause defines the messaging layer, on top of which the alarm event data is transmitted using the
existing reporting formats like for example Sia and Contact ID. Clause 7 defines the initial
commissioning of an SPT, as well as how SPTs connect to the RCT.
The functionality of the alarm messaging and polling protocol includes:
– exchanging master and session parameters;
– (alarm) event reporting (including linking to out-of-band additional data related to events, like
audio/video);
– line monitoring;
– transparent message transmission, e.g. vendor specific messages that, for example, can be used
for remote commands from RCT to SPT.
It fulfils the following requirements:
– encryption, fulfilling requirements for most demanding category of EN 50136-1;
– authentication, fulfilling requirements for most demanding category of EN 50136-1;
– SPT: allows a broad range of hardware (limited demands on memory footprint as well as CPU
power);
- 7 - CLC/TS 50136-9:2013
– RCT: allows support for at least 10 000 SPTs in compliance with any category in EN 50136-1,
using modern general purpose server hardware;
– allow Dynamic IP addresses of the SPTs;
– allow one or more SPTs to be placed behind a NAT firewall.
5.2 Message format overview
5.2.1 General
This subclause describes the basic outline of all messages.
Each message shall be explicitly acknowledged, including line supervision messages.
Backwards compatibility is achieved by the implementation of the RESP_CMD_NOT_SUPPORTED
result value, which the receiving party can send as answer to unsupported messages.
Multi-byte values will be transmitted using network byte order (big-endian).
5.2.2 Identifiers
The following identifiers exist:
Table 1 – Identifiers
Description Purpose Present in Encrypted See
Look up the current symmetric All messages No 5.2.4
Connection Handle
encryption key
Contributing to N / A 5.2.5
Device ID Uniquely identify the hardware hashes in all
messages
The Connection Handle is unencrypted. It is a unique number, initialized during the setup of the
connection. Its sole purpose is to be able to look up the encryption key. It is valid for the
communication session only.
The Device ID uniquely identifies the hardware once the connection has been established. The Device
ID is used when computing the hash value for each message. In combination with the encryption of
the hash this is used for substitution detection.
NOTE Device ID is not equivalent to any account code or similar ID specified by application protocol
The Device ID shall be stored in non-volatile memory within the SPT.
The IP address is not used for identification purposes, in order to allow for the use of dynamic or
translated IP addresses.
5.2.3 Message format
The basic unencrypted format of all messages is as follows. Message in this format is never
transmitted. It is described here only to clarify the hash value calculation.
Table 2– Basic unencrypted format of messages
Byte Index Bytes Description See Group
0 4 Connection Handle 5.2.4 Header
4 16 Device ID 5.2.5
20 2 Tx Sequence number 5.2.8
22 2 Rx Sequence number 5.2.8
24 2 Flags 5.2.9
26 1 Protocol version number 5.7
Byte Index Bytes Description See Group
Message
27 1 Message ID 5.2.6
28 2 Message Length 5.2.7
30 n Message Data Clause 6
The basic encrypted, transmitted format of all messages is as follows. Note that the Device ID field is
not included in the encrypted message, but its value is used to compute the message hash value i.e.
the hash is calculated from the unencrypted version of the message described above.
Table 3 – Basic encrypted format of messages
Byte Index Bytes Description See Encrypted Group
0 4 Connection Handle 5.2.4 No Header
4 2 Tx Sequence number 5.2.8 Yes
6 2 Rx Sequence number 5.2.8 Yes
8 2 Flags 5.2.9 Yes
10 1 Protocol version number 5.7 Yes
11 1 Message ID 5.2.6 Yes Message
12 2 Message Length 5.2.7 Yes
14 n Message Data Clause 6 Yes
14 + n Padding 5.3.1 Yes Tail
32 Hash – SHA-256, or 5.4 Yes
32 Hash – RIPEMD-256
The Connection Handle is unencrypted; the remainder of the message is encrypted using the
encryption method as negotiated during the commissioning stage.
Message ID’s are defined in pairs: each message has its matching response. For responses the first
byte of the Message Data always holds a ‘Result code’ as defined in Annex A.
All fields are described in detail in the following subclauses.
5.2.4 Connection Handle
The Connection Handle is assigned (uniquely for the RCT to which a SPT reports) using the
commissioning protocol. The RCT creates a unique Connection Handle and links this to the Device ID
of the SPT in its internal database. This translation results in a compact, fixed length Connection
Handle.
The purpose of the Connection Handle is to be able to determine the encryption key to be used to
decrypt the received message, independent of the IP address of the message.
The Connection Handle is not a (by the installer/operator) configurable parameter, nor made visible on
user interfaces. It is generated and used internally by the SPT/RCT equipment only.
5.2.5 Device ID
5.2.5.1 General
The Device ID uniquely identifies the SPT and RCT. It is used (in combination with the encryption) for
substitution detection. Both SPT and RCT can verify the identity of the connected party using this field,
and create a substitution alarm in case it has changed.
Within the message header, the Device ID itself is never transmitted. However Device ID is used to
contribute to the message hash calculation
- 9 - CLC/TS 50136-9:2013
Device ID is 16 bytes long.
5.2.5.2 SPT Device ID
The Device ID of the SPT is an ID that is random to the SPT, but fixed and read-only over the lifetime
of the SPT, i.e. A hardware serial number. It is unique within the SPT database in the RCT.
The Device ID is created during manufacturing time of the device; in messaging, it is never transmitted
itself in cleartext, but is needed to be known in cleartext for the ARC to configure the RCT accordingly.
Thus, it is only transmitted during initial commissioning phase to the RCT.
Uniqueness is assured by the following principles:
– Each SPT manufacturer shall use his 24 bits “Organizationally Unique Identifier” as assigned to
him by the IEEE for MAC-address generation
– Each SPT manufacturer not having such a code shall attend for such a code from IEEE.
– If an interface in the SPT makes use of a MAC address, the next 24 bits in the device ID shall be
the same as the rest of MAC address specified by the manufacturer. If such interface does not
exist, the manufacturer shall use another numbering scheme documented by the manufacturer.
– The manufacturer shall use non-consecutive, randomly distributed numbers for the rest of the
device ID field and guarantee uniqueness for all his delivered SPT devices.
5.2.5.3 RCT Device ID
The Device ID of the RCT is an ID that is unique within the receiver and never changed within the
lifetime of a receiver. It represents the unique identity of the RCT.
The RCT device ID is made available to the SPT during the commissioning phase.
5.2.6 Message ID
The Message ID’s as used are listed in the following table:
Table 4 – Message ID overview
Direction Version Message ID
Message name Description
SPT RCT
POLL_MSG Poll message 1 0x11
EVENT_MSG Event message 1 0x30
CONN_HANDLE_REQ Connection handle request 1 0x40
DEVICE_ID_REQ Device ID request 1 0x41
ENCRYPT_SELECT_REQ Encryption selection request 1 0x42
ENCRYPT_KEY_REQ Encryption key exchange 1 0x43
HASH_SELECT_REQ Hash selection request 1 0x44
PATH_SUPERVISION_REQ Path supervision request 1 0x45
SET_TIME_CMD Set time command 1 0x47
VERSION_REQ Protocol version request 1 0x48
PMTU_REQ P-MTU 1 0x60
PMTU_PROBE P-MTU probe 1 0x61
DTLS_COMPLETE_REQ DTLS completed request 1 0x62
TRANSPARENT_MSG Transparent message 1 0x70
POLL_RESP Poll Response 1 0x91
EVENT_RESP Event response 1 0xB0
CONN_HANDLE_RESP Connection handle response 1 0xC0
DEVICE_ID_RESP Device ID response 1 0xC1
ENCRYPT_SELECT_RESP Encryption selection response 1 0xC2
ENCRYPT_KEY_RESP Encryption key exchange response 1 0xC3
HASH_SELECT_RESP Hash selection response 1 0xC4
PATH_SUPERVISION_RESP Path supervision response 1 0xC5
SET_TIME_RESP Set time response 1 0xC7
VERSION_RESP Protocol version response 1 0xC8
PMTU_RESP P-MTU response 1 0xE0
PMTU_PROBE_RESP P-MTU probe response 1 0xE1
DTLS_COMPLETE_RESP DTLS completed response 1 0xE2
TRANSPARENT_RESP Transparent response 1 0xF0
The Message ID of any Response is the same as the Message ID of the corresponding Command,
but with bit 7 set.
5.2.7 Message length
This is the length of the Message Data (excluding Message ID and Message length). This field is
used:
– in variable length messages (see for example 6.3.1 and 6.4.18) to check for the end of data;
– to be able to determine the start of an embedded reverse command (see 5.8).
Possible padding is never considered when calculating the value of message length field.
- 11 - CLC/TS 50136-9:2013
5.2.8 Sequence numbers
The sequence number is used to determine if a message is missing or duplicated. Both ends have a
transmit sequence number and a receive sequence number.
These two counters exist at both ends (e.g. we are speaking about 4 counters in total), whereas the
RX_Sequence counters are used to realize a “state-full machine” implementation.
These counters are used to fulfil three simultaneous functions:
a) Initially, both the SPT and RCT choose their TX_seqs to be a random number, then they use it as
a datagram counter, incrementing them for each sent datagram by one. The RX_seqs are the
expected next TX_seqs from the other communication end-point. That is: If one did see “42” as
the last TX_seq coming in from the communication partner, oneself would send out “43” as next
RX_seq. As the other end does this in the same style, the TX_seq and RX_seq function as a
mutual sequence control mechanism.
b) Second, they can simultaneously function as a resend-mechanism: If one detected that one
missed a datagram (because for example, the incoming TX_seq is “44”, but one expected
TX_seq=43) or the one got is corrupt (by checking the hash), one just resends the own old
previously sent last datagram and the other side will see by the old TX_seq that one wants to get
a re-transmission.
c) Being chosen randomly and being part of the encrypted data block, they rule out replay attacks.
For each connection, every message has to be acknowledged before the next new (not
retransmission) message may be transmitted.
5.2.9 Flags
The following flags are defined:
Table 5 – Flags
Byte Bit Definition
Reverse command included in response:
0 0 – value 0 = no reverse command included,
– value 1 = reverse command included
0 1…7 Reserved
1 0…7 Reserved
5.3 Padding and message length
5.3.1 Padding
Padding is required for the following two reasons:
– create a message length which is a multiple of the block length of the encryption algorithm as
used;
– make poll and alarm messages look alike.
Padding is done using random or pseudo-random data. Random bytes are appended to the actual
messages data until the total message length is one of those as specified in the next clause.
5.3.2 Message length
The message lengths as used fulfil the requirements as mentioned in 5.3.1 (using a 16 or 32 byte
block length), and are a compromise between obfuscation of alarm events and bandwidth usage.
This results message lengths that are a multiple of 128 + 4 bytes for the Connection Handle:
– 132 bytes (4 bytes Connection Handle + 8 × 16 bytes);
– 260 bytes (4 bytes Connection Handle + 16 × 16 bytes);
– etc.
5.4 Hashing
The following methods of message validation are supported:
Table 6 – Hashing ID’s
Hash ID Description Hash size in bytes
0 SHA-256 32
1 RIPEMD-256 32
RCTs have to implement all methods. However, it is permissible to configure a RCT not to accept all
hash methods.
SPTs shall at least implement the default method, but can implement all methods.
The default method is 0 (SHA-256) until explicitly updated using the messages as defined in 6.4.10
and 6.4.11.
The hashing method to be used is negotiated during session initialization, using the messages as
defined in 6.4.10 and 6.4.11.
The selectable hashing method allows for an upgrade of security in the future while maintaining
backwards compatibility.
The hash is included in the encrypted part of the message.
5.5 Encryption
5.5.1 General
Except for the Connection Handle, the entire message is encrypted. The encryption method to be
used has been negotiated during Commissioning. The following methods are supported:
Table 7 – Encryption ID’s
Encryption ID Description
Unencrypted
May only be used for debugging purposes or in test environments.
1 AES-128
2 AES-256
RCTs have to implement all methods. SPTs shall at least implement the default method, but can
implement all methods. The default method is 2 (AES-256) until explicitly updated using the messages
as defined in 6.4.6 and 6.4.7.
The encryption key is valid only for one connection between an SPT and the RCT, e.g. the RCT shall
keep track of all different keys as used by the SPTs connected to it.
The operation mode to be used with AES is CBC (Cipher Block Chaining) as specified in NIST Special
Publication 800-38A (2001 edition). The IV (Initialization Vector) is all zeros.
The selectable encryption method allows for an upgrade of security in the future while maintaining
backwards compatibility.
The sole purpose of the non-encrypted mode is for implementation ease (the messaging layer can be
implemented without encryption in place, and only once this is ready one can add the encryption).
- 13 - CLC/TS 50136-9:2013
5.5.2 Key exchange
The lifetime of a key is determined by the number of transmitted packets. To ensure security, key
updates are triggered regularly by the RCT every N successfully transmitted packets (using the RCT’s
sequence counter as reference), with N being a value which is sent from the RCT to the SPT during
the initial commissioning phase.
To enforce security, a key exchange is to be triggered by the RCT at least once a week or at least
every 2 = 65536 successful packets (whichever comes first).
In addition to that regular pattern, both RCT and SPT can invoke additional key exchanges.
To avoid RCT and SPT getting out of synchronisation when an alarm message is triggered exactly in
between an on-going session key exchange action, the RCT shall maintain the old session key until
the first successful transmission of a packet with the new session key is acknowledged.
5.6 Timeouts and retries
The timeouts (after which a message will be retried) will increase with each retry as defined in
RFC793.
In addition to RFC793, the resulting time-out value is upper-bound by the reporting time of the ATP
plus/minus an evenly randomly distributed time offset of 10 %.
NOTE RFC793 defines a learning algorithm, which tries to adapt to the available network capacity. To do so, it tries to
calculate a best-guess of the network’s round-trip-delay time, consisting of 90 % the time of the previously used time-out value
plus 10 % the round-trip-delay time of the last packet. Times a (safety) factor of 2, this value is used as the next time-out value.
The intention is to adapt to the congestion state of the network: The more the network is congested,
the larger the timeout value grows, trying to avoid a flooding of the RCT in case of a network
congestion.
To avoid too long a delay of a retry, this principle is upper-bound by a maximum time-out value.
Especially in case of an invent which could still lead to all SPTs trying to re-send to their RCT in
parallel, the upper limit defined by the reporting time of the ATP is changed by an evenly distributed
random component.
The random component shall be based on a (pseudo)random number generator which assures
randomly distributed outputs from all SPTs, even if they generate the value at the same moment of
time, e.g. by taking the SPT’s Device ID into the random number calculation.
5.7 Version number
The version number in the message header is an unsigned numerical byte value, indicating the
version of the protocol actually being used.
It defaults to “1”, representing the first version of this protocol implementation. SPT and RCT shall
mutually agree upon the protocol version to be used during the commissioning phase. The RCT may
be configured to require a specified set of protocol versions and to refuse to communicate using other
versions.
5.8 Reverse commands
To allow for an RCT to send commands to an SPT without depending on properties of the network
environment in between (e.g. any forwarding- or adopted firewall rules, especially on the side of the
SPTs networking equipment), a mechanism for packing reverse commands into response messages
is implemented.
The approach taken is to ‘piggy-pack’ an embedded reverse command in the response message. This
is indicated by the flag in the header of the response message (see 5.2.9).
The Message ID and the Message Data will be added to the message as follows:
Table 8 – Reverse commands
Byte Index Bytes Description What
0 HL Header, ‘Reverse command’-flag set to 1 Header
HL 1 Message ID Response message
HL + 1 2 Message Length of the response data
HL + 3 n Response message Data
HL + 3 + n 1 Message ID Embedded reverse command message
HL + 4 + n 2 Message Length of the reverse command
HL + 6 + n m Command message Data
HL + 6 + n + m Padding Tail
Hash
The Message Length of the response data shall be used to determine the start position of the
Embedded reverse command message.
It is still possible for an RCT to send commands asynchronously (without waiting for a poll), however,
depending on the network environment this command may not reach the SPT.
5.9 Initial values
The following values are used by the protocol until the variables are explicitly set by the corresponding
configuration messages.
Table 9 – Initial values
What Value Description
Connection handle 0 / Number Not set yet (DTLS) or shared secret
Hash 0 SHA-256
Encryption ID 2 AES-256
Heartbeat interval time 0 No Polling
TX sequence counter random Starts with random number
RX sequence counter 0 No packet received yet
6 Message types
6.1 General
This clause defines the messages as used in this protocol. Note that the examples show only the
Message Data; Header, Message ID and Message length are not shown in the message overviews.
6.2 Path supervision
6.2.1 General
This clause describes the format of the poll message and its reply. A configuration message is used to
negotiate the Poll Rate during commissioning. This configuration message is described in 6.4.12. The
Poll Message itself does not include the Heartbeat interval time.
Path supervision works on heartbeat traffic from the SPT to the RCT.
Any other message can implicitly function as Poll Message, e.g. the polling device can reset its ‘poll
interval’ timer upon sending any message, and the poll monitoring device can reset its ‘timeout’ timer
upon reception of any valid message from the other end.
6.2.2 Poll message
The Poll message has the following format:
- 15 - CLC/TS 50136-9:2013
SPT RCT
Table 10 – Poll message SPT RCT
Byte Index Bytes Description
0 HL Header, Message ID and Message Length
HL Padding
Hash
This message is sent by the polling device in case no messages have been sent for the heartbeat
interval time as negotiated by the Path supervision request/response messages (6.4.12/6.4.13) during
connection setup.
6.2.3 Poll response
The Poll response message has the following format:
RCT SPT
Table 11 – Poll response RCT SPT
Byte Index Bytes Description
0 HL Header, Message ID and Message Length
a
HL 1 Result code
Padding
Hash
a
Result code can be:
RESP_ACKNOWLEDGE
RESP_POLL_REESTABLISH_CONNECTION
6.3 Event reporting
6.3.1 Event message format
6.3.1.1 General
The (alarm) event message shall always contain the actual event data. Next to this mandatory
information the protocol provides the option to transmit additional information. To maintain the link
between event and additional data, this data is all transmitted within one message.
To achieve this, the event message is divided into fields, each accompanied by their own length
indicator.
Rationale:
– fields like ‘link’ are variable length, hence the ‘length’-bytes;
– to maintain a uniform format no distinction has been made between variable and fixed length
fields.
The Alarm event message has the following format:
SPT RCT
Table 12 – Event message format – SPT RCT
Byte Index Bytes Description
0 HL Header, Message ID and Message Length
HL 1 Field Identifier
HL + 1 2 Field Length (L1)
HL + 3 L1 Field Data
HL + 3 + L1 1 2nd Field Identifier (Optional)
HL + 4 + L1 2 2nd Field Length (L2) (Optional)
HL + 6 + L1 L2 2nd Field Data (Optional) … etc…
HL + 6 + L1 + L2 Padding
Hash
The Field Length (L1, L2, …) is the length of the Field Data (excluding Field Identifier and Field Length
bytes).
The following fields are defined:
Table 13 – Event message format – Fields
Field number Description
0x00 Event field
0x01 Time event field
0x02 Time message field
0x80 Link field: IP Address
0x81 Link field: IP Port
0x82 Link field: URL
0x83 Link field: Filename
Field numbers above 0x80 provide a link to out-of-band additional information, like for example:
– pictures accompanying the event (IP address and port number, filename);
– audio or video streams
that are transmitted via a secondary channel. Note that the time fields can also be used to match
events with the accompanying data.
These fields are explained in the next subclauses.
6.3.1.2 Event field
SPT: Mandatory
RCT: Mandatory
Table 14 – Event field
Relative
Bytes Description
Byte Index
Protocol Identifier: (See Annex B for definition and
0 1
message layout)
Event data, for example:
1 L
- 17 - CLC/TS 50136-9:2013
6.3.1.3 Time event field
SPT: Optional
RCT: Mandatory
Table 15 – Time event field
Relative
Bytes Description
Byte Index
0 8 Time format according to RFC958 (NTP) / RFC4330 (SNTP V4)
This field holds the timestamp on which the event occurred.
Time format is a 64 bit integer as described in RFC958 (NTP) / RFC4330 (SNTP V4), allowing easy
local synchronization. Note that NTP basically
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...