SIST-TS CLC/TS 50134-9:2018

SLOVENSKI STANDARD
SIST-TS CLC/TS 50134-9:2018
01-november-2018
Alarmni sistemi - Socialni alarmni sistemi - 9. del: Komunikacijski protokoli IP
Alarm systems - Social alarm systems - Part 9: IP Communications Protocol
Systèmes d'alarme - Systèmes d'alarme sociale - Partie 9: Protocole de communication
IP
Ta slovenski standard je istoveten z: CLC/TS 50134-9:2018
ICS:
13.320 Alarmni in opozorilni sistemi Alarm and warning systems
SIST-TS CLC/TS 50134-9:2018 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TS CLC/TS 50134-9:2018

---------------------- Page: 2 ----------------------

SIST-TS CLC/TS 50134-9:2018


TECHNICAL SPECIFICATION CLC/TS 50134-9

SPÉCIFICATION TECHNIQUE

TECHNISCHE SPEZIFIKATION
September 2018
ICS 13.320; 35.240.99

English Version
Alarm systems - Social alarm systems - Part 9: IP
Communications Protocol
Systèmes d'alarme - Systèmes d'alarme sociale - Partie 9: Alarmanlagen - Personen-Hilferufanlagen - Teil 9: IP
Protocole de communication IP Übertragungsprotokoll
This Technical Specification was approved by CENELEC on 2018-05-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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, 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
© 2018 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
 Ref. No. CLC/TS 50134-9:2018 E

---------------------- Page: 3 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 8
4 Social Alarm transmission network architecture . 9
4.1 General . 9
4.2 Alarm and status messages . 10
4.2.1 General . 10
4.2.2 Authentication . 10
4.2.3 Encryption . 10
4.3 Voice / multimedia over IP implementation . 10
4.4 Separate voice network . 10
5 Use Case 1: Event without voice- or multimedia communication . 11
5.1 General . 11
5.2 Event not treated by alarm receiver . 11
5.3 Event information update . 12
5.4 Aborting message session . 12
5.5 Heartbeat . 12
6 Use case 2: Event with voice or multimedia communication . 12
6.1 LUC initiated voice / multimedia channel . 12
6.2 ARC initiated voice / multimedia channel . 13
6.3 Voice session initiation decision . 14
7 Message format description . 14
7.1 General . 14
7.2 Interoperability Considerations with Version Numbering . 15
7.2.1 General . 15
7.2.2 Interoperability between LUC and ARC versions with the same major version number . 15
7.2.3 Interoperability between LUC and ARC with Different Major Version Numbers . 15
7.2.4 Interoperability with SCAIP . 15
7.3 Message Request. 15
7.4 Message Response . 19
8 DTMF code . 21
9 Sessions . 22
9.1 Message . 22
9.2 Voice or multimedia . 23
Annex A (normative) Codes for device types . 24
Annex B (normative) Codes for device components . 27
Annex C (normative) Status codes . 28
Annex D (normative) Location codes . 32
Annex E (normative) Info codes . 34
2

---------------------- Page: 4 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
Annex F (informative) XML schema . 35
Annex G (informative) Rationale and roadmap . 40
Bibliography . 41

3

---------------------- Page: 5 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
European foreword
This document (CLC/TS 50134-9:2018) 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 shall not be held responsible for identifying any or all such patent rights.
EN 50134 consists of the following parts, under the general title Alarm systems — Social alarm systems:
— Part 1: System requirements;
— Part 2: Trigger devices;
Part 3: Local unit and controller;
—
— Part 5: Interconnections and communications;
Part 7: Application guidelines;
—
— Part 9: IP Communications Protocol [the present Technical Specification].
Annexes which are designated “informative” are given for information only.
4

---------------------- Page: 6 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
Introduction
As telecommunication operators continue to migrate towards Next Generation Networks they are increasingly
converging voice traffic onto their IP infrastructures which may have an adverse impact on the reliability of in-
call, tone based protocols.
The impact differs per country but is rapidly increasing across Europe. In addition, cellular technology is
increasingly used next to broadband, cable and fibre solutions.
This Technical Specification defines the IP communications protocol for social alarms, optimized for stand-
alone usage. The majority of current social alarms usage is stand-alone within the home and not related to
other alarm systems. The combination of social alarms with other types of alarm systems is pending for a
future version of this standard.
5

---------------------- Page: 7 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
1 Scope
This Technical Specification specifies a protocol for point-to-point transmission of alarms, faults, control
signals and communications monitoring, between a Local Unit and Controller and an Alarm Receiving Centre
using the Internet protocol (IP). The protocol is intended for use over any network that supports the
transmission of IP data with sufficient quality of service to support VoIP or a separate voice channel.
The Alarm Protocol is defined as an XML scheme including the alarm types, codes and necessary additional
information.
The alarm protocol is an application layer protocol using another Internet Protocol as a transport protocol to
handle addressing and transport functions. The transport protocol initially defined in this Technical
Specification is SIP (Session Initiation Protocol).
The system performance characteristics for alarm transmission are specified in EN 50134-5. The performance
characteristics of the Local Unit and Controller are expected to comply with the requirements of its associated
alarm system standard and to apply for the transmission of social alarms.
The protocols described in this standard are based on the SS 91100:2014 SCAIP standard [7] and defined to
enable backwards compatibility with existing products based on the SCAIP standard.
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 50134–1, Alarm systems — Social alarm systems — Part 1: System requirements
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and
times
ITU X509, Information technology — Open Systems Interconnection — The Directory: Public-key and attribute
certificate frameworks
RFC 2119, Key words for use in RFCs to Indicate Requirement Levels

RFC 2617, HTTP Authentication: Basic and Digest Access Authentication
[HTTP-AUTH]
RFC 3261, SIP: Session Initiation Protocol
[SIP]
RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP)
[SDP]
RFC 3428, Session Initiation Protocol (SIP) Extension for Instant Messaging
[SIP-IM]
RFC 3550, RTP: A Transport Protocol for Real-Time Applications
[RTP]
RFC 3711, The Secure Real-time Transport Protocol (SRTP)
[SRTP]
RFC 4568, Session Description Protocol (SDP) - Security Descriptions for Media Streams
[SDP-SEC]
RFC 4733, RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
[RTP-DTMF]
RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address
[ICE]
Translator (NAT) Traversal for Offer/Answer Protocols
RFC 5389, Session Traversal Utilities for NAT (STUN)
[STUN]
6

---------------------- Page: 8 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
RFC 5764, Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the
[SRTP-DTLS]
Secure Real-time Transport Protocol (SRTP)
RFC 5766, Traversal Using Relays around NAT (TURN): Relay Extensions to Session
[TURN]
Traversal Utilities for NAT (STUN)
RFC 5768, Indicating Support for Interactive Connectivity Establishment (ICE) in the Session
[SIP-ICE]
Initiation Protocol (SIP)
RFC 5870, A Uniform Resource Identifier for Geographic Locations ('geo' URI)

RFC 6314, NAT Traversal Practices for Client-Server SIP
[SIP-NAT]
G.711 (11/88), Pulse code modulation (PCM) of voice frequencies
G.729 (06/12), Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction
(CS-ACELP)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
alarm receiver
alarm receiving centre
system part which provides facilities for communication with a number of controllers, and providing the alarm
receiving and information processing system as an interface to the alarm recipient
3.2
codec
device capable of encoding and decoding a digital data stream or signal
3.3
controller
alarm sender
interface between one or more Local Units and the alarm transmission system or alarm recipient
3.4
heartbeat
periodic event generated by hardware or software to indicate normal operation or to synchronize parts of a
system
3.5
in-band signalling
sending of control information within the same band or channel used for voice
3.6
interconnections
transmission system that provides the communication between trigger devices and local unit and controller
7

---------------------- Page: 9 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
3.7
Local Unit and Controller
interface between the user and the controller which enables two-way speech
3.8
multimedia
media and content that use a combination of different content forms as text, audio, still images, animation,
video or interactivity
3.9
polling
sampling of a device to synchronize an activity
3.10
protocol
system of digital rules for message exchange within or between computers
3.11
social alarm system
telecare system
system providing 24 h facilities for alarm triggering, identification, signal transmission, alarm reception, two-
way speech communication, reassurance and assistance, for use by persons considered to be at risk
3.2 Abbreviations
Abbreviation Definition
ARC Alarm Receiving Centre
ASCII American Standard Code for Information Interchange
GGA Global Positioning System Fix Data
GPS Global Positioning System
GSM Global System for Mobile Communications
IP Internet Protocol
ISO International Organization for Standardization
LUC Local Unit and Controller
NMEA National Marine Electronics Association
POTS Plain Old Telephone Service
RFC Request for Comments
RTP Real-time Transport Protocol
SRTP Secure Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SIP-PP Session Initiation Protocol, Peer-to-peer.
TLS Transport Layer Security
UCS Universal Character Set
UDP User Datagram Protocol
UTF UCS Transformation Formats
XML eXtensible Markup Language
URI Uniform Resource Identifier
8

---------------------- Page: 10 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
Abbreviation Definition
SCAIP Social Care Alarm Internet Protocol
NGN Next Generation Network, a packet-based network able to provide services
including Telecommunication Services (such as voice) and able to make use of
multiple broadband, QoS-enabled transport technologies and in which service-
related functions are independent from underlying transport-related technologies.
4 Social Alarm transmission network architecture
4.1 General
The network architecture assumed by this standard as shown in Figure 1 is the existence of an all IP network
used for both the alarm communication protocol and voice, or the existence of an IP network for the alarm
communication protocol and a separate voice path outside of the IP network. The separate voice network can
be provided by cellular, analog POTS, broadband cable or VoIP operator infrastructure or a combination of
these.
In addition, in the second case the IP network may not be available while a voice session is in progress (e.g.
when 2G/2.5G modems are used in the LUC). Note that the second case is technology agnostic with respect
to the technology between LUC and voice network and the technology between ARC and voice network other
than the requirement that LUC and ARC are addressable via E.164 addressing.
Alarm Receiver
Alarm Sender
Alarm Alarm
protocol protocol
ARC
LUC IP network ARC
Voice over IP or
Voice over IP or
multimedia over IP
multimedia over IP
Alarm Receiver
Alarm Sender
Alarm Alarm
protocol protocol
ARC
LUC IP network ARC
voice
voice
Voice network

Figure 1 — Network architecture options
The protocol allows for a LUC to communicate to multiple ARCs. The mechanisms for ensuring availability of
an ARC and ensuring the LUC communicates to the correct ARC are not part of this standard, but could
consist of, for example, global load balancing, DNS, SIP proxies as part of the IP network, or use of the status
code in the message response indicating to the LUC to contact the another ARC.
9

---------------------- Page: 11 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
In addition, there may be constraints in the IP network on the reachability of the LUC from the ARC due to the
presence of an on premise NAT router or firewall.
4.2 Alarm and status messages
4.2.1 General
Alarm and status messages shall use SIP messaging [SIP-IM].
4.2.2 Authentication
The application layer protocol shall support authentication on a per connection basis, at least the same level
of encryption and authentication mechanisms as SIP. Authentication shall be either user specific, where each
alarm sender logs in on a separate account or group specific, where all alarm senders log in on a common
account.
The authentication mechanism shall support HTTP Digest authentication.
Alarm receivers shall only accept and process messages from authenticated, and thus authorized, alarm
senders. The LUC shall authenticate towards the ARC using HTTP digest authentication.
4.2.3 Encryption
The LUC and the ARC shall support encryption.
The LUC shall not transmit personal or sensitive information over an unsecure connection without encryption.
The LUC and ARC shall support secure SIP over unsecure connections.
Personal and Sensitive data are only allowed to be transmitted over secure SIP.
The ARC shall present a valid ITU X509 certificate.
LUC shall verify the identity of the server certificate using a local Root CA Certificate
LUC to ARC SIP session shall be encrypted with TLS V1.2 or higher.
LUC to ARC SIP session shall use cryptographic algorithms AES-128 encryption minimum.
NOTE The management of certificates and the behaviour when certificates are invalid are out of scope of this
standard.
4.3 Voice / multimedia over IP implementation
Voice / multimedia channels over the IP network shall use SIP [SIP], SDP [SDP] and RTP [RTP].
LUC to ARC voice session shall support codec G.711 (a-law) or G.729 minimum.
The LUC shall support firewall traversal for VoIP and SIP using ICE [STUN], TURN [TURN], ICE for SIP [SIP-
ICE] and NAT traversal for SIP [SIP-NAT].
The LUC and the ARC shall support secure communication through the use of TLS. The need for a secure
connection is indicated by the use of a “sips:” URI as the destination for SIP. This also indicates the LUC and
ARC shall use SRTP [SRTP] for the voice channel. The LUC and ARC shall support [SDP-SEC] to negotiate a
secure voice channel.
LUC to ARC voice session shall be encrypted with SRTP using AES-128 encryption minimum
NOTE Whether secure communications need to be used is determined by the organization deploying the social
alarm system.
4.4 Separate voice network
When the voice channel is set up out of band using a different technology such as a cellular network, a Next
Generation Network (NGN) or an analog POTS, signalling and voice channel occur outside of the IP network.
The voice channel in this case shall be able to terminate on the POTS or a NGN with voice functionality
10

---------------------- Page: 12 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
supporting E.164 phone numbers at the ARC, so that ARC does not need special connectivity other than to
the POTS or NGN. If the LUC supports call back, it shall be possible to call to the LUC using an E.164 phone
number, which may be over cellular, NGN or analog POTS.
Some functions should be controlled by single DTMF codes from the alarm receiver to enable a basic control
facility when the use of the voice channel results in loss of IP connectivity (e.g. 2G/2.5G cellular connectivity).
NOTE The alarm receiver of the Message Request might or might not be the same as the alarm receiver of the voice
or multimedia communication. The alarm sender might be able to connect to multiple alarm receivers for different events.
5 Use Case 1: Event without voice- or multimedia communication
5.1 General
Figure 2 shows the communication model with an alarm sender communicating over the IP network, e.g.
Internet, with TS50134 as protocol and an alarm receiver as endpoint. Messages are initiated from either an
end user, e.g. human, or a device and could have the function either as an alarm or a status message.

Figure 2 — Communication setup
Figure 3 shows the Alarm Protocol message exchange between the alarm sender and the alarm receiver.

Figure 3 — Message exchange
In this use case, the alarm sender sends a Message Request to the alarm receiver. Each Message Request
shall be acknowledged by the alarm receiver using a Message Response.
An event shall be considered successfully handled when the status number (status-number, see Table 2) of
the Message Response is set to 0.
5.2 Event not treated by alarm receiver
If the alarm receiver cannot determine the event as treated it shall return a Message Response with status
message (status-number, see Table 2) set to 4. This shall cause the alarm sender to resend the same
Message Request after 5 to 20 s.
This polling sequence shall continue for at least 3 min but shall not continue for more than 30 min.
11

---------------------- Page: 13 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
5.3 Event information update
If the alarm sender has new information related to an event that is being processed the alarm sender shall
send a Message Request with message type (message-type, see Table 1) set to Information update and all
mandatory data elements set to the same value as the initial Message Request.
5.4 Aborting message session
The alarm sender shall stop resending the Message Request and continue with an alternative action if the
alarm sender has not received a Message Response with status number (status-number, see Table 2) set to 0
within a specified time. In such case it shall abort the alarm by sending a Message Request with message
type (message-type, see Table 1) set to Reset and reference (reference, see Table 1) set to the same value
as in the initial Message Request.
5.5 Heartbeat
The alarm sender shall poll the alarm receiver periodically with a Message Request having message type
(message-type, see Table 1) set to Heartbeat. The alarm receiver shall return a Message Response with
status number (status-number, see Table 2) set to 0.
The heartbeat period should be minimum 1 min and maximum 1 440 min.
6 Use case 2: Event with voice or multimedia communication
6.1 LUC initiated voice / multimedia channel
In this use case the alarm sender will send a Message Request as well as establish a voice or multimedia
session. The initial message exchange shall be handled the same way as in use case 1, shown in Figure 2. If
the alarm sender receives a Message Response with status number (status-number, see Table 2) set to 0 and
media reply (media-reply, see Table 2) set to 1 or more, it should initiate a voice or multimedia session. Upon
reception of the Message Response, the alarm sender should initiate the voice session within 60 s. Note that
call handling reply (callhandling-reply, see Table 2) shall be set to 61 or 62, or omitted.
Figure 4 shows a message exchange combined with the establishment of a LUC initiated voice or multimedia
communication.
12

---------------------- Page: 14 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)

Figure 4 — Message exchange with LUC initiated voice or multimedia communication
The voice or multimedia communication shall be initiated by the alarm sender. Once the communication is
established it may be modified or terminated by either the alarm sender or the alarm receiver.
6.2 ARC initiated voice / multimedia channel
In this use case the alarm sender will send a Message Request. As a result of this Message Request, the
ARC establishes a voice or multimedia session. The initial message exchange shall be handled the same way
as in use case 1, shown in Figure 3. In this exchange the LUC sends a Message Request with the call
handling parameter (call-handling, see Table 1) set to 1. ARC sends a Message Response with status number
(status-number, see Table 2) set to 0 and media reply (media-reply, see Table 2) set to 1 or more together
with the call handling reply information (callhandling-reply, see Table 2). The ARC subsequently initiates a
voice or multimedia session by sending a Session Setup Request. After sending of the Message Response,
the ARC should initiate the voice session within the specified time in the call handling reply information.
NOTE The decision for callback is described in 6.3.
Figure 5 shows the message exchange combined with the establishment of a voice or multimedia
communication.
13

---------------------- Page: 15 ----------------------

SIST-TS CLC/TS 50134-9:2018
CLC/TS 50134-9:2018 (E)
Alarm Sender
Alarm Receiver
Message Request
Message Response
Alarm Sender
Alarm Receiver
Session Setup Request
Session Setup Response
Voice / Multimedia
Session Teardown Request
Session Teardown Response
- or -
Session Teardown Request
Session Teardown Response

Figure 5 — Message exchange with ARC initiated voice or multimedia communication
6.3 Voice session initiation decision
The LUC can request the set-up of a voice channel and can indicate it will call or ask for a call back. The
decision whether the voice session shall be initiated by the LUC or the ARC is taken by the ARC.
The LUC shall support calling in to the ARC. The LUC may support call backs.
The ARC shall support calling into the ARC. If the option exists for the ARC to establish a media channel to
the LUC, then the ARC may support calling out to the LUC.
The LUC and ARC shall support a media channel for voice for alarms where a voice channel is required. The
LUC and ARC may support other media than voice for multimedia over IP.
7 Message format description
7.1 General
TS50134 uses an XML format for the messages to represent the alarms and information codes. The
messages shall conform to a specific XML schema that should be used to verify t
...