The NEXES Core

Led by ORO, The NEXES Core WP establishes the infrastructure elements of the next generation emergency services, including the architecture, design, functional and logical components and interfaces for network and service convergence (Task 3.1), the public communications networks (Task 3.2), the core structural functions, such as those provided by the Location and the IP Multimedia Subsystem (IMS) servers (Task 3.3 and 3.4), the interoperability with legacy systems through gateways (Task 3.5) and applicable security recommendations (Task 3.6).

The NEXES Core comprises:

  • Task 3.1 – System Requirements and High Level Architecture;
  • Task 3.2 – Adaptation of Public Communications Networks and Service;
  • Task 3.3 – Advanced Location Capabilities;
  • Task 3.4 – The NEXES IMS;
  • Task 3.5 – The NEXES Gateways;
  • Task 3.6 – NEXES Security Issues and Recommendations.

 

Task 3.1 – System Requirements and High Level Architecture

Led by RIN, throughout two iterations, this task defined and further specified the NEXES’s system requirements, architecture and design. The users requirements, needs and gaps were allocated and translated to system requirements (keeping their traceability). On the basis of the collected, functional and non-functional requirements for the NEXES system, the most suitable technologies and solutions were proposed. Subsequently, the architecture was established based on EENA’s Long Term Definition (LTD) document, IETF emergency standards, Internet standards and technologies (e.g., IP, SIP, SOA, web and XML), open-source tools and components from NEXES partners. The modelled architecture focused on key aspects: scalability, extensibility, performance, reliability, modularity, configurability, interoperability and robustness.

NEXES partners performed in-depth analysis of what is required and expected of Next Generation Emergency Services from their relevant areas of expertise. Of key importance is NEXES’s declared intent to convey multiple IP-enabled communication channels between citizens and emergency services, under the Total Conversation umbrella. Consequently, NEXES high-level architecture was designed to empower citizens to select the communication channel of their choice to reach emergency services across Europe, also envisaging interoperability mechanisms among emergency services.

The following figure abstracts emergency services’ components and interfaces, including legacy and next generation elements, which may differ from country to country.

NEXES High-Level Architecture
NEXES High-Level Architecture

Aside from the main components in the architecture of emergency services, NEXES partners also addressed 18 logical interfaces identified between those components.

Overall, two main areas were addressed to establish NEXES’s high-level framework:

  • A first domain dedicated to the next generation emergency calls using total conversation, where citizens and emergency services’ operators communicate in real- time with voice, video and text simultaneously. In this domain, attention was placed to the proposed NEXES 112 App, enabling TC and the exchange of additional data, applying the pan-European mobile emergency application (PEMEA) architecture. In parallel to the NEXES 112 App, native applications enable calls to emergency services benefitting from Long Term Evolution (LTE) and WiFi technologies instead of the circuit- switched mobile networks citizens rely on today. Emergency calls also present enhanced location data, with a higher accuracy being possible through the combination of user equipment location with network-provided location. Furthermore, the integration of the next generation emergency calls with legacy emergency systems through gateways was addressed.
  • The second domain emphasised the new and exciting innovations NEXES is considering as part of the next generation emergency services’ context: the First Responders App, the public alerting and early warning systems, the next generation eCall systems and the automated alerting services provided by smart health and environmental sensors and devices. These devices were explored on their capability to generate emergency calls based on sensor read triggers (e.g., environmental sensors may detect a building on fire, an eHealth device may detect a patient having a heart attack or a car may detect a crash). Each of these situations were addressed through contextual architectures and own set of requirements, with a special emphasis on the NEXES core functions that support the broad variety of communication channels.

Task 3.1 produced a high-level definition of NEXES components and interfaces since its inherent pan-European approach does implicate that, for different implementations and variations to be rendered useful, only a high-level architecture and requirements featuring common key components and interfaces would enable the promotion of interoperability and interchangeability.

With the completion of the task’s activities, the attainment of the task’s objectives and the submission of Deliverable D3.1 – NEXES System Requirements and Architecture Specification, Task 3.1 is closed.

 

Task 3.2 – Adaptation of Public Communications Networks and Service

Benefiting from the NEXES partners ORO and TS public communications networks, this task dealt with the implementation of adaptations and/or evolutions required by mobile and fixed/landline communications networks to enable next generation 112 emergency services, including the placing of emergency calls over IP networks, supporting total conversation capabilities and the use of 112 emergency applications as an OTT service. This work followed applicable NEXES network requirements from deliverable D3.1 and the NEXES Pan-European Specification for Emergency Apps (PESEA) from deliverable D4.1, as well as multiple applicable standards and specifications, namely those issued by 3GPP.

NEXES considered public communication access enabled via legacy (2G/3G), new (High Speed Downlink Packet Access Dual Carrier and 4G/LTE/LTE Dual Carrier) and Internet (e.g., WiFi/Mobile WiFi) technologies, where aspects related with standards, prioritisation and regulations (Internet access, in particular, poses serious regulatory concerns to be addressed considering the Universal Service Directive) were addressed.

NEXES partners identified the required equipment, technologies and functional block interworking to enable the new next generation functionalities, integrated the needed equipment into a functional network architecture, representing the call flow of end-to-end next generation emergency calls, and established the suitable end- to-end quality of service for handling IP-enabled emergency calls.

In what regards the mobile network infrastructure, newly adopted technologies as VoLTE and VoWiFi were considered, where the IMS functions as the core enabling component (to be further addressed in Task 3.4). The next figure illustrates the NEXES VoWiFi architecture, following VoLTE’s architectural blueprint and introducing a new node, the Evolved Packet Data Gateway (ePDG), in the Evolved Packet Core (EPC) and an Authentication, Authorisation and Accounting (AAA) server for user’s authentication and management.

NEXES VoWiFi Architecture
NEXES VoWiFi Architecture

Considerations were also presented concerning enhanced location capabilities, more specifically its implications in mobile communications infrastructures. Herein, directly benefiting from the IMS, location information can be transmitted through SIP either as User Provided Location Information or a Network Provided Location Information or both. Mobile networks service providers shall then implement dedicated architecture elements and functions to empower advanced location capabilities (these are further detailed in Task 3.3).

A particularly relevant and innovative network component in the NEXES architecture is the Routing Determination Function (RDF), whose role is to provide the proper outgoing routing address for emergency calls to be sent to the proper PSAP. In the NEXES’s context, determination of “the proper PSAP” considers caller location, but also additional criteria: the preferred form of communication (e.g., real time text), the possibility for multimedia support (voice and video) and data exchange support (e.g., send user profile and medical data) and language preference. On the call receiving end, the PSAP system exhibits an evolution from legacy TDM links to full IP connection, seamlessly supporting SIP and Real- time Transfer Protocol (RTP) traffic, as well as end-to-end TC and data exchange, as depicted in this figure.

High-Level Interconnect IP Emergency Network
High-Level Interconnect IP Emergency Network

Furthermore, the mobile network adaptations proposed in NEXES concluded with the prioritisation of emergency-related data traffic over normal (non-emergency) data traffic, including OTT support, a function that also includes the specifications to be adopted at the core network to provide free-of-charge access and data services.

Concerning the NEXES proposed adaptations in legacy fixed/landline network, these considered emergency calls to be originated using the native functions in the terminal equipment or user equipment. The emergency call flow within the fixed/landline networks is depicted in the next figure, where the green lines represent the legacy Integrated Services Digital Network User Part signalling and the red ones refer to the Next Generation Networks SIP signalling. Emergency call prioritisation is implemented via dedicated signalling/media trunks, reserved exclusively for emergency calls.

Fixed/Landline Network Emergency Call Flow
Fixed/Landline Network Emergency Call Flow

Through the use of the NEXES Gateways (further explained in Task 3.5), the public fixed/landline network operators are able to support next generation IP-based PSAPs. However, realistically, NEXES anticipated that legacy networks will not implement significant advanced capabilities due to their prevailing technological limitations. Instead, in the near future, it is expected that more and more legacy networks will migrate to IP-based fixed/landline networks and support the new capabilities required for NGES.

The NEXES participants in Task 3.2 also discussed at length a dedicated use case for the integration of PESEA-based emergency applications in the public mobile network infrastructure, a main reference for the NEXES Pilot to be conducted in Slovenia involving TS’s network infrastructure and the components provided by NEXES partners. The solution envisaged is based on the NEXES PESEA and enables the integration of the end-to-end NEXES 112 App system (or a similar next generation emergency App) in the emergency communication between citizens and a legacy PSAP system that supports Web Real Time Communications (WebRTC), using a mobile network operator (MNO) environment implementing 2G/3G/4G mobile technologies.

High-Level NEXES 112 App System Architecture
High-Level NEXES 112 App System Architecture

With the completion of the task’s activities, the attainment of the task’s objectives and the submission of Deliverable D3.2 – Adaptation of Public Communications Networks for NEXES, Task 3.2 is closed.

 

Task 3.3 – Advanced Location Capabilities

Led by DW, this task implemented NEXES’s advanced location information capabilities for emergency calls, compatible with applicable international standards, particularly those developed by the IETF, ETSI, the International Telecommunication Union (ITU) and the Open Mobile Alliance (OMA).

Implementing the Location Information Server (LIS), NEXES provides advanced location capability as new means of accessing emergency services (4G/LTE networks, Internet, cable, WiFi hotspots and private networks). Location data is improved with new sources of location information, such as WiFi Access Points and the positioning data provided by the user equipment. Related risks, issues and opportunities were also addressed (e.g., anonymity, better location to detect potential hoax or false calls).

A comprehensive analysis was performed on existing and emerging location capabilities for emergency calls, which included two models: the network-based and the device-based location.

Concerning the network-based location, both fixed/landline and mobile service models were considered, including:

  • Circuit-Switched Emergency Calling Architectures, namely Traditional Fixed/Landline and 3GPP Cellular Networks;
  • The IMS Emergency Calling Architecture, comprising Home Subscriber Server-based Location Retrieval, Location Provision Using Evolved Packet System and the Policy and Charging Control Framework, Location Provision from the Mobility Management Entity to the Gateway Mobile Location Centre and Location for Voice-over-WiFi (VoWiFi) Calls;
  • M/493 Emergency Calling Architecture (location delivery for all emergency calls including VoIP-out services);
  • IETF Emergency Calling Architecture, including IETF Device-Centric Calling Model and IETF Switch-Centric Calling Model;
  • The Pan-European specifications for emergency Apps (PESEA) detailed in Task 4.1.

Concerning the device-based location, aimed to exploit most smartphones, tablets and laptops’ capabilities to deliver highly accurate location information, while at the same time preserving the user’s privacy and assuring security, the NEXES partners considered:

  • Global Navigation Satellite System or GNSS-based location;
  • Access Database Systems (e.g., location determined via a mac address of a known resource);
  • WiFi location solutions.

A major aspect also addressed concerned the relevance of having a strong trust relationship between the involved entities in the location information data flow: the App, the App provider and downstream users of location information, namely PSAPs.

Combining the different location retrieval methods, Task 3.3 addressed how NEXES proposes to implement advanced location capabilities for next generation emergency services, detailing the components and logical interfaces affected by the message flow on location and routing information and benefiting from a dedicated LIS functional in all-IP environments. A wide range of new and evolving access technologies, including 4G/LTE networks, Digital Subscriber Line, Fibre and Cable Internet, WiFi hotspots and private enterprise networks, were directly considered. The location information is then conveyed, used and accessed in a number of different ways, depending on the calling and PSAP solutions in operation. The location interfaces and associated entities identified are depicted in the next figure:

NEXES Core Location Interfaces
NEXES Core Location Interfaces

NEXES tackled the most promising technologies regarding advanced caller location techniques, coupled into service provider calling architectures, to provide a solution that considers application-only architectures, OTT VoIP architectures, Total Conversation architectures, hybrid application voice-provider architectures and carrier IMS architectures. NEXES’s extensive set of mechanisms and protocols for the acquisition, conveyance to, and updating of location information for the PSAP far exceeds what is available to any emergency service in Europe today.

With the completion of the task’s activities, the attainment of the task’s objectives and the submission of Deliverable D3.3 – NEXES Advanced Location Capabilities, Task 3.3 is closed.

 

D3.4 – NEXES IMS Architecture

Led by ORO, this task is dedicated to the NEXES IP Multimedia Subsystem (IMS), the component responsible for IP-based emergency call services, supporting TC and data exchange. The NEXES IMS is based on ORO’s components and integrated with ORO’s network elements, developed to support NEXES next generation emergency services (e.g., VoLTE and VoWiFi emergency calls, PSAP routing, registration of users from specific OTT emergency Apps and user data payload). A special emphasis has been given to the Emergency – Call Session Control Function (E-CSCF) component that deals with handling and routing of emergency calls, where a multi-criteria selection is being considered, based on PSAP location, status (e.g., overloaded, maintenance, not operational) and capabilities (e.g., multimedia support, language).

ORO defined the proposed IMS architecture for NEXES and established associated challenges, anticipating the potential impact on the end-to-end NEXES System architecture. A thorough presentation of the IMS functions, entities, messaging and protocols has been compiled, highlighting the IMS-to-PSAP communication.

For the reporting period, Task 3.4 has been focused on the execution of feasibility studies, encompassing the flow of emergency calls from citizens to PSAP operators, the routing of calls, the numbering plan applicable to NEXES, the IMS security and quality of service aspects, the SIP interface specification, the charging specification and the recording details. The results of these studies will then be translated into the production of design and documentation to support the network elements’ development and integration work.

Thus far, the design of the NEXES IMS network integration has taken into consideration the following principles and assumptions:

  • The network is open for interconnections with other networks using standard-based interfaces;
  • The network is open for integration with other network elements or platforms using standard-based interfaces;
  • The network can be deployed in phases to support different service launch needs;
  • The network is scalable and capable of accommodating new capacity demands;
  • The network can meet the Regulatory Authority’s requirements.

Currently, the image below depicts the general network diagram and the envisaged integration of the NEXES IMS component.

NEXES IMS Network Diagram
NEXES IMS Network Diagram
NEXES IMS Interconnections
NEXES IMS Interconnections

The planned development and integration work will unfold in the next months in order to achieve the platform’s acceptance, namely in what concerns to the LRF/RDF, the IP interconnection to the PSAPs and the Border Gateway components. Thus far, the integration studies conducted on the NEXES IMS server and the network infrastructure continue to exhibit highly promising results.

 

Task 3.5 – The NEXES Gateways

This task was dedicated to the integration of NEXES with legacy systems. Two gateways were designed and deployed: one gateway to connect callers in legacy wireline/wireless networks to NEXES and one gateway to connect NEXES to existing emergency call taking and handling systems that do not include Internet-enabled technologies.

Indeed, NEXES envisages and proposes all IP architecture for both originator (fixed/landline and wireless) networks and PSAP systems. Still, the evolution to such type of infrastructure is likely to be performed in steps, without necessarily synchronising the development of the operators’ networks to that of the PSAP operators. In this respect, NEXES understands as its responsibility the assurance of interoperability with legacy originator (circuit-switched) networks or with legacy PSAP systems. To that end, NEXES partners defined the need to develop two functional components:

  1. The Legacy Network Gateway (LNG), responsible for providing interoperability between legacy originator networks and the Emergency Services IP Network (ESINet);
  2. The Legacy PSAP Gateway (LPG), responsible for providing interoperability between the ESINet and legacy PSAPs.

NEXES Gateways’ high-level architecture is depicted next.

NEXES Gateways High-Level Architecture
NEXES Gateways High-Level Architecture

Task 3.5 addressed the architecture, design and interfaces information on the NEXES Gateways, as well as a set of guidelines to instruct on the actual implementation of the LNG and the LPG. Both the NEXES LNG and LPG have been designed and developed, being now an integral part of the system deployed in NEXES Campaigns of Demonstration.

The purpose of the NEXES Gateways is not to enhance emergency call functionality (namely, adding text and/or video) to the legacy parts (originator network and PSAP) but rather to enable next generation emergency call delivery when the main architecture utilised is all-IP (IP-enabled PSAP, ESINet, IP-enabled user equipment). Basically, the NEXES Gateways provide the necessary interworking functions for both signalling and media communication, thus assuring interoperability within NEXES, considering the functionalities of the current emergency systems. It is expected that, even if these nodes are mandatory for a transition period, they will be of temporary use as the ultimate scope is to attain a full migration of emergency services towards an all IP environment, as envisaged by NEXES, in its quality of a reference implementation to next generation emergency services.

With the completion of the task’s activities, the attainment of the task’s objectives and the submission of Deliverable D3.5 – NEXES Gateways, Task 3.5 is closed.

 

Task 3.6 – NEXES Security Issues and Recommendations

Bridging with Computer Emergency Response Teams (CERT) authorities, standardisation and regulatory authorities, Task 3.6 addressed the security issues involving the adoption and use of Internet-enabled technologies by emergency services. The security of the IP-based infrastructure and enabled services is ascertained through extensive security protection measures, such as firewalls, denial of service attack protection mechanisms, authentication and access policies, logging and incident management and reporting. Also the issues of providing secure and protected storage and of handling and sharing of private personal data are considered.

Following a dedicated methodology, the NEXES partners discussed the new threats, vulnerabilities and risks posed by the adoption of new Internet-based technologies by emergency services and their associated transformation towards next generation emergency services.
Existing publicly available literature on security challenges was collected and reviewed as a starting point and debated, as the risk scenarios were drafted to tackle the many different security issues likely to affect the main elements that compose a next generation emergency system and its operational environment: call origination, public communications infrastructure, the emergency services’ network, the PSAPs domain, the EROs domain and the FRs domain.

As the security analysis of the system was being performed and assessed and numerous security controls and processes were being proposed, it became clear that not all the elements in next generation emergency services represent the same risk level: specific elements have been established for years and have been extensively analysed from the security point of view (e.g., the public telecommunications operations using landline and mobile cellular communications); other elements represent closed private networks (e.g., the PSAPs, the EROs and the FRs) under regulation and considered to be trusted with advanced security controls in place and even the newly dedicated area to next generation emergency services, the ESINet, is envisioned by NEXES as a private network, with closed components and limited controlled interfaces with the exterior.

On the contrary, the next generation emergency services’ architecture also presents specific elements that are unregulated or weakly regulated spaces (the call origination area and part of the Internet service providers’ communications). Herein, the practice of security controls may or may not be followed. Consequently, additional security controls may need to be implemented or enforced in the trusted or regulated spaces interfacing with the untrusted or unregulated ones to ensure the former’s components are not compromised security-wise. Overall, the trusted/regulated and untrusted/unregulated spaces represent the whole NG112 system, with broad panoply of assets, the valuable entities to safeguard against the new threats. These assets indeed display the system’s attributes requiring protection: confidentiality, integrity and availability.

Trusted and Untrusted Spaces Within NGES
Trusted and Untrusted Spaces Within NGES

Through the Deliverable D3.6 – NEXES Security Recommendations, the NEXES Consortium provided practical security recommendations to better manage the new risk exposure and establish best security practices in the technological, human and organisational dimensions. Risk scenarios were created to illustrate the potential new threats and vulnerabilities of next generation emergency services and detailed the security analysis for each specific system element and associated assets, presenting adequate security controls and processes. The resulting analysis provided an extensive set of 144 security recommendations that (next generation) emergency services should consider for their own protection, organised into 13 domains: Information Security, Asset Management, Human Resources, Physical Security, Communications and Operations Management, Access Control, Information Management, Information Systems, NG112 Apps Security, System Configuration, Incident Response, Business Continuity and Compliance.

The results of Task 3.6 not only support the security specifications for the development of the NEXES System and Apps for citizens and First Responders but also guide emergency services in dealing with the security hurdles of evolving towards next generation emergency services. Indeed, emergency services may benefit from the NEXES Security Recommendations to assess current security controls and establish a continuous improvement roadmap into the full implementation of security controls and processes that facilitate the adoption of Internet-enabled technologies to support provided services.

With the completion of the task’s activities, the attainment of the task’s objectives and the submission of Deliverable D3.6 – NEXES Security Recommendations, Task 3.6 is closed.

Print Friendly, PDF & Email