Key areas to consider when moving from analog to IP-based social care alarms

IP-based technology is fundamentally different from analog

The move calls for the awareness and understanding that alarm communication works fundamentally different in IP-based technology compared to in an analog-based technology. Knowing these differences makes it easier to build modern social care alarm solutions and embrace the digital shift.

The areas I want to address are:

• Different social care alarm use cases call for different digital protocols
• Transmission of alarm event
• Transmission of voice communication
• DNS, NAT and IP addresses in robust and reliable services
• Design for security

Different social care alarm use cases call for different digital protocols

The major signaling protocol nowadays when communication is made over IP is SIP (Session Initiation Protocol), which is used to initiate, maintain, and terminate real-time voice and video communication sessions.

In the telecare domain, two major IP-based social care alarm protocols are used, both based on the SIP protocol. These are SCAIP (CENELEC – TS 50134/9), which is a European standard, and NOW-IP (BS 8521-2:2020) which is a British standard. The two protocols are designed and optimized for different use cases and markets; SCAIP for dispersed alarms and NOW-IP for group living.

SCAIP (CENELEC – TS 50134/9)

In dispersed alarms the primary digital alarm communication protocol is SCAIP (CENELEC – TS 50134/9). SCAIP handles point-to-point transmission of alarms, faults, control signal and communications monitoring, optimized for a combined (standalone) local unit and controller and an alarm receiving centre (ARC).

NOW-IP (BS 8521-2:2020)

NOW-IP (BS 8521-2:2020) is the digital communications protocol optimized for specialized group living environments. It is designed to support multiple users in a specialized group living environment using a shared social alarm infrastructure. Normally these systems contain multiple local units connected to a single controller. Please note that NOW-IP is only relevant in the UK market.

Transmission of alarm events

In analog-based alarm communication the alarm event information is transmitted and encoded as tones within an ordinary telephone call. In IP-based alarm communication the alarm transmission is separated from the voice call and the event information is sent as a data packet. This mean that transmission of alarm communication is fundamentally different in analog and IP-based solutions.

The advantage of IP-based protocols is that data packets are easier to handle than events encoded as tones, as tones are more sensitive to network disturbances and delays. This is important to understand as it impacts how an end-to-end solution is built.

In IP-based alarm communication, a SIP infrastructure must be incorporated to handle alarm events and subsequent voice communication. This infrastructure must take care of the complexity around private and public IP addresses and the challenges that arise when care alarm devices are placed behind a network address translation (NAT) or firewalls. More about NAT further down in this blog.

Transmission of voice communication

As mentioned above, the alarm event is transmitted within a telephone call – as tones – in analog-based alarm communication, while it is separated from the voice communication in IP-based protocols. In a typical alarm scenario, however, a combination of alarm events and subsequent voice communication is used. This means that the two functionalities need to play together, and alarm events and voice calls must be possible to correlate with each other.

As alarm events move to IP, the telephony infrastructure that receives the voice communication must be upgraded to support VoIP calls. VoIP platforms are widely deployed today, but most of them are deployed behind a firewall for internal communication. In social care alarm cases there will be a large number of distributed units that must be able to communicate securely with the alarm receiving platform. The same challenges apply here as for alarm events with regards to security and NAT Traversal.

DNS, NAT and IP addresses in robust and reliable services

Domain Name System (DNS) is the phonebook of the internet and translates domain names to IP addresses. The handling of IP addresses, public and private, is key in all IP-based communication.

In a SIP-based infrastructure, the DNS is fundamental to build a robust and reliable service. For example, it is crucial with proper DNS support to allow automatic failover and the ability for traffic to take multiple different paths should one path fail. This is the design applied in all modern communications network and cloud-based services.

An alarm device that is deployed on a private IP network requires a NAT functionality to be in place. This, however, introduces challenge as the end-to-end connectivity is lost when NAT is used. To overcome and work around these challenges, a NAT Traversal mechanism can be applied. You can read more about the challenges that NAT introduce and how they are addressed with NAT Traversal in this blog post.

Design for security

Security can be regarded as a reason in itself for moving from analog- to digital based alarm communication. The lack of authentication mechanisms in old analog protocols makes them vulnerable to dishonest usage and present a clear security risk.

In SIP-based communication, security mechanisms are already provided from the start through the SIP protocol. Authentication request, and encryption of signaling as well as encryption of media streams are built in, and in addition to providing secure transmission of signaling and media streams this also ensures full interoperability in an end-to-end ecosystem.

Unfortunately, many alarm devices or platforms do not have these key security features implemented. It might be several reasons for this, for example:

• The equipment manufacturer has a background from the old analog world and is not aware of the security requirements when a service is delivered on an IP network.
  
  
• A decision to not implement the additional complexity of a secure solution is justified with the argument that there was no security in the old protocol…
  
  
• Some deployments rely on building a VPN between the alarm device and the ARC, but this do not protect against an intruder that have managed to get inside of the network. Such deployments also add cost and complexity making it harder to scale.

My recommendation is to not take any security shortcuts, and to use the already standardized security protocols that are in place and proven to work on Internet.

iotcomms.io – experts in building SIP-based telecare communication for critical applications

In the shift from analog- to digital based social care alarm solutions, it is important to understand the complexity that a move to SIP (SCAIP or NOW-IP) holds. It is however also essential to point out that the benefits with SIP-based communication by far outweigh the challenges of building one.

iotcomms.io offers a cloud-native all-IP alarm, voice and video communication platform. A key capability of the platform is its SIP infrastructure, which is a central part in any of iotcomms.io’s alarm, voice or video cloud-based services.

With our deep knowledge of analog alarm communication protocols, we fully understand the challenges that moving from analog- to digital-based communication imply. The iotcomms.io platform removes the need to possess deep SIP, SCAIP or NOW-IP protocol competence in-house, and enables buying the SIP/SCAIP/NOW-IP communication as a service instead. Built for scale, the platform addresses all the challenges outlined in this post.

In addition to supporting the IP-based alarm protocols, the platform also supports the old analog-based protocols. This enables a smooth and controlled migration from analog to IP, as well as protecting your existing investments.

Who would benefit from the iotcomms.io platform?

As the telecare industry is growing it is also becoming more and more fragmented and specialized, with new players entering the market with new and innovative technical offerings.

We see the following players as target groups for the iotcomms.io platform:

• Equipment manufacturers wanting to efficiently incorporate alarm events and VoIP capabilities into their devices.
  
  
• Alarm receiving center software developers wanting to add the ability to receive analog as well as IP-based alarm events, and VoIP capabilities, in their platform.
  
  
• Alarm Center operators wanting a robust infrastructure to protect their internal systems as care alarm devices are deployed in IP networks, and to handle the SIP based voice communication.