Emergency Call 4-0-2107v1

No further reproduction or networking is permitted. Distributed by Nokia.
Copyrighted material licensed to jeetoo.ramprakash.ext@nokia.com on 17-11-2022.

VoX Core Engineered System 21.6 (Cloud Native)
Emergency Call for the VoX Core

Engineered System
DN1000030711
Issue 4-0
1 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Disclaimer
The information in this document applies solely to the hardware/software product (“Product”) specified herein, and
only as specified herein. Reference to “Nokia” later in this document shall mean the respective company within Nokia
Group of Companies with whom you have entered into the Agreement (as defined below).
This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the purposes
defined in the agreement between You and Nokia (“Agreement”) under which this document is distributed. No part of
this document may be used, copied, reproduced, modified or transmitted in any form or means without the prior
written permission of Nokia. If You have not entered into an Agreement applicable to the Product, or if that
Agreement has expired or has been terminated, You may not use this document in any manner and You are obliged to
return it to Nokia and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You assume full
responsibility when using it. Nokia welcomes your comments as part of the process of continuous development and
improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements concerning the
suitability, capacity, fitness for purpose or performance of the Product are given solely on an “as is” and “as available”
basis in this document, and Nokia reserves the right to change any such information and statements without notice.
Nokia has made all reasonable efforts to ensure that the content of this document is adequate and free of material
errors and omissions, and Nokia will correct errors that You identify in this document. Nokia's total liability for any
errors in the document is strictly limited to the correction of such error(s). Nokia does not warrant that the use of the
software in the Product will be uninterrupted or error-free.
NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF
AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE, IS MADE IN RELATION TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE LIABLE FOR ANY
DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY
LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS
OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE
CASE OF ERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT.
This document is Nokia proprietary and confidential information, which may not be distributed or disclosed to any
third parties without the prior written consent of Nokia.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be
trademarks of their respective owners.
Copyright © 2020 Nokia. Nokia confidential.
Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after
having carefully read the safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental
Information” part of this document or documentation set.
Nokia is continually striving to reduce the adverse environmental effects of its products and services. We would like to
encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle
product packaging and follow the recommendations for power use and proper disposal of our products and their
components.
If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please
contact us at Nokia for any additional information.
2 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

1 Summary of changes
Changes between document issues are cumulative. Therefore, the latest document issue
contains all changes made to previous issues.
Change See
Products and functionalities have been Products and functionalities in the scope of
updated to reflect the VoX Core Engineered the VoX Core Engineered System
System 21.6 package
Summary of changes has been updated Summary of changes
Summary of changes is now a numbered Table of Contents
heading for easier navigation, which
necessitated an update in the table of
contents
Table 1 Summary of changes between issues 4-0 and 3-0
Change See
Products and functionalities have been updated to Products and functionalities in the scope of the VoX
reflect the VoX Core Engineered System package 21.3 Core Engineered System
Editorial changes and removal of obsolete paragraphs Throughout the document
Summary of changes has been updated Table 2 Summary of changes between issues 3-0 and 2-
5
Change See
The use-cases for 5G Emergency call hs been updated Use cases for 5G Emergency call
to reflect the current scope of the Core Engineered
System
Editorial changes Throughout the document
3 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Change See
The scope of the Emergency Call for the VoX

Core Engineered System document has been
changed to reflect the scope of the VoX Core
Engineered System. This includes:
• 5G-related use cases have been
4.1. VoNR emergency call with normal 5G
addedInformation regarding the products
registration
which are not in the scope of the VoX
Core Engineered System have been 4.2 Emergency call with EPS Fallback
removed from the document. 4.3 Emergency services fallback
• Where applicable, products and
5G Emergency call overview has been added
functionalities have been updated
according to the VoX Core Engineered
System portfolio, restricting the network
functions and releases to those used in
the first VoLTE Core Engineered System.
Summary of changes have been updated. Summary of changes for Emergency Call for
VoLTE Core Engineered System
Table 4 Changes between version 2-0 and 1-0
4 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Contents
1 Summary of changes ........................................................................................................................... 3
2 Products and functionalities in the scope of the VoX Core Engineered System ....................... 7
3 Overview of Emergency Call in the VoX Core Engineered System ............................................... 8
3.1 VoLTE and VoWiFi ......................................................................................................................... 8
3.2 5G Emergency Call ....................................................................................................................... 9
4 Detailed description of VoLTE and VoWiFi Emergency Call ......................................................... 11
4.1 Establishment of the emergency bearer................................................................................ 14
4.2 Priorities in EPS (bearer priority) ............................................................................................. 14
4.3 Emergency registration............................................................................................................. 15
4.4 Emergency call and Emergency SRVCC ................................................................................... 16
4.5 Emergency call for Voice over Wi-Fi ........................................................................................ 18
4.6 The Feature Expansion Environment servlet ......................................................................... 19
4.7 Interfaces between network elements in VoLTE and VoWiFi System for Emergency Call
19
5 Use cases for VoLTE and VoWiFi Emergency Call .......................................................................... 21
5.1 EPS Emergency and Voice services support .......................................................................... 21
5.2 Emergency Number List handling............................................................................................ 21
5.3 VoLTE emergency attach .......................................................................................................... 22
5.4 VoWiFi emergency attach ......................................................................................................... 23
5.4.1 VoWiFi emergency attach: HSS-based Emergency APN ............................................... 23
5.4.2 VoWiFi emergency attach: AAA-based Emergency APN ............................................... 25
5.5 Registration with VoLTE and VoWiFi Emergency Call ............................................................ 28
5.6 UE detectable emergency session .......................................................................................... 30
5.7 Non UE detectable emergency session .................................................................................. 33
5.8 UE detectable emergency session – without IMS registration ............................................ 35
5.9 SRVCC for IMS emergency call ................................................................................................. 36
5.10 SRVCC temporary rejection in Emergency call .................................................................. 38
5.11 PSAP Emergency Callback ..................................................................................................... 41
6 Use cases for 5G Emergency call ..................................................................................................... 43
6.1 Emergency services fallback ..................................................................................................... 43
7 Engineering considerations for VoLTE, VoNR and VoWiFi Emergency Call ................................ 45
5 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

7.1 Provisioning Emergency Call..................................................................................................... 45
8 Associated documents for VoLTE, VoNR and VoWiFi Emergency Call ........................................ 46
9 Acronyms for VoX Emergency Call .................................................................................................. 48
List of tables
Table 1 Summary of changes between issues 4-0 and 3-0 .................................................................. 3
Table 4 Changes between version 2-0 and 1-0 ...................................................................................... 4
Table 5 Products and functionalities in the scope of the VoX Core Engineered System ................. 7
Table 6 Emergency and authentication-related subscriber information .......................................... 13
Table 7 IMs emergency call alternatives ................................................................................................. 14
Table 8 - List of acronyms ........................................................................................................................ 48
List of figures
Figure 1 VoLTE and VoWIFi Emergency call reference architecture ..................................................... 9
Figure 2 CS fallback for emergency call .................................................................................................. 12
Figure 3 IMS emergency call ..................................................................................................................... 12
Figure 4 Priorities in the EPS and emergency call ................................................................................. 15
Figure 5 IMS emergency registration architecture ............................................................................... 16
Figure 6 VoLTE emergency attach .......................................................................................................... 23
Figure 7 VoWiFi emergency attach: HSS-based Emergency APN........................................................ 25
Figure 8 VoWiFi emergency attach: AAA-based Emergency APN ........................................................ 27
Figure 9 IMS emergency registration ...................................................................................................... 29
Figure 10 IMS emergency registration with VoWiFi .............................................................................. 30
Figure 11 UE detectable IMS emergency session with VoLTE, part 1 ................................................ 31
Figure 12 UE detectable IMS emergency session with VoLTE, part 2 ................................................ 32
Figure 13 UE detectable IMS emergency session with VoWiFi ............................................................ 33
Figure 14 Emergency call SRVCC ............................................................................................................. 37
Figure 15 Emergency Session Transfer call, PSI routing ...................................................................... 38
Figure 16 Emergency Session Transfer call and IMS DNS routing ...................................................... 38
Figure 17 Pre-alerting phase SRVCC attempt ....................................................................................... 40
Figure 18 Alerting phase SRVCC attempt .............................................................................................. 41
Figure 19 Emergency Session Fallback based on 3GPP TS 23.502 .................................................... 44
Figure 20 Emergency services fallback ................................................................................................... 44
6 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

2 Products and functionalities in the scope of the
VoX Core Engineered System
Product Functionality Software release
CloudBand Infrastructure Network Function Virtualization Infrastructure software

Software (CBIS) (OpenStack VIM) 20 SP2/PP3
CloudBand Application Manager
(CBAM) Virtualized Network Function Manager (VNFM) 21
20 FP2 (on bare
Nokia Container Services (NCS) Containers as a service (CaaS) metal)
21.5 (CN-B)
(dedicated
Zero Touch Services (ZTS) Common O&M services instance per CNF)
serving call state control function (S-CSCF)
interrogating call state control function (I-CSCF)
emergency call state control function (E-CSCF)
CFX-5000 Cloud emergency access transfer function (EATF) 21.5 (CN-B)
breakout gateway control function (BGCF)
transit routing control function (TRCF)
multimedia telephony service (MMTel)

Nokia Telecom Application
Server (Nokia TAS) MCS feature IP multimedia service switching function (IM-SSF) 21.2 (CN-B)
set service centralization and continuity application server
(SCC AS)
IP short message gateway (IPSM-GW)
proxy call state control function (P-CSCF)
access transfer control function (ATCF)
IMS application layer gateway (IMS-ALG)
Nokia Session Border Controller
access transfer gateway function (ATGW) 21.5 (CN-B)
(SBC)
IMS access gateway (IMSAGW)
interconnect border control function (I-BCF) (optional)
interconnect border gateway function (I-BGF) (optional)
Radisys Media Resource multimedia resource function processor (MRFP)
cd16.0 (CN-B)
Function (cdMRF) multimedia resource function controller (MRFC)
ENUM
NetNumber TITAN 20.06 (VNF)
Ut Proxy
element management system (EMS) 20 SP2105 or
NetAct
network management system (NMS) later releases
FP8 MR or later
Nokia Archive Cloud Backup and restore
release
NetGuard Identity Access 19 SP4 or later
Identity Access Manager
Manager release
NetGuard Audit Compliance 19 SP4 or later
Audit Compliance Manager
Manager release
Table 5 Products and functionalities in the scope of the VoX Core Engineered System
7 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

3 Overview of Emergency Call in the VoX Core
Engineered System
The Voice over LTE (VoLTE), Voice over Wi-Fi (VoWiFi) and Integrated IP Multimedia Subsystem
(IMS) services solution supports emergency calls for VoLTE subscribers. The emergency services
for the 5G system are defined in the 3GPP TS 23.501 System architecture for the 5G System
(5GS) and the 3GPP TS 23.502 Procedures for the 5G System; Stage 2 (Release 15). The actual
IMS-based emergency call concept remains the same as with the VoLTE emergency service.
3.1 VoLTE and VoWiFi
The VoLTE and VoWiFi Emergency Call solution is based on the following procedures:
• The Universal Integrated Circuit Card (UICC) of the User Equipment (UE) has the generic
Emergency Number list and the Evolved Packet Core (EPC) can upgrade this list during
EPC attach and Tracking Area change.
• The User Equipment (UE) and Evolved Packet Core (EPC) support emergency bearers as
well as emergency attach procedures.
• The Proxy Call Session Control Function (P-CSCF) detects emergency calls and routes
them to the Emergency Call Session Control Function (E-CSCF).
• The E-CSCF provides integrated Routing Determination Function (RDF) to route
emergency calls to the correct Public Safety Answering Point (PSAP) destination address
based on the location of the UE.
• The Serving Call Session Control Function (S-CSCF) supports the IMS emergency
registration procedure.
• The Emergency Access Transfer Function (EATF) supports Single Radio Voice Call
Continuity (SRVCC) handover to the Circuit-Switched (CS) domain for emergency calls.
The Policy and Charging Rules Function (PCRF) supports the default and the dedicated
emergency bearers.
Note: The UE and network must support 3GPP TS 24.229: IP multimedia call control protocol
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 and
Release 9 emergency procedures as specified in 3GPP TS 24.301: Non-Access-Stratum (NAS)
protocol for Evolved Packet System (EPS); Stage 3.
Note: The HSS may provide the subscriber specific Reference Location for routing the
emergency call towards the closest PSAP. This solution can be used for subscribers with some
type of fixed line access.
8 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 1 VoLTE and VoWIFi Emergency call reference architecture
The E-CSCF handles IMS emergency requests and selects an emergency center or PSAP based
on the location of the caller and the type of emergency.
The Location Retrieval Function (LRF) handles the retrieval of the location information for the
UE, including Interim Location, Initial Location and Updated Location (if needed).
PSAP selection can be:
• based on the Feature Expansion Environment (FEE) of the CFX-5000 (RDF)

• based on the Media Gateway Control Function (MGCF)
• through integrating a 3rd party RDF/LRF service
The P-CSCF, E-CSCF, LRF and EATF are always located in the serving network to which the UE is
attached (the home network, or the visited network while roaming). The serving network
provides the user with access to the services of their home environment. When roaming, the
serving network is referred to as the visited network.
If CS or LTE accesses are not available, or the UE does not detect an emergency call attempt,
the UE may try to make an emergency call via Wi-Fi. In this case, the support of emergency calls
via Wi-Fi is implementation specific.
3.2 5G Emergency Call
The 5GS provides specific emergency Data Network Name (DNN) to be used for emergency
call/service purpose similarly as EPS provides it through emergency Access Point Name (APN).
9 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

The emergency DNN is established using emergency PDU session. The emergency PDU session
can be initiated with normal 5G registration or with emergency registration to the 5GS. During
emergency registration the subscriber is in limited service state and it may be unauthenticated.
This includes the case when no SIM card is available, and the IMEI/PEI is used for identification in
the network.
After the emergency PDU session successfully established the UE has to use the IMS emergency
service to reach the PSAP via a voices session.
There is a specific Emergency service fallback procedure defined in the 5GS. The UE can request
fallback to 4G EPS with the Service request procedure before establishing emergency PDU
session in the 5G. This results handover or redirection to the EPS and the emergency service/call
will be provided via the 4G EPS access to the UE.
Figure 2 shows the overall architecture for the 5G Option2 based emergency service. This is
based on the IMS Services for 5G architecture with the extension of location service and
emergency related elements. These elements are the LMF, GMLC/LRF, E-CSCF and
interconnection towards the PSAP.
Figure 2 5G emergency call reference architecture
10 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

4 Detailed description of VoLTE and VoWiFi
Emergency Call
This section provides detailed information regarding Voice over LTE (VoLTE), Voice over Wi-Fi
(VoWiFi) emergency calls, such as solution differences, IP Multimedia Subsystem (IMS) emergency
calls, Circuit-Switched (CS) fallback for emergency calls, subscriptions, emergency call
alternatives, emergency bearer establishments, bearer priorities, emergency registrations,
emergency Single Radio Voice Call Continuity (SRVCC), and the Feature Expansion Environment
(FEE) servlet.
Different solutions
Each operator may have a completely different solution, because aside from the framework
provided by standards organizations, there are:
• local regulations defining the use of Location Services in order to determine the closest
Public Safety Answering Point (PSAP) to the caller and a requirement to get more
accurate location information for the terminal during or after the emergency call.
• differences between local, national and international regulations
• differences between operator policies filling the gaps from standards and regulations
The combination of the following conditions determines a solution for emergency calls:
• the User Equipment (UE) has or has no valid subscription
• the UE is authenticated or not authenticated in the network
• the UE is authorized to use Packet-Switched (PS) services
• there is a requirement to handle Emergency Callback from the PSAP
Note: While not mandatory due to the reasons listed above, the use of a Public Safety Answering
Point (PSAP) is always the preferred option for Emergency Calls in the VoLTE Core Engineered
System.
Emergency calls with single IMS subscription and with dual IMS/CS registration
3GPP specifications earlier than Release 9 specified that mobile emergency calls are handled by
the CS domain. The main reason for not using IMS for emergency calls in a mobile session is due
to missing location information in the IMS session setup. Therefore, if an emergency call is
received over mobile access, it will be gracefully rejected by the Proxy Call Session Control
Function (P-CSCF). This rejection includes a reason for this special handling within an XML body,
which instructs the UE to use the CS domain. This mechanism can only be used for emergency
calls received over mobile access if, in addition to an IMS registration, a CS registration is
available.
11 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 2 CS fallback for emergency call
Figure 3 IMS emergency call
However, emergency calls received over other access networks, such as fixed or WLAN access
networks, must not be rejected if appropriate location information is available in the IMS. The
IMS can then handle these emergency calls, and the Call Session Control Function (CSCF)
guarantees the appropriate routing via the Media Gateway Control
Function (MGCF) to an emergency service center in the Public Switched Telephone Network
(PSTN). To differentiate between emergency and normal calls, P-CSCFs are preconfigured with
emergency numbers that are used in the operator network.
Subscription
Information about a user's subscription is located in both the Universal Integrated Circuit Card
(UICC) and the Home Subscriber Server (HSS).
UICC HSS
International Mobile Subscriber Identity: IMPU/IMPI/IMSI/MSISDN

Subscriber Identity (IMSI)
12 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

UICC HSS
Authentication Key (Ki) Subscriber Authentication Key (Ki)
Operator-Specific Service provisioning: filter criteria, mobility

Emergency Number information, service information
Location Area Identity (LAI) Quality of Service information
List of services
Table 6 Emergency and authentication-related subscriber information
The Emergency Session Transfer Number for SRVCC (E-STN-SR) is configured to the Mobile
Softswitch (MSS) enhanced for SRVCC, and the Public Service Identity (PSI) is configured to the
serving network HSS for session transfer call routing toward the Emergency Access Transfer
Function (EATF).
Emergency call alternatives
The IMS emergency call alternatives listed in Table 6: IMS emergency call alternatives are valid
for both VoLTE and VoWiFi accesses.
Number Case 1st attempt 2nd attempt Description

1 UE CSFB EC The UE selects the CS.
detectable
2 UE IMS EC CS EC The P-CSCF rejects with SIP 380
detectable “Alternative service.”
3 UE IMS EC Emergency connectivity, default EPS
detectable emergency bearer allocation, IMS
emergency registration and
authentication, default bearer supervision,
IMS emergency call set-up, emergency call
anchoring at the EATF, dedicated EPS
emergency bearer allocation and session
routing to the PSAP.
4 UE IMS EC CS EC, if not Emergency attach, default EPS emergency
detectable, non- allowed bearer allocation, IMS emergency call set-
authenticated user up, emergency call anchoring at the EATF,
dedicated Evolved Packet System (EPS)
emergency bearer allocation and session
routing to the PSAP.
5 Non-UE IMS EC CS EC The P-CSCF rejects with SIP 380
detectable “Alternative service.”
6 Non-UE IMS EC The P-CSCF rejects with SIP 380
detectable “Alternative service, IMS emergency
session,” the UE shall continue as UE
detectable emergency call.
13 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Number Case 1st attempt 2nd attempt Description
7 Non-UE IMS EC IMS emergency attempt is routed to E-
detectable CSCF.
Table 7 IMs emergency call alternatives
4.1 Establishment of the emergency bearer
The Mobility Management Entity (MME) and the Access Security Management Entity (ASME) take
part in the authentication process to establish the emergency bearer. The Mobility Management
Entity (MME) function is provided by the Cloud Mobility Manager (CMM) in the Nokia Reference
architecture.
Evolved Packet System (EPS) Authentication and Key Agreement (AKA) Procedure
The Mobility Management Entity (MME) acts as Access Security Management Entity (ASME)
providing the following functionalities:
• authenticates the User Equipment (UE)

• provides authentication of the network for the UE
• generates and exchanges security keys
• provides temporary UE identities
• provides ciphering and integrity protection services
The UEs that are not in limited service state, shall initiate normal initial attach when not already
attached to receive EPS emergency bearer services. The emergency bearer services are provided
to normal attached UEs.
As for UEs that are in limited service state, the emergency bearer services are provided
depending on local regulations and operator’s policy. The MME allows or rejects an emergency
attach request for UEs in limited service state. For instance, local regulations may deny
emergency services from UEs without a Universal Integrated Circuit Card (UICC).
If the pre-defined pool of IP addresses configured in the emergency Access Point Name (APN) is
fully used up, then the UE can perform a fallback to Circuit-Switched (CS).
4.2 Priorities in EPS (bearer priority)
Each Evolved Packet System (EPS) bearer has Quality of Service (QoS) parameters with an
Allocation and Retention Priority (ARP), which contains a priority level that defines the relative
importance of a resource request. This allows the decision whether a bearer establishment or
modification request can be accepted or needs to be rejected in case of limited resources.
An EPS bearer, either Guaranteed Bit Rate (GBR) or Non-GBR, has the following bearer-level QoS
parameters:
• QoS Class Identifier (QCI)

• Allocation and Retention Priority (ARP) The ARP contains information about:
14 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

• priority level (with a range of 1 to 15 with 1 as the highest level of priority) Priority levels
are typically used for the following purposes:
o the admission control of GBR traffic
o ensuring the availability of emergency bearers
o to decide which existing bearers to preempt, or to free up, during resource
limitations
The recommended value for priority level is 2.
• pre-emption capability (with possible values of yes or no)
The pre-emption capability information defines whether a service data flow can
get resources that were already assigned to another service data flow with a lower
priority level.
• pre-emption vulnerability (with possible values of yes or no)
The pre-emption vulnerability information defines whether a service data flow can
lose the resources assigned to it in order to admit a service data flow with higher
priority level.
Priorities for voice, video and Session Initiation Protocol (SIP) signaling in the EPS are described
in the following figure:
Figure 4 Priorities in the EPS and emergency call
4.3 Emergency registration
The IP Multimedia Subsystem (IMS) emergency registration and authentication are home
network functionalities. Emergency registration is allowed in all cases including blocked users.
Emergency registration is performed at the Call Session Control Function (CSCF), the Home
Subscriber Server (HSS) enables the registration of IP Multimedia Public Identity (IMPU) or IMPI.
The P-CSCF function is provided by the Nokia SBC in the Nokia Reference architecture. It can
additionally be provided by the CFX-5000.
15 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

From a roaming point of view, the serving network can perform the emergency call according to
an operator-configurable option — even if authentication fails. Therefore, roaming cases are not
actual roaming cases, and the serving network handles the call.
Figure 5 IMS emergency registration architecture
Emergency registration is indicated by the sos parameter in the Contact header and always
expires using a timer. The emergency registration Access Point Name (APN) is configurable, and
roaming control is suppressed.
Normal and emergency registrations are supported in parallel (for which there are different IP
addresses), but the IP Multimedia Private Identity (IMPI) is shared. Emergency registration is
always allowed, even for blocked users. Emergency registration is performed at the Call Session
Control Function (CSCF), and the Home Subscriber Server (HSS) allows the registration for the
proper IP Multimedia Public Identity (IMPU) or IMPI.
Emergency registration uses IMS Authentication and Key Agreement (AKA) (over IPsec and TSL)
authentication. Once a public user identity and the associated contact address is registered,
neither the UE nor the network will perform a deregistration. The UE will be deregistered when
the emergency registration expires.
4.4 Emergency call and Emergency SRVCC
IP Multimedia Subsystem (IMS) emergency call and emergency Single Radio Voice Call Continuity
(SRVCC) are serving network functionalities allowing uninterrupted emergency voice call when
moving out of LTE coverage. The EATF and E-CSCF functionalities are provided by the CFX-
5000, the P-CSCF functionality is provided by the Nokia SBC. Additionally, the CFX-5000 can
also provide the P-CSCF functionality.
Emergency SRVCC allows an uninterrupted emergency voice call when moving from the Long-
Term Evolution (LTE) coverage to the Circuit Switched (CS) coverage.
16 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

An LTE User Equipment (UE) performs an emergency registration via the default emergency
bearer and then initiates an emergency call. This triggers the Proxy Call Session Control Function
(P-CSCF)/Policy and Charging Rules Function (PCRF) to request a voice bearer from the Evolved
Packet System (EPS). As a result, the EPS establishes a dedicated emergency bearer for a voice
call.
The role of the Emergency Call Session Control Function (E-CSCF) is to involve
Emergency Access Transfer Function (EATF) — if a handover from an LTE to CircuitSwitched (CS)
domain is possible — and to route the call to the correct Public Safety Answering Point (PSAP).
The Routing Determination Function (RDF) provides the Public Safety Answering Point (PSAP)
address based on the UE’s location. The RDF can be integrated to the E-CSCF. A suitable PSAP
can also be determined based on the information received from the UE or based on network-
provided location information.
The Initial Filter Criteria (iFC) at the E-CSCF must be configured properly so that only the initial
emergency INVITE requests with the International Mobile Equipment Identity (IMEI) value in the
Contact header are triggered to the EATF. Additional information (for example, the P-Access-
Network-Info header) may be used for the triggering.
The E-UTRAN makes the decision about the handover (HO) request based on the UE's
measurement reports and informs the Mobility Management Entity (MME) that a PacketSwitched
(PS) to CS handover is required.
The MME initiates the emergency SRVCC for voice component toward the SRVCC Mobile
Softswitch (MSS).
The MSS provides the call control and the control of multimedia gateways, allowing the same
circuit-switched services as the mobile services switching centre (MSS). It is a media gateway
controller (MGC) and a further development of the 3G MSS. The MSC server integrates the
functions of a mobile services switching centre (MSS), visitor location register (VLR), service
switching point (SSP), and MGW control into a single entity.
SRVCC functionality in the MSS acts as a CS-anchor-MSS toward the target 2G/3G CS domain
and initiates the session transfer procedure to the anchoring point by using the preconfigured
Emergency Session Transfer Number for SRVCC (E-STN-SR). The SRVCC MSS, together with the
EATF anchor, hides mobility between the LTE and the 2G/3G CS domain from the remote side of
the call.
The E-STN-SR must be provisioned in the HSS as a Public Service Identity (PSI) user with direct
routing activated. Session Initiation Protocol Uniform Resource Identifiers (SIP URI) and/or Tel
URI forms are used, depending on the R-URI sent from the MSS.
The EATF IP address is static information which cannot be changed. The address cannot be
transferred to the MSS because it is preconfigured. The standard defines one EATF address
without defining a resilience solution.
Transport type between the MSS and the EATF is pre-defined in the MSS.
17 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

The IP version protocol is defined in the following way: for the user plane, the UE decides to ask
for an IPv6 or an IPv4v6 address, according to the standard. The IP version selection on the
control plane is operator-configured.
4.5 Emergency call for Voice over Wi-Fi
Different types of devices with Voice over Wi-Fi (VoWiFi) support may behave differently in case
of emergency calls. When initiating a call from untrusted access, UE behavior is the same as that
of a VoLTE enabled device in LTE access. The E-CSCF and EATF functions are provided by the
CFX-5000 in the Nokia Reference architecture. Additionally, the CFX-5000 can provide P-CSCF
functionality. The Policy and Charging Rules Function (PCRF) is provided by the SPS-P in the
Nokia Reference architecture.
Untrusted Access VoWiFi emergency call solution
If a User Equipment (UE) initiates an emergency call in untrusted access, it is assumed to behave
the same as a Voice over LTE (VoLTE) device in LTE access.
• The UE provides the Emergency Access Point Name (APN) in the IKEv2 Authentication and
the Tunnel Setup procedure.
• The Evolved Packet Data Gateway (ePDG) requests authentication and authorization
from the Authentication, Authorization, and Accounting (AAA) server.
• The AAA server requests the subscriber profile from the HSS and either uses the locally
configured Emergency APN or receives it from the Home Subscriber Server (HSS). If the
Emergency APN configuration for Wi-Fi is provided by the HSS, sending to the Mobility
Management Entity (MME) over the S6a interface can be blocked.
• Upon successful authentication, the Emergency APN configuration is sent to the ePDG.
• The ePDG selects the Packet Data Network Gateway (P-GW) and establishes the Default
Evolved Packet System (EPS) Emergency bearer based on the received Emergency APN
configuration.
• The UE can then do the emergency registration and the emergency call, including the sos
indication to the R-URI and IMEI in SIP INVITE Contact header instance parameter.
• The Proxy Call Session Control Function (P-CSCF) detects an emergency call and routes
the call to the Emergency Call Session Control Function (E-CSCF). Emergency Access
Transfer Function (EATF) anchors the emergency call control plane.
• Lawful Interception (LI) for emergency calls is done via the P-CSCF/Border Gateway
(BGW).
• The Policy and Charging Rules Function (PCRF) creates the dedicated emergency bearers
to the P-GW during emergency call.
• The same Emergency APN must be configured in the HSS, MME, ePDG and UE.
• Call back as a normal terminating call from the Public Safety Answering Point (PSAP) by
use of the Mobile Subscriber Integrated Services Digital Network (ISDN) Number
(MSISDN).
• Because the home network control model is used in VoWiFi calls, and the call cannot be
routed to the PSAP in the visited network, the E-CSCF rejects emergency calls initiated
from the visited network.
18 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Note: Emergency call mobility is not supported between Wi-Fi and LTE because the used P-GW
address is not notified to the HSS from LTE or from Wi-Fi.
The non-UE-detected emergency call is handled as a normal VoWiFi call until the PCSCF, where
the call can be detected as emergency call, is routed to the E-CSCF or rejected with a 380
response with alternative service.
4.6 The Feature Expansion Environment servlet
The Feature Expansion Environment (FEE) of CFX-5000 provides a mechanism for the release of
independent developments of small adaptations and extensions to the IP Multimedia Subsystem
(IMS) call control.
Emergency call routing functionality is implemented in the FEE servlet for the following reasons:
• Emergency call functionality is specified by various standardization bodies, including

3GPP (3GPP TS 23.167: IP Multimedia Subsystem (IMS) emergency sessions) and National
Emergency Number Association (NENA) i2 and i3.
• Project-specific adaptations (for example, location databases) can be done more easily in
a SIP servlet.
• The adaptations can include not only minor SIP header content, but possibly new
communication interfaces.
• The routing in dependence on radio network sector IDs requires the handling of large
configuration tables, which is currently not supported in the CFX-5000. Thus far, two FEE
servlet applications (elrf and nena) for the emergency service have been implemented. In
both cases, the service is running on the FEE and must be triggered via Initial Filer
Criteria (iFC) at the Emergency Call Session Control Function (ECSCF) or Serving Call State
Control Function (S-CSCF).
The NENA servlet can handle Cell-ID parameter in the P-Access-Network-Info (PANI) header for
eUTRAN, UTRAN, GERAN and High Rate Package Data (HRPD) mobile network types. If a Cell-ID
parameter is not defined, the servlet defaults to HRPD.
4.7 Interfaces between network elements in VoLTE and VoWiFi System for Emergency
Call
Voice over LTE (VoLTE), Voice over Wi-Fi (VoWiFi) Emergency Call management in different
network elements is carried out through various interfaces.
The Mw interface is the reference point between the Proxy Call Session Control Function (P-
CSCF) and Emergency Call Session Control Function (E-CSCF). The Mw interface supports the
instance-id media feature tag with value based on the International Mobile Equipment Identity
(IMEI).
The I4 interface is the reference point between the E-CSCF and the Emergency Access Transfer
Function (EATF).
19 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

The I5 interface is the reference point between the Interrogating Call Session Control Function
(I-CSCF) and the EATF.
The SWm interface is the reference point between the Authorization, Authentication and
Accounting (AAA) interface and Evolved Packet Data Gateway (ePDG).
The TDM/IP interface is the reference point between the media gateway (MGW) and the public
safety answering point (PSAP).
The ISUP interface is the reference point between the mobile subscriber station/media gateway
control function (MSS/MGCF) and the public safety answering point (PSAP).
20 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

5 Use cases for VoLTE and VoWiFi Emergency Call
This section details the use cases for VoLTE and VoWiFi Emergency Call.
5.1 EPS Emergency and Voice services support
In case the Evolved Packet System (EPS) voice and emergency services are supported, the User
Equipment (UE) selects the CS or EPS domain to establish the emergency call.
Purpose
The User Equipment (UE) receives information that the Evolved Packet System (EPS) voice and
emergency services are supported. The user equipment uses this information to select the
domain (CS or EPS) for emergency calls.
The default EPS emergency bearers and the emergency Access Point Name (APN) are established
for IP Multimedia System (IMS) emergency services.
Preconditions
IMS Emergency Call is supported by the EPS.
Procedure
During the EPS attach and tracking area update the support of voice and emergency services are
indicated to the UE in non-access stratum (NAS) procedures.
As a result, the UE can store the network's emergency and voice service support information and
can follow the emergency call domain selection rules.
5.2 Emergency Number List handling
Emergency Number List handling is available if the Emergency numbers are saved in the UMTS
Integrated Circuit (IC) card (UICC).
Purpose
To deliver the local public land mobile network (PLMN) based Emergency Number List to the User
Equipment (UE) for emergency call detection.
Preconditions
• Emergency numbers are saved in the UMTS Integrated Circuit (IC) card (UICC).
• The following method will be supported:
• IP Multimedia Subsystem (IMS) emergency call is supported by the Evolved Packet
System (EPS).
• IMS emergency call is supported by the UE.
21 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

• PLMN-based Emergency Number List is configured at the EPS.
Procedure
The Emergency Number List is delivered to the UE during non-access stratum (NAS) procedures
(ATTACH or TRACKING AREA UPDATE).
After the Emergency Number List delivery, the UE can detect the emergency call based on the
received list and emergency numbers saved in UICC.
If the Emergency Number List is not received at the UE during EPS ATTACH or TRACKING AREA
UPDATE:
• if the PLMN is not changed, the previous list, that was received earlier is valid
• if the PLMN changes the emergency numbers saved in the UICC are valid
The operator can download the emergency number list to the UE to avoid non-UE detectable
emergency sessions.
5.3 VoLTE emergency attach
In this case, the UE attaches to the EPS using the default emergency bearer defined with PDN
Connectivity Request. The Serving-/Packet Data Network Gateway (S-/P-GW) receives a Create
Session Request from the MME, then the default emergency bearer is authorized and allocated
by the PCRF and the eNodeB respectively.
Purpose
Emergency User Equipment (UE) attaches to the Evolved Packet System (EPS).
Procedure
Before the UE detectable emergency session starts towards the IP Multimedia Subsystem (IMS)
the following steps are performed:
1. The default EPS emergency bearer for signaling is requested by the UE using a Packet
Data Network (PDN) Connectivity Request.
2. The Mobility Management Entity (MME) then sends the Create Session Request towards
the Serving-/Packet Data Network Gateway (S-/P-GW).
3. The default EPS emergency bearer is authorized by the Policy and Charging Rules
Function (PCRF).
4. The default EPS emergency bearer is allocated by the eNodeB and the PDN Connectivity
is created towards the UE.
22 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 6 VoLTE emergency attach
5.4 VoWiFi emergency attach
Nokia offers two alternative methods for VoWiFi emergency attach: the HSS- and the AAA-based
Emergency APNs.
5.4.1 VoWiFi emergency attach: HSS-based Emergency APN
During VoWiFi emergency attach, the UE provides the Emergency APN, the subscriber is
requested from the HSS and subsequently authenticated by the AAA. The ePDG selects the P-
GW and establishes the Default EPS emergency bearer for the call.
Purpose
Emergency UE attaches to the evolved Package Data Gateway (ePDG).
Preconditions
• An ePDG selection, Proxy Call State Control Function (P-CSCF) discovery, Packet Data
Network Gateway (P-GW) selection and Voice over LTE (VoLTE) subscription are available.
• Authentication, authorization, and accounting (AAA) registration data and non-3GPP
access subscription exist in the Home Subscriber Server (HSS).
23 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

• HSS has the Emergency Access Point Name (APN) Configuration Data for ePDG Attach.
Procedure
Untrusted attach procedure via Wi-Fi is followed as described in the VoX Core Engineered
System Description document, with the following additions:
• The UE provides the Emergency APN in IKEv2 Authentication and Tunnel Setup
procedure.
• The AAA server requests the subscriber from the HSS.
• The AAA server authenticates the user and authorizes the use of non-3GPP access. It
returns the APN Configuration received from the HSS in EAP-Success. The ePDG selects
the P-GW and establishes the Default EPS emergency bearer based on the received
Emergency APN configuration.
24 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 7 VoWiFi emergency attach: HSS-based Emergency APN
5.4.2 VoWiFi emergency attach: AAA-based Emergency APN
During the AAA-based Emergency APN procedure, the AAA server detects the Emergency APN
sent by the user and processes the registration by retrieving non3GPP-user-data from the HSS.
If the APN is subscribed, this configuration is used by the ePDG, otherwise, the APN is located in
the emergency APN list and the subscriber is authorized to use the IMS voice service.
25 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Purpose
Emergency User Equipment (UE) attaches to the evolved Package Data Gateway (ePDG).
Preconditions
• An ePDG selection, Proxy Call State Control Function (P-CSCF) discovery, Packet Data
Network Gateway (P-GW) selection and Voice over LTE (VoLTE) subscription are available.
• Authentication, authorization, and accounting (AAA) registration data and non-3GPP
access subscription exist in the Home Subscriber Server (HSS).
• AAA has the Emergency Access Point Name (APN) Configuration Data for ePDG Attach.
Procedure
Untrusted attach procedure via Wi-Fi is followed as described in the Voice over Wi-Fi overview
document, with the following additions:
• The UE provides the Emergency APN in IKEv2 Authentication and Tunnel Setup
procedure.
• The AAA server detects the Emergency Attach case based on Emergency APN received at
the beginning of the child security associations negotiation.
• The AAA server processes the registration and non-3GPP-user-data is retrieved from the
HSS.
o If the APN is found among subscribed APNs, this APN Configuration is used
toward the ePDG.
o If the APN is not found among the subscribed APNs then the following happens:
1. The AAA server compares the requested APN with the emergency APN
list.
2. The subscriber is authorized to use the IMS voice service.
• The AAA server answers with EAP-Success to the ePDG.
26 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

© 2021 Nokia
[DN1000030711] [Issue 4-0]
Figure 8 VoWiFi emergency attach: AAA-based Emergency APN
27 / 50
5.5 Registration with VoLTE and VoWiFi Emergency Call
In case of a VoLTE Emergency Call, the IMS registration is performed before the UE detectable
emergency session starts. The registration is managed by the Serving Call State Control
Function (S-CSCF) and the subscriber is authenticated by the HSS. The Emergency Call is
performed without IMS registration in case of authentication failure. When registering the
Emergency Call on VoWiFi, the IMS-Authentication and Key Agreement (AKA) is used for
performing the authentication, the UE using ePDG Wi-Fi access uses the IMS emergency Access
Point Name (APN).
Purpose
An IP Multimedia Subsystem (IMS) emergency registration is required before an IMS emergency

call from Long Term Evolution (LTE) access or from Wi-Fi access. If the authentication fails the
UE initiates the emergency session without IMS emergency registration.
Preconditions
• The User Equipment (UE) is attached to the Evolved Packet System (EPS) in case of Voice
over LTE (VoLTE).
• The UE is attached to the evolved Packet Data Gateway (ePDG) in case of Voice over Wi-Fi
(VoWiFi).
Note: Emergency registration is required if the UE is EPS-attached before making an emergency

call.
Description for VoLTE
Before the UE detectable emergency session starts towards the IMS the following steps are
performed:
1. The IMS emergency registration is done by using IMS registration with the Contact
header including sos. The registration is handled by the home network Serving Call State
Control Function (S-CSCF) and the subscriber is authenticated by the Home Subscriber
Server (HSS). However, the 3rd party registration is not carried out and the Proxy Call
Session Control Function (P-CSCF) does not request the reg-event package. The
exception to this process is when the authentication fails.
2. The P-CSCF can set the optional Signaling Bearer Supervision for the default EPS
emergency bearer via the Policy and Charging Rules Function (PCRF) towards the Packet
Data Network Gateway (P-GW).
28 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 9 IMS emergency registration
After the successful IMS emergency registration, the IMS emergency call can be established.
If the authentication fails the UE initiates the emergency session without IMS emergency
registration, if allowed by the serving operator.
Even if the subscriber is registered to IMS in the home network, the emergency registration can
be performed. The UE does not perform emergency deregistration but waits until the
registration expires.
Description for VoWiFi
1. A SIP REGISTER message with sos parameter in the Contact header is sent by the UE to
the P-CSCF
2. IMS-Authentication and Key Agreement (AKA) authentication is used during IMS
emergency registration.
3. The UE using ePDG Wi-Fi-access uses the IMS emergency Access Point Name (APN).
4. ATCF is not involved by P-CSCF during IMS Emergency registration.
5. Using initial Filter Criteria (iFC) configuration avoids third party registration.
29 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

UE A ePDG P- PCRF AAA P- HSS I- S- TAS
GW CSCF CSCF CSCF
Figure 10 IMS emergency registration with VoWiFi
5.6 UE detectable emergency session
In case of a UE detectable emergency session, a SIP emergency request sent by the subscriber
registered in IMS is translated to emergency service Uniform Resource Name (URN). The Proxy
Call State Control Function (P-CSCF) detects the emergency session and anchors it to the
Emergency Access Transfer Function (EATF). The Emergency Call State Control Function (E-CSCF)
may route the call to a Public Safety Answering Point (PSAP) based on location information. The
E-CSCF functionality is provided by the CFX5000.
Purpose
The user makes an IP Multimedia Subsystem (IMS) emergency call. The User Equipment (UE)
detects that the request is an emergency call.
Preconditions
• The subscriber is registered in IMS either by using normal IMS registration or IMS
emergency registration.
• Emergency Single Radio Voice Call Continuity (SRVCC) is provisioned at the serving
Evolved Packet System (EPS) network.
• Emergency numbers are provisioned to the UMTS Integrated Circuit (IC) card (UICC) or
are delivered from the EPS to the UE.
• UE provided location information
30 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Description
• The UE builds the SIP emergency request and starts the emergency session towards the
network.
• The UE translates any user-indicated emergency number to an emergency service
Uniform Resource Name (URN). This is a service URN with a top-level service type of sos.
• The Proxy Call State Control Function (P-CSCF) detects the emergency call, based on
configured emergency numbers, and routes it to the Emergency Call State Control
Function (E-CSCF).
• E-CSCF anchors the emergency session at the Emergency Access Transfer Function
(EATF).
• The E-CSCF may request information from the Location Retrieval Function (LRF) to route
the emergency call to the Public Safety Answering Point (PSAP), based on location
information.
• The E-CSCF then routes the emergency session to the PSAP. PSAP routing alternatives
are:
o Based on User Provided Location Information (UPLI) of type P-Access-
NetworkInfo (PANI)
o Based on Network Provided Location Information (NPLI)
o 2 default PSAPs
o Default PSAP fall back routing
o Home Subscriber Server (HSS) prefix
• The dedicated EPS emergency bearer for emergency session is established for
emergency call voice.
Even if the IMS subscription is deactivated, the emergency service must be available.
• The UE makes an IMS emergency call to the PSAP.
Figure 11 UE detectable IMS emergency session with VoLTE, part 1
31 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

© 2021 Nokia
Figure 12 UE detectable IMS emergency session with VoLTE, part 2
[DN1000030711] [Issue 4-0]

32 / 50
Figure 13 UE detectable IMS emergency session with VoWiFi
5.7 Non UE detectable emergency session
In case of a non-UE detectable emergency session, the UE starts the SIP session establishment
without adding the IMEI or the sos parameter to the SIP Contact header. The Proxy Call State
Control Function (P-CSCF) detects the IMS emergency session and rejects or allows the
33 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

emergency session based on operator policy. The P-CSCF and ATCF functionality is provided by
the Nokia SBC and it can additionally be provided by the CFX-5000.
Purpose
The user makes an IP Multimedia Subsystem (IMS) emergency call. The User Equipment (UE) does
not detect that the request is an emergency call.
Preconditions
The subscriber is normally registered in the IMS and the IMS Access Point Name (APN) is
allocated.
The UE provided location information.
Description
• The UE starts SIP session establishment normally, without adding the IMEI or the sos
parameter to the SIP Contact header.
• The IMS emergency session is detected at the Proxy Call State Control Function (PCSCF).
• Based on operator policy, configured at the P-CSCF, it shall reject or allow the emergency
request:
1. Reject with SIP 380 Alternative Service, with guidelines to use of circuit-switched
(CS) emergency service.
The UE follows the guidelines and attempts the emergency call via CS.
2. Reject with SIP 380 Alternative Service, with indication of emergency session. The
UE requests the emergency Packet Data Network (PDN) connection, performs the
emergency registration and then the IMS emergency attempt.
3. Allow and route to Emergency Call State Control Function (E-CSCF) with anchoring
at the Emergency Access Transfer Function (EATF) (VoLTE). The IMS emergency
attempt is routed to the E-CSCF and is anchored at the EATF. Consequences:
The emergency PDN connection is not used because the EPS does not detect the
emergency session.
Note: A possible emergency Single Radio Voice Call Continuity (SRVCC) will fail
because the Mobility Management Entity (MME) starts packet-switched (PS) to CS
handover towards the SRVCC MSS, the session transfer call is initiated towards the
SCC AS/ATCF but the IMS emergency session is anchored at the EATF.
4. Allow and route to E-CSCF without anchoring at the EATF (VoWiFi).
The Emergency call is routed to the E-CSCF, but not anchored at the EATF because the
International Mobile Equipment Identity (IMEI) is missing. The E-CSCF contacts the Location
Retrieval Function (LRF) to route the call to the Public Safety Answering Point (PSAP) based on
location information.
34 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

5.8 UE detectable emergency session – without IMS registration
If a user cannot perform an IMS registration and sends an emergency session request with
anonymous user indication, the Proxy Call Session Control Function (P-CSCF) forwards the
request to the Emergency Call Session Control Function (E-CSCF) which anchors the call to the
Emergency Access Transfer Function (EATF). Location information may be requested in order to
route the call to a Public Safety Answering Point (PSAP). If anonymous users are not allowed by
the IMS, the UE makes a circuit switched (CS) emergency call.
Purpose
IP Multimedia Subsystem (IMS) emergency session establishment without IMS registration.
Preconditions
• The user does not have the credentials to perform IMS authentication or the SIM has
been blocked and so the emergency registration fails.
• Emergency Single Radio Voice Call Continuity (SRVCC) is provisioned at the serving
network.
• IMS emergency session establishment is allowed without IMS registration.
Description
• IMS registration/Packet Core (PaCo) authentication cannot be done.

• Before the IMS emergency call, emergency attach is performed to allocate the Default
Evolved Packet System (EPS) emergency bearer for signaling. The Emergency Access
Point Name (APN) is allocated.
• The User Equipment (UE) includes both the “anonymous user” and the “emergency
service” indications in the emergency session establishment request.
• If the Proxy Call Session Control Function (P-CSCF) rejects the “anonymous user”
emergency session request, the UE must not attempt again to send an “anonymous
user” emergency call request using the same network.
• If the P-CSCF accepts the “anonymous user” emergency session request, it forwards the
request to the Emergency Call Session Control Function (E-CSCF).
• The E-CSCF anchors the emergency session at the Emergency Access Transfer Function
(EATF).
• The E-CSCF may request the information from the Location Retrieval Function (LRF) to
route the emergency call to the Public Safety Answering Point (PSAP).
Note: The IMEI is used as mobile ID.
A successful IMS emergency call is made between the UE and the PSAP if the P-CSCF
configuration allows it.
If anonymous users are not allowed by the IMS the UE makes a circuit-switched (CS) emergency
call.
35 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

5.9 SRVCC for IMS emergency call
If the IMS emergency session is initiated from LTE access, the MME initiates the PS to CS
handover based on the UE measurement reports and the eNodeB handover decision. The SRVCC
enabled MSS initiates the service continuity procedures towards the CS access with emergency
call priority parameters. After the emergency session SRVCC is performed, the location
continuity procedure is initiated for the UE.
Purpose
Support of Single Radio Voice Call Continuity (SRVCC) for active phase emergency calls.
Preconditions
• The IP Multimedia Subsystem (IMS) emergency session is established from Long Term
Evolution (LTE) access and anchored at the Emergency Access Transfer Function (EATF)
for Emergency SRVCC.
• The Evolved Packet System (EPS) Mobility Management Entity (MME) is aware of the
emergency session based on the Default Emergency Packet Data Network (PDN)
connection.
• The EPS MME has received the IMEI during EPS attach.
Description
• Based on the User Equipment (UE) measurement reports and the eNodeB handover
decision the MME initiates the packet-switched (PS) to circuit-switched (CS) handover
request with emergency indication towards the MSC Server (MSS) enhanced for SRVCC.
• The SRVCC MSS then initiates the service continuity procedures towards the CS access
with emergency call priority parameters.
• Then the SRVCC MSS initiates the session transfer call by sending an INVITE toward the
Emergency Access Transfer Function (EATF) with the locally configured E-STN-SR and
equipment identifier (IMEI).
Note: If the IMS emergency session is supported in limited service mode (for example,
for UE without UICC), the emergency SRVCC is done using the UE's equipment identifier.
• The Emergency Session Transfer call is routed to the EATF. Routing alternatives are:
1. using Direct Public Service Identity (PSI) routing.
2. using IMS Domain Name Server (DNS) based routing at the Interrogating Call Session
Control Function (I-CSCF).
• The EATF then detects the Emergency Session Transfer call, finds out the anchored call,
does the Session Transfer, updates the remote leg and releases the source access leg of
the call.
• After the emergency session SRVCC is performed, the location continuity procedure is
initiated for the UE. Either the MME transfers the target side SRVCC MSS identity to the
source side Gateway Mobile Location Center (GMLC), or the SRVCC MSS transfers its own
identity to the target side GMLC.
36 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 14 Emergency call SRVCC
The IMS emergency call is moved to the CS access and the call continues.
Note: The Emergency Session Transfer call dynamic Payload Types must be allocated from the
upper range to avoid the conflict with the original call Payload Type allocation (range from 112
to 127).
Note: If the G.711 codec is used for the emergency calls (using the MSS PRFILE parameter
DEFAULT_EMERGENCY_CALL_COD), a compressed codec is selected for the IMS leg and is
transcoded to the G.711 codec before it is passed to the PSAP. In the emergency SRVCC case
this transcoding is moved to a Multimedia Gateway (MGW) controlled by an SRVCC MSS and may
cause an additional transcoding if the CS access is not located under the SRVCC MSS but at the
target MSS.
Direct PSI routing
If Direct PSI routing is used, the MSS Emergency Session Transfer Number for SRVCC (E-STN-SR)
analysis result is the I-CSCF Uniform Resource Identifier (URI). The I-CSCF detects the IMS
domain and performs the location query towards the Home Subscriber Server (HSS) and the E-
STN-SR is configured as PSI in the HSS returning the EATF URI.
37 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 15 Emergency Session Transfer call, PSI routing
IMS DNS based routing
If IMS DNS based routing is used, the MSS E-STN-SR analysis result will be the I-CSCF URI. The I-
CSCF performs a DNS query based on the domain and gets the EATF address.
Figure 16 Emergency Session Transfer call and IMS DNS routing
5.10 SRVCC temporary rejection in Emergency call
When an originating Emergency call is in pre-alerting phase and the eNodeB requests a handover
from the MME, the SRVCC MSS initiates the session transfer towards the EATF. The EATF rejects
the Emergency call in pre-alerting or in alerting phase, using SIP 480 Temporarily Unavailable.
The eNodeB can request the handover multiple times, in case the LTE coverage is still poor.
Purpose
38 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

SRVCC temporary rejection in Emergency call.
Preconditions
• The EATF supports the functionality for call preservation, if the call is not yet in active
phase.
• The SRVCC MSS will send the PS to CS response to the MME after the Session Transfer
call is responded (in local configuration).
• Originating IMS Emergency call control plane is anchored at the EATF.
• Poor LTE coverage is detected, and CS coverage is available.
Description
1. The originating Emergency call is in pre-alerting phase (SIP 183 Session Progress
received) or in alerting phase (SIP 180 Alerting received) to the initial SIP INVITE.
2. The eNodeB requests the handover from the MME.
3. In case the QCI=1 is reserved, the MME requests PS to CS handover from the SRVCC MSS.
4. The SRVCC MSS prepares for CS handover.
5. The SRVCC MSS initiates the Session Transfer call towards the EATF anchor.
6. The EATF detects that the Emergency call is in pre-alerting or in alerting phase, and
therefore rejects the session transfer attempt using SIP 480 Temporarily Unavailable.
7. The SRVCC MSS responses the PS to CS Response with “Temporary reject cause” value.
8. The MME forwards the rejection towards the eNodeB.
9. The eNodeB can request the handover multiple times, in case the LTE coverage is still
poor, in this case the steps 2 to 8 are repeated.
10. When the PSAP answers the call, the session transfer is performed normally.
39 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

© 2021 Nokia
Figure 17 Pre-alerting phase SRVCC attempt
[DN1000030711] [Issue 4-0]

40 / 50
Figure 18 Alerting phase SRVCC attempt
5.11 PSAP Emergency Callback
Public Safety Answering Point (PSAP) callback to UE is performed using the SIP header as
identifier for an emergency call. Callback from the PSAP is treated as a normal terminated call,
emergency calls are routed through the S-CSCF which defines the window for the callback,
enabling or barring the call by involving the Telephony Application Server. Nokia TAS MCS feature
set is the recommended product for TAS functionalities.
Purpose
Support an emergency callback from the Public Safety Answering Point (PSAP) to the User
Equipment (UE) after the original emergency call is released.
Preconditions
Redirecting and barring features must be informed of the emergency nature of the call.
In case of PSAP Emergency Callback for Voice over Wi-Fi (VoWiFi), the UE needs to be attached
via Wi-Fi access and IP Multimedia Subsystem (IMS) registered.
41 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Description
PSAP Callback to the emergency caller is not yet part of 3GPP specifications. The SIP header field
PSAP-callback is used for identifying calls as PSAP callbacks. Another solution using a timer and
whitelisting is also described. The document also specifies using Globally Routable User Agent
(UA) URIs (GRUUs) to identify a specific device behind a SIP address-of-record (AOR) from where
the emergency call was made.
Callback from the PSAP is treated as a normal terminated call. Provisioning a TEL-URI for the
subscriber is required so that it can be used as an identity.
If a PSAP performs a callback, a new session is created from the PSAP to the user. All redirecting
and barring features set up for the PSAP or network configurations enabling incoming call
barring or call forwarding involving a Telephony Application Server (TAS) at the terminating leg
by the Serving Call Session Control Function (S-CSCF) resulted in the TAS diverting or stopping
an emergency callback. TAS was neither aware of a performed emergency call nor of the
terminating session being a PSAP callback.
Emergency calls are routed through the S-CSCF. Setting a timer on the S-CSCF allows callbacks
for a certain time limit. TAS (Nokia TAS MCS profile) is informed that the call is within the callback
window and that the PSAP callback feature interaction is needed. As there is no indication in the
callback itself (no indications have been standardized so far), each terminating call in the callback
period will be handled as a callback. The callback period (timer) does not end after the first
terminating call within that callback period.
42 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

6 Use cases for 5G Emergency call
The emergency services for the 5GS defined in the TS 23.501 and TS 23.502. The actual IMS
based emergency call concept remains the same as with the VoLTE emergency service, with the
following notable differences:
• SRVCC is not applicable
• CS FB cannot be used
The 3GPP Release 15 defined the Location Services only for regulatory purposes. There are 5G-
NI-LR and 5G-MT-LR procedures. There is no MO-LR procedure defined in the Release 15
content, commercial location services are to be added in Release 16.
6.1 Emergency services fallback
Purpose
The purpose of this use case is to perform an emergency call with emergency services fallback.
This use case is described in the 3GPP TS 23.502.
Preconditions
• The UE is registered to the 5GS, emergency services fallback indication and emergency
numbers are provided in registration accept.
• There are eMBB and IMS PDU sessions established.
Description
• There is an emergency call initiated on the UE with one of the well-known emergency
numbers (112 or 911).
• The UE will send a Service request with the type set to emergency to trigger Emergency
Services Fallback.
• The AMF receiving the Service request with type emergency will start the Emergency
Services Fallback towards the gNB.
• The gNB triggers either handover or redirection towards the EPS.
• The N26 handover that is triggered with the NG-RAN may forward the Emergency
indication to the target eNB in the Source to Target Transparent Container, and the
target eNB allocates radio bearer resources, while taking the received indication into
account.
• After the UE and EPS has finished the fallback procedure (the handover or redirection)
the emergency call setup continues, using the EPS emergency services and resources.
• The UE makes the Emergency registration to the IMS using the EME APN.
• Then the actual IMS emergency call setup initiated over the EME APN in the EPS and the
use case is actually a UE detectable emergency call.
Note: The location information about the UE is provided from the EPS towards the PSAP after
the Emergency fallback procedure completed. There is no location information provided from
the 5GS.
43 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 19 Emergency Session Fallback based on 3GPP TS 23.502
Emergency Services Fallback

Normal registration in 5G with UE detectable EME session
AMF provided the Emergency Services Fallback indication to the UE during 5G registration
5G access IMS
UA-A
5G UE 5G gNB AMF SMF/PGW-C UPF/PGW-U LMF GMLC PCF P-CSCF S/E-CSCF BGCF/MGCF PSAP
IMS DNN 5QI=5 non-GBR flow
911 or 112 call
Service Request (type: emergency)
CM-IDLE UE Context Setup
CM-Connected UE Context Mod
Trigger for handover or redirection
- Emergency indication
in RRC LTE eNB MME SGW
- Combined Attach
- TAU with user
pending indication Handover/redirection 5G->4G ; TAU
MME should handle it even not

configured for the emergency
Emergency PDN Connection setup
IMS emergency registration and emergency call setup completed with location information from the 4G/EPS access
EME APN QCI=1 GBR bearer for emergency voice User plane voice
Emergency call over 4G/EPS
Figure 20 Emergency services fallback
44 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

7 Engineering considerations for VoLTE, VoNR and
VoWiFi Emergency Call
This section describes the necessary engineering considerations, such as provisioning, files,
parameters, statistics, capacity, interworking features/functionalities, and compliance regarding
VoLTE and VoWiFi Emergency Call.
7.1 Provisioning Emergency Call
The following IP Multimedia Subsystem (IMS) VoLTE subscription profile is required for the VoLTE
and VoWiFi Emergency Call feature.
The Home Subscriber Server (HSS) subscription profile must include:
• IP Multimedia Public Identity (IMPU)

• IP Multimedia Private Identity (IMPI)
• Authentication data: <key, algorithm versions>
• Packet Services
A Public Service Identity (PSI) subscription for Emergency Session Transfer Number for SRVCC
(E-STN-SR) routing is also necessary.
To enable Voice over Wi-Fi (VoWiFi), in addition to the data required to enable Voice over LTE
(VoLTE), the following non-3GPP data can be provisioned in the HSS:
• Mandatory: Access to Non-3GPP APN enabled must be set to TRUE

• Mandatory: Emergency Access Point Name (APN) with block sending over S6a
45 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

8 Associated documents for VoLTE, VoNR and
VoWiFi Emergency Call
This is a collection of documents (standards and product documents) that are associated with
the Emergency Call for the VoX Core Engineered System.
Standards
3GPP TS 23.501 System architecture for the 5G System (5GS)
3GPP TS 23.502 Procedures for the 5G System; Stage 2, Release 15.
3GPP TS 24.301: General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access
3GPP TS 23.167: IP Multimedia Subsystem (IMS) emergency sessions
3GPP TS 23.216: Single Radio Voice Call Continuity (SRVCC); Stage 2
3GPP TS 23.237: IP Multimedia Subsystem (IMS) Service Continuity; Stage 2
3GPP TS 23.271: Functional stage 2 description of Location Services (LCS)
3GPP TS 23.122: Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
3GPP TS 23.203: Policy and charging control architecture
3GPP TS 24.229: IP multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol
3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access
3GPP TS 29.212: Policy and Charging Control over Gx reference point
3GPP TS 29.213: Policy and Charging Control signaling flows and Quality of Service (QoS)
parameter mapping
3GPP TS 29.214: Policy and Charging Control over Rx reference point
3GPP TS 22.101: Service aspects; Service principles
3GPP TS 24.237: IP Multimedia (IM) Core Network (CN) subsystem Service Continuity; Stage 3
3GPP TS 29.280: Evolved Packet System (EPS); 3GPP Sv interface (MME to MSC, and SGSN to
MSC) for SRVCC
46 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

RFC 5031: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
RFC 5627: Obtaining and Using Globally Routable User Agent URIs (GRUUs)
RFC 7090: Public Safety Answering Point (PSAP) Callback
Product documentation for CFX-5000
Feature 5120: Emergency
Associated documents for VoX Core Engineered System
Single Radio Voice Call Continuity for the VoLTE Core Engineered System Product
documentation for CMS-8200
FC123_106070: PSI Basics Part 1.
Operating CMS-8200 HSS
FC123_108027: Support Sh Interface from LRF-RDF
Product documentation for Open MSS
Feature 2008: SRVCC Support in MSS
Product documentation
VoX Core Engineered System Overview
Cloud Mobility Manager Operating Documentation
Feature 2008: SRVCC Support in MSS
LTE572: IMS emergency sessions, RL30
SRVCC, MME Feature Overview, available in Cloud Mobility Manager Operating Documentation
Nokia Telecom Application Server Operating Documentation
Nokia Session Border Controller Operating Documentation
47 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

9 Acronyms for VoX Emergency Call
Table 8 - List of acronyms
Term Definition
3GPP 3rd Generation Partnership Project
AAA Authorization, Authentication and Accounting
AMBR Aggregated Maximum Bit Rate
AMF Access and Mobility Management Function
APN Access Point Name
ARP Allocation and Retention Policy
CCA Credit-Control-Answer
CCR Credit-Control-Request
CDR Charging Detail Record
CSCF Call Session Control Function
CSG Closed Subscriber Group
DNN Data Network Name
EC Emergency Call
E-CSCF Emergency Call Session Control Function
E-STN- Emergency Session Transfer Number for SRVCC
SR
eHRPD Evolved HRPD
EATF Emergency Access Transfer Function
em Emergency
EMC Emergency Call
EMM EPS Mobility Management
eNodeB Evolved NodeB
ENSP Emergency Network Service Provider
ePDF Evolved Package Data Gateway
eMBB Enhanced Mobile Broadband
EPC Evolved Packet Core
EPS Evolved Packet System
ESRN Emergency Session Routing Number
48 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

E- Evolved UTRAN
UTRAN
FEE Feature Expansion Environment
GMLC Gateway Mobile Location Centre
I-CSCF Interrogating Call Session Control Function
iFC Initial Filter Criteria
LI Lawful Interception
MGCF Media Gateway Control Function
MME Mobility Management Entity
Nokia Nokia Session Border Controller
SBC
Nokia Nokia Telecom Application Server
TAS
PAI P-Asserted Identity
PCRF Policy and Charging Rules Function
P-CSCF Proxy Call State Control Function
PS Packet-Switched
PSAP Public safety answering point
P-GW Packet Data Network Gateway
QCI QoS Class Indicator
QoS Quality of Service
RAT Radio Access Technology
RURI Request URI
SCC AS Service Centralization and Continuity Application Server
SCL Supported Codec List
S-CSCF Serving CSCF
SPD Serving Profile Database
SGSN Serving GPRS Support Node
S-GW Serving Gateway
SAE- System Architecture Evolution Gateway
GW
SRVCC Single Radio Voice Call Continuity
STN-SR Session Transfer Number for SRVCC
49 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

T-ADS Terminating Access Domain Selection
TAS Telecommunication Application Server
TrFO Transcoder-Free Operation
TRS Transit Routing Server
UE User Equipment
UTRAN UMTS Terrestrial Radio Access Network
VoLTE Voice over LTE
VoWiFi Voice over Wi-Fi
50 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Emergency Call 4-0-2107v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Emergency Call 4-0-2107v1

Uploaded by

Copyright:

Available Formats

No further reproduction or networking is permitted. Distributed by Nokia.

Copyrighted material licensed to jeetoo.ramprakash.ext@nokia.com on 17-11-2022.

Emergency Call for the VoX Core

1 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Important Notice on Product Safety

2 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Editorial changes and removal of obsolete paragraphs Throughout the document

Table 2 Summary of changes between issues 3-0 and 2-5

Editorial changes Throughout the document

Table 3 Summary of changes between issues 2-5 and 2-0

3 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

The scope of the Emergency Call for the VoX

4 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

5 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

6 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Product Functionality Software release

CloudBand Infrastructure Network Function Virtualization Infrastructure software

transit routing control function (TRCF)

multimedia telephony service (MMTel)

7 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

3.1 VoLTE and VoWiFi

8 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

PSAP selection can be:

• based on the Feature Expansion Environment (FEE) of the CFX-5000 (RDF)

3.2 5G Emergency Call

9 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 2 5G emergency call reference architecture

10 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

11 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 3 IMS emergency call

International Mobile Subscriber Identity: IMPU/IMPI/IMSI/MSISDN

12 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Authentication Key (Ki) Subscriber Authentication Key (Ki)

Operator-Specific Service provisioning: filter criteria, mobility

Location Area Identity (LAI) Quality of Service information

Table 6 Emergency and authentication-related subscriber information

Emergency call alternatives

Number Case 1st attempt 2nd attempt Description

13 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

4.1 Establishment of the emergency bearer

• authenticates the User Equipment (UE)

4.2 Priorities in EPS (bearer priority)

• QoS Class Identifier (QCI)

14 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 4 Priorities in the EPS and emergency call

4.3 Emergency registration

15 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

Figure 5 IMS emergency registration architecture

4.4 Emergency call and Emergency SRVCC

16 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

17 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

4.5 Emergency call for Voice over Wi-Fi

Untrusted Access VoWiFi emergency call solution

18 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

4.6 The Feature Expansion Environment servlet

• Emergency call functionality is specified by various standardization bodies, including

19 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

20 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

5.1 EPS Emergency and Voice services support

IMS Emergency Call is supported by the EPS.

5.2 Emergency Number List handling

21 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia

5.3 VoLTE emergency attach

22 / 50 [DN1000030711] [Issue 4-0] © 2021 Nokia