---

ПІДТВЕРДЖУВАЛЬНЕ ПОВІДОМЛЕННЯ

Наказом Міністерства економічного розвитку і торгівлі України
від 30.12.2014 № 1494

CLC/TS 50136-9:2013

en: Alarm systems - Alarm transmission systems and equipment - Part 9:
Requirements for common protocol for alarm transmission using the Internet
protocol

прийнято як національний стандарт
методом підтвердження за позначенням

ДСТУ CLC/TS 50136-9:2014

uk: Системи тривожної сигналізації. Системи передавання тривожних
сповіщень та устатковання. Частина 9. Вимоги до загального протоколу для
передавання тривожних сповіщень з використанням Інтернет протоколу
(CLC/TS 50136-9:2013, IDT)

З наданням чинності від 2016-01-01T

CLC/TS 50136-9

ECHNICAL SPECIFICATION SPECIFICATION TECHNIQUE

TECHNISCHE SPEZIFIKATION January 2013

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

Systemes d’alarmes -

Systemes et equipements de transmission d’alarme -

Partie 9 : Exigences pour Ie protocole commun de transmission d’alarme utilisant Ie protocole Internet

Alarmanlagen -

Alarmubertragungsanlagen und - einrichtungen -

Teil 9: Anforderungen an standardisierte Protokolle zur Alarmubertragung unter Nutzung des Internetprotokoll

s

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
Comite Europeen de Normalisation Electrotechnique
Europaisches Komitee fur Elektrotechnische Normung

Management Centre: Avenue Mamix 17, В -1000 Brussels

© 2013 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members

.Contents

Foreword 4

1. Scope 5

2. Normative references 5

3. Terms, definitions and abbreviations 5

   1. Terms and definitions 5

   2. Abbreviations 5

4. Objective 6

5. Messaging 6

   1. General 6

   2. Message format overview 7

   3. Padding and message length 11

   4. Hashing 12

   5. Encryption 12

   6. Timeouts and retries 13

   7. Version number 13

   8. Reverse commands 13

   9. Initial values 14

6. Message types 14

   1. General 14

   2. Path supervision 14

   3. Event reporting 15

   4. Configuration messages 19

7. Commissioning and connection setup 27

1. .1 Commissioning 27

12. Connection setup 31

1. (normative) Result codes 32

2. (normative) Protocol Identifiers 33

3. (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

4. (informative) Examples of messaging sequences 35

D.1 Commissioning 35

D.2 Connection setup 38

5. (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

6. (informative) Design principles 44

F.1 General 44

F.2 Information Security 44

F.3 Use of UDP signalling 44

Bibliography 45

1. - Identifiers 7

2. Basic unencrypted format of messages 7

3. - Basic encrypted format of messages 8

4. - Message ID overview 10

5. - Flags 11

6. - Hashing ID’s 12

7. - Encryption ID’s 12

8. - Reverse commands 14

9. - Initial values 14

10. Poll message SPT <- RCT 15

11. - Poll response RCT <- -> SPT 15

12. - Event message format - SPT -> RCT 16

13. - Event message format - Fields 16

14. - Event field 16

15. - Time event field 17

16. - Time message field 17

17. - Link field - IP Address 17

18. - Link field - IP Port number 18

Table 19-Link field-URL 18

20. - Link field - Filename 18

21. - Event response message format 18

22. - Connection handle request message format 19

23. - Connection handle response message format 20

24. - Device ID request message format 20

25. - Device ID request flags 20

26. - Device ID response message format 21

27. - Encryption selection request message format 21

28. ‘Master Encryption Selection request’ flag 21

29. - Encryption selection response message format 22

30. - Encryption key exchange request message format 22

31. - ‘Master Key request’ flag 22

32. - Encryption key exchange response message format 23

33. - Hash selection request message format 23

34. - Hash selection response message format 23

35. - Path supervision request message format 24

36. - Path supervision response message format 24

37. - Set time command message format 24

38. - Set time response message format 25

39. - Protocol version request message format 25

40. Protocol version response message format 25

41. - Transparent message format 25

42. - Transparent response format 26

43. - DTLS completed request message format 26

44. - DTLS completed response message format 26

45. - RCT IP parameter request message format 27

46. - RCT IP parameter response message format 27

47. - Message flow during the commissioning of a new SPT 28

48. - Message flow during connection setup 31

1. 1 - Result codes 32

1 - Protocol identifiers 33CLC/TS 50136-9:2013

-4-

Foreword

This document (CLC/TS 50136-9:2013) has been prepared by CLC/TC 79 "Alarm systems".

1. 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.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

   1. Terms and definitions

For the purposes of this document, the terms and definitions given in EN 50136-1:2012 apply.

For the purposes of this document, the following abbreviations apply.

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

   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);

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.

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).

The following identifiers exist:

Table 1 - Identifiers

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.

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

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

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.

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.

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

Device ID is 16 bytes long.

Б.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.