Attachment 0

Ref.
Ares(2017)4775177 - 30/09/2017
NEXES Research and Innovation Action

Grant Agreement nº 653337
NEXES IMS Architecture

Deliverable D3.4
Version: 1.0
30/09/2017
DOCUMENT CONTROL DATA:
Action acronym: NEXES
Action full title: NEXt generation Emergency Services
Work Package: WP3 – The NEXES Core
Deliverable number: D3.4
Document title: NEXES IMS Architecture
Version: 1.0
Delivery date: 30 June 2017
Nature: Report
Dissemination level: PU
Authors: Liviu Ciulei, Marius Iordache and Vlad Sorici (ORO);

Christer Ulfsparre, Christoffer Friberg and Filip
Asplund (OMN); James Jackson and Dan James (RIN)
Reviewers: Anastasia Bolovinou (ICCS); Janez Sterle and Urban

Sedlar (UL); Anastasia Bolovinou (ICCS); Bertrand
Casse and James Winterbottom (DW); and Cosmin
Carjan and Claudiu Gura (TN)
Editors: Barbara Guerra (RIN)
Lead contractor for ORO

this deliverable:
This project has received funding from the European Union’s Horizon 2020
research and innovation programme under grant agreement No 653337.
NEXES – GA No. 653337 | Deliverable D3.4 Page 2 of 54

CHANGE HISTORY:
Date Version Change

First working release of the document
17-06-2016 0.1
(Yellow Review)
Second working release of the document
27-04-2017 0.2
(Second Yellow Review)
Third working release of the document
16-08-2017 0.3
(Red Review)
Fourth working release of the document
18-09-2017 0.4
(Processed comments from Red Review)
30-09-2017 1.0 First official release of the document
DISCLOSURE STATEMENT
No part of this document may be used, reproduced and/or disclosed in any form or by any
means without the prior written permission of the NEXES Consortium.
DISCLAIMER
This delivery was screened by the NEXES Steering Board.

This delivery holds NO SENSITIVE DATA and/or content that has potential for misuse.

ABOUT NEXES
The NEXES Research and Innovation Action aims to research, test and validate the
promising integration of IP-based communication technologies and interoperability into the
next generation emergency services, so that they attain increased effectiveness and
performance. Empowered by smartphones with cameras, messaging and internet-based
applications connecting to social media, citizens expect emergency services to use the
same technologies. However, this is not the case.
NEXES innovates the approach to the dynamics between emergency services and citizens,
allowing (i) the use of total conversation capabilities in emergencies, including social media,
to the benefit of citizens, including those with disability or special needs (ii) the exploitation
of improved location information to rapidly and effectively identify and locate the caller and
the incident site and (iii) the leverage of Internet-enabled connectivity to enhance
interoperability and shared awareness among emergency services, to the benefit of a more
secure society.
The NEXES Consortium gathers world-class European entities, well experienced in the
research and development of innovative solutions for communications and emergency
products and solutions. The NEXES Team presents extensive background knowledge and
in-house solutions to adapt, test and validate in NEXES’s open Testing Regime and
Validation Framework, ensuring solid results are achieved to produce relevant
Recommendations and contributions to Europe’s standardisation effort on emergency
services. To leverage related dissemination and market exploitation activities, the NEXES
System, Apps and its operational benefits are demonstrated in three realistic pilots to end-
users and stakeholders. In fact, end-users’ involvement, directly ensured by NEXES
Partners and indirectly by invited Advisors, is a key contributor to guarantee NEXES’s
operational validity as a reference implementation system for next generation emergency
services.
To learn more please see: www.nexes.eu.

TABLE OF CONTENTS
1 EXECUTIVE SUMMARY .................................................................................................. 8
2 INTRODUCTION .............................................................................................................. 9
2.1 DELIVERABLE’S PURPOSE ............................................................................................ 10
2.2 DELIVERABLE’S CONTEXT ............................................................................................ 10
2.3 APPLIED METHODOLOGY ............................................................................................. 11
2.4 KEY CONCEPTS .......................................................................................................... 12
3 THE NEXES IMS HIGH-LEVEL ARCHITECTURE ........................................................ 14

3.1 THE ROLE OF THE IMS COMPONENT ............................................................................ 14
3.2 INTEGRATING THE IMS COMPONENT IN NEXES ............................................................ 16
3.2.1 Call Origination ...............................................................................................................16
3.2.2 Access Network ..............................................................................................................17
3.2.3 ESINet and the PSAP System ........................................................................................17
4 THE NEXES IMS COMPONENT ................................................................................... 18

4.1 CORE IMS ELEMENTS ................................................................................................. 18
4.1.1 The Call Session Control Function .................................................................................18
4.1.1.1 Proxy CSCF .............................................................................................................19
4.1.1.2 Interrogating CSCF ..................................................................................................20
4.1.1.3 Serving CSCF ..........................................................................................................20
4.1.1.4 Selecting the S-CSCF .............................................................................................20
4.1.1.5 Emergency CSCF ....................................................................................................21
4.2 AUXILIARY IMS ELEMENTS .......................................................................................... 23
4.2.1 Border Gateway / Session Border Controller .................................................................23
4.2.2 The Electronic Number Mapping System .......................................................................24
4.2.3 The IMS-HELD Interworking Function ............................................................................26
4.2.4 Location Retrieval Function / Routing Determination Function ......................................26
4.2.5 LPG Interworking Function .............................................................................................27
5 THE NEXES IMS FUNCTIONALITY .............................................................................. 29

5.1 REGISTRATION AND AUTHENTICATION ........................................................................... 29
5.1.1 Registration and Authentication for Native Calling .........................................................29
5.1.2 Registration and Authentication for OTT Calling ............................................................31
5.2 LOCATION RETRIEVAL AND CALL ROUTING .................................................................... 32
5.2.1 Location Retrieval and Call Routing for Native Calling ...................................................32
5.2.1.1 Native WiFi Calling While Abroad ............................................................................34
5.2.2 Location Retrieval and Call Routing for OTT Calling.......................................................35
5.2.3 Location Retrieval and Call Routing Using the PEMEA Network ....................................36
5.3 CALL SET-UP AND CONTROL ....................................................................................... 37
5.3.1 Initial Call Set-up .............................................................................................................37
5.3.2 Modifying an Emergency Call in Progress ......................................................................37
5.3.3 Charging and Reporting..................................................................................................38
5.3.4 Quality of Service ............................................................................................................39
5.4 EVOLUTION IN FUNCTIONALITY ..................................................................................... 40

5.4.1 Rich Communication Suite .............................................................................................40
5.4.2 Web-based Real Time Communication ..........................................................................41
5.4.3 Next Generation eCall .....................................................................................................42
5.5 SECURITY ................................................................................................................... 42
5.5.1 Network Snooping ..........................................................................................................43
5.5.2 Session Hijacking ............................................................................................................43
5.5.3 Denial of Service .............................................................................................................43
5.5.4 P-CSCF Discovery ..........................................................................................................44
5.5.5 Service Abuse .................................................................................................................44
5.5.6 Toll Fraud ........................................................................................................................45
6 CONCLUSION................................................................................................................ 46
7 BIBLIOGRAPHICAL REFERENCES ............................................................................. 47
8 ACRONYMS AND DEFINITIONS .................................................................................. 49
9 ANNEX ........................................................................................................................... 54
9.1 MAPPING THE NEXES SYSTEM REQUIREMENTS TO THE IMS COMPONENTS ................... 54

LIST OF TABLES
Table 1 – Key Concepts Of Deliverable D3.4 .......................................................................................13

Table 2 – Supported Protocols For Connecting To PSAP Systems ....................................................17
Table 3 – CSCF Supported 3GPP Reference Points ...........................................................................19
Table 4 – Specifications For The Lq Interface ......................................................................................24
Table 5 – ENUM Record For A Volte Subscriber .................................................................................25
Table 6 – EENA Proposal For Qos Of Emergency Services Traffic......................................................40
LIST OF FIGURES
Figure 1 – NEXES General Architecture .................................................................................................9

Figure 2 – Applied Methodology for Task 3.4 ......................................................................................12
Figure 3 – NEXES IMS As a Central Component of NEXES Architecture ............................................14
Figure 4 – Involved OTT Calling Components and Flow ......................................................................15
Figure 5 – Involved Native Calling Components and Flow ..................................................................16
Figure 6 – NEXES IMS Architecture Deployed in Romania ..................................................................18
Figure 7 – E-CSCF Interconnection .....................................................................................................22
Figure 8 – Decomposed SBC Model as Implemented in NEXES ........................................................23
Figure 9 – DNS Redundancy Diagram .................................................................................................25
Figure 10 – The REGISTER Message Flow ..........................................................................................30
Figure 11 – The Location Retrieval Message Flow via a) the Sh Interface and via b) the MAP Interface
......................................................................................................................................................33
Figure 12 – NEXES IMS Architecture for Location Retrieval in OTT Calling ........................................35
Figure 13 – Call Routing Using the PEMEA Network ...........................................................................36
Figure 14 – eCall Basic Routing ...........................................................................................................42

1 EXECUTIVE SUMMARY
The NEXES System presents a core theme of innovation, leveraging on the use of cutting
edge technology to drive the advancement of communications between citizens and
emergency services. The use of Internet-based protocols is a key factor within the design
of NEXES and therefore requires the appropriate components to support the multimedia
services aimed to be provided. As a consequence, the IP Multimedia Subsystem (IMS)
component became an integral part of the NEXES Core.
The NEXES IMS component enables innovative functionalities to emergency
communications:
• Total Conversation – a standardised concept allowing an audio-visual conversation with
bidirectional full-duplex real-time transfer of real-time text, video and voice;
• Enhanced Location – an accurate, precise and reliable location information on
emergencies, through user equipment (UE) location-aware capabilities.
The NEXES IMS component is based on the IMS subcomponents defined under the 3GPP /
ETSI standards: 3GPP TS 24.229 [1], 3GPP TR 23.869 [2] and RFC 3261 [3]. The
implementation has then been adapted or particularised for the NEXES System, in order to
enable more advanced functionalities than the mere standard Voice-over-Long Term
Evolution (VoLTE) or Voice-over-WiFi (VoWiFi) emergency calling. Within NEXES, the IMS
becomes open to integration to known emergency applications that will be able to achieve
both Total Conversation and Enhanced Location capabilities. In this respect, the NEXES
IMS is adapted to support Session Initiation Protocol (SIP) messages manipulation,
authentication with third-party applications and zero rating for emergency messages over
the operator’s network who owns the IMS. In addition, the NEXES IMS allows integration
with smart devices (e.g. Machine to Machine or M2M SIP-enabled platforms) and eCall
platforms.
Although countries with deployed IMS implementations still fall back to circuit-switched
networks to handle emergency calls today, the NEXES IMS serves as a beacon of support
and guideline to ensure that emergency calls applying VoLTE, VoWiFi and Video-over-LTE
(ViLTE) do reach next generation Public Safety Answering Points (PSAPs) and enable
emergency services to benefit from the full advantages brought by next generation
networks.

2 INTRODUCTION
As a next generation emergency service implementation, the NEXES System proposes the
introduction of IP-based communication technologies to support advanced information and
communication capabilities between citizens, emergency response organisations (EROs)
and First Responder teams (FRs), through the offer of improved services that result from
the adoption of a core IMS component. The IMS Component is therefore responsible for
enabling:
• Standard Voice-over-IP (VoIP) emergency communication (VoLTE and VoWiFi);

• Over-the-top (OTT) emergency applications (e.g., the NEXES Apps);
• Total Conversation capabilities (combination of real-time text, video and voice
communication);
• Advanced routing capabilities based on the network-provided location and the UE-
provided location.
As an integral part of the NEXES System, the IMS component allows for the adoption of
cutting edge technology to drive the advancement of communications between citizens
and emergency services. As a reference implementation of next generation emergency
services, NEXES brings about the conditions for the successful adoption of IMS as a key
enabler to next generation emergency services and the exploitation of the numerous
opportunities delivered by advanced IP-enabled information and communication
technologies.
NEXES main components are depicted in Figure 1 and explained hereafter.
Figure 1 – NEXES General Architecture

NEXES is incorporating already standardised solutions to accommodate different advanced
IP-enabled information and communication technologies and bridge with new emergency
services’ proposed implementations.
As part of the NEXES Core, the IMS component is deployed within the Public
Communication Networks architectural domain, implementing full IP communication,
enabling the delivery of fast and reliable IP multimedia services and taking full advantage of
SIP technologies’ implementation for emergency calling. Adopting the IMS component,
NEXES embodies a new concept that envisions the interconnection between the IMS and
next generation PSAP systems to support next generation emergency services
enhancements.
2.1 Deliverable’s Purpose
A result of the NEXES RIA Task 3.4 – “The NEXES IMS”, this report presents the
development and integration process of the IMS core component within the NEXES
System, as it enables the enriched SIP communication for both native and OTT emergency
calls.
Task 3.4 – “The NEXES IMS” is a part of Work Package 3 – The NEXES Core, a work
package dedicated to the definition of the NEXES System requirements and architecture
specifications, including the design and development of the functional and logical
components and interfaces related with the telecommunications infrastructure and the
emergency network.
Presenting the main achievements and results of Task 3.4 activities, this deliverable
describes in detail the development and integration effort of the network adaptations
required to enable IMS functionality, namely the integration with OTT applications, the
support to enhanced location and the adoption of the Pan European Specifications for
Emergency Apps (PESEA) to achieve interwork with the Pan European Mobile Emergency
Applications (PEMEA) network.
2.2 Deliverable’s Context
The overall aim of the NEXES RIA is to attain a universal, democratic and inclusive
emergency service, improving the ability of emergency services to respond to emergencies,

as well as the ability of citizens, including those experiencing disability or special needs, to
reach to emergency services.
To support a universal, democratic and inclusive emergency service, it is vital that

emergency services adopt IP-enabled information and communication technologies and
benefit from their inherent advantages. As a core component of the NEXES System, the
NEXES IP Multimedia Subsystem delivers those capabilities and contributes to making
NEXES a reference implementation of next generation emergency services.
Providing specific features and practical implementation guidelines associated with the
adoption of the IMS component by next generation communication networks to support
emergency calling, deliverable D3.4 – The NEXES IMS Architecture outlines the major
architectural adaptations required to achieve the key innovations envisaged in NEXES.
2.3 Applied Methodology
The work performed in Task 3.4 – The NEXES IMS is mostly of a technical nature: the
design and implementation of the NEXES IMS component based on the NEXES System
Requirements established in deliverable D3.1 – NEXES System Requirements and
Architecture Specification.
Aside the system requirements defined as a result of Task 3.1 – System Requirements and
High-Level Architecture, deliverable D3.4 – NEXES IMS Architecture also benefits from
valuable inputs from the deliverables that describe NEXES components interacting with the
NEXES IMS (the deliverables D3.2 – Adaptation of Public Communications Networks, D3.3
– NEXES Advanced Location Capabilities and D3.5 – NEXES Gateways) and also from the
deliverables correlated from a technology point of view, considering security (D3.6 – NEXES
Security Recommendations), Applications (D4.1 – Overview of NEXES App Framework for
Pan-European Next Generation Emergency Services and D4.2 – Emergency App API) and
PSAP connectivity (D5.1 – Next Generation PSAP Systems) aspects.
Moreover, the NEXES IMS component complies and is aligned with all the applicable
standards and protocols of the European Telecommunications Standards Institute (ETSI),
the International Telecommunication Union (ITU), the 3rd Generation Partnership Project
(3GPP) and the Internet Engineering Task Force (IETF).
The following figure depicts the process flow adopted in the applied methodology for
executing Task 3.4 activities.

Figure 2 – Applied Methodology for Task 3.4
2.4 Key Concepts
This document applies several key concepts:
Architectural Concepts
Scalability Scalability is the capability ensuring systems are able to withstand a very large
number of users.
Redundancy Redundancy is the capability to duplicate critical components or functions of a
system with the intention of increasing its reliability.
Resilience Resilience is the capability to provide and maintain the system’s acceptable level
of service in the face of faults and challenges to normal operation.
Extensibility Extensibility is the capability enabling future applications to use NEXES concepts,
extend and enhance them.
NEXES Components
PSAP Public Safety Answering Point is the call centre that takes emergency calls.
ERO Emergency Response Organisations are responsible for dispatching responders to
the incident area upon the reception of information from the PSAP or the caller.
FR First Responders are the first emergency service members (paramedics,
firefighters, police officers) at the incident scene.

Telecommunications Components
4G 4G is the 4th 3GPP generation of radio access networks that supports high data
services rate.
LTE Long-Term Evolution is a standard for high-speed wireless communication for
mobile phones and data terminals.
IMS IP Multimedia Subsystem is a framework for providing media over an IP network.
OTT Over the Top is the application or service delivered over the Internet without
involving the traditional data carrier.
VoLTE Voice Over LTE is the standard for voice services over LTE communication
networks based on IP Multimedia Subsystem.
VoWiFi Voice Over WiFi is the standard for voice services over WiFi communication
networks based on IP Multimedia Subsystem.
Applications Key Concepts
User Equipment User Equipment comprises phones, smartphones, fax or any device used to
communicate with emergency services.
Emergency call Voice, video, text or other type of communication comprising an emergency
request between the citizen and the PSAP/ERO.
Table 1 – Key Concepts of Deliverable D3.4

3 THE NEXES IMS HIGH-LEVEL ARCHITECTURE
3.1 The Role of the IMS Component
The IMS is a modular and standardised subsystem allowing the addition of new protocols
and communications technologies to a system. The NEXES IMS is based on existing off-
the-shelf components owned by ORO, abiding to 3GPP standards (revision 11 or above),
extended to support the NEXES implementation of next generation emergency services
(e.g., PSAP routing and user data payload).
The IMS is usually deployed by mobile operators to allow the offering of multimedia
services over IP connectivity. Therefore, its primary use is to enable regular multimedia calls
to be charged according to the client’s subscription. However, the IMS also has the
capability to support dedicated functions for emergency services. In this context, the main
services enabled by the IMS component are the VoLTE and VoWiFi emergency call services
that are natively supported by smartphones. As illustrated in the image below, the
dedicated emergency calls handling is performed by the Emergency - Call Session Control
Function (E-CSCF) within the IMS.
Call Access Application

ESINET PSAP
Originator Network provider
Location NG
OTT Server PSAP1
Public IP access network Emergency
calling
IP network NG
NEXES IMS
S
PSAP2
P/S/E-CSCF
4G network Legacy
Native PGW PSAP1
calling LRF/
Wi-Fi network LPG
RDF
Legacy
HSS PSAP2
Figure 3 – NEXES IMS As a Central Component of NEXES Architecture
In the 3GPP standardisation, several high-level design proposals address the retrieval of
user location for advanced routing to the right PSAP but it is missing the specific actions to
enable such performance. In this deliverable, it is included the approach followed in NEXES
to support that next generation capability.

Additionally, the IMS not only provides services where emergency callers are uniquely
identified and authorised using their Subscriber Identity Module (SIM) card credentials (i.e.
native VoLTE and VoWiFi calls), but also supports OTT communication services. Because
the type of access and the credentials are different, there are differences between the two
methods of communication.
Illustrated in Figure 4, the components involved in OTT calls are:
• The NEXES App;

• A public IP access network;
• The NEXES IMS;
• The Home Subscriber Server (HSS);
• The NEXES Location Server;
• The Emergency IP network (ESINet);
• The NEXES PSAP.
Call Access Network Application

ESINET PSAP
Originator Provider provider
Location NG
OTT Server PSAP1
calling
S Operator IP network NG
HSS IMS PSAP2
P/S/E-CSCF
4G network Legacy
Native PGW PSAP1
calling LRF/
Wi-Fi network LPG
RDF
Legacy
PSAP2
Figure 4 – Involved OTT Calling Components and Flow
Whereas, as presented in Figure 5, the components involved in native calls are:
• Native emergency call function in the operating system;

• Mobile data connection or WiFi connection with VoWiFi service;
• The NEXES IMS;
• The Home Subscriber Server (HSS);
• The Location Retrieval Function (LRF);
• The NEXES Legacy PSAP Gateway (LPG);

• The Emergency IP network (ESINet);
• The NEXES PSAP;
• The legacy PSAP.
Call Access Application

ESINET PSAP
Originator Network provider
Location NG
OTT Server PSAP1
calling
S Operator IP network NG
HSS IMS PSAP2
P/S/E-CSCF
4G network Legacy
Native PGW PSAP1
calling LRF/
Wi-Fi network LPG
RDF
Legacy
PSAP2
Figure 5 – Involved Native Calling Components and Flow
Both communication methods have been addressed in Task 3.4 as the work to integrate
the IMS core component in NEXES unfolded.
3.2 Integrating the IMS Component in NEXES
This section describes the integration of the IMS component in NEXES, considering the
interrelation with the specific components of the access part and of the NEXES core.
3.2.1 Call Origination
In native calling, the device’s operating system handles the registration and call generation
processes. Authentication is attained through the SIM credentials (to which only the
operating system has access) and the emergency call generation is performed by pressing
the native call button. The selection of the access to be used for the emergency call is
executed by the operating system based on a set of rules determined by the network’s
nature: legacy (circuit switched 2G/3G) or next generation (IP-based 4G/WiFi).

In OTT calling, the call generation and authentication is performed by the NEXES App,
designed and implemented as part of the NEXES RIA’s Work Package 4 – The Edge of
NEXES. As Apps have limited access to SIM credentials, the authentication is not possible
through those credentials and a password-based credential mechanism is required.
3.2.2 Access Network
For VoLTE and VoWiFi interconnection, the device communicates with the IP address
received from the Packet Data Network Gateway (PGW) after the authentication done with
the HSS. The PGW is an anchoring gateway enabling mobility between accesses.
The IMS component uses the Policy and Charging Rules Function (PCRF) to trigger a
dedicated bearer when the emergency call is placed, so resources needed for the call are
guaranteed in an end-to-end LTE access network.
3.2.3 ESINet and the PSAP System
From the IMS perspective, the interconnection with the PSAP system can be accomplished
through two types of network technologies: either the IP network for SIP communication
with next generation PSAPs or a Signalling System No. 7 (SS7) network for communication
with legacy PSAPs. Both interconnection processes use standardised interfaces based on
ITU-T, 3GPP and IETF technical specifications. Within NEXES, namely within the NEXES
IMS component, there are no non-standard implementations or proprietary use of optional
parameters, including with respect to the interconnection with external PSAPs.
The following table depicts the two technologies used to interconnect ESINet and the PSAP
system in NEXES:
Interconnect Network Protocol Standard

Next Generation PSAP SIP RFC 3261
Legacy PSAP ISUP ITU-T Q76x
Table 2 – Supported Protocols for Connecting to PSAP Systems

4 THE NEXES IMS COMPONENT
This section details the IMS Component and its interfaces, addressing the functional
perspective associated with the Call Session Control Function (Proxy CSCF, Interrogating
Call State Control Function, Serving Call State Control Function), the Border
Gateways/Session Border Controller (SBC), the E-CSCF, the LPG (Media Gateway
Controller Function/Media Gateway), the Electronic Number Mapping System (ENUM) and
the Location Retrieval Function/ Routing Determination Function (LRF/RDF).
The following image represents the NEXES IMS architecture as implemented for the
Romanian emergency services, which uses a legacy PSAP.
Figure 6 – NEXES IMS Architecture Deployed in Romania
4.1 Core IMS Elements
4.1.1 The Call Session Control Function
The Call Session Control Function (CSCF) is the central network element of the IMS
component and provides the functionality of a multimedia session controller, supporting the
device’s registration (includes the authentication process; the primary authentication
method is the IMS Authentication and Key Agreement or IMS-AKA but is also supports

other methods, such as http digest, Transport Layer Security-based http digest),
emergency call session set-up and connection to Application servers.
The CSCF is defined to play three different roles that may be co-located in the same node
or in separate nodes connected through the Mw interface, and all are involved in the UE-
related SIP signalling transactions. In the NEXES IMS solution, the CSCF element co-
locates logically the different IMS roles:
• Proxy CSCF (P-CSCF);

• Serving CSCF (S-CSCF);
• Interrogating CSCF (I-CSCF);
• Breakout Gateway Control Function (BGCF);
• Emergency CSCF (E-CSCF).
The CSCF supports the reference points and protocols listed in the following table:
3GPP Reference Point Protocol

Gm, ISC, Mg, Mj, Mr, Mw, Mi, Ma SIP
Cx, Rx, Sh, Ro, Rf Diameter
Iq, Ix H.248
Table 3 – CSCF Supported 3GPP Reference Points
4.1.1.1 Proxy CSCF
The Proxy CSCF (P-CSCF) is the first contact point of the IMS component that the UE
interacts with, and it is responsible for all functions related to controlling the IP connectivity
layer. The P-CSCF performs the SIP signalling compression and decompression, the IMS
Authentication and Key Agreement (AKA) and the Transport Layer Security (TLS) integrity
and confidentiality protection. The P-CSCF also provides the Access Border Control
Function (A-BCF) for Network Address Translation (NAT), IP version conversion and pin
holing at the network border. In addition, the P-CSCF is responsible for the identification of
emergency calls.
The P-CSCF is typically located in the same network as the Evolved Packet System (EPS).
Nevertheless, a so-called Local Breakout concept may be set to allow the P-CSCF to
remain in the home network, while the Policy Charging and Rules Function (PCRF) remains
in the visited network and may be used.

4.1.1.2 Interrogating CSCF
The Interrogating CSCF (I-CSCF) is the network entry point in the IMS home network and
it is located at the border of the home network. It is responsible for finding out the UE’s
registration status, and either assigning a new S-CSCF or routing to the right existing S-
CSCF. The request may come from Proxy CSCF (P-CSCF), from other multimedia networks
or from Circuit Switched (CS) networks through the Media Gateway Control Function
(MGCF).
The I-CSCF interrogates the HSS for information that enables the call to be directed to the
Serving CSCF. The I-CSCF provides the call gateway and addresses call handling
functions, although it is not involved in mobile-originated communications.
The I-CSCF queries Domain Name System (DNS) servers to obtain the HSS address. Then,
either a S-CSCF is selected from the S-CSCF list configured at the I-CSCF, according to
the capabilities required for the subscriber, or the S-CSCF name returned by the HSS is
used. A subsequent DNS query resolves the S-CSCF name(s) to IP address(es). Preferably,
the elected S-CSCF is located on the same node to avoid NE interconnection.
4.1.1.3 Serving CSCF
The Serving CSCF (S-CSCF) is located in the user’s home network and it maintains the
user’s registration and session. At registration, the S-CSCF interfaces with the HSS to
receive the subscription profile, including authentication information, and it authenticates
the UE. For the service sessions, the S-CSCF signals with the UE through the other CSCFs.
It also carries the main responsibility for controlling the interworking elements. The S-CSCF
may also need to interact with MGCF for interworking with CS networks, or with other
multimedia networks for UE requested services.
The S-CSCF queries DNS servers to obtain the HSS address. When a new subscriber is
registering, the S-CSCF loads the appropriate subscriber profile from the HSS and
searches for a suitable application server with the Fully Qualified Domain Name (FQDN) that
is translated using DNS.
4.1.1.4 Selecting the S-CSCF
The I-CSCF selects an S-CSCF based on its capability, priority and weight. To configure
the S-CSCF selection, in the parameter table “Table of S-CSCF SIP URIs and Capabilities”,

it should be configured the parameters “S-CSCF Uniform Resource Identifier (URI)”, “S-
CSCF Capabilities”, “S-CSCF Priority” and “S-CSCF Weight” with appropriate values:
• The value of the parameter “S-CSCF URI” denotes the URI of the S-CSCF containing
either a dedicated name or an IP. Dedicated S-CSCF names require a DNS
configuration that directly resolves to IP-addresses;
• The value of the parameter “S-CSCF Capabilities” denotes a number that is assigned to
the different S-CSCFs. These numbers can, for example, represent specific capabilities
of the respective S-CSCF or the desired preference of usage;
• The value of the parameter “S-CSCF Priority” controls the S-CSCF selection within a
set of S-CSCFs having equal capabilities. It is a number ranging from 0 to 999 where 0
has the highest priority and 999 the lowest. Value 0 has a special meaning and is
reserved for migrating from an old S-CSCF to a new S-CSCF. An S-CSCF that has
priority 0 is preferred when the HSS returns capabilities but it is ignored during S-CSCF
re-selection;
• The value of the parameter “S-CSCF Weight” controls the S-CSCF selection within a
set of S-CSCFs having equal capabilities and equal priority. It is a number ranging from
1 to 65535. If all required mandatory capabilities, same number of required optional
capabilities and same priority of two or more S-CSCFs match, the I-CSCF considers the
value configured for the parameter “S-CSCF Weight” between the equivalent S-CSCFs
in the S-CSCF list.
The I-CSCF selects one best S-CSCF every time and tries it. If the selected S-CSCF is
unavailable, the I-CSCF tries the next best S-CSCF from the remaining list of S-CSCFs. The
parameter “S-CSCF Weight” is considered only if there are several S-CSCFs, which are
equally suitable according to the capabilities and priority of the S-CSCFs.
4.1.1.5 Emergency CSCF
The Emergency CSCF (E-CSCF) is the server co-located with other CSCF functions (P/S/I)
and provides the emergency calling routing capability. The E-CSCF is responsible for all the
emergency calls the P-CSCF detects, based on a pre-configured list of emergency
numbers. The E-CSCF serves emergency sessions for both registered and unregistered
subscribers.

For selecting the right PSAP, the E-CSCF interfaces a LRF via the SIP-based Ml interface.
Also the E-CSCF is able to perform P-CSCF re-selection, for example when a user is not
registered on the IMS network and initiates an emergency call.
The E-CSCF function is enabled using a stateless Proxy SIP Server, which supports two
functions requiring location information and routing.
In the following scheme, it is depicted the emergency call flow that is routed by the E-CSCF
to the right PSAP.
Cell-ID
DB RDF
HSS
Sh querry
NPLI LRF
MME
INVITE tel: 112;p INVITE tel: PSAP no

PAI: tel:+MSISDN
PANI: GSTN
PANI: PLMN+TAC+ECI;np MGCF/
PANI: PLMN+TAC+ECI
LTE attach
PANI: PLMN+TAC+ECI
MSC
procedure
UE PGW P-CSCF E-CSCF PSAP
INVITE INVITE tel: 112;p INVITE tel: PSAP no
INVITE tel: 112;p PAI: tel:+MSISDN PANI: GSTN
PANI: PLMN+TAC+ECI PANI: PLMN+TAC+ECI PANI: PLMN+TAC+ECI;np
I4 PANI: PLMN+TAC+ECI
PCRF
EATF
Figure 7 – E-CSCF Interconnection
The main interfaces of the E-CSCF are:
• The MI – interface between the LRF and the E-CSCF, based on the SIP IP multimedia
Service Control (ISC);
• The I4 – interface between the E-CSCF and the Emergency Access Transfer Function
(EATF) to allow hand-over for emergency calls;
• The I5 – interface between the I-CSCF and the EATF to allow the I-CSCF to connect to
the Single Radio Voice Call Continuity (SRVCC) - Mobile Softswitch (MSS) / Media
Gateway Control Function (MGCF).

4.2 Auxiliary IMS Elements
4.2.1 Border Gateway / Session Border Controller
The Border Gateway (BGW) or the Session Border Controller (SBC) has multiple roles in the
IMS component, for it provides security, quality of service, connectivity, media stream,
statistics and billing functionalities.
The SBC function consists of a Border Control Function (BCF) and a Border Gateway
Function (BGF). The BCF handles the SIP signalling and controls the BGF, whereas the
BGF is the enforcement point for the bearer traffic – it allows only accepted bearer flows to
pass and it ensures that the flows do not exceed its allowed bandwidth. The SBC is
typically applied in VoIP networks on the border between the VoIP access network and the
core network. In a decomposed SBC model, the BCF that is signalling is logically and
physically separated from the BGF that is handling the media traffic. The BCF and BGF
units are then connected by a standard based H.248 control interface. The BGW
implemented for the NEXES IMS incorporates a decomposed SBC:
Access Border Control
• A-BCF
• IMS-ALG
• ATCF
P-CSCF/
BGCF
S-CSCF /
Gm Mw
I-CSCF
SIP SIP
Iq H.248
BGW
Mb Mb MGW/
(RTP/MSRP) MRFP
Figure 8 – Decomposed SBC Model as Implemented in NEXES
In the NEXES IMS solution, the BCF is implemented in the CSCF which controls the BGW
accomplishing the BGF. The BGF is a media traffic handling function responsible for media
(Real Time Protocol or RTP, Message Session Relay Protocol or MSRP) and transport
protocols (Transmission Control Protocol or TCP, User Datagram Protocol or UDP), media
payload (IR.92, IR.94, Rich Communication Suite or RCS) and IP address (IPv4, IPv6)

translation and interworking, as well as for applying different policing rules to the media
traffic.
In the decomposed IMS border control solution, the CSCF and the BGW, connected
through the Iq/Ix H.248 interface, ensure the delivery of all IMS services to any device via
any IP access. In addition, the IMS Border Control solution protects both the IMS core
network and the users from a wide range of attacks; it enforces the Service Level
Agreement (SLA) and fulfils regulatory requirements such as lawful interception for all
services and media types.
In the IMS Border Control solution, the Access Transfer Control Function (ATCF), the BCF,
and also the P-CSCF are co-located in the CSCF element, while the Access Transfer
Gateway (ATGW), the Border Gateway Function (BGF), as well as the Transition Gateway
(TrGW) functions are implemented by the BGW. The ATCF and ATGW functional entities are
connected through the Iq H.248 interface and will be supported in the next IMS release.
The specifications for the Iq interface are:
Interface Item Interface Data

ASI Products CSCF (ATCF/IBCF)
PAE Products BGW
PAE Side Hand Over Point Switch / Router Core
High Availability Required Path redundancy
Data Link Layer Protocol Gigabit Ethernet
Network Layer Protocol IP
Transport Layer Protocol SCTP
Application Layer Protocol H248
Table 4 – Specifications for the lq Interface
4.2.2 The Electronic Number Mapping System
The Electronic Number Mapping System (ENUM) server’s functionality is defined as the
mapping of “Telephone Numbers” to “Uniform Resource Identifiers” (URIs) using the
Domain Name System (DNS) in the domain e164.arpa. Defined by IETF in RFC3761 [7], the
ENUM is an application of DNS to map internet addresses (URIs) associated to E.164
numbers. Each E.164 number is mapped to a globally unique name. Its role is relevant for
the IMS component for it:
• Assures convergence between CS-based and IP-based LTE networks;

• Allows interoperability between naming/addressing schemes of different networks;

• Offers the possibility of using only one contact address (the E.164-number) for different
services spreading over different networks.
The ENUM cluster consists of one primary (Master) and three secondary (Slave) servers, as
shown in the next figure:
ENUM (2 units)
Inum01 AXFR, IXFR Inum01

IMS Zone (master) (slave)
(Master)
DNS
DNS
DN
S
DN
CSCF TAS
Figure 9 – DNS Redundancy Diagram
Redundancy ensures that, in emergency cases, either the ENUM server with the master
copy or the ENUM server with the slave copy of the zone compensates the outage of the
broken ENUM server. In case of an outage of a ENUM Server, there is the:
• Storing of provisioning requests to a zone on the ENUM server holding the slave copies
and the processing of these requests when the master copy of the zone is online again;
• Recovery of the ENUM server after the outage, updated according to changes during
the outage period.
A ENUM server entry is required for every IMS subscription to ensure that IMS routing
principles work correctly. It is also required that the provisioning solution, while inserting
appropriate data into the HSS, is also able to provision the ENUM database.
The ENUM converts an E.164 number to the so-called ARPA format that gives a globally
unique name to the Naming Authority Pointer Resource Record (NAPTR). NAPTR records
are used to store ENUM information. Based on this information, the E.164 telephone
number is mapped to a URI in the Internet. The following table provides a ENUM record
example created at the ENUM server.
Record Per Subscriber

x.x.x.x.x.x.x.x.x.7.0.4.e164.arpa.IN NAPTR 1 1 "u" "E2U+sip" "!^(.*)$!sip:<Global
Tel>@ims.mnc010.mcc226.3gppnetwork.org!
Table 5 – ENUM Record for a VoLTE Subscriber

4.2.3 The IMS-HELD Interworking Function
The IMS HTTP-Enabled Location Delivery (HELD) interworking function has been developed
to solve the need to interface the NEXES IMS component with the NEXES Location Server.
The OTT SIP emergency call reaches the IMS and then is routed towards the IMS-HELD
interworking function based on the URI (domain included). The IMS-HELD interworking
function retrieves the information from the SIP INVITE and performs a HELD request
towards the Location Information Server (LIS). The interface between the IMS-HELD
interworking function and the LIS uses the HELD Protocol (RFC 5985) [8].
4.2.4 Location Retrieval Function / Routing Determination Function
For the emergency call to be properly handled from a routing perspective, there is a need
for a Location Retrieval Function (LRF) within the network. The LRF is performed by a
server that retrieves the user’s location information from the operator’s network and inserts
it in a well-known/common format in order for the call to be routed according to the user’s
location. The location information retrieved is called Network Provided Location Information
(NPLI) and it is the most reliable location information to be used for routing an emergency
call to the right PSAP.
The main elements of this function are the:
• Location Retrieval Function – it queries the network elements (internal or external

databases) to retrieve the location of a subscriber (if not already provided);
• Routing Determination Function (RDF) – it is a geospatial or tabular routing database,
usually integrated with LRF.
The network elements that can be queried by the LRF are the HSS through the Sh Diameter
interface and the Home Location Register (HLR) through the Message Application Part
(MAP) interface. In the current NEXES IMS implementation, the MAP interface is the one
used.
The dedicated field for the location information in SIP signalling is the P-Access-Network-
Info (PANI) header. The network-provided location information and the user-provided
location information may both be kept in the SIP signalling, with the NPLI also displaying a
“;np” parameter at the end of the PANI header, as shown below:

PANI = E-UTRAN; hss-PLMN+TAC+ECI;np.
Or
P-Access-Network-Info: GSTN;gstn-location=”83970557000000”;np
Where
"E-UTRAN" : access-type=3GPP-E-UTRAN-FDD
"801.11" : access-type=IEEE-802.11
"GSTN" : access-type=GSTN
np – network provided
4.2.5 LPG Interworking Function
The LPG is composed of a Media Gateway Control Function (MGCF) and a Media Gateway
(MGW), entities that are responsible for the interconnection of the “IMS world” to outer
telecommunication worlds, including legacy PSAPs.
The MGCF maps the SIP signalling to the ISDN User Part (ISUP) or the Bearer-Independent
Call Control (BICC) signalling in order to connect to outer elements of telecommunication
networks. The MGCF performs controlling and routing (Control Plane) using SIP and ISUP
signalling while the MGW represents the User Plane part (the payload from the user
towards the network).
From an IMS perspective, the LPG Interworking Function represents a SIP endpoint that
performs call control and protocol conversion and controls the resources in a MGW
through an H.248 interface. Sometimes, the MGCF also plays the role of a Public Switched
Telephone Network (PSTN) Gateway, when it interfaces with the PSTN circuit-switched
core network where legacy PSAPs are connected.
The MGW is the equipment that handles the Real Time Protocol (RTP) stream (voice, video)
by converting it into Pulse Code Modulation (PCM). The MGW interfaces with CS networks
through the media plane.
The MGCF and the MGW are deployed in a redundant and geographical configuration so
that any emergency call can reach any PSAP, no matter the user’s location. Regarding the
user’s location, it is used in a dedicated field in the ISUP/BICC signalling and converted
from the location information retrieved from the network by the LRF. This field is interpreted
by the PSAP using the agreed mechanism: the location information is included in the called
party number and it contains the prefix, that is, the number designated for emergency to
enable the call’s routing to the PSAP, as well as some discriminators (to identify the service

and the service provider) and the location information following the Location Area Code
(LAC) + Cell ID (CI) rule. One example of such a field is provided here:
Called party number (Called Address Signals): 2111574000140189 -

where
21 – county prefix (Bucharest)
115 – number for emergency calls routed in transit operator network
5 – service identifier (emergency calls for VoWiFi)
74 – service provider identifier (Orange Romania)
00 – filler
014 – LAC – location area code (retrieved from the network for the calling subscriber)
0189 0 CI – cell id (retrieved from the network for the calling subscriber)

5 THE NEXES IMS FUNCTIONALITY
5.1 Registration and Authentication
5.1.1 Registration and Authentication for Native Calling
The registration and authentication processes in the IMS for a VoLTE/VoWiFi subscriber is
accomplished by applying different mechanisms and algorithms. The servers used are the
P-CSCF, the S-CSCF, the I-CSCF, the E-CSCF and the HSS. In the NEXES IMS, the
standard authentication method uses the IMS-AKA/md5 digest, but other methods (HTTP
digest, TLS-based HTTP digest) may also be used. The IMS-AKA represents the standard
security protocol used in the IMS and it enables to establish both the encryption - the Triple
Data Encryption Algorithm (3DES) or the Advanced Encryption Standard Cipher Algorithm
in Cipher Block Chaining (AES-CBC) - and the integrity - (the keyed-Hash Message
Authentication Code MD5 (HMAC-MD5) or the HMAC-SHA-1) - keys.
All permanent or temporary subscriber-relevant data that corresponds to the individual IMS
subscription is centrally stored in the Home Subscriber Server (HSS). The HSS front-end
interacts with the subscriber repository (database) providing the IMS subscriber data to the
requesting network elements (S-CSCF).
To obtain access to the IMS platform, the user must first register successfully with one IMS
Public User Identity (IMPU) or a SIP URI, using the defined authentication mechanism. The
IMPU could be the phone number in a SIP format or the user’s International Mobile
Subscriber Identity (IMSI) in a SIP format. An example of the IMPU would be:
SIP:<IMSI>@ims.mnc010.mcc226.3gppnetwork.org (temp IMPU, barred)

SIP:<Global Number>@ims.mnc010.mcc226.3gppnetwork.org (default)
TEL:<Global Number>
According to the prevailing standard, the IMPI would be:
<IMSI>@ims.mnc010.mcc226.3gppnetwork.org
An example of the SIP URI would be:
sip:+40744859865@ims.mnc010.mcc226.3gppnetwork.org
Or
sip: 466976789012345@ims.mnc010.mcc226.3gppnetwork.org
where the Mobile Station International Subscriber Directory Number (MSISDN) is

40744859865 and the IMSI is 466976789012345.

The process to register to the IMS platform comprises a set of steps: the user first registers
successfully with one IMPU or SIP URI by using the defined authentication mechanism. The
registration process is initiated by the IMS user by sending a SIP REGISTER to the P-CSCF
discovered previously. The REGISTER message is then sent to the I-CSCF that uses a
Diameter User-Authorisation-Request (UAR) message to query the HSS database. Based
on the HSS’s answer (User-Authorisation-Answer or UAA message), the I-CSCF informs the
P-CSCF of the S-CSCF that is serving that subscriber. Then, it forwards the REGISTER
message to the S-CSCF. The S-CSCF uses a Diameter Multimedia-Authorisation-Request
(MAR) message to the HSS to calculate the Authentication Vector (AV), thus generating the
quintuple <RAND, AUTN, XRES, CK, IK> and returns this to the S-CSCF through a
Multimedia-Authorisation-Answer (MAA) message. This message indicates the network is
requesting the terminal to use its security algorithms to authenticate itself.
Figure 10 – The REGISTER Message Flow
After the S-CSCF sends the SIP 401 Unauthorised message accompanied by four of the
five parameters making-up the AV to I-CSCF, which forwards the message to the P-CSCF.
Again, the P-CSCF forwards the message to the user with only two parameters, the RAND
and the AUTN. Since the terminal has the same secret key to the corresponding HSS, the

user can calculate the AUTN. If it matches the one received from the network, the network
is considered legitimate. The user also calculates its response (RES), sent in a SIP
REGISTER message with IMPI and Average Revenue Per User (ARPU) that reaches the P-
CSCF which forwards it to the I-CSCF. The I-CSCF sends a Diameter UAR to the HSS,
which responds with the address of the S-CSCF through another Diameter UAA message.
Then, the I-CSCF forwards the registration message with the RES to S-CSCF and the S-
CSCF sends a Server-Assignment-Request (SAR) Diameter message to the HSS that
replies with a Server-Assignment-Answer (SAA) message. If the RES parameter sent by the
user is equal to eXpected authentication RESult (XRES), calculated by the HSS during the
first registration attempt, then the HSS authenticates the user by means of the Diameter
SAA message. Finally, the S-CSCF sends a SIP 200 OK message to the P-CSCF, which
forwards it to the user.
5.1.2 Registration and Authentication for OTT Calling
For the registration and authentication of OTT calls, the user profile located in the HSS
must contain all information related to the OTT subscriber: the SIP URI, the domain, the
specific profile (language, user type, application server identity).
The registration flow is similar to the one provided in the previous section and the SIP
message flow is also the same (REGISTER, 401 Unauthorised, second REGISTER and 200
OK). However, since the device does not have a SIM card (providing the ISIM or the
Universal Subscriber Identity Module or USIM capability), another type of authentication is
required. There are multiple methods to authenticate OTT Applications. According to the
NEXES Security Recommendations, the NEXES IMS implements the digest access
authentication, specified by RFC 2069, later replaced by RFC 2617 [9], an agreed-upon
method that a web server may use to negotiate credentials, such as username or
password, with a user's web browser or Application.
The digest access authentication method confirms the identity of a user before sending
sensitive information, such as personal information, performing sensitive functions (online
banking transactions). The method applies a hash function to the username and password
before sending them over the IP network. Technically, the digest authentication is an
application of MD5 cryptographic hashing with usage of nonce values to prevent replay
attacks and it uses the HTTP protocol. The authentication response is formed as follows:

HA1=MD5(username:realm:password)
HA2=MD5(method:digestURI)
response=MD5(HA1:nonce:HA2)
(HA1 and HA2 are names of string variables)
A REGISTER message for a NEXES OTT subscriber would be:
REGISTER sip:nexes.ims.orange.ro SIP/2.0

Via: SIP/2.0/UDP 172.17.42.51:5060;branch=z9hG4bK08c7vo10cohacnjlt9o0.1
From: <sip:+40374999900@nexes.ims.orange.ro>;tag=1637340517
To: 40374999900 <sip:+40374999900@nexes.ims.orange.ro>
Contact: "40374999900" <sip:+40374999900-
kblp7gokflqa9@172.17.42.51:5060;transport=udp>
Call-ID: B163D2103F9745148006DCEAD86F8B51@nexes.ims.orange.ro
CSeq: 54141 REGISTER
Expires: 1800
Max-Forwards: 69
Content-Length: 0
Route: <sip:10.245.48.85:5066;lr>
5.2 Location Retrieval and Call Routing
5.2.1 Location Retrieval and Call Routing for Native Calling
For VoLTE/VoWiFi emergency calls, the IMS emergency call was introduced in the 3GPP
Rel 9. Emergency Call Handling for native calling allows the P-CSCF to detect emergency
calls identified via pre-configured emergency numbers and to route such requests to a E-
CSCF. The P-CSCF supports the e2 interface towards the Connectivity Location Function
(CLF) and the Mw interface towards an E-CSCF. Since emergency call handling is required
by regulatory authorities, the CSCF enables the operator’s network to comply with the legal
requirements and to serve the VoLTE and VoWiFi subscribers in an efficient manner in case
of an emergency.
The Emergency Registration and the Emergency Call Handling service is provided,
including the support of the location information in the Cell_ID or Segment_ID parameters
carried in the SIP PANI header. The PANI header may include one of two types of location
information:
• The Network Provided Location Information (NPLI);

• The User Provided Location Information (UPLI).

The NPLI is the recommended method for providing the most reliable location information
and it is used in NEXES. When it is not available, then the UPLI may also be used.
When initiating an emergency call, after the successful emergency registration, the user
sends a SIP INVITE towards the P-CSCF. The P-CSCF detects that the INVITE corresponds
to an emergency request, either by using the dedicated emergency numbers database
(e.g., 112, 999) or by parsing the SIP INVITE with the SIP service Uniform Resource Name
(URN) urn:service:sos in the request URI. The SIP INVITE is then forwarded to the E-CSCF
that is sending the SIP INVITE to the LRF server. After successfully receiving this SIP
message, the LRF uses first the Diameter Sh message and then the MAP interface to
retrieve the user location from the HSS or the Home Location Register (HLR).
The DIAMETER messages used are the User Data Request/User Data Answer (UDR/UDA)
and the LRF supports the data reference avp as “Location information”, according to the
3GPP standard.
IMS HSS HLR
Sh UDR Sh UDA MAP ATI

E-CSCF
E-CSCF
INVITE tel:112;p...
INVITE tel:112;p...
PAI: tel:+MSISDN
PAI: tel:+MSISDN
PANI: PLMN+TAC+ECI LRF
PANI: PLMN+TAC+ECI
or IEEE-802.11
LRF
a) b)
Figure 11 – The Location Retrieval Message Flow via a) the Sh Interface and via b) the MAP Interface
For each emergency call, the LRF retrieves the last known 2G/3G/4G location (LAC, CI,
DISTRICT - county) by using either the Sh or MAP interfaces and processes it:
• LAC and CI analysis:

• if it receives a location:
• if the location is received from the 4G network (the decision is made based on
the length of the CI), it will search in the CELL_LOCATION table a 2G/3G LAC

and CI of a cell that is on the same site as the 4G cell / the nearest 2G/3G cell
and it will insert this LAC and CI in the SIP PANI Header;
• else the LAC and CI received will be inserted in the SIP PANI Header;
• else, it will not add the location information and, for the next steps, it will use the
default routing;
• district analysis:
• if it receives a district, it will use its value in order to get the prefix that must be
added to the called number, based on a table/memory file that links the district to its
prefix (ex: for Bucharest and Ilfov, the "021" prefix will be added to the called party,
changing it to 021112 or with NEXES PSAP destination);
• else, it will use a default prefix set in the configuration file of the service.
After, the service enriches the INVITE with location information, adds the prefix to the called
party and routes the INVITE to the MGCF.
5.2.1.1 Native WiFi Calling While Abroad
The scenario for native WiFi emergency calling while the user is abroad has been
addressed by NEXES and two solutions were considered.
Mid-term Solution
In the mid-term, enabling native WiFi emergency calling by a user that is abroad is possible
through a mechanism that detects and allows or disallows emergency calls to be routed to
the home network.
This mechanism either uses Mobile Network Code (MNC) / Mobile Country Code (MCC)
information when the user registers to the IMS network or benefits from national
agreements that allow emergency calls.
There are two distinct cases: in the case VoWiFi (and VoLTE) roaming is allowed, the user
must be able to connect to the abroad network’s P-CSCF that will treat the emergency call
like a regular local IMS emergency call; it performs an emergency registration and, based
on the subscriber’s NPLI, routes the call to the emergency centre. In the case emergency
calls over IMS are not permitted in the abroad network, the device performs a Circuit
Switched Fall Back (CSFB)-based on the error received from the IMS network (either a 5xx
error case or a specific error case with a SIP reason).

Depending on the regulations for emergency calls in the abroad country, the call could be
routed to the home country emergency calls but this is not yet regulated as it requires a
strong cooperation between the operators in the abroad country and the local authorities in
home country or perhaps with the subscribers’ operator. Moreover, this option will require a
strong standardisation effort, to establish a common location information format. The
NEXES RIA addresses the opportunity to discuss this new standardisation effort, bringing
forth relevant use cases for roaming IMS regulation (Home Routing or Local Breakout).
Long-term Solution
This scenario is applicable only when sufficient operator networks support native WiFi
calling. If abroad, the device would use the local network’s Evolved Packet Data Gateway
(ePDG) to gain access to native WiFi calling through the "epdg.epc.mnc<MNC>
.mcc<MCC>.pub.3gppnetwork.org" FQDN as per 3GPP TS 23.003 [16] § 19.4.2.9, but
using the MNC and MCC from the visited network, instead of the MNC and MCC from the
SIM card. In this case, the visited ePDG authenticates the user with the home
Authentication, Authorisation and Accounting (AAA) and gives access to the local IMS
services for emergency calling. As a result, the emergency call does not reach the home
IMS and is routed by the visited network to the local PSAP with more accurate location
information. However, if there is no ePDG in the visited network, the UE would fall back to
the mid-term solution to ensure a successful emergency call set-up.
5.2.2 Location Retrieval and Call Routing for OTT Calling
For OTT emergency calling, the location retrieval and call routing flow is similar with the one
described in the previous section (on native calling), where the main component is also the
LRF, triggered via SIP.
Figure 12 – NEXES IMS Architecture for Location Retrieval in OTT Calling

Overall, for each OTT emergency call, the E-CSCF triggers the LRF based on 112
information in the Request URI header (either 112 or sos urn). Then, the LRF would retrieve
the user’s 2G/3G/4G location and insert this location in the PANI header in the SIP request
sent to the SIP gateway. If it does not find the location, it will use a default location. It will
also add in the Request URI, the prefix of the NEXES PSAP. Finally, the call is routed to the
SIP GW (the SBC) that will forward the SIP INVITE to the NEXES PSAP.
5.2.3 Location Retrieval and Call Routing Using the PEMEA Network
When using the PEMEA network, the IMS will follow the network’s indication of the right
PSAP and route the emergency call to the PSAP indicated in the SIP INVITE. The flow
would be:
1. The user makes a call using the NEXES App that sends the location and user data to
the Application Provider (AP), along with the request for a SIP URI capability;
2. The AP creates an Emergency Data Send (EDS) message that includes an
apMoreInformation element request for a SIP URI; the message is forwarded through
the PEMEA network to a terminating PSAP Service Provider (PSP). The terminating PSP
sends the EDS message to the PSAP;
3. The PSAP indicates the capabilities it supports back to the AP;
4. The PSAP invokes the SIP URI capability and hands to the AP the SIP URI for the
PSAP;
5. The AP sends the PSAP SIP URI to the NEXES App;
6. The NEXES App sends a SIP INVITE for an emergency call to the PSAP URI;
7. The INVITE is routed via the IMS and through the ESInet to the PSAP.
VSP ESInet
SIP INVITE (PSAP-URI)
7
6
3
onCapSupportPost
1
Data + SIP-URI Req
App AP PEMEA PSP Data + SIP-URI Req

PSAP
PSAP SIP URI 2
5
Invoke SIP (PSAP URI)
Figure 13 – Call Routing Using the PEMEA Network

If further routing is required in the ESINet, then the PSP can be associated with the gateway
into the ESINet, in which case the LRF or Emergency Services Routing Proxy (ESRP) in the
ESINet can request location and perform its own routing using a RDF or Emergency Call
Routing Function (ECRF). In this mode, the PSP acts as a proxy to access other information
in the PEMEA network, including location updates and user data.
5.3 Call Set-up and Control
5.3.1 Initial Call Set-up
For any SIP call, the media negotiation takes place in the initial INVITE and OK messages
exchanged between the caller and the callee. In the body of each INVITE and OK message,
there is a Session Description Protocol (SDP) body indicating which media types and
formats they intend to use. Below is a very minimal example of an SDP body with audio,
video and real-time text:
v=0
o=anonymous 1434443509 1434443508 IN IP4 10.0.0.2
s=-
i=SIPClient
c=IN IP4 10.0.0.2
t=0 0
m=audio 6000 RTP/AVP 8
a=rtpmap:8 PCMA/8000
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
m=text 6006 RTP/AVP 99 98
a=rtpmap:99 RED/1000
a=rtpmap:98 T140/1000
a=fmtp:99 98/98/98
The caller’s device sends a SIP INVITE containing a SDP body resembling the above
example, and the callee’s device responds in accordance, with the current preferences. For
instance, the callee may not want an audio stream and the response would then indicate
that in the SDP body. Note that the example above is simplistic, stripped of options such as
bandwidth preferences and additional connection information. Real-world SDP bodies are
often larger.
5.3.2 Modifying an Emergency Call in Progress
Modifying an emergency call in progress means adding/changing different parameters that

are used for call control or for call routing: e.g., parameters related to call quality (voice and

video codecs) may be dynamically allocated and, based on the quality of the access type, a
better codec can be used during renegotiation between the subscriber and the network
equipment.
One means of modifying the emergency call in progress relates to changes caused by the
user’s mobility. One such function supported by the NEXES IMS platform is the Emergency
Access Transfer Function (EATF), which plays the role of the media anchor for voice call
continuity when the user is moving from a 4G coverage area to a 3G coverage area or is
moving from a packet-switched (PS) core access (3GPP access) to a CS core access
(traditional 2G/3G voice) network. The EATF is only available for native emergency calling,
when the user is located in WiFi or a 4G (VoLTE or VoWiFi).
There are also situations where the user wants to add or remove a specific media type
during an active emergency call. It is possible for the user to terminate the call and re-
establish it with the new media parameters, but this method is quite disruptive.
Alternatively, the SIP specification allows the use of re-INVITEs, which is simply the
capability to send another INVITE during the call, presenting updated parameters. Both the
original caller and the callee may send a re-INVITE during an ongoing emergency call and it
may modify almost every aspect of an ongoing call (the most common change is the call’s
media characteristics). It may also be used to place a call on hold, by sending a re-INVITE
with media streams that are disabled, and to add new media streams to an ongoing call
(e.g., to add a video stream to an audio-only call: the re-INVITE suggests a video stream
and the receiver’s device replies based on its capabilities; if the receiver is capable and
willing, that is, it has been configured to allow video calls, it responds with a matching SDP
body and the new media stream can be started.
5.3.3 Charging and Reporting
Although the emergency service (voice, video, text) is offered as a free service, the
requirements involved also accounts for the overall traffic split by category/type of traffic or
by user traffic.
In the NEXES IMS solution, there is a need to provide charging/reporting for the emergency
calls that are served by the network. For such purpose, multiple interfaces/protocols can be
used: retrieve the Call Data Reports (CDRs) using ftp/sftp, use the Diameter interfaces to
trigger charging events and store them in a common format as csv or xls files. The servers
that can issue reports/charging information are the S-CSCF, the E-CSCF, the LRF/RDF and

the MGCF. The E-CSCF is able to perform offline charging, which can be used for operator-
interworking charging/accounting, as well as for statistical purposes.
The CDRs may be retrieved from the MGCF. An example for such a CDR is presented
below:
2017-03-30 07:40:59,134|172.19.28.134|2017-03-30 07:40:53.823|2017-03-30

07:40:56.852|"zxjdWpV6gD1KCr"|"NexesIMS|"tel:+40744448353"|"40744448353"|"tel:+40744448
353"|"40744448353"|"112"|"40744448353"|"9483b03fade2f9bf4ccd"|"IMS.TP.ORANGE.RO"|||||||"
+4021"|"IMS.TP02.MNC010.MCC226.3GPPNETWORK.ORG"||SUCCESS
5.3.4 Quality of Service
The design and implementation of Quality of Service (QoS) mechanisms assure the
prioritisation for emergency calls: firstly, voice calls; secondly, video and real-time text, in
case of high traffic (namely during a large-scale emergency). QoS is therefore a must for the
NEXES IMS platform.
In emergency calling, QoS relates directly to the principles guiding the emergency concept:
availability, continuity and reliability. The emergency call should be initiated with special
handling capabilities in order to guarantee the resources for the total duration of the call. In
this context, QoS is ensured differently, depending on the network level (access, core and
border). In NEXES, to allow traffic prioritisation and QoS, mechanisms were implemented to
deal with different flows, both within NEXES IMS network elements and at the edge of
NEXES (access and PSAPs).
The first level of QoS may be achieved at access levels by using dedicated access links for
native calls (VoLTE/VoWiFi). Using a dedicated emergency Access Point Name (APN), the
service provider may enhance and prioritise the different types of traffic (normal call vs.
emergency call, emergency call vs. data).
The emergency APN provides the user a dedicated bearer and a local P-CSCF address and
thus enables the relevant network elements to prioritise bearers when performing
admission control for a specific emergency call.
Another important QoS level relates with prioritisation. The prioritization mechanism allows
the network to statically or dynamically allocate and maintain resources in order for the
emergency call to have an end-to-end priority. For traffic prioritisation related to signalling,
the QoS Class Identifier (QCI) 5 is used; for voice calls, the QCI 1 is used and it

corresponds to specific Differentiated Services Code Expedited Forwarding (DSCP EF); for
video traffic, the QCI 4 is used, according to the next table1.
Marking Use DSCP Marking

0 Routine Traffic Default
1 112 Signalling AF12
2 112 Text Media AF12
3 112 Audio Media EF
4 112 Video Media AF11
5 112 Non-Human-associated Call AF21
6 Intra ESINet Events AF21
7 Intra ESINet other 112 traffic AF22
Table 6 – EENA Proposal for QoS of Emergency Services Traffic
The NEXES IMS solution also implements specific traffic classes of QoS for emergency
services, considering the requirements established for voice traffic prioritisation:
• Emergency services for call signalling prioritisation in IP networks must be the same
applied to emergency calls in legacy voice networks;
• Radio prioritisation;
• PCRF is involved for Policy and Charging Enforcement Function (PCEF) rules;
• No quota reporting is required;
• Video emergency services must have lower priority than voice calls with bandwidth
reservation (for emergency services).
5.4 Evolution in Functionality
5.4.1 Rich Communication Suite
Rich Communication Suite (RCS) represents a standard defined by the GSM Association
(GSMA) that combines different services defined by the 3GPP and the Open Mobile Alliance
(OMA). The RCS is therefore a communication protocol between mobile phones and the
carrier, aiming at replacing Short Message Service (SMS) messages with a text message
system that is richer, providing phone-book polling for service discovery and transmitting
in-call multimedia. In this context, RCS is a potential evolution of the NEXES IMS solution. It
allows transmission of voice, video and text via any IP access (2G/3G/4G/WiFi) and the
1
Proposal of the European Emergency Number Association (EENA) on NG112 [17].

most used functions would be normal SIP voice, shared video (see-what-I-see), instant
messaging, store-and-forward, file transfer (photo, video, documents), share location. The
development of the RCS service has led to the Enhanced RCS (RCSe).
The introduction of RCS/RCSe capabilities is causing changes in the call registration and
set-up design. The solution applied is to use non-prioritised traffic (RCS/RCSe is available
on standard and compatible applications registered and certified by GSMA) and establish a
dedicated PSAP for this type of traffic.
The NEXES IMS solution is fully GSMA RCS initiative-compliant, delivering a rich end-to-
communication platform that uses mobile end-user devices. It supports instant messaging
(IM) as specified in 3GPP TS 23.228, message sessions using SIP/SDP and the transport of
Message Session Relay Protocol (MSRP) media streams over TCP between end-user
devices. The MSRP is a connection-oriented protocol for exchanging arbitrary (binary)
content and the MSRP sessions are typically arranged using SIP with SDP content (same
set-up used for a session of audio or video media). MSRP can be used within a SIP session
to do Instant Messaging (IM), to transfer files, to share images or video.
Secure MSRP is implemented by applying Transport Layer Security (TLS) between the user
equipment and the Border Gateway (end-to-access-edge). The successor to the Secure
Sockets Layer (SSL), TLS is a protocol that ensures privacy between communicating
applications and their users on the Internet: when a server and client communicate, TLS
ensures that no third-party may eavesdrop or tamper with any message. The TLS
authentication is enabled by exchanging fingerprints of self-signed certificates of the UE
and the BGW on the (SIP) control layer. Also the MSRP over TLS may be implemented in a
future development of the NEXES IMS solution.
5.4.2 Web-based Real Time Communication
Web-based Real Time Communication (WebRTC) is a free, open project that provides
browsers and mobile Applications real-time communication capabilities via simple APIs.
The scope of the protocol is to enable rich, high-quality RTC applications to be developed
for the browser, mobile platforms and Internet of Things (IoT) devices, allowing them to
communicate via a common set of protocols.
NEXES has developed its own implementation of a WebRTC-based App and PSAP system.

5.4.3 Next Generation eCall
eCall [4] is an European initiative with the purpose to bring rapid assistance to drivers
involved in car accidents/collisions anywhere in the European Union. In case of a crash, an
eCall-equipped car automatically calls the nearest PSAP emergency centre. Even if no
passenger is able to speak, e.g. due to injuries, a 'Minimum Set of Data' is sent to the
PSAP centre, which includes the exact location of the crash site. Shortly after the accident,
emergency services are made aware that there has been an accident and its exact location.
The following image illustrates the basic routing of the eCall mechanism 2.
Figure 14 – eCall Basic Routing
NEXES implements a prototype for a next generation eCall system, adding to the traditional
eCall mechanism the total conversation capability (audio call, video and chat) and the
exchange of relevant data.
5.5 Security
This section is dedicated to the presentation of the main findings of Task 3.4 with respect
to the implementation of different levels and mechanisms of security in the context of the
NEXES IMS solution, including but not limited, to the prevention and mitigation of the most
predominant threats or risks:
• Network snooping;
• Session hijacking;
• Denial of Service;
• P-CSCF discovery;
• Service abuse;
• Toll fraud.
2
https://ec.europa.eu/digital-single-market/sites/digital-agenda/files/ecall_process.png.

5.5.1 Network Snooping
Network snooping is related to the breaking of confidentiality. Without the protection

offered by encrypted services, it is easy for an attacker to capture the SIP signalling and the
RTP traffic using packet sniffing tools, such as Wireshark. Another attack against
confidentiality can be realised using scan tools to gather sensitive and valuable information
about the IMS components, operating systems and network topology.
The affected assets by this predominant attack would be the user data and the user
communication (SIP calls).
Implemented mitigation techniques within NEXES are the use of a Secure Sockets Layer/
Transactions per Second (SSL/TPS) or the Internet Protocol Security (IPSec) for securing IP
sessions and the use of SIP over TLS 1.2 (SIPS) and Secure RTP (SRTP) for securing the
SIP and RTP sessions (signalling and media).
5.5.2 Session Hijacking
Session hijacking is a mechanism in which an attacker can get a SIP users’ subscription
and, consequently, that user’s communication. There are multiple ways of performing such
attacks, the most common of which is related to de-registering a user, generating a race
condition for a registration and even modifying the IP addresses in SIP fields in the Contact
header. All these methods ensure that subsequent registrations and incoming calls are
diverted to the attacker’s device.
The affected assets by this predominant attack would be the user registration and the
user’s future sessions.
Implemented mitigation techniques within NEXES are the implementation of the SIPS and
the authentication of SIP requests and responses.
5.5.3 Denial of Service
A Denial of Service (DoS) attack represents a flooding of a SIP server with a high volume of
SIP messages (SIP Register of SIP INVITE). The attack can be performed even if the SIP
endpoints accept the requests as a first step of an authentication process. The DoS attack
hence attains the exhaustion of the SIP server’s bandwidth and allocated resources,
resulting in the excessive load of the systems’ processors and a decrease of the QoS

related to voice calls. It may even cause the opportunity to issue new legit registrations for
a user.
Moreover, specific DoS attacks are indirect: they may be performed against servers that are
using the Dynamic Host Configuration Protocol (DHCP), DNS or the Bootstrap Protocol
(BootP). These DoS attacks aim to inhibit and block not only voice-related applications but
also data applications.
There are multiple methods to prevent and mitigate DoS attacks. In NEXES, it is privileged
the use of firewalls and rules to block potentially malicious SIP packets (malformed packets
and protocol errors that flood the access interfaces).
5.5.4 P-CSCF Discovery
The P-CSCF is the entry point in a standard IMS system. As a consequence, it is one of the
key elements envisaged in a dedicated attack. The mechanism used for P-CSCF discovery
comprises cache poisoning and DNS spoofing, aiming to disrupt the registration process of
an IMS user. The attacker hence may alter the process of P-CSCF discovery by changing
the DNS for a domain name or an IP address to a specific User Equipment, thus preventing
the subscriber from registering to the legit SIP server or enabling its registry to a fake
server.
Implemented mitigation techniques within NEXES involve the inclusion of the P-CSCF
discovery mechanism as part of the establishment of connectivity towards the IP-
Connectivity Access Network (a default in the NEXES IMS).
5.5.5 Service Abuse
Service abuse attacks impact the use of a service. It encompasses attackers acquiring
access to a different service than the one initially granted initially: for example, an attacker
enabling a video service on top of a voice service by using a potential security breach in the
SIP signalling.
Implemented mitigation techniques within NEXES are the requirement for a SIP user to
perform a codec re-negotiation after a specific period of time, as well as the prohibition to
access specific services.

5.5.6 Toll Fraud
Toll fraud refers to the possibility of an attacker being able to continue using an already
established media stream, after the SIP server closed the accounting information due to a
received BYE message. This type of attack is possible in IMS networks that do not exert an
effective control of media streams.
Implemented mitigation techniques within NEXES are:
1. The subscriber accesses the IMS network with strong authentication (access security);
2. The flow exchanged between clients and application servers is secured via a Virtual
Private Network (VPN) tunnel or an IPsec mechanism (network security);
3. Systems and applications are secured, with the software being regularly updated and
maintained and periodic security assessments being performed. The RFCs
implemented for IMS security are the RFC 6280 [11], the RFC 5069 [12] and the TS
33.203 [15]. Optionally, it is possible to implement a security mechanism related to SIP
over TLS and SRTP, according to the RFC 3711 [13] and the RFC 6188 [14].

6 CONCLUSION
The NEXES IMS is an all-IP platform that provides standardised interfaces for connecting
the users’ emergency Apps to the IMS world via a SIP protocol and towards the legacy
network for emergency services.
Standardised interfaces allow the emergency signalling to pass the NEXES IMS core
elements, abiding to the IMS specification with Total Conversation capabilities (audio, real-
time text, video, images) included in SIP.
By adding relevant information to the SIP signalling, namely location information in

dedicated fields, the NEXES IMS enables the use of dedicated SIP headers to perform the
routing of emergency calls to the right PSAP.
Following the IMS architectural framework, the NEXES IMS also allows the routing of legacy
VoLTE and VoWiFi emergency calls to the right next generation NEXES PSAP over an IP
interconnection, enabling NEXES gateways’ functionalities for interoperability between
legacy systems and next generation networks.
As the NEXES adopts its implementation of the IMS it also considers the evolution of this
component to accommodate future technological developments, new IMS services (RCSe,
WebRTC and NG eCall) with valuable insight to create a strong base for future
standardisation efforts.

7 BIBLIOGRAPHICAL REFERENCES
rd
[1] 3 Generation Partnership Project, 3GPP TS 24.229, “IP Multimedia Call Control Protocol
Based On The Session Initiation Protocol (SIP) and Session Description Protocol (SDP)
Stage 3”, Technical Specification, March 2014,
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationI
d=1055.
rd
[2] 3 Generation Partnership Project, 3GPP TR 23.869 V9, “IMS Emergency calls over General
Packet Radio Service (GPRS) and Evolved Packet Service (EPS) Release 9”, March 2009,
http://www.qtc.jp/3GPP/Specs/23869-900.pdf.
[3] J. Rosenberg et al., RFC 3261, “SIP: Session Initiation Protocol”, Internet Engineering Task
Force, Standards Track, June 2002, https://www.ietf.org/rfc/rfc3261.txt.
[4] European Commission, eCall, https://ec.europa.eu/digital-single-market/en/ecall-time-

saved-lives-saved.
[5] R. Gellens et al., RFC7852, “Additional Data Related to an Emergency Call”, Internet
Engineering Task Force, Standards Track, July 2016, https://tools.ietf.org/html/rfc7852.
rd
[6] 3 Generation Partnership Project, 3GPP TS 23.167, “IP Multimedia Subsystem (IMS)
Emergency Sessions”, Technical Specification, January 2015,
d=799.
rd
[7] 3 Generation Partnership Project, 3GPP RFC 3761, “The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)”,
Standards Track, April 2004, https://www.ietf.org/rfc/rfc3761.txt.
rd
[8] 3 Generation Partnership Project, 3GPP RFC 5985, “HTTP-Enabled Location Delivery
(HELD)”, Standards Track, September 2010, https://tools.ietf.org/html/rfc5985.
rd
[9] 3 Generation Partnership Project, 3GPP RFC 2617, “HTTP Authentication: Basic and Digest
Access Authentication”, Standards Track, June 1999, https://www.ietf.org/rfc/rfc2617.txt.
rd
[10] 3 Generation Partnership Project, 3GPP RFC 3966, “The tel URI for Telephone Numbers”,
Standards Track, December 2004, https://www.ietf.org/rfc/rfc3966.txt.
rd
[11] 3 Generation Partnership Project, 3GPP RFC 6280, “An Architecture for Location and
Location Privacy in Internet Applications”, Best Current Practice, July 2011,
https://tools.ietf.org/html/rfc6280.
rd
[12] 3 Generation Partnership Project, 3GPP RFC 5069, “Security Threats and Requirements for
Emergency Call Marking and Mapping”, Information, January 2008,
https://www.ietf.org/rfc/rfc5069.txt.
rd
[13] 3 Generation Partnership Project, 3GPP RFC 3711, “The Secure Real-time Transport
Protocol (SRTP)”, Standards Track, March 2004, https://www.rfc-editor.org/rfc/rfc3711.txt.

rd
[14] 3 Generation Partnership Project, 3GPP RFC 6188, “The Use of AES-192 and AES-256 in
Secure RTP”, Standards Track, March 2011, https://tools.ietf.org/html/rfc6188.
rd
[15] 3 Generation Partnership Project, 3GPP TS 33.203 Version 11.2.0 Release 11, “3G
Security: Access security for IP-based services, Technical Specification, November 2012,
d=2277.
rd
[16] 3 Generation Partnership Project, 3GPP TS 23.003, “UMTS; Numbering, Addressing and
Identification”, Technical Specification, Release 5, June 2006,
d=729.
[17] European Emergency Number Association, Next Generation 112 Long Term Definition, April
2012, http://www.eena.org/ressource/static/files/eena_ng112_ltd_v1-0_final.pdf.

8 ACRONYMS AND DEFINITIONS
2G 2nd Generation
3DES Triple Data Encryption Standard
3G 3rd Generation
3GPP 3rd Generation Partnership Project
4G 4th Generation
AAA Authentication, Authorisation, Accounting
A-BCF Access Border Control Function
AES Advanced Encryption Standard
AP Application Provider
APN Access Point Name
App Application
ATCF Access Transfer Control Function
ATGW Access Transfer Gateway
ARPU Average Revenue Per User
AUTN AUthentication TokeN
AV Authentication Vector
BCF Border Control Function
BGCF Breakout Gateway Control Function
BGF Border Gateway Function
BGW Border Gateway
BICC Bearer-Independent Call Control
BootP Bootstrap Protocol
CBC Cipher Block Chaining
CDR Call Data Report
CI Cell ID
CLF Connectivity Location Function
CS Circuit Switched
CSCF Call Session Control Function
CSFB Circuit Switched Fall Back
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Server
DoS Denial of Service
DSCP EF Differentiated Services Code Point Expedited Forwarding
EATF Emergency Access Transfer Function
ECRF Emergency Call Routing Function

E-CSCF Emergency - Call Session Control Function
EDS Emergency Data Send
ENUM Electronic Number Mapping System
ePDG Evolved Packet Data Gateway
EPS Evolved Packet System
ERO Emergency Response Organisation
ESRP Emergency Services Routing Proxy
ETSI European Telecommunications Standards Institute
ESINet Emergency Services IP Network
FQDN Fully Qualified Domain Name
FR First Responder
GSM Global System for Mobile Communications
GSMA GSM Association
GW Gateway
HELD HTTP Enabled Location Delivery
HLR Home Location Register
HMAC keyed-Hash Message Authentication Code
HSS Home Subscriber Server
HTTP Hyper Text Transport Protocol
IBCF Interconnect Border Control Function
I-CSCF Interrogating Call State Control Function
ID Identifier
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IM Instant Messaging
IMPI IP Multimedia Private Identity
IMPU IP Multimedia Public User Identity
IMS IP Multimedia Subsystem
IMS-AKA IP Multimedia Subsystem Authentication and Key Agreement
IMSI International Mobile Subscriber Identity
IoT Internet of Things
IP Internet Protocol
IPSec Internet Protocol Security
ISC IP multimedia Service Control
ISUP Integrated Services Digital Network User Part
ITU International Telecommunication Union
LAC Location Area Code

LIS Location Information Server
LPG Legacy PSAP Gateway
LRF Location Retrieval Function
LTE Long Term Evolution
M2M Machine-to-Machine
MAA Multimedia-Authorisation-Answer
MAP Message Application Part
MAR Multimedia-Authorisation-Request
MCC Mobile Country Code
MGCF Media Gateway Controller Function
MGW Media Gateway
MNC Mobile Network Code
MSISDN Mobile Station International Subscriber Directory Number
MSRP Message Session Relay Protocol
MSS Mobile Softswitch Solution
NAPTR Naming Authority Pointer Resource Record
NAT Network Address Translation
NEXES NEXt generation Emergency Services
NG Next Generation
NPLI Network Provided Location Information
OMA Open Mobile Alliance
OTT Over-The-Top
PANI P-Access-Network-Info
PCEF Policy and Charging Enforcement Function
PCM Pulse Code Modulation
PCRF Policy and Charging Rules Function
P-CSCF Proxy Call Session Control Function
PEMEA Pan-European Mobile Emergency Application
PESEA Pan European Specifications for Emergency Apps
PGW Packet Data Network Gateway
PLMN Public Land Mobile Network
PS Packet Switched
PSAP Public Safety Answering Point
PSP PSAP Service Provider
PSTN Public Switched Telephone Network
QCI Quality-of-service Class Identifier
QoS Quality of Service

RAND RANDom
RCS Rich Communication Suite
RCSe Enhanced Rich Communication Suite
RDF Route Determination Function
RES Result
RFC Request For Comments
RTC Real Time Communication
RTP Real Time Protocol
SAA Server-Assignment-Answer
SAR Server-Assignment-Request
SBC Session Border Control
S-CSCF Serving Call State Control Function
SCTP Stream Control Transmission Protocol
SDP Session Description Protocol
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SIPS Session Initiation Protocol Security
SLA Service Level Agreement
SMS Short Message Service
SRTP Secure Real Time Protocol
SRVCC Single Radio Voice Call Continuity
SS7 Signalling System No. 7
SSL Secure Socket Layer
STUN Session Transversal Utilities for NAT
TCP Transmission Control Protocol
TLS Transport Layer Security
TPS Transactions Per Second
TrGW Transition Gateway
TURN Transversal Using Relays around NAT
UAA User-Authorisation-Answer
UAR User-Authorisation-Request
UDP User Datagram Protocol
UE User Equipment
UPLI User Provided Location Information
URI Universal Resource Identifier
URL Universal Resource Locator
URN Universal Resource Name

USIM Universal Subscriber Identity Module
ViLTE Video- over-Long Term Evolution
VoIP Voice-over-IP
VoLTE Voice-over-Long Term Evolution
VoWiFi Voice-over-WiFi
VPN Virtual Private Network
WebRTC Web-based Real Time Communication
WiFi Wireless Fidelity
WP Work Package
XRES eXpected authentication RESult
XML eXtensible Mark-up Language

9 ANNEX
9.1 Mapping the NEXES System Requirements to the IMS

Components
NEXES IMS
NEXES System Requirements Fulfilment
Components
[O-010] The NEXES system shall support an end-to-end
P-CSCF, E-CSCF Yes
emergency communication call over any IP access network.
[O-020] The NEXES system shall not disrupt legacy calls from E-CSCF, BGW,
Yes
being delivered to the correct PSAPs. MGCF
[O-030] NEXES shall offer a new set of communication methods P-CSCF, E-CSCF,
Yes
to initiate an emergency call. BGW, MGCF
[O-040] NEXES shall support Total Conversation during an P-CSCF, E-CSCF,
Yes
emergency call. BGW
[O-050] The NEXES system shall be designed to operate at a
All components Yes
Pan-European level.
[O-060] The NEXES system should provide multiple
SBC, P-CSCF Yes
communication channels with emergency services.
[O-070] The NEXES system should allow citizens to choose
from different communications channels the one to use when SBC, P-CSCF Yes
calling an emergency service.
[O-080] The NEXES system must be inclusive of all users, trying
All components Yes
to accommodate all citizens’ needs.
[O-090] The NEXES system shall be designed to allow the P-CSCF, E-CSCF,
Yes
interoperability of PSAPs, EROs and FRs. SBC
[O-100] The NEXES system shall be designed use a variety of E-CSCF, HSS,
Yes
mechanisms to accurately retrieve the calling citizen’s location. HLR, LRF
[O-110] The NEXES system shall be designed to provide the
E-CSCF, MGCF,
calling citizens’ location with a higher accuracy location than Yes
LRF, HLR
legacy systems.
[O-120] The NEXES system shall provide a free service to Yes
All components
citizens when calling the emergency number.
[O-130] The citizens’ access to the NEXES system shall not
P-CSCF Yes
require pre-registration.
[O-140] The NEXES system should only receive personal
information with consent of the owner and there must be a good N/A
reason for collecting that information.
[O-150] The NEXES should adopt widely used and open
All components Yes
standards.
[C-010] The NEXES system shall support various types of UE,
including legacy phones (traditional analog landline), mobile
P-CSCF Yes
phones (any generation) and other IP-enabled equipment
(including soft phones supporting NEXES functionalities).
[C-200] RTP implementation shall include an RTP Control
BGW, MGCF Yes
Protocol (RTCP) implementation according to IETF RFC 3550.

Attachment 0

Uploaded by

Document Information

Original Title

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

Attachment 0

Uploaded by

Copyright:

Available Formats

Ref.

NEXES Research and Innovation Action

NEXES IMS Architecture

Action acronym: NEXES

Action full title: NEXt generation Emergency Services

Work Package: WP3 – The NEXES Core

Deliverable number: D3.4

Document title: NEXES IMS Architecture

Delivery date: 30 June 2017

Authors: Liviu Ciulei, Marius Iordache and Vlad Sorici (ORO);

Reviewers: Anastasia Bolovinou (ICCS); Janez Sterle and Urban

Editors: Barbara Guerra (RIN)

Lead contractor for ORO

NEXES – GA No. 653337 | Deliverable D3.4 Page 2 of 54

Date Version Change

This delivery was screened by the NEXES Steering Board.

NEXES – GA No. 653337 | Deliverable D3.4 Page 3 of 54

To learn more please see: www.nexes.eu.

NEXES – GA No. 653337 | Deliverable D3.4 Page 4 of 54

1 EXECUTIVE SUMMARY .................................................................................................. 8

3 THE NEXES IMS HIGH-LEVEL ARCHITECTURE ........................................................ 14

4 THE NEXES IMS COMPONENT ................................................................................... 18

5 THE NEXES IMS FUNCTIONALITY .............................................................................. 29

NEXES – GA No. 653337 | Deliverable D3.4 Page 5 of 54

NEXES – GA No. 653337 | Deliverable D3.4 Page 6 of 54

Table 1 – Key Concepts Of Deliverable D3.4 .......................................................................................13

Figure 1 – NEXES General Architecture .................................................................................................9

NEXES – GA No. 653337 | Deliverable D3.4 Page 7 of 54

NEXES – GA No. 653337 | Deliverable D3.4 Page 8 of 54

• Standard Voice-over-IP (VoIP) emergency communication (VoLTE and VoWiFi);

NEXES main components are depicted in Figure 1 and explained hereafter.

Figure 1 – NEXES General Architecture

NEXES – GA No. 653337 | Deliverable D3.4 Page 9 of 54

2.1 Deliverable’s Purpose

2.2 Deliverable’s Context

NEXES – GA No. 653337 | Deliverable D3.4 Page 10 of 54

To support a universal, democratic and inclusive emergency service, it is vital that

2.3 Applied Methodology

NEXES – GA No. 653337 | Deliverable D3.4 Page 11 of 54

2.4 Key Concepts

This document applies several key concepts:

NEXES – GA No. 653337 | Deliverable D3.4 Page 12 of 54

NEXES – GA No. 653337 | Deliverable D3.4 Page 13 of 54

3.1 The Role of the IMS Component

Call Access Application

Figure 3 – NEXES IMS As a Central Component of NEXES Architecture

NEXES – GA No. 653337 | Deliverable D3.4 Page 14 of 54

Illustrated in Figure 4, the components involved in OTT calls are:

• The NEXES App;

Call Access Network Application

Figure 4 – Involved OTT Calling Components and Flow

Whereas, as presented in Figure 5, the components involved in native calls are:

• Native emergency call function in the operating system;

NEXES – GA No. 653337 | Deliverable D3.4 Page 15 of 54

Call Access Application

Figure 5 – Involved Native Calling Components and Flow

3.2 Integrating the IMS Component in NEXES

3.2.1 Call Origination

NEXES – GA No. 653337 | Deliverable D3.4 Page 16 of 54

3.2.2 Access Network

3.2.3 ESINet and the PSAP System

Interconnect Network Protocol Standard

NEXES – GA No. 653337 | Deliverable D3.4 Page 17 of 54