Analogue to Digital Transition [A2DT] Technical Advisory Group Programme A2DT Document Record ID Key Sub-Prog / Project Technical Advisory Group - TAG SRO Martyn Wallace, CIO, Local Government Digital Office Status Final Programme Director Moira Mackenzie, Head of Development SCTT/NHS 24 Version 2.0 Author Russell Scott Version Date 02 Nov- 2017 Telecare IP Standards for A2DT - Technical Advisory Group [TAG]
Amendment History: Version Date Amendment History 0.1 June 2017 First draft Technical IP Standard for A2DT 0.2 June 2017 Second draft Updated with additional context and details 0.3 July 2017 Third draft Minor changes on Annex 1, and context on standards 0.4 Aug 2017 Fourth Draft Updates and comments from Wave 1 and TAG 0.5 Aug 2017 Removal of Conclusion Section plus Advice & Guidance Section updated 1.0 Sept/Oct 2017 Updated following considerations and Scottish Government TEC Executives feedback. Incorporated input from NHS Central Legal Office 2.0 Nov 2017 Final version for sign off Reviewers: This document must be reviewed by the following: Name Title / Responsibility Date Version TAG Members Various July/Aug 17 0.2-0.5 Approvals: This document must be approved by the following: Name Title / Responsibility Date Version A2DT Steering Group Oct 17 2.0 TEC Programme Executive Group Oct 17 2.0 Distribution: Technical Advisory Group; includes various stakeholders who are supporting the Analogue to Digital [A2DT] Programme, in collaboration with Scottish Government TEC Programme, Local Government Digital Office, SCTT/NHS24 along with Wave 1 partnerships engaged with the programme. Document Status: The controlled copy of this document is maintained in the A2DT repository. Any copies of this document held outside of that system, in whatever format (e.g. paper, email attachment), are considered to have passed out of control and should be checked for currency and validity. Disclaimer: This paper has been prepared for information purposes only, and is not intended to provide, and should not be relied on for technical, legal or other advice. You should consult your own legal, technical and other suitably qualified advisors before engaging in any action referred to in this paper. The Technical Advisory Group and its individual stakeholder members shall not be liable to you or anyone else for any decision made or action taken in reliance on the information in this paper. Page 2 of 9
Contents 1. Introduction... 4 2. Role and Scope of TAG... 4 3. Background and Context... 4 4. Method and Approach... 4 4.1 SCAIP... 5 4.2 NOWIP... 5 4.3 TS50134-9... 5 5. Results... 5 6. Advice and Guidance... 5 Annex 1: Comparison Matrix... 6 Annex 2: Glossary... 9 Page 3 of 9
1. Introduction This document sets out advice and guidance in support of a digital Internet Protocol [IP] technical standard for social alarm systems in support of the A2DT digital Telecare collaborative programme in Scotland. 2. Role and Scope of TAG The role of the TAG Group is to assist partnership areas in the transition from an analogue Telecare system in developing an end to end digital Telecare Service. As a group we have been formed to provide an advisory and guidance role for the full A2DT programme of work, working in collaboration with local partners and across all the workstreams and their respective objectives. It should be recognised that TAG do not have any formal decision-making power and report formally into the A2DT Steering Group within the national Technology Enabled Care(TEC) Programme. 3. Background and Context As a group we were aware we had a gap around having a defined technical standard in support of IP solution based Social Alarm service, and therefore working with a number of stakeholders the group have investigated, assessed and evaluated current standards along with the soon to be ratified BSI standard [TS50134-9] for an IP Social Alarm solution. As an advisory group, this document covers that technical assessment and aims to provide advice and guidance in support of the A2DT Programme and those partnerships looking to adopt digital telecare services in the future. 4. Method and Approach The method and approach adopted was to conduct and assess three current standards, and from a technical perspective, evaluate each of them against some key principles taking into account the key base technologies, type of information carried, and the level of security. For further details, please refer to Annex 1. Page 4 of 9
4.1 SCAIP - An open Dispersed Alarms protocol for the communication between the home and the alarm receiving centre. This has been the Swedish standard, which was approved in April 2014 in support of Sweden's rollout of digital telecare services. 4.2 NOWIP An existing communication protocol to support connectivity between Grouped Housing Telecare alarm equipment and alarm response centres (ARC) over a public IP network. This standard primarily supports the ability to connect/ring around to multiple/grouped housing residences during the same call. The NOW-IP protocol encompasses a full range of 'Equipment Control Functions' and 'Commands' which would seemingly align more to a grouped housing model. This standard has been in operation since 2012. 4.3 TS50134-9 The European Committee for Electrotechnical Standardization (CENELEC) have developed and produced a new standard which is currently being ratified under BSI. This open IP Protocol standard has used SCAIP as the baseline; however, additional enhancements have been incorporated to address security encryption. This standard is anticipated to evolve over time, with its initial focus supporting a dispersed social alarm setting. 5. Results The output from the assessment and evaluation was a comparison matrix (see Annex 1) that assessed each of the three highlighted standards against the key criteria and technical principles which had been previously identified by the TAG. It does however need recognising that this analysis was a desk top evaluation and has not been validated within a demonstrator/testing environment set up for an end to end digital Telecare simulation. Wave 1 Digital Telecare deployments are currently being implemented that will provide an opportunity for a real life evaluation of the protocols, which will provide further learning, that can be included within any future updates of this guidance. 6. Advice and Guidance From a technical perspective and at the time of issuing this paper, the advice and guidance from TAG, would be to adopt TS50134-9 for a dispersed housing model and NOW-IP for a grouped housing model, along with ensuring any new Telecare equipment procured should comply with either TS50134-9 or NOW-IP. It also needs to be recognised that for both Telecare service models, partnerships need to ensure that these are implemented as part of a wider information security approach, as approved within their respective organisations or local authority. However, it is worth noting that our assessment does not preclude the NOW-IP standard as being unacceptable for a dispersed/individual housing model, rather that the TS50134-9 standard is seemingly technically better suited from the desktop analysis undertaken to the dispersed/individual housing model. Page 5 of 9
TAG will look to provide further information, advice and guidance incorporating the learning and feedback from the Wave 1, Wave 2 and Hub and Cluster workstreams over time, and will inform partnerships and local authorities throughout the duration of this programme of activity. We also welcome comment or feedback on the information and assumptions contained in this guidance. Annex 1: Comparison Matrix Comparison of SCAIP and TS50134-9 and NOW-IP Aspect SCAIP TS50134-9 NOW-IP Defined by Applicable scenario Grouped housing support Swedish Standards Institute (SWIS) Communication between users and social services (LUC and ARC) - electronic messaging from LUC, data streaming channel, human-to-human channel System configuration code for grouped equipment supported Can identify a controlling unit and peripherals of that unit. It appears that where a group site has a shared controller that groups alarm units as part of that site, then they are unable to be identified. Progressed under European Committee for Electrotechnical Standardisation (CENELEC), ratification by British Standards Institute (BSI) which is under final review Development of the standard for better support of grouped housing is being considered as part of future new work item proposals NOW-IP project, intended to generate acceptance by Continua plus an additional scenario is indicated: query/control/programming of local equipment by the ARC, such as door locks System configuration code for grouped equipment supported includes elements such as "Equipment Control Functions and Commands" Can identify the controller of a site/installation and a local unit within the installation. It appears that a peripheral of a local unit cannot be identified. Key base technologies (see standard for detailed list of 'normative references') information carried SIP MESSAGE or SIP + E.164 or SIP + RTP XML (SCAIP adaption) IP network Event messages, media streams (voice or multimedia sessions), plus TLS, and expands on details Recognises that the alarm protocol and the media session may run over different network paths. (This design seems to be considered better for grouped housing.) TLS SIP SIMPLE or SIP + RTP BS8521 data sequences IP network plus programming messages Page 6 of 9
Summary of event messaging Summary of Heartbeat messaging Summary of media sessions Security A message is initiated from the alarm sender. If the receiver returns the following message response of- 'event was not received successfully' then the alarm sender will resend the message after short interval. Sender may also supply information update message at any time Session is terminated when either - receiver returns message to confirm that alarm handled - timeout is reached (send final reset message) Alarm sender sends heartbeat message receiver confirms open channel with response message Begin with the basic event message protocol as above. If that session terminates with the receiver confirming readiness for the media session, then alarm sender can initiate that session. Session is terminated with request from either party. The session may carry DTMF audio tones to provide some control facilities for the receiver. Left largely to considerations outside the standard. Points towards wrapping SCAIP into encryption provided by TLS. Requires authentication of alarm senders via HTTP Authentication (not clear what that actually looks like when the person only holds a device with an alarm button) Allows the media session to be on a non-ip connection. plus support for a scenario (call back) where the sender requests a media session but that session is then initiated by the ARC. Requires channel encryption via TLS (note that the minimum requirement is already outdated). Requires that the ARC is in possession of a valid certificate Requires authentication of alarm senders via HTTP Digest Note that this is framed in terms of capability to support ('shall'). It is left to the organisation to determine if the information requires this level of protection (for Personal and Sensitive data). This appears to open a path whereby a nonsecured legacy device that complies with plain SCAIP can Initiated by message from alarm sender receiver to respond with acknowledgement of the alarm sender to retry if session connection disrupted Alarm sender sends heartbeat message Receiver can acknowledge or return command or programming message Begin by ringing the receiver Follow with basic event message protocol as above Media stream starts when receiver OKs the invite Session is terminated by the receiver. Requires TLS Otherwise left to considerations outside the specification Page 7 of 9
also be connected - if permitted. Other Note that 'alarm' in this standard is a quite a flexible term. The codes from the dictionary show that this can also cover routine events such as door movement and light switches being operated. Requires backwards compatibility to support products that comply with SCAIP Note that the last update was made in 2011 which is a relatively long time ago. At that time it did not seem to have formal acceptance. A more up to date version may exists and formalisation may have happened. Page 8 of 9
Annex 2: Glossary 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 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 servicerelated functions are independent from underlying transport-related technologies. Page 9 of 9