The Road to VoLTE Emergency Calling: Addressing the Opportunities and Challenges

The commercial and regulatory drive to roll out 4G/5G networks is generally welcomed by all stakeholders. Mobile Network Operators (MNOs) can increase network capacity by refarming valuable spectrum from “legacy” 2G and 3G network services to facilitate the provision of more enhanced services to their customers while regulators and authorities will be pleased to see faster speeds, better connectivity, and more enhanced and flexible communication services available to the public.

But what does all mean for emergency communications and the conventional “emergency call”?

VoLTE originated Emergency calls

3GPP mobile standards have always incorporated specific provisions for emergency calling on mobile networks such as prioritisation, signalling, and the identification of emergency calls, to name a few. The standards include provisions for emergency calls using VoLTE such as network attach considerations and the addressing and identification of emergency calls.

The obvious difference is that these calls are packet-switched (PS) IP-based communications using the Session Initiation Protocol (SIP): this introduces opportunities and scope to further enhance emergency communications services as well as a particular set of challenges.

While VoLTE is widely used in many countries for conventional calls today, many networks are still utilising what is known as Circuit-Switched Fall Back (CSFB) for emergency calls. This process begins when a user attempts an emergency call and the network does not support emergency calling over VoLTE. This means that when an emergency call is attempted, the device must register on an available 2G/3G network in order to place the call. As long as networks rely on CSFB for the support of emergency calls, 2G and/or 3G network coverage and capacity must be maintained at appropriate levels to support emergency calling even though most conventional voice calls will be using VoLTE. This acts as a further incentive for MNOs to move to VoLTE support for emergency calls (although it is expected that a minimum level of 2G coverage will need to be maintained for a considerable period to support legacy emergency calling devices, including eCall IVS systems).

From the PSAP perspective

There are many questions that a PSAP may have about this process, from their perspective. A call is just a call, right? Does it really matter whether it originated on 3G or 4G? Does it matter if the call  was transported using legacy circuit-switched (CS) technology or VoLTE?

Strictly speaking – no, it doesn’t matter, and if the MNOs ensure that calls can be routed to the PSAP over existing routes and interconnects, the PSAP will still get the call they need to answer. However, they will miss out on the opportunity to use additional information and services available with VoLTE including:

What is involved in accepting VoLTE originated calls?

Whether or not a device will use VoLTE to make an emergency call is controlled by the mobile network. When the device registers on 4G, the mobile network informs the device as to whether emergency calling is supported on VoLTE or if the device should use CSFB.

At the time of writing, while VoLTE is in widespread use, all emergency calls received by our PSAP have been placed using CSFB. This means that while the devices are registered on 4G networks, and 4G data and voice calling is used in normal everyday communications, as soon as the user attempts to make an emergency call the device must attach to a 2G or 3G network. This has the potential to introduce a very slight delay in the call setup which in general is not noticed: however, it also introduces the risk that it may not be able to attach quickly enough to an allowed network, and the call may be made in a limited-service state if an emergency attach to another network is used. 

Enabling VoLTE originated emergency calls, when the user is already using VoLTE for normal calls, would seem to provide a more reliable and seamless user experience. However, it is not simply a matter of the mobile network telling devices that VoLTE originated emergency calling is supported on the network.

We began to explore the implications of enabling VoLTE originated emergency communications with MNOs by convening a technical working group comprised of technical representatives of the national PSAP, the regulator, and all of the MNOs.

Initial exploration revealed that transport of UTRAN Cell IDs was the immediate issue which could affect how emergency calls are handled. In Ireland, the Serving Cell ID is sent to the PSAP as part of the initial call setup to allow initial caller location (for call routing purposes) to be established. This approach to transporting Cell ID (in the call signalling sent to the PSAP) differs from many other countries: however, it does mean that the PSAP does not need to rely on any external location servers to establish the required call routing.

The implication for VoLTE originated emergency calls is that E-UTRAN Cell IDs differ from 2G/3G cell IDs in that they are hex values which contain letters. Such values cannot be transported in TDM signalling (e.g. ISDN, or in our case, SS7) which presented a unique challenge for transporting Cell ID for a VoLTE call. 2 options were explored:

• ● MNOs translate hex E-UTRAN Cell ID to a decimal value in a similar format to the 2G/3G Cell IDs before routing the call to the PSAP
• ● Upgrade the PSAP software to handle the new UTRAN Cell ID format and ensure all VoLTE originated calls are routed to the PSAP over SIP interconnects only.

Option 1 was considered to present considerable additional effort and complexity on the part of the MNOs and given that TDM interconnects were being rapidly retired. So, Option 2 it was – upgrading the PSAP software.

Our PSAP platform was already fully IP and could handle VoLTE calls natively, so it seemed like a relatively straightforward approach of updating our caller location systems to deal with the new hex Cell ID formats and to simply ensure that the transport of these calls was end-to-end SIP.

With this (overly?) optimistic outlook, and one of the MNOs testing in their test Lab, we received our first few VoLTE test calls. We were fortunate in the fact that the MNO involved already had an end-to-end SIP interconnection with our PSAP for live emergency calls which could easily be used to transport the VoLTE test calls from their lab to our test queues – or so we thought – more on that later.

There were some initial obstacles to overcome, mostly centred around addressing and call identification/classification on our platform. Perhaps more research into 3GPP specifications could have avoided this, but these issues were quite easily resolved. These issues included the “R-URI” and “TO” fields in the SIP headers, as well as the correct format to expect the E-UTRAN Cell ID in the “SIP P-ANI” header. We chose to extract the originating Cell-ID from the SIP P-ANI header as this is the standard method of transporting this information in VoLTE. We observed the Cell ID in this header being added by both device and the IMS. In some cases we received both in slightly different formats but this can be controlled by the network.

We had to make some changes to the R-URI. For our initial implementation we chose to have the default SOS URN, included in the R-URI, rewritten back to a traditional 112 string (including a suffix) to identify the originating MNO. This is important to us for operational reasons including that it identifies the call as mobile originated across our entire platform which helps to minimise change initially. We opted to stick with our traditional number-based addressing approach although this will be reviewed in the future. We also anticipate that we will eventually switch to the SOS URN format as this can sometimes convey additional information about the call (e.g. the requested emergency service). The key here is small changes in incremental steps.

Once we started receiving some test calls, and addressing issues were largely resolved, we turned our focus to one of the more exciting features and capabilities of VoLTE originated emergency calls using end-to-end SIP transport to the PSAP. That is, location transport as PIDF-LO. We were very eager to see PIDF-LO data “in the wild” as so far all we had seen were examples in documents, standards, and white papers. We needed to know what the PIDF-LO data looked like so that we could extract the location and use it in call handling and caller location.

Location representation in our platform is relatively simple and can be divided into 3 main categories or types:

• ● unstructured civic address;
• ● post code; or
• ● geographic coordinates with, or without, an accuracy estimate (radius).

Locations in PIDF-LO are represented as GML – a flexible XML style representation of a geographic location. By its very nature this can take any number of forms from a simple unstructured civic address to a complex shape represented in 3 axes in a huge variety of coordinate systems.

As we have yet to see real, live PIDF-LO data make it all the way to our caller location system we have chosen a 2-step approach to dealing with PIDF-LO:

• ● Stage 1: extract and store the PIDF-LO data when received with a call.; and
• ● Stage 2: on review of real-world data, identify the types of location and associated GML generated by various devices in a variety of location scenarios.

Our expectation is that we can transpose the GML locations presented to a standard format familiar to our systems and most importantly familiar to the emergency services: i.e. point (WGS84) with radius or as its more commonly, and inaccurately referred to among the emergency services – “the AML”!

In attempting to get PIDF-LO data all the way through from the MNO test lab to our PSAP platform was, however, where we met the most significant obstacle and perhaps the biggest caveat for any MNOs and PSAPS considering trying to use this data as we are.

As described earlier, we assumed we were in a promising situation as we already had end-to-end SIP interconnection in place with our trialling MNO for live emergency calls (i.e. circuit-switched originated emergency calls). What we didn’t realise was that, as this SIP interconnection was put in place for the live emergency calls to route calls from the Test Lab (and test IMS network), these calls were actually transported via the existing live CS core SIP platform which is a legacy SIP platform. It turns out that this intermediate SIP platform does not understand or recognise the PIDF-LO MIME body parts and strips them out of the messaging.

So where to from here?

PIDF-LO is one of the key features and capabilities in which we are interested so work is ongoing to determine the best routing option and may involve direct interconnection. Direct interconnection is desirable from an architecture perspective: however, no other real commercial drivers for it exist at the moment and the eventual topology will be a combination of what is commercially feasible while providing the greatest resilience and redundancy in routing of emergency calls.

There is also further testing and investigation to be carried out including roaming and compatibility issues with inbound roamers. This also includes the scenario where no roaming agreement is in place and the roaming device performs an emergency attach. There are also a variety of handover or mobility scenarios that need to be tested including from PS to CS. 

Based on our experiences to date we would recommend to:

• ● Start testing early: system changes could be required.
• ● Work closely with MNOs and ideally a group of MNOs – the MNOs have lab facilities which can originate VoLTE calls.
• ● Consider direct SIP Integration between PSAP Lab/Dev platforms and MNO Labs.
• ● Encourage MNOs to test multiple devices – VoLTE implementation should be standard … but.

The journey continues!