This is an emergency!

I used to enjoy the feeling to be for two weeks in the mountings skiing or canoeing down the river and not to know anything about what happens in the world, without a weather forecast and without knowing about my friends and family. That’s what I call relaxation 😉 Mobile phones changed our behavior significantly. We’re always reachable and we never ever really switch off unless there is no signal.  When there is no signal we start to feel uneasy – we can’t call and what if anything happens?

Mobile communication changed our way how we act in case of emergency and also its effectiveness. Emergency crews can get on scene much faster, have more information and can update emergency centers with the latest development. It is even possible to provide so called assisted first aid. On the other hand people rely sometimes on mobiles a bit too much.

„ZZS KV, KZOS v Jihlavě (01)“ od Radim Holiš, Wikimedia Commons. Licensed by CC BY-SA 3.0 cz via Wikimedia Commons


To support emergency calling is one of the basic requirements for VoLTE. When we need to reach a Public Safety Answering/Access Point (PSAP) or Emergency Control/Communication Centre (ECC), the common VoIP is not enough. That’s why we have some new elements in the IMS network. The relevant standards are RFC 50313GPP TS 24.229 and TS 23.167.

These days mobile operators mostly still fallback to CS, when an emergency call is requested.  If the P-CSCF recognizes an emergency number or urn:service:sos, it responds back with 380 Alternative Service with and XML body which contains <ims-3gpp> element, with the <alternative-service>.  The UE then attempts the CS domain.

But our goal is to support the Emergency Calling directly in IMS. What are the key functionalities which have to be supported?

  • Identification

It is important to identify an emergency call or registration. This has to be done even before other authentication checks. Sometimes operators support not only emergency number (e.g. 911, 999, 112) but also ‘panic numbers’ (e.g. 9999, 91111, etc.) and non-emergency numbers (e.g. 101 in England, Wales and Scotland). On the other hand we have to ensure that it is not misused to gain an unwanted access in to the network.

  • Prioritization

It is an legislative imperative that emergency calls have to be handle with higher priority. In case of a major disaster it can happen that normal calls or registration will be rejected in favor of  emergency calls.

  • Localisation

The location information is needed for 2 main reasons in emergency services. Firstly the location information is needed in order to determine which PSAP serves the area where the UE is currently located. The second purpose is for the PSAP to get more accurate or updated location information for the terminal during or after the emergency session.

  • Routing

There can be many PSAP servers serving different services (e.g. Ambulance, Police, Firefighters, Gas, ..) and they can be running on different technologies. IMS has to be able to route the call to the PSAP which is responsible for the call type of emergency and the area where the UE is located at. In case that the PSAP is not accessible the call has to be forwarded to another PSAP.

The architecture for Emergency calls looks like this:

Emergency services in VoLTE/IMS

In a nutshell when a subscriber dials an emergency number, it is being recognized by UE and forwarded to P-CSCF. P-CSCF routes all the emergency calls to E-CSCF. E-CSCF selects a particular PSAP (long number) based on the region (retrieved from LRF) and type of the service (Ambulance/Fire/Police/..).

The emergency aware IMS functions are:


  • Shall be able to detect an emergency session and indicate it to the network. However even if the UE can’t detect an emergency session access and IMS network have to be able to detect this.
  • The case where the UE does not have sufficient credentials to authenticate with the IMS shall also be supported.
  • In the case that UE is not already IMS registered, it shall perform a registration for the support of emergency services (emergency registration).
  • Should support a capability to obtain local emergency numbers from the network once such a capability has been defined and agreed.


  • The UE must be able to perform domain selection for emergency calls, and automatically be able to retry in the other domain if an emergency session attempt fails.
  • The UE must be able to detect if the network is not supporting IMS emergency and select the CS domain.
  • The UE must support SR-VCC for IMS emergency sessions.

UE also translates any indicated emergency number (3GPP TS 22.101)  to an emergency service URN –  urn:service:sos, urn:service:sos.ambulance, urn:service:sos.police,, urn:service:sos.marine, urn:service:sos.mountain, which is then inserted in R-URI. This enables to call an emergency service without dialing any particular number/short code.

Moreover a handset (ME) supports default numbers and emergency numbers retrieved from a SIM card:

  1. 112 and 911 shall always be available. These numbers shall be stored on the ME.
  2. Any emergency call number stored on a SIM/USIM when the SIM/USIM is present.
  3. 000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME.
  4. Additional emergency call numbers that may have been downloaded by the serving network when the SIM/USIM is present.

What particular numbers are supported and provisioned depends on local jurisdiction. For North America the E911 standards are maintained by NENA. In Europe the E112 service is standardized by EENA.


  • Handles registration requests with an emergency Public User Identifier like any other registration request.
  • Detects and prioritize an emergency session.
  • Prevents the assertion of an emergency Public User Identifier in non-emergency requests.
  • May query IP-CAN for location identifier.
  • Selects an E-CSCF in the same network to handle the emergency session request.
  • Should be able to identify the service data flow associated with emergency service and inform PCRF accordingly.
  • P-CSCF may insert or replace the PANI header with the information supplied by PCRF or NASS. Operator policies may determine whether to send UE’s PANI as is to the IMS network or to change it (or add it, if not coming from the UE).

Emergency-CSCF (E-CSCF)

  • Receives an emergency session establishment request from a P-CSCF.
  • May request the LRF to retrieve location information.
  • If required, the E-CSCF requests the LRF to validate the location information if included by the UE.
  • Determines or queries the LRF for the proper routing information/PSAP destination.
  • Routes emergency session establishment requests to an appropriate destination including anonymous session establishment requests.
  • It is a subject to national requirements, the E-CSCF may send the contents of the P-Asserted-ID or UE identification to the LRF.
  • Based on local policy, the E-CSCF may route the emergency IMS call to ECS for further call process.
  • Forwards the SIP request containing the UE’s location information to the PSAP/Emergency Centre or BGCF/MGCF. The location information can contain explicit location information and/or a reference key to allow the PSAP to retrieve location at a later stage.

 Location Retrieval Function (LRF)

  • Handles the retrieval of location information for the UE.
  • May interact with a separate Routing Determination Function (RDF) or contain an integrated RDF in order to obtain routing information.
  • May interact with a separate Location Server or contain an integrated Location Server in order to obtain location information.
  •  The LRF may interact with or contain other types of location server functions in order to obtain location information.
  • Location indicated in geographical terms, for example geographical coordinates or street address IETF RFC 4119

 Emergency Call Server (ECS)

  • The functional entity consists of a Location Retrieval Function (LRF) and either a routing proxy or a redirect server.

Emergency Access Transfer Function (EATF)

  • A similar functionality as the ATCF for regular calls (in this case we don’t anchor media, similar to R9 access transfer). EATF is identified by E-STN-SR.


  • Determines the duration of the registration for a received Emergency Registration,based on the Expires header in the received REGISTER request and based on local policy of the serving system.
  • S-CSCF may insert or replace the PANI header value with the information supplied by HSS.
  • In Roaming scenario it can happen that the originated network doesn’t recognize the emergency number and call is routed to home network.


  • It shall be possible to access the IP-CAN without sufficient security credentials.
  • It shall be possible to reject requests from UE without sufficient security credentials to establish bearer resources
  • In the case that the IP-CAN receives a request to establish bearer resources for emergency services, it shall be possible for the IP-CAN to prioritize emergency services traffic. PCC (Policy and Charging Control) methods may be used to inform the IP-CAN and request appropriate handling of the emergency service. The QoS information for emergency traffic is specified in TS 23.203.

Emergency Call Flow

Very high-level flow for a call establishment can look like this

Emergency Call Flow

Emergency Call Flow

Note, between E-CSCF and LRF we can use also SIP redirect mechanism.

The specification distinguish mainly whether the UE did or did not do the emergency registration before issuing the emergency call. Note that the PSAP can request a call back to the UE even in case when the UE is not registered in the network. For more details please refer to the spec.

P-CSCF, EATF and E-CSCF are always located in the same network. In case the UE is roaming, they are located in visited network (see also TS 23.237). From the practical point of view the E- functionality is often a part of SBC or the SBC (P-CSCF) is routing the emergency traffic to a dedicated E-CSCF. The emergency call is always performed in the access network (so we should not route to the home network in case of roaming). For S8HR roaming the option is to use CS or call without emergency registration (3GPP TS 23.167).

The location information can be taken from SIP P-Access-Network-Info (PANI) header created by UE and Area Service Number is derived from the utran-cell-id which is present in the header. E.g.:

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1230405670089101
 123                : MCC
 04                 : MNC
 0567 (HEX)         : LAC
 00891 (HEX)        : eNB ID   -> 0002193 (7 digits dec)
 02 (HEX)           : Cell ID  -> 002 (3 digits dec)
 ⇒ Area Service Number: 911123040002193002

where 911 is the emergency call indication.

Usually for non-emergency services (common calls, lawfull intercept, location based charging, etc.) we don’t trust the location (or any other :)) information provided by UE and we use either the information provided by P-CSCF or even S-CSCF (see above). This information may not be accurate but it is sufficient and trusted. However in case of emergency calls we require more accurate data and we use the PANI header provided by UE. The Cell Identifier, Location Identifier, or WLAN Identifier coming in the UE’s PANI is then mapped by using the pre-configured addresses of the cell tower (for Cell/Location ID), home address (for WLAN ID) in the network databases. (For more details see the 3GPP 24.229 and 3GPP 23.003, RFC 3455)

Other posts related to emergency services:




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s