prEN IEC 60839-7-9:2026

Alarm and electronic security systems - Part 7-9: Message formats and protocols for serial data interfaces in alarm transmission systems - Requirements for common protocol for alarm transmission using the internet protocol

Alarm- und elektronische Sicherheitssysteme – Teil 7-9: Nachrichtenformate und Protokolle für serielle Datenschnittstellen in Alarmübertragungssystemen – Anforderungen an ein gemeinsames Protokoll für die Alarmübertragung unter Verwendung des Internetprotokolls

Alarmni in elektronski varnostni sistemi - 7-9. del: Oblike sporočil in protokolov za serijske podatkovne vmesnike v alarmnih prenosnih sistemih - Zahteve za skupni protokol za prenos alarma po internetnem protokolu

General Information

• Status: Not Published
• Publication Date: 25-Jul-2027
• Technical Committee: CLC/TC 79 - Alarm systems
• Current Stage: 4060 - Enquiry results established and sent to TC, SR, BTTF - Enquiry
• Start Date: 27-Mar-2026
• Completion Date: 27-Mar-2026
• Ref Project: oSIST prEN IEC 60839-7-9:2026 - Alarm and electronic security systems - Part 7-9: Message formats and protocols for serial data interfaces in alarm transmission systems - Requirements for common protocol for alarm transmission using the internet protocol

Overview

prEN IEC 60839-7-9:2026 is a draft international standard developed by CLC/IEC for alarm and electronic security systems. This standard specifies the message formats and protocols for serial data interfaces in alarm transmission systems, focusing on the requirements for a common protocol for alarm transmission using Internet Protocol (IP). By addressing both event communication and encryption over TCP/IP and UDP/IP, prEN IEC 60839-7-9 seeks to improve interoperability and secure transmission of security and alarm information between premises equipment (like control panels) and central station receivers.

Key Topics

• Internet Protocol (IP) Communication: The standard requires that alarm event data be transmitted using either TCP or UDP over IP-based networks, such as Ethernet or cellular networks. Both protocols may be supported, and equipment should auto-select or allow user configuration between them.

• Message Formats: It defines a strict message structure for alarm events and supervision data, including:

  • CRC checks for message integrity
  • Structured headers with account identification
  • ASCII-based encoding for data fields

• Encryption and Security: To address information security and data privacy, the standard provides requirements for optional AES encryption of message content, including support for different key lengths (128, 192, or 256 bits), and mandates cipher block chaining for encrypted messages. Encryption is optional for sending equipment but mandatory for receiving central station receivers.

• Interoperability and Marking: Equipment must be clearly marked according to supported protocols (UDP, TCP, or both) to ensure compatibility and facilitate system integration.

• Error Handling and Acknowledgment: Provides for reliable data transfer via acknowledgment (ACK) and negative acknowledgment (NAK) messages, along with protocol details for handling errors or transmission failures.

Applications

prEN IEC 60839-7-9:2026 offers significant value for manufacturers, integrators, and users of alarm and electronic security systems by:

• Ensuring compatibility: With clearly defined protocols and message structures, equipment from different manufacturers can reliably exchange alarm data, which is crucial for broad system integration and central monitoring.
• Enhancing security: Optional but robust data encryption protects sensitive security event information during IP transmission, better safeguarding against interception or tampering.
• Supporting diverse IP networks: The standard supports transmission over various IP media, such as Ethernet LAN, Wi-Fi (802.11x), cellular (GPRS), and future IP-based technologies, making it adaptable for both new and existing infrastructure.
• Simplifying deployment: Clearly defined requirements on media, addressing, and protocol identifiers make system configuration and troubleshooting more straightforward for installers and operators.

Typical use cases include:

• Security alarm control panels communicating with central monitoring stations
• Fire alarm systems reporting events to remote receivers
• Access control or integrated security systems transmitting status and emergency messages over IP networks

Related Standards

This standard fits within a broader family of international standards for alarm and electronic security systems:

• EN IEC 60839 Series: Covers general requirements, system architecture, and other communication protocols for security systems.
• ISO/IEC 27001: Information security management - relevant for organizations implementing encrypted alarm communications.
• SIA-DCS and ADM-CID Protocols: Specific digital communication standards referenced within this document for interoperability.

For optimal compatibility and security, prEN IEC 60839-7-9 should be implemented alongside these and other applicable standards governing alarm communications and data privacy.

---

Keywords: alarm transmission protocol, IP-based alarm systems, electronic security standards, encrypted alarm communication, TCP/IP alarm messaging, UDP/IP security, interoperability, prEN IEC 60839-7-9, CLC, central station receiver, premises equipment, message structure in alarm signaling, AES encryption alarm systems.

Standards Content (Sample)

SLOVENSKI STANDARD
01-februar-2026
Alarmni in elektronski varnostni sistemi - 7-9. del: Oblike sporočil in protokolov za
serijske podatkovne vmesnike v alarmnih prenosnih sistemih - Zahteve za skupni
protokol za prenos alarma po internetnem protokolu
Alarm and electronic security systems - Part 7-9: Message formats and protocols for
serial data interfaces in alarm transmission systems - Requirements for common
protocol for alarm transmission using the internet protocol
Ta slovenski standard je istoveten z: prEN IEC 60839-7-9
ICS:
13.320 Alarmni in opozorilni sistemi Alarm and warning systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

79/737/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 60839-7-9 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2026-01-02 2026-03-27
SUPERSEDES DOCUMENTS:
79/711/NP, 79/718A/RVN
IEC TC 79 : ALARM AND ELECTRONIC SECURITY SYSTEMS
SECRETARIAT: SECRETARY:
France Mr Jean-François LIGNEREUX
OF INTEREST TO THE FOLLOWING COMMITTEES: HORIZONTAL FUNCTION(S):

ASPECTS CONCERNED:
Information security and data privacy
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft
for Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of
which they are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).

TITLE:
Alarm and electronic security systems - Part 7-9: Message formats and protocols for serial data
interfaces in alarm transmission systems – Requirements for common protocol for alarm
transmission using the internet protocol

PROPOSED STABILITY DATE: 2031
NOTE FROM TC/SC OFFICERS:
Projct number set to IEC 60839-7-9 according Decision 2025-01 of TC 79 2025 plenary meeting.

electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

IEC CDV 60839-7-9 © IEC 2025
1 CONTENTS
3 FOREWORD . 4
4 1 Scope . 6
5 2 Normative references . 6
6 3 Terms, definitions and abbreviated terms . 6
7 3.1 Terms and definitions . 6
8 3.2 Abbreviated terms . 7
9 4 Compatibility . 7
10 4.1 User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). 7
11 4.1.1 General . 7
12 4.1.2 UDP Source Port Number . 8
13 4.2 Marking . 8
14 5 Requirements . 8
15 5.1 Media. 8
16 5.2 IP Addresses . 8
17 5.3 Communication Sequence . 8
18 5.4 Encryption . 9
19 5.4.1 General . 9
20 5.4.2 Encryption Standard . 9
21 5.4.3 Identifying Encrypted Messages . 9
22 5.4.4 Encrypted Elements . 9
23 5.4.5 Padding . 10
24 5.4.6 Encryption Key . 10
25 5.4.7 Cipher Block Chaining . 10
26 5.4.8 Encoding . 11
27 5.5 Messages . 11
28 5.5.1 General . 11
29 5.5.2 Event Messages (PE) . 11
30 5.5.3 Supervision Message . 16
31 5.5.4 Acknowledgement Messages (CSR) . 17
32 5.5.5 Remote Commands (see Annex H) . 18
33 5.6 Error Handling . 18
34 5.6.1 General . 18
35 5.6.2 Errors Observed by Premises Equipment . 18
36 5.6.3 Errors Observed by Central Station Receiver . 19
37 Annex A (informative) Cipher Block Chaining . 20
38 Annex B (informative) Example Message Frames . 22
39 B.1 General . 22
40 B.2 Fire Alarm, Zone 129, SIA DC-03 Format, Non-Encrypted, No Timestamp . 22
41 B.3 Fire Alarm, Zone 129, Contact ID DC-05 Format, Non-Encrypted, No
42 Timestamp, Group 0 . 22
43 B.4 Fire Alarm, Zone 129, SIA DC-03 Format, Non-Encrypted, With Timestamp . 22
44 B.5 Fire Alarm, Zone 129, SIA DC-03 Format, Encrypted . 22
IEC CDV 60839-7-9 © IEC 2025
45 B.6 Fire Alarm, Zone 129, SIA DC-03 Format, Non-Encrypted, No Timestamp, MAC
46 Address x1234567890AB . 23
47 B.7 Intrusion Alarm, Zone 65, Contact ID DC-05 Format, Non-Encrypted, Group 2,
48 MAC Address x1234567890AB, Validation Data (future) . 23
49 B.8 Open Area 2, User 3, SIA DC-03 Format, Non-Encrypted, No Timestamp . 23
50 B.9 Fire Alarm, Zone 129, SIA DC-03 Format, Non-Encrypted, No Timestamp,
51 Network Address x1234567890AB . 23
52 Annex C (informative) Recommended Self-Validation Procedures . 24
53 C.1 General . 24
54 C.2 Premises Equipment Testing . 24
55 C.2.1 Receiver Simulator . 24
56 C.2.2 Testing Process . 24
57 C.2.3 Test Cases . 24
58 C.3 Central Station Receiver Testing . 26
59 C.3.1 Premises Equipment Simulator . 26
60 C.3.2 Testing Process . 27
61 C.3.3 Test Cases . 27
62 Annex D (informative) Encryption Keys . 30
63 Annex E (informative) Example: Transmission Sequences . 31
64 E.1 Reference system diagram. 31
65 E.2 Primary Transmission Path Failure. 31
66 E.3 Successful Encrypted Transmission . 32
67 E.4 Primary Receiver Failure . 32
68 E.5 Unsupported Message . 33
69 E.6 Expired Time Stamp . 33
70 E.7 Supervision Message with Optional Extended Data . 34
71 Annex F (informative) Checklist of Major Requirements . 35
72 Annex G (informative) Protocol Identifier Tokens . 36
73 Annex H (normative) Optional Remote Commands . 37
74 BIBLIOGRAPHY . 41
76 Figure 1 – UDP Protocol . 9
77 Figure 2 – TCP Protocol . 9
78 Figure A.1 – The CBC Mode . 21
79 Figure E.1 – Reference System Diagram . 32
80 Figure E.2 – Primary transmission path failure . 33
81 Figure E.3 – Successful Encrypted Transmission . 33
82 Figure E.4 – Primary Receiver Failure . 34
83 Figure E.5 – Unsupported Message . 34
84 Figure E.6 – Expired Time Stamp . 35
85 Figure E.7 – Supervision Message with Optional Extended Data . 35
86 Figure H.1 – Remote Command Sequence . 41
87 Figure H.2 – Encryption Key Change Sequence . 42
IEC CDV 60839-7-9 © IEC 2025
89 Table 1 – Extended Data Identifiers . 14
90 Table 2 – Trigger Identifiers . 16
91 Table G.1 – Tokens . 38
IEC CDV 60839-7-9 © IEC 2025
94 INTERNATIONAL ELECTROTECHNICAL COMMISSION
95 ____________
97 ALARM AND ELECTRONIC SECURITY SYSTEMS –
99 Part 7-9: Message formats and protocols for serial data interfaces in alarm
100 transmission systems – Requirements for common protocol for alarm
101 transmission using the internet protocol
103 FOREWORD
104 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all
105 national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-
106 operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition
107 to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly
108 Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is
109 entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in
110 this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also
111 participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO)
112 in accordance with conditions determined by agreement between the two organizations.
113 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
114 consensus of opinion on the relevant subjects since each technical committee has representation from all interested
115 IEC National Committees.
116 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
117 Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
118 Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation
119 by any end user.
120 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
121 transparently to the maximum extent possible in their national and regional publications. Any divergence between any
122 IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
123 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
124 assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services
125 carried out by independent certification bodies.
126 6) All users should ensure that they have the latest edition of this publication.
127 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members
128 of its technical committees and IEC National Committees for any personal injury, property damage or other damage
129 of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of
130 the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.
131 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
132 indispensable for the correct application of this publication.
133 9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s).
134 IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof.
135 As of the date of publication of this document, IEC had not received notice of (a) patent(s), which may be required to
136 implement this document. However, implementers are cautioned that this may not represent the latest information,
137 which may be obtained from the patent database available at https://patents.iec.ch. IEC shall not be held responsible
138 for identifying any or all such patent rights.
139 IEC 60839-7-9 has been prepared by IEC technical committee 79: ALARM AND ELECTRONIC
140 SECURITY SYSTEMS. It is an International Standard.
IEC CDV 60839-7-9 © IEC 2025
141 The text of this International Standard is based on the following documents:
Draft Report on voting
79/XX/FDIS 79/XX/RVD
143 Full information on the voting for its approval can be found in the report on voting indicated in the
144 above table.
145 The language used for the development of this International Standard is English.
146 This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
147 accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available at
148 www.iec.ch/members_experts/refdocs. The main document types developed by IEC are described
149 in greater detail at www.iec.ch/publications.
150 The committee has decided that the contents of this document will remain unchanged until the
151 stability date indicated on the IEC website under webstore.iec.ch in the data related to the specific
152 document. At this date, the document will be
153 • reconfirmed,
154 • withdrawn, or
155 • revised.
IEC CDV 60839-7-9 © IEC 2025
158 Requirements for common protocol for alarm transmission using the
159 Internet Protocol
160 1 Scope
161 This international standard defines the communication requirements of sending event content
162 between premises equipment and central station using Internet protocol (IP). The standard allows
163 both the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) for communication.
164 This standard is intended for use by manufactures of control panels and central station receivers
165 to ensure equipment compatibility, as well as all affected parties.
166 2 Normative references
167 There are no normative references in this document.
168 3 Terms, definitions and abbreviated terms
169 For the purposes of this document, the following terms and definitions apply.
170 ISO and IEC maintain terminology databases for use in standardization at the following addresses:
171 • IEC Electropedia: available at https://www.electropedia.org/
172 • ISO Online browsing platform: available at https://www.iso.org/obp
174 3.1 Terms and definitions
175 3.1.1
176 Acknowledgment
177 ACK
178 A return message indicating correct receipt of a transmitted message
179 3.1.2
180 Authentication
181 A process to assure that a received message is not a counterfeit sent by an unauthorized sender
182 3.1.3
183 Central Station Receiver
184 CSR
185 A central station receiver accepts connections from premises equipment, for the purpose of
186 transmitting event information to the central station
187 3.1.4
188 Encryption
189 The process of obscuring the content of a transmitted data message so it cannot be read or
190 replicated by unauthorized persons or equipment
191 3.1.5
192 Encryption Key
193 A data word used to encrypt and decrypt a message
194 3.1.6
195 Frame
196 The elements that make up a complete message for this protocol
IEC CDV 60839-7-9 © IEC 2025
197 3.1.7
198 IP Address
199 The unique identifier number assigned to a device on an IP network
200 3.1.8
201 Negative Acknowledgement
202 NAK
203 A return message indicating rejection of a transmitted message
204 3.1.9
205 Premises Equipment
206 PE
207 general class of electronic systems that are field-installed for the purpose of reporting event data
208 to a central station
209 Note 1 to entry: Security systems, fire alarm control panels and access control systems are examples of premises
210 equipment.
212 3.2 Abbreviated terms
213 IP Internet Protocol
214 UDP User Datagram Protocol
215 TCP Transmission Control Protocol
216 GPRS Global Packet Radio Service
217 DNS Domain Name Service
218 AES Advanced Encryption Standard
219 NIST National Institute of Standards and Technologies
220 CRC Cyclic Redundancy Checkword
221 ASCII American Standard for Information Interchange
222 SIA-DCS Security Industry Association-Digital Communication Standard
223 ID IDentifier
224 JSON JavaScript Object Notation
225 UTC Universal Time Coordinated
226 CBC Cypher Block Chaining
227 UUT Unit Under Test
229 4 Compatibility
230 4.1 User Datagram Protocol (UDP) and Transmission Control Protocol (TCP)
231 4.1.1 General
232 Premises Equipment (PE) and Central Station Receivers (CSRs) shall support either UDP or TCP
233 for event message transmission, and may support both UDP and TCP. When CSRs support both
234 protocols, the CSR shall automatically use the appropriate protocol for incoming messages without
IEC CDV 60839-7-9 © IEC 2025
235 requiring a configuration setting. When PE support both protocols, the protocol use may be
236 manually specified, or the manufacturer may implement a method to attempt message delivery with
237 one protocol, and switch to the other as necessary.
238 When PE or CSRs support only one protocol, UDP is the preferred implementation but TCP may
239 be used.
240 4.1.2 UDP Source Port Number
241 When UDP is used, the transmitter may set the source port number in the UDP header to the
242 desired port at which replies from the central station receiver will be accepted. This transmitter
243 behaviour is recommended.
244 4.2 Marking
245 Equipment capable of using UDP/IP for communication shall be marked as compatible with
246 "IEC 60839-7-9 Reporting (UDP-2025)". Equipment capable of using TCP/IP for communication
247 shall be marked as compatible with "IEC 60839-7-9 Reporting (TCP-2025)". Equipment capable of
248 using UDP/IP or TCP/IP for communication shall be marked as compatible with "IEC 60839-7-9
249 Reporting (UDP/TCP-2025)".
250 Additionally, equipment shall be marked to show the list of Annex G tokens (protocols) that are
251 supported.
252 When PE and CSRs implementing this standard share at least one protocol (UDP or TCP), they
253 are intended to be interoperable.
254 5 Requirements
255 Note 1 to entry: Annex F summaries the major requirements described below.
256 5.1 Media
257 This standard can be implemented on any media that carries Internet protocol (IP), including but
258 not limited to Ethernet, 802.11x, GPRS and cellular protocols. The ability of the network to perform
259 media conversion and provide limited protection for message integrity is assumed.
260 5.2 IP Addresses
261 The central station receiver (CSR) shall be hosted on a static IP address. The premises equipment
262 (PE) may be hosted on a dynamic or static IP address and shall be capable of being programmed
263 with the IP address to which events are to be sent.
264 The PE may have an option to use DNS to obtain the address of the CSR, however the installation
265 is not compliant with this standard when the DNS option is enabled.
266 5.3 Communication Sequence
267 When UDP is used, a simple transmit/acknowledge sequence is used to transmit messages
268 (Figure 1):
Premises Equipment CS Receiver
transmit event or supervision message()
acknowledgement message()
270 Figure 1 – UDP Protocol
IEC CDV 60839-7-9 © IEC 2025
272 When TCP is used, the process is very similar (Figure 2):
274 Figure 2 – TCP Protocol
275 Annex E gives some examples of transmission sequences.
276 5.4 Encryption
277 5.4.1 General
278 PE may indicate use of AES encryption to transmit events. Encryption support is optional for PE.
279 Encryption support is mandatory for CSRs.
280 5.4.2 Encryption Standard
281 For the AES requirements, refer to Federal Information Processing Standards Publication 197 that
282 is available from the National Institute of Standards and Technology.
283 Additionally, encrypted messages shall use Cipher Block Chaining, as described in section 6.2 of
284 NIST Special Publication 800-38A (2001 Edition).
285 5.4.3 Identifying Encrypted Messages
286 Encrypted messages shall be identified with an asterisk as described in section 5.5.2.6 of this
287 standard.
288 5.4.4 Encrypted Elements
289 When encryption is used, only the data, timestamp and padding content of a message are
290 encrypted. Encryption begins on the byte after the opening bracket "[" on the data element, and
291 ends just before the terminating .
292 The encrypted elements are shaded in the frame, below:
<0LLL>
<"id"><#acct>[|.data.][x…data…]

IEC CDV 60839-7-9 © IEC 2025
295 5.4.5 Padding
296 5.4.5.1 General
297 Only when encryption is used, messages shall be padded with pseudo-random data (pad) so that
298 the byte count of the encrypted region is an even multiple of 16.
299 5.4.5.2 Padded Region
300 The characters counted for padding and encryption begin after the opening bracket "[" on the data
301 element, and include the pad field (pad), data, and timestamp field. The final is not included
302 in the count for padding and is not encrypted.
303 5.4.5.3 Pad Data
304 Pad data shall be pseudo-random bytes which vary from one message to the next. This data will
305 consist of binary values 0-255, except that it shall not contain the ASCII values for the character
306 "|" (124, x7C), "[" (91, x5B) or "]" (93, x5D).
307 5.4.5.4 pad (Pad Data Field)
308 When a message is encrypted, padding is inserted between the open bracket character "[" and the
309 pad termination character "|". Between 16 and 31 pad characters shall be inserted in the pad field
310 such that the total number of encrypted characters (from the first pad character up to and including
311 the last timestamp character is an even multiple of 16.
312 The "|" character immediately following the pad field shall appear in all encrypted messages. This
313 pad termination "|" character shall not appear in unencrypted messages, though the "|" character
314 that typically separates the account number from the rest of the data may appear.
315 5.4.6 Encryption Key
316 5.4.6.1 General
317 When encryption is selected, the PE may use a key length of 128, 192 or 256 bits. A matching key
318 value (and therefore matching key length) must be programmed at the PE and the CSR.
319 Annex D gives some recommendations regarding the handling of private keys.
320 5.4.6.2 Central Station Receiver Requirements
321 A CSR shall support all three key lengths, as well as messages using no encryption. Other key
322 lengths may be incorporated into the standard in the future, but are currently non-compliant.
323 Each port may be configurable with multiple encryption keys, to be used with individual accounts
324 or groups of accounts.
325 5.4.6.3 Premises Equipment Requirements
326 When the PE supports encryption, it shall be able to store a private key of 128, 192 or 256 bits in
327 length, at the option of the manufacturer
328 5.4.6.4 Key Contents
329 When private or session keys are created, a pseudo-random process shall be used. Each bit shall
330 have an equal probability of being 0 or 1 as the key is created. The use of a binary-encoded ASCII
331 phrase as the key is specifically discouraged.
332 5.4.7 Cipher Block Chaining
333 The encrypted blocks of a message implement cipher block chaining as described in section 6.2 of
334 NIST Special Publication 800-38A (2001 Edition). For this protocol, the initialization vector (IV) will
335 be all zeros, as the padding characters provide the variability needed for message confidentiality.
336 Refer to Annex A for a copy of the cipher block chaining method to be used.
IEC CDV 60839-7-9 © IEC 2025
337 5.4.8 Encoding
338 In the encrypted region of the message, each byte shall be encoded for transmission as two ASCII
339 characters (0-9, A-F or a-f) representing the hexadecimal value of the encrypted byte.
340 For example, the message:
B3680040"ADM-CID"0001L000000#1234[#1234|1140 00 007]_22:49:34,01-22-2012

341 When encrypted, the message might (depending on the encryption key used) be transmitted using
342 the following ASCII characters:
4B89007B"*ADM-CID"0001L000000#1234
[371baac130fe81508f556e6fd2ccfd8826e9ba186f0fb67
4bb87c079484e546dff35532aa285936a00c27b6feb053f68

343 5.5 Messages
344 5.5.1 General
345 PE may send two types of messages: event and supervision.
346 CSRs send only one type of message, acknowledgment, which may have four types: ACK, NAK,
347 DUH or RSP.
348 Annex B gives some examples of messages, and Annex C proposes some self-validation
349 procedures.
350 5.5.2 Event Messages (PE)
351 5.5.2.1 General
352 Event messages follow a structured ASCII format consisting of a header line and a message body.
353 The header contains a 16-bit CRC checksum and a message length field. The body contains the
354 event data, beginning with a quoted protocol identifier and including a sequence number, receiver
355 ID, line prefix, account number, optional data, and a timestamp.
356 This format is designed to support secure and reliable communication of a wide range of event
357 types, including burglary, fire, panic, access control, and system status. Messages may be
358 transmitted in plaintext or encrypted form. All fields are encoded in 7-bit ASCII unless otherwise
359 specified. The template for each event:
<0LLL>
<"id"><#acct>[|.data.][x…data…]

360 5.5.2.2 LF
361 This is the ASCII linefeed character, transmitted as a binary value 0x0A.
362 5.5.2.3 crc
363 The CRC (Cyclic Redundancy Check) is a 16-bit checksum used to verify the integrity of the event
364 message. It shall be calculated over the second line of the message — beginning with the first
365 quotation mark (") of the ID token and ending with the last character before the terminating carriage
366 return ().
367 The CRC algorithm shall be:
IEC CDV 60839-7-9 © IEC 2025
368 - Polynomial: 0x8005 (reflected: 0xA001)
369 - Initial value: 0x0000
370 - Bit order: Input bytes shall be processed least significant bit first (reflected)
371 - Final XOR: None
372 - Output: 16-bit result shall be encoded as four uppercase ASCII hexadecimal characters
373 (e.g., "93FA")
374 The CRC shall be placed on the first line of the message, immediately following the ASCII Line
375 Feed ().
376 When encryption is used, the CRC shall be calculated after encryption is applied to the message
377 body.
378 5.5.2.4 0LLL
379 This length element consists of the character "0" (ASCII zero) followed by three ASCII hex digits
380 giving the message length, and it counts the same characters used in the CRC calculation — from
381 the first quote of the ID to the character before the final carriage return., as described in section
382 5.5.2.3.
383 5.5.2.5 "id" (ID Token)
384 The <"id"> field contains an ASCII token to indicate the format used in the data field of the message,
385 and whether or not encryption is used. The quote characters are included in the message.
386 A CSR compliant with this standard shall support at least the SIA-DCS and ADM-CID tokens
387 (protocols) shown in Annex G.
388 PE shall support at least one of the tokens SIA-DCS and ADM-CID, and may support any others
389 shown in Annex G.
390 5.5.2.6 Encryption Flag:
391 When the data and timestamp of a message are encrypted, the ID Token is modified to insert an
392 ASCII "*" after the quotation character and before the first character of the token. For example, an
393 unencrypted SIA DCS packet would use the token "SIA-DCS" and an encrypted SIA DCS packet
394 would use the token "*SIA-DCS".
395 5.5.2.7 seq
396 The PE applies a sequence number to each message as it is queued. The CSR shall echo the
397 sequence number of the message to which it is replying in its acknowledgement messages.
398 The PE shall not increment the sequence number when repeating a message due to a
399 communication failure or no response from a CSR.
400 The PE shall assign a 4-digit ASCII sequence number to each newly queued message. The range
401 of sequence numbers is 0001 to 9999, after which the counter shall wrap back to 0001. When a
402 message is retransmitted due to communication failure or lack of acknowledgment, the original
403 sequence number shall be preserved and reused without incrementation. Sequence numbers are
404 associated with PE account numbers, and are shared across different reporting paths or media.
405 The sequence number shall be transmitted as four ASCII characters.
406 5.5.2.8 Account Identification (Rrcvr, Lpref, #acct)
407 5.5.2.8.1 General
408 Each set of PE may be provided with up to three complementary identifying tokens.
IEC CDV 60839-7-9 © IEC 2025
409 5.5.2.8.2 #acct (Account Number)
410 The account number is the most specific token, and is always programmed into the premises
411 equipment to identify it. The account token appears both in the header of the message (which is
412 never encrypted) and in the data of the message (which may be encrypted).
413 This element consists of an ASCII "#", followed by 3-16 ASCII characters representing hexadecimal
414 digits for the account number.
415 In certain special applications, the information provided in the #acct element may not match the
416 account number contained within the message data (see paragraph 5.5.2.9). For example, a
417 manufacturer may choose to transmit a MAC or network address as an identifier.
418 5.5.2.8.3 Lpref (Account Prefix)
419 The account prefix can be programmed into the PE to extend the identification provided by the
420 account number.
421 This element is required, and consists of an ASCII "L", followed by 1 to 6 hexadecimal ASCII digits
422 for the account prefix. When the PE does not need to transmit an account prefix, "L0" shall be
423 transmitted for this element.
424 While the field may contain arbitrary identifyig information, the description is "receiver line number"
425 and it may be regarded to define groups of account numbers.
426 5.5.2.8.4 Rrcvr (Receiver Number)
427 In some cases, PE may be programmed to further extend the identification provided by the account
428 number and account prefix by providing a receiver number.
429 This element is optional, and consists of an ASCII "R", followed by 1 to 6 hexadecimal ASCII digits
430 for the receiver number. When the PE does not need to transmit a receiver number, nothing shall
431 be transmitted for this element (i.e. "R" or "R0" are not to be transmitted in this case).
432 While the field may contain arbitrary identifyig information, the description is "receiver number" and
433 it may be regarded to define groups of receiver line numbers.
434 5.5.2.9 [Data] or [|Data] (Message Data)
435 All data is in ASCII characters and the bracket characters "[" and "]" are included in the transmitted
436 message. The data field format is dependent upon the ID token of the message.
437 Where an account number is associated with a message (most message types), the account
438 number data appears at the start of the data, preceded by the "#" character and followed by the
439 field separator "|". The account number is 3 to 16 ASCII characters representing hexadecimal digits.
440 Additional optional elements may follow the account number within the same bracketed field. These
441 elements shall be separated by the pipe (|) character and may include identifiers defined in Table 1.
442 When encryption is applied, the data element and timestamp may be encrypted together, as
443 described in section 5.4. In such cases, the data field may begin with an optional field used
444 to fill remaining space before the encrypted payload.
445 Refer to section 5.4.5.4 for the definition and usage of the field in encrypted messages.
446 5.5.2.10 [x…data…] (Optional Extended Data)
447 This field allows the PE to attach additional information to the message, by including one or more
448 optional extended data fields.
449 Use of this field is optional for the PE.
IEC CDV 60839-7-9 © IEC 2025
450 The receiver shall be able to receive and properly process a message containing the optional
451 extended data, however use of the information contained within the extended data field is optional.
452 The start field is delimited with the ASCII character "[", followed by a single ASCII character (data
453 identifier) that identifies the content of the data field. The data identifier may be any uppercase
454 ASCII character in the range "A" to "Z". The field is terminated with the ASCII character "]".
455 Following the identifier, extended data may contain characters encoded according to the legacy
456 Windows 1252 character or UTF-8.
457 The following data identifiers are defined (Table 1 and Table 2):
458 Table 1 – Extended Data Identifiers
Name ID Description Data ("[", Example
"]" or "|"
disallowed
)
Authentication "A" A hash of the 12 ASCII A6F2348C99335DF38
Hash message that characters
allows the (0-9, A-F or
(Note 4)
message to be a-f)
authenticated
Supervision “C” An identifier for Up to 64 CDP
Category the number of ASCII
(This manufacturer-specific field
communication characters
allows the PE to indicate to which
paths and link
standards the communication link
supervision
complies.)
category
Network Path “G” Manufacturer 1 ASCII
G2
specific identifier character,
(This manufacturer-specific field
for the path that “0”-“9”
allows the PE to indicate which
was used for the
network path was used for the
communication
communication. Note that the “L”
field in the message header can be
used for similar information.)
Time of "H" Time that event ASCII
H13:59:58,12-31-2012
Occurrence occurred (may be
different than
message time
stamp)
Alarm Text "I" alarm text which Windows I2nd Floor West PIR
may be a 1252 or
(Note 2)
description of the UTF-8
(capital
event or a characters
letter I)
comment
regarding the
event
JSON Data “J” Allows transfer of Up to 1024 J{"address": {
a manufacturer- Windows
"street": "21 Elm",
specific JSON 1252 or
"city": "New York",
Data Payload UTF-8
"state": "NY",
characters
"zip": "10021"
}
}
IEC CDV 60839-7-9 © IEC 2025
Name ID Description Data ("[", Example
"]" or "|"
disallowed
)
Encryption Key “K” Key exchange Up to 64 KABCDABCDABCDABCDABCD
request from (even
ABCDABCDABCD
CSR to PE (up to number)
256 bits) ASCII
characters
(0-9, A-F or
a-f)
Location "L" location of event Windows L3rd Floor Hallway
on site 1252 or
UTF-8
(Note 2)
characters
MAC Address "M" MAC address of 12 ASCII M0026B9E4268B
the PE characters
(0-9, A-F or
a-f)
Network “N” Hardware Up to 128 N1133557799bbddff
Address network address (even
This manufacturer-specific field is
associated with number)
similar to the MAC address field,
the ASCII
but may contain a different identifier
communication characters
than a MAC address.
path used (0-9, A-F or
a-f)
Building Name "O" building name Windows OIDS Centre
(capital 1252 or
(Note 2)
letter O) UTF-8
characters
Programming "P" contains a Windows (future use)
Data message used to 1252 or
(Note 2)
support UTF-8
programming or characters
other interactive
operations with
the receiver
Room "R" room of event Windows R2322
(Note 1) 1252 or
(Note 2)
UTF-8
characters
Site Name "S" site name Windows S123Main St., 55123
describing the 1252 or
(Note 2)
premises UTF-8
characters
Alarm Trigger "T" trigger for event ASCII Tx
(Note 1)
(Note 3)
Verification "V" information about Windows Vhttp://verify.com/34AC4DE3446
audio or video 1252 or
(Note 2)
information that UTF-8
may be characters
associated with
the event report
Longitude "X" location of event, ASCII X093W23.456
longitude (Note
(Note 2)
1)
location of event,
Latitude "Y" ASCII Y45N23.456
latitude (Note 1)
(Note 2)
Altitude "Z" altitude of event ASCII Z123.2M
(Note 1)
(Note 2)
IEC CDV 60839-7-9 © IEC 2025
459 Note 1 to entry: The content of these fields may be assigned by a local authority having jurisdiction.
460 Note 2 to entry: The format of these variable length fields is free form, and is not specified here.
461 Note 3 to entry: The following trigger identifiers are defined:
462 Table 2 – Trigger Identifiers
Tag Assignment Type
F Fire / Smoke Detector Automatic
G Gas Detector Automatic
W Water / flooding detector Automatic
S Sensor (temp / humid. / pressure) Semi-automatic
C Contact (intrusion or other) Semi-automatic
M Manual Trigger (e.g., switch) Manual
463 Note 4 to entry: The length, format and algorithm used for the data of this field is determined by the manufacturer, except
464 that binary-formatted data is disallowed. When the extended data field is used to transfer a hash code, this adds an
465 integrity control function to the end-to-end transmission (from premises to central station). In some countries this may be
466 required by the authorities having jurisdiction.
467 5.5.2.11 Timestamp
468 The timestamp shall be included in encrypted messages, and may be included on messages that
469 are not encrypted. This field is used to provide protection against message playback. The
470 timestamp indicates when the event was queued for transmission to the central station, and may
471 indicate a time significantly different than the time of event occurrence. The timestamp is always
472 transmitted with a reference of UTC.
473 The format of the timestamp is: <_HH:MM:SS,MM-DD-YYYY>. The braces are not part of the
474 transmitted message, but the underscore, colon, comma and hyphen charact
...