SIST-TS CLC/TS 50136-9:2021
(Main)Alarm systems - Alarm transmission systems and equipment - Part 9: Requirements for common protocol for alarm transmission using the Internet Protocol (IP)
Alarm systems - Alarm transmission systems and equipment - Part 9: Requirements for common protocol for alarm transmission using the Internet Protocol (IP)
This document 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 applies for transmission of all types of alarms including, but not limited to, fire, intrusion, access control and social alarms.
Compliance with this document is voluntary.
Alarmanlagen - Alarmübertragungsanlagen und -einrichtungen - Teil 9: Anforderungen an standardisierte Protokolle zur Alarmübertragung unter Nutzung des Internetprotokolls (IP)
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 (IP)
Alarmni sistemi - Sistemi in oprema za prenos alarma - 9. del: Zahteve za skupni protokol za prenos alarma po internetnem protokolu
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CLC/TS 50136-9:2021
01-januar-2021
Nadomešča:
SIST-TS CLC/TS 50136-9:2017
Alarmni sistemi - Sistemi in oprema za prenos alarma - 9. del: Zahteve za skupni
protokol za prenos alarma po internetnem protokolu
Alarm systems - Alarm transmission systems and equipment - Part 9: Requirements for
common protocol for alarm transmission using the Internet Protocol (IP)
Alarmanlagen - Alarmübertragungsanlagen und -einrichtungen - Teil 9: Anforderungen
an standardisierte Protokolle zur Alarmübertragung unter Nutzung des Internetprotokolls
(IP)
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 (IP)
Ta slovenski standard je istoveten z: CLC/TS 50136-9:2020
ICS:
13.320 Alarmni in opozorilni sistemi Alarm and warning systems
33.040.40 Podatkovna komunikacijska Data communication
omrežja networks
SIST-TS CLC/TS 50136-9:2021 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TS CLC/TS 50136-9:2021
---------------------- Page: 2 ----------------------
SIST-TS CLC/TS 50136-9:2021
TECHNICAL SPECIFICATION CLC/TS 50136-9
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
November 2020
ICS 13.320; 33.040.40 Supersedes CLC/TS 50136-9:2017
English Version
Alarm systems - Alarm transmission systems and equipment -
Part 9: Requirements for common protocol for alarm
transmission using the Internet Protocol (IP)
Systèmes d'alarmes - Systèmes et équipements de Alarmanlagen - Alarmübertragungsanlagen und -
transmission d'alarme - Partie 9 : Exigences pour le einrichtungen - Teil 9: Anforderungen an standardisierte
protocole commun de transmission d'alarme utilisant le Protokolle zur Alarmübertragung unter Nutzung des
protocole Internet (IP) Internetprotokolls (IP)
This Technical Specification was approved by CENELEC on 2020-09-28.
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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. CLC/TS 50136-9:2020 E
---------------------- Page: 3 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
Contents Page
European foreword . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and abbreviations . 6
3.1 Terms and definitions . 6
3.2 Abbreviations . 6
4 Objective . 7
5 Messaging . 7
5.1 General . 7
5.2 Message format overview . 8
5.3 Padding and message length . 12
5.4 Hashing . 13
5.5 Encryption . 13
5.6 Timeouts and retries . 14
5.7 Version number . 15
5.8 Reverse commands . 15
5.9 Initial values . 15
6 Message types . 16
6.1 General . 16
6.2 Path supervision . 16
6.3 Event message format . 17
6.4 Event response format . 23
6.5 Configuration messages . 23
7 Commissioning and connection setup . 36
7.1 General . 36
7.2 Commissioning . 36
7.3 Connection setup . 39
Annex A (normative) Result codes . 41
Annex B (normative) Protocol identifiers . 42
Annex C (normative) Shared secret . 43
Annex D (informative) Examples of messaging sequences . 44
Annex E (informative) Examples of application protocols . 51
Annex F (informative) Design principles . 53
Bibliography. 54
Tables
Table 1 — Backwards compatibility . 8
Table 2 — Backwards compatibility result code. 8
2
---------------------- Page: 4 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
Table 3 — Identifiers . 9
Table 4 — Basic unencrypted format of messages . 9
Table 5 — Basic encrypted format of messages . 10
Table 6 — Message ID overview . 11
Table 7 — Flags . 12
Table 8 — Hashing ID’s . 13
Table 9 — Encryption ID’s . 14
Table 10 — Reverse commands . 15
Table 11 — Initial values . 15
Table 12 — Poll message SPT ← → RCT . 16
Table 13 — Poll response RCT ← → SPT . 16
Table 14 — Poll response - result code . 17
Table 15 — Event message format – SPT → RCT. 17
Table 16 — Event message format – Fields . 18
Table 17 — Event field . 18
Table 18 — Time event field . 19
Table 19 — Time message field. 19
Table 20 — Link field – IP Address . 19
Table 21 — Link field – Port number . 20
Table 22 — Link field – URL . 20
Table 23 — Link field – Filename . 20
Table 24 — Alarm Text . 20
Table 25 — Site Name . 21
Table 26 — Building Name . 21
Table 27 — Location . 21
Table 28 — Room . 21
Table 29 — Alarm Trigger . 22
Table 30 — Longitude . 22
Table 31 — Latitude . 22
Table 32 — Altitude . 22
Table 33 — Event response message format . 23
Table 34 — Event response - result code . 23
Table 35 — Connection handle request message format . 24
Table 36 — Connection handle response message format . 24
Table 37 — Connection handle response - result code . 24
Table 38 — Device ID request message format . 25
Table 39 — Device ID request flags . 25
Table 40 — Device ID response message format . 25
Table 41 — Encryption selection request message format . 26
Table 42 — ‘Master Encryption Selection request’ flag . 26
3
---------------------- Page: 5 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
Table 43 — Encryption selection response message format . 26
Table 44 — Encryption selection response - result code . 26
Table 45 — Encryption key exchange request message format . 27
Table 46 — ‘Master Key request’ flag . 27
Table 47 — Encryption key exchange response message format. 28
Table 48 — Encryption key - result code . 28
Table 49 — Hash selection request message format . 28
Table 50 — Hash selection response message format . 29
Table 51 — Path supervision request message format . 29
Table 52 — Path supervision response message format . 30
Table 53 — Path supervision response - result code . 30
Table 54 — Set time command message format . 30
Table 55 — Set time response message format . 31
Table 56 — Set time response - result code . 31
Table 57 — Protocol version request message format . 31
Table 58 — Protocol version response message format . 32
Table 59 — Protocol version response - result code . 32
Table 60 — Transparent message format . 32
Table 61 — Transparent response format . 33
Table 62 — Transparent response - result code. 33
Table 63 — DTLS completed request message format . 33
Table 64 — DTLS completed response message format . 34
Table 65 — DTLS completed response - result code . 34
Table 66 — RCT IP parameter request message format . 34
Table 67 — RCT IP parameter response message format . 35
Table 68 — RCT IP parameter response - result code . 35
Table 69 — Message flow during the commissioning of a new SPT . 37
Table 70 — Message flow during connection setup . 40
Table A.1 — Result codes . 41
Table B.1 — Protocol identifiers . 42
Table D.1 — Example of the commissioning messaging sequence . 45
Table D.2 — Example of the connection setup messaging sequence . 48
Table E.1 — VdS2465 message example . 52
4
---------------------- Page: 6 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
European foreword
This document (CLC/TS 50136-9:2020) has been prepared by CLC/TC 79 “Alarm systems”.
This document supersedes CLC/TS 50136-9:2017.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
This document specifies a common IP transport protocol for alarm transmission. The published version
(2017, second version) required solving both technical and security issues identified during the first actual
implementations of the protocol. The working group was working closely with the early adopters of the
protocol and has a very clear and complete list of issues and solutions. This revision supersedes the
previous version.
EN 50136 consists of the following parts, under the general title Alarm systems - Alarm transmission
systems and equipment:
— Part 1: General requirements for alarm transmission systems
— Part 2: General requirements for Supervised Premises Transceiver (SPT)
— Part 3: Requirements for Receiving Centre Transceiver (RCT)
— Part 4: Annunciation equipment used in alarm receiving centres
— Part 5: (Free)
— Part 6: (Free)
— Part 7: Application guidelines
— Part 8: (Free)
— Part 9: Requirements for a common protocol for alarm transmission using the Internet Protocol (IP)
5
---------------------- Page: 7 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
1 Scope
This document 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 requirements for the performance of the alarm transmission system, the SPT and the RCT are
specified in the relevant parts of the EN 50136 series.
Compliance with this document is voluntary.
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 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.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
AES Advanced Encryption Standard
ARC Alarm Receiving Centre
ATP Alarm Transmission Path
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
6
---------------------- Page: 8 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
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 Transceiver
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 objective of this document 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 document is voluntary, any other alarm transmission protocol or equipment not
covered by this document may be used, provided that the requirements of EN 50136-1 are met.
The protocol and its elements concern one ATP only.
This protocol is designed to run on top of UDP and is designed to support both IPv4 and IPv6.
NOTE For more information on the use of IP and UDP in alarm transmission, please refer to Annex F.
5 Messaging
5.1 General
This clause defines the messaging layer, on top of which the alarm event data are transmitted using the
existing reporting formats such as, 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;
7
---------------------- Page: 9 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
— (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);
— 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 a response with the same message id as
the unknown message, however with bit 7 set, with the result code:
“RESP_CMD_NOT_SUPPORTED”.
Table 1 — Backwards compatibility
Byte index Bytes Description
0 HL Header, Message ID and Message Length
HL 1 Result code
Padding
Hash
Table 2 — Backwards compatibility result code
Description Purpose
Description
RESP_CMD_NOT_SUPPORT If the message ID is not supported by the RCT
ED
Multi-byte values will be transmitted using network byte order (big-endian).
Examples:
1. Consider sending message: "Example message."In this case "E" is considered the most significant
byte and should therefore be sent first.
2. Consider sending the encryption key (hex): "363E-2B16-8DBB-5A95-7D5F-2BF4-25A4-5D7C-363E-
2B16-8DBB-5A95-7D5F-2BF4-25A4-5D7C" In this case 0x36 is considered the most significant byte
and should therefore be sent first.
8
---------------------- Page: 10 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
This rule will follow the recommendations of the RFC 1700.
https://tools.ietf.org/html/rfc1700
5.2.2 Identifiers
The following identifiers exist:
Table 3 — Identifiers
Description Purpose Present in Encrypted See
Connection Look up the current All messages No 5.2.4
Handle symmetric encryption key
Device ID Uniquely identify the N / A 5.2.5
hardware
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.
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 4 — Basic unencrypted format of messages
Byte Index Bytes Description See Group
0 4 Connection handle 5.2.4 Header
4 2 Tx Sequence number 5.2.8
6 2 Rx Sequence number 5.2.8
8 2 Flags 5.2.9
10 1 Protocol version number 5.7
11 1 Message ID 5.2.6
12 2 Message Length 5.2.7 Message
14 n Message data Clause 6
14 + n n Padding 6.4
The basic encrypted, transmitted format of all messages is as follows. Note that the Device ID field is not
included in the encrypted message and its value is not used to compute the message hash value, i.e. the
hash is calculated from the unencrypted version of the message described above.
9
---------------------- Page: 11 ----------------------
SIST-TS CLC/TS 50136-9:2021
CLC/TS 50136-9:2020 (E)
Table 5 — Basic encrypted format of messages
Byte Index Bytes Description See Encrypted Group
0 4 Connection Handle 5.2.4 No Header
Message
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
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
Hash – RIPEMD-256
32
The Connection Handle is unencrypted; the remainder of the message (from Tx Sequence Number up to
and including Hash) 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 normative 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 mes
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.