IEC 60839 alarm transmission systems and IP messaging

The IEC alarm transmission publications cover different parts of the reporting system. Identify the relevant publication for the premises equipment, receiver and message exchange.

Overview#

The IEC 60839-5 series addresses alarm transmission systems between supervised premises and an alarm receiving centre. IEC TS 60839-7-8:2019 addresses a common message protocol for alarm transmission using Internet Protocol. The publications divide system performance, premises equipment, receiving centre equipment, and protocol concerns; support for one part must not be represented as conformity to the entire path.

Publication map#

Status and scope below follow the IEC catalogue as reviewed 25 August 2026.

The complete texts are paid IEC publications. Catalogue abstracts establish scope and lifecycle context, but not field encodings, timing values, classification criteria, conformance tests, or security mechanisms. Use licensed copies for engineering decisions.

Roles and boundaries#

protected premises                                  alarm receiving centre

alarm system -> supervised premises transceiver -> transmission network
                                                        │
                                                        ▼
monitoring automation <- receiving-centre interface <- RCT

Important terms include:

• alarm transmission system (ATS): the system that conveys alarm information across the defined path;
• supervised premises transceiver (SPT): the premises side transmission equipment;
• receiving centre transceiver (RCT): the receiving centre side transmission equipment;
• alarm transmission path: the defined connection through the transmission system/network;
• alarm receiving centre (ARC): the organization/facility that receives and handles alarm information;
• monitoring automation: downstream software that presents, correlates, persists, and routes received events.

A communicator, gateway, receiver, and monitoring application may be sold as one product stack but remain different assurance boundaries. Network reachability, RCT receipt, protocol acceptance, automation ingestion, operator presentation, and response must be modelled separately.

System view before message view#

An alarm transmission design should define:

• protected premises and receiving centre endpoints;
• single or diverse paths and their independence assumptions;
• transmission network ownership and service boundaries;
• supervision, fault detection, reporting, restoration, and escalation;
• availability, transmission time, and other declared performance criteria;
• power, backup, clock, buffering, and behaviour during extended outage;
• substitution, replay, redirection, tampering, and denial of service controls;
• commissioning, maintenance, change, and conformity evidence.

Don't infer system performance from nominal bandwidth, a successful connection, or one delivered test message. The declared classification and evidence must follow the exact IEC edition, regional adoption, product certificates, and installed design.

IP message boundary#

IEC TS 60839-7-8 belongs at the application message layer. IP, TCP, UDP, TLS, mobile, or fixed networks provide lower layer services according to the chosen profile; they don't supply alarm event meaning or end to end outcome.

A defensive implementation record should identify:

• exact publication, regional profile, and vendor interoperability profile;
• transport and connection lifecycle;
• sender, receiver, account/object, message, and sequence identity;
• event vocabulary and how initial, repeat, update, fault, and restore are represented;
• application acknowledgement and negative result semantics;
• timeout, retry, duplicate, delayed, reordered, and buffered message behaviour;
• maximum encoded and decoded lengths, field constraints, and parser rejection rules;
• security mode, peer authentication, confidentiality/integrity, replay protection, and key lifecycle;
• failover route and reconciliation when paths or receivers change.

Transport acceptance isn't an alarm protocol acknowledgement. Protocol acknowledgement isn't automation persistence. Automation persistence isn't operator handling or emergency response.

Relationship to SIA DC09#

SIA DC09 also carries protected premises alarm events to a central station receiver over IP networks. The two references are not aliases.

Some products or gateways may implement both. That doesn't imply field level equivalence, bidirectional lossless conversion, or shared certification. For a gateway, publish an explicit mapping of account identity, event/restore semantics, timestamps, acknowledgements, retry state, encryption/security context, and every unsupported value.

Reliability and duplicate handling#

Alarm paths retry because loss and uncertain outcomes are expected. Preserve enough state to distinguish:

• a retransmission of the same application message;
• a repeated occurrence reported with a new identity;
• a late message buffered during outage;
• a restore paired to an earlier condition;
• the same event received through a diverse path;
• receiver failover followed by replay or state reconciliation.

Deduplication must not discard a genuine repeated alarm, and duplicate delivery must not create duplicate dispatch or operator action. Keep the bounded original evidence or a protected evidence reference, parsing result, receiver result, correlation, route, and timestamps according to privacy and retention policy.

Security architecture#

• Authenticate each SPT/RCT or gateway identity and bind it to permitted accounts, sites, paths, and message types.
• Don't use source IP, caller/network identity, or a syntactically valid account field as sole authorisation.
• Use the exact approved security profile; reject silent downgrade and shared default credentials.
• Give every device/customer or suitably small security domain independently revocable keys or credentials where the normative profile permits.
• Protect provisioning, receiver routing, account mapping, key rotation, certificate trust, firmware, time, and remote management more strongly than ordinary read access.
• Segment event listeners from receiver management and monitoring automation administration.
• Enforce connection, authentication, message, decoded size, retry, and event rate limits per authenticated source and tenant.
• Alert on path substitution, repeated integrity/decryption failure, sequence anomalies, unexpected payload type, clock discontinuity, route change, and prolonged supervision loss.

Encryption protects content only within its defined endpoints and key model. It doesn't prove that the event belongs to the claimed account, that automation handled it correctly, or that a response occurred.

Failure and degraded states#

Design evidence should address loss of primary/secondary network, DNS or addressing dependency, power/backup, SPT, RCT, automation, database, time source, certificate/credential service, and operator interface. Define:

• which events are buffered, their maximum count/age/bytes, and overflow behaviour;
• failover ordering, backoff, route authorisation, and split brain prevention;
• supervision fault and restoration reporting;
• whether old alarms are replayed and how operators see their original occurrence time;
• how planned maintenance differs from an unplanned path failure;
• reconciliation after receiver or automation recovery.

Never generate a synthetic restore simply to clear a stale condition after outage.

Verification and procurement evidence#

Require evidence for:

• applicable IEC parts/editions, regional adoptions, product certificates, and declared system classification;
• SPT, RCT, network/path, automation, and service provider ownership;
• exact message and transport profile, including optional features and maximums;
• normal, duplicate, delayed, reordered, malformed, unsupported, and over limit message handling;
• acknowledgement, timeout, retry, buffer, diverse path, failover, and recovery semantics;
• peer/account authorisation, cryptographic profile, provisioning, rotation, revocation, and downgrade resistance;
• monitoring of path health, security anomalies, time quality, and receiver/automation handoff;
• explicit distinction among path availability, protocol acceptance, automation persistence, operator handling, and response.

Protocol fixtures should use synthetic accounts and an isolated receiver/automation environment with no dispatch connection. Operational alarm path acceptance requires written authority from the premises and monitoring organizations, controlled change, responsible operators, abort/restoration criteria, and retained evidence.

Primary sources#

• IEC, IEC 60839-5-1:2014, alarm transmission systems general requirements.
• IEC, IEC 60839-5-2:2016, supervised premises transceiver requirements.
• IEC, IEC 60839-5-3:2016, receiving centre transceiver requirements.
• IEC, IEC TS 60839-7-8:2019, common alarm transmission protocol using IP.

Related SIA material: SIA DC09 IP event reporting, SIA DC07 receiver to automation, and Contact ID / SIA DC05.

Section overview · Wiki home