Standardization of IP-based emergency services systems is ongoing for more than 10 years and many of the specifications have been completed already in the IETF, 3GPP, NENA and EENA.

Nevertheless, new emergency services standardization efforts are born. One of these newly added activities is the work in the ETSI M493 group (which is now transitioned to the E2NA). You may not have heard about it. This is not your fault: information about the M493 group is hard to find in the Internet. This write-up aims to provide some insight.

The story starts in March 2011 when the EGEA COCOM group [0] met and discussed the current status of emergency services development in European member states. As an outcome of the meeting a new mandate, namely EC M/493 [1], was published.

In this mandate the European Commission asks European Standards Organizations to work on caller location standards for usage with emergency services in an IP environment. ETSI kindly accepted the mandate and created a new group – the M493 group.

This group has now been working on a stage 2 document on a new emergency services architecture since early 2012. In a nutshell, the architectures describes how emergency calls are initiated from the end device, travel via the VoIP service provider (VSP), through the emergency services network to the PSAP. The VSP interacts with the access network provider to obtain a reference to location information and routing information. The VSP then uses this information to route the call to the PSAP (via a sort-of IP-based emergency services network). The PSAP or the emergency services network use the location reference to exchange it for location.

While there has been progress to develop this architecture document the group ran into a couple of problems. Here is a list of challenges as I see them.

0. A mandate is not a requirements document.

When the work in the M493 group was started the charter of the group was developed based on the text from the mandate. The members in the group had envisioned that the mandate would be used to shed light on specific protocol design requirements or that the European Commission would participate in the meetings to provide additional insight into their thinking.

Unfortunately, the European Commission does not participate in the work directly and attempts to solicit feedback naturally take time. An official letter with the questions has to be written and agreement within the group has to be found regarding the proper wording. Feedback is also not available immediately.

In retrospect it would have been more useful to develop a requirements document that can be discussed with the European Commission.

1. Location from the end host is considered harmful.

The M493 architecture assumes that location information comes from the access network provider only; information from the end device itself is untrusted. The concern is primarily driven by fears about security problems PSAP operators may encounter. The IETF ECRIT working group has worked on a document, called “Trustworthy Location” [2], that illustrates the problems. That document also points to the challenges with a pure location-based view and urges to look at the larger picture (and at other information associated with the call, such as identity information).

There is, however, a lot of missed opportunity here since there is a lot of development in the area of location based services at the end device (based on GPS integration into mobile phones but also based on third party location based services). These location-based services will not be re-usable in the M493 architecture as it currently seems.

The current architecture assumes that location is available for every IP caller everywhere from day one. There is no transition story for how to get to the final deployment stage.

It is also worth noting that location servers not only need to be available with every access network but also within enterprise networks. This is because the VSP uses the source IP address of the incoming call setup message to find a location server. When an end user utilizes a VPN then that lookup will resolve to the IP address obtained by the VPN and does not represent the IP address the end device has obtained from the access network provider. In addition to enterprise networks that are impacted any infrastructure provider who terminates tunnels (like IPv4-IPv6 transition gateways, VPNs, mobility anchor points, or TURN servers) is impacted. It is hard to say how large the number of impacted networks actually is.

In case you are hoping for a shift to better location for emergency services you may be disappointed. In Europe emergency services typically only have access to location at the granularity of cell ids (for cellular services). This is not likely going to change with this architecture either since the development or selection of location determination techniques are not scope of the group.

2. Focus on voice only.

The mandate by the European Commission puts a focus on voice services and the expertise in the group is on voice services only. Any considerations regarding multi-media emergency calling have been excluded and therefore the outcome may not work sufficiently well with media other than voice. This direction is also driven by the main proponents who have an integration with the current PSTN in mind, which does not support multi-media communication either.

3. Regulating VoIP providers is hard.

The current regulation on emergency services uses E.164 numbers to decide whether a company is covered by regulation or not. While this is a reasonable approach for past telecommunication infrastructure many communication services today do not use E.164 numbers. Consequently, they are not covered by regulation either. This regime seems to have been carried over to the IP world. Whenever the VSP is separate from the access network provider, which is the case for many Internet communication services and the VSP offers services outside their own country the situation gets challenging. How should the regulator impose obligations on VSPs that may essentially be located anywhere?

4. Operational complexity added.

While the M493 architecture does not require any location-to-service infrastructure like the IETF proposes with LoST it creates operational complexity.

First, the VSP is likely in the need to establish a relationship between the access network operator for the interaction with the location server. It is not likely that these location servers will be accessible for everyone on the Internet.

The next relationship that is requires is between the VSP and the emergency services provider. Here, it is also likely that a VoIP peering relationship needs to exist in order to route emergency calls from the VSP to the emergency services network. Unlike in many other architectures this emergency services network is envisioned to be operated by telecommunication operators, at least in the countries that participate in the work. This may allow a flow of money from the VSP to the provider of that emergency services network.

Finally, there is a relationship between the access network operator and the PSAP & emergency services network. This relationship is needed establish the necessary security infrastructure (such as the exchange of keys) for retrieval of location information.

5. Access Networks have no call visibility.

While the location retrieval and routing strategy follows the old telecommunication model the interaction between the end device and the VSP for emergency call handling is modern. Since one of the most popular example of an over-the-top VoIP provider is Skype and Skype uses a proprietary protocol the interaction between the end device and its VSP is left unspecified.

This also means that an emergency call itself is not understood by the access network and therefore no QoS treatment or preferential treatment of the call setup will be guaranteed for OTT providers. This also means that telecommunication operators that block certain VoIP services, or execute traffic management practices may accidentally block emergency calls or make them fail in other ways.

6. Current deployments respected.

The mandate points to the importance of considering current deployments and to consider them in the design.

While this is clearly a good idea it leads to various challenges. First, since almost no emergency services authorities are present in the discussion it is almost impossible to argue how the current emergency services deployment in Europe (from a technical point of view) looks like.

Even more important than the current deployment situation is the vision for the future since the transition to IP allows a number of short-comings of the current system to be corrected. Also in terms of finance it would be useful to make changes. In most cases emergency services authorities know about the deployment status and barely anyone else.

Consequently, the current deployment situation is mostly guessed (if considered at all).

7. Stakeholders missing.

The most severe aspect of the entire work is the lack of participation from a large part of the stakeholder community. While the European Commission may have hoped to involve more European stakeholders in the conversation it unfortunately turned out to be far less than available in other forums. This may have many reasons, including the cost of the participation in ETSI, lack of interest, recognition of ETSI in the standardization world, or the missing outreach.

In particular, the following stakeholders are largely absent:

• Emergency services authorities: For most meetings no emergency services authorities are present.
• Emergency services equipment vendors: Only telecommunication equipment manufacturers are present.
• VoIP providers, and OTT players in general: Only Microsoft is present.
• Regulators: only two regulators participate in the work.
• Enterprise networks. No enterprise network operators are interested in the work.
• ISPs

References

[0] EGEA COCOM, available at http://circa.europa.eu/Public/irc/infso/egea/home
[1] EC Mandate 493, available at http://www.etsi.org/images/files/ECMandates/m493.pdf
[2] H. Tschofenig, et al, “Trustworthy Location”, available at http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location