DELIVERABLE 2.2: ARCHITECTURE
SPECIFICATION eCall OVER IMS
Version number:
1.0
Authors:
Ana Robnik, Angelos Goulianos,
Boštjan Pintar, Grega Prešeren, Harold
Linke, , Jordi Contreras, Lambros
Lambrinos, Roman Kužnar, Primož
Žnidar
Activity lead:
ISKRATEL
Supporting partners
Advanced Automotive Antennas S.L.,
Cyprus University of Technology,
HITEC, SA CATAPULT,
SINTESIO, VEM Solutions
Due date:
31/01/2020
Delivery date:
25/01/2020
Delivery date updated document
This project is funded under the Connected Europe Fund Annual
Programme
Grant agreement no. 2018-EU-TM-0079-S
Deliverable 2.2: Architecture specification eCall over IMS
Page 1
CONTROL SHEET
Version history
Version
Date
Main author
Summary of changes
0.1
16.07.2019
Ana Robnik
The initial document
0.2.1
26.07.2019
Roman Kužnar, Boštjan
Pintar, Iztok Juvančič
Sintesio
Requirements
0.2.2
02.08.2019
Ana Robnik, Primož Žnidar
Iskratel
Requirements
0.2.3
07.08.2019
Bob Williams
Review
0.2.4
20.08.2019
Angelos Goulianos, SAC
Requirements
0.2.5
21.08.2019
Harold Linke, HiTEC
Review and add use cases
0.2.6
23.08.2019
Angelos Goulianos, SAC
Requirements
0.2.7
28.08.2019
Ana Robnik
Document Restructuring after
Meeting
0.2.8
30.08.2019
Harold Linke
Add use cases in Annex I
0.2.9
30.08.2019
Roman Kužnar
Detailed figures
0.2.9
30.08.2019
Ana Robnik
List of standards
0.2.9
19.09.2019
Angelos Goulianos
Use case and User Needs
0.2.9.
19.09.2019
Bob Williams
Internal Review
0.2.10
23.09.2019
Ana Robnik
Review and formatting after
Meeting
0.2.11
30.09.2019
Angelos Goulianos
Satellite IMS reference
architectures
15.10.2019
Lambros Lambrinos
Use case
Primož Žnidar
Use case
Roman Kužnar
Scenarios and Reqs
Boštjan Pintar
Scenarios and Reqs
Harold Linke
Reqs for the external
databases
0.3.0
18.10.2019
Ana Robnik
Review and Corrections of the
document to be ready for
Activity 3
0.4.0
14.11.2019
Angelos Goulianos
Architecture and Reference
points for IMS, satellite
communications and ESInet.
Page 2
Primož Žnidar
ANNEX III Recommendations
Roman Kužnar
Boštjan Pintar
Ana Robnik
0.5.0
28.11.2019
Primož Žnidar
Standards and ESInet
Boštjan Pintar
To resolve comments
Ana Robnik
0.6.0
0.7.0
9.12.2019
19.12.2019
Lambros Lambrinos
ANNEX III Recommendations
Marco Annoni
Conclusions
Lambros Lambrinos
ANNEX III Recommendations
Marco Annoni
Conclusions
Bob Williams
To resolve last open issues
0.8.0
20.12.2019
Ana Robnik
Version ready for review
1.0
15.01.2020
Ana Robnik
Final submission
1.1
25.01.2020
Angelos Goulianos,
Expected Outcomes UC02-2
Extensions UC02-2 & UC02-3
Ana Robnik
Name
Date
Prepared
Ana Robnik
20.12.2019
Reviewed
Andy Rooke
12.01.2020
Authorized
Andy Rooke
25/01/2020
Page 3
TABLE OF CONTENTS
Control sheet ................................................................................................. 2
Table of contents ........................................................................................... 4
Figures .......................................................................................................... 6
Tables............................................................................................................ 7
Purpose of the document ............................................................................... 8
Terms and Definitions .................................................................................... 9
1
Introduction ........................................................................................... 14
1.1
1.1.1
1.1.2
1.1.3
1.2
sAFE Contractual References ................................................................................... 14
Overview........................................................................................................................... 14
Communication details of the Agency ............................................................................. 14
Any communication details of the beneficiaries .............................................................. 14
An IMS based eCall ................................................................................................... 15
2
Methodology ......................................................................................... 16
3
Standards considered and used .............................................................. 17
4
USE CASES ............................................................................................. 20
4.1
4.2
4.3
Introduction .............................................................................................................. 20
The list of Use Cases from the external sources ....................................................... 20
Use Cases defined in sAFE project ............................................................................ 20
4.3.1 The list of Use cases .......................................................................................................... 20
4.3.2 The Use case UC02-1 – Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP ....... 21
4.3.3 The Use case No. 2, UC02 – Satellite networks enhancements and support as an
additional IP-CAN ........................................................................................................................... 26
4.3.4 The Use case UC02-3 – NG-eCall Supplemental Data from External sources provided by
Functional Elements in ESInet ........................................................................................................ 33
5
THE ARCHITECTURE REQUIREMENTS FOR NG 112 ECALL ........................ 39
5.1
5.2
5.2.1
5.3
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
Page 4
Introduction .............................................................................................................. 39
High-level Architecture requirements based on use cases and end-to-end scenarios
40
High-level Architecture requirements based on Standards ............................................. 40
Architecture principles apply to NG-eCall sessions .................................................. 44
Detailed Architecture Requirements for NG-eCall.................................................... 45
IMS network requirements for NG-eCall ......................................................................... 45
Location information for NG eCall ................................................................................... 47
Media................................................................................................................................ 48
IP-CAN............................................................................................................................... 48
NG-eCall enabled IVS requirements ................................................................................. 49
5.4.6
5.4.7
5.4.8
5.4.9
5.4.10
5.4.11
6
ARCHITECTURE MODEL AND REFERENCE POINTS ................................... 57
6.1
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.3
6.3.1
7
NG-eCall enabled PSAP Requirements ............................................................................. 50
The ESInet and its Core Elements Requirements ............................................................. 51
NG-eCall Satellite connectivity requirements .................................................................. 52
NG eCall enabled Data Requirements .............................................................................. 54
NG-eCall enabled Security/Privacy Requirements....................................................... 54
Freight and other additional Information from external databases ........................... 55
Deployment scenarios for NG eCall architectures ................................................... 57
IMS Core Network as Emergency Service Network for NG eCall service ................. 57
Reference Points .............................................................................................................. 57
Functional Description of IMS functional entities ............................................................ 58
NG e-call IMS over satellite through EPC ......................................................................... 62
NG e-call IMS over satellite through 5G Core Network ................................................... 63
NG-eCall over ESInet including IMS Core as originating network ............................ 65
The ESInet Functional Elements ....................................................................................... 67
Conclusions ............................................................................................ 70
REFERENCES ................................................................................................ 72
ANNEX I - The Use Cases FROM THE external SOURCES ................................ 73
ANNEX II - The Use Case Template ............................................................... 88
7.1
The needs derived from the Use Cases ..................................................................... 92
ANNEX III – Recommendations FOR NG-eCALL Architecture ......................... 94
Page 5
FIGURES
FIGURE 1: COMPRESSION OF CIRCUIT SWITCHED 112-ECALL AND 112 IMS-ECALL. .................................. 15
FIGURE 2: END-TO-END SCENARIOS FOR CO-EXISTED CS IN NG-ECALL. .................................................... 39
FIGURE 3: ESSENTIAL FUNCTIONAL ELEMENTS REQUIRED TO IMPLEMENT ECALL SCENARIOS. ......................... 40
FIGURE 4: OVERVIEW OF NETWORK ENTITIES FOR CS-ECALL AND NG ECALL. ............................................ 42
FIGURE 5: NG-ECALL WITH ESINET AS A POINT-OF-INTERCONNECT TO CS AND/OR IMS NETWORK. .............. 44
FIGURE 6: IVS SUPPORTING ECALL USING IMS REQUIRED COMMUNICATION CAPABILITIES............................ 50
FIGURE 7: IMS CORE AS EMERGENCY SERVICE NETWORK FOR NG ECALL................................................. 57
FIGURE 8. ARCHITECTURE FOR NG E-CALL IMS OVER SATELLITE THROUGH EPC NETWORK .......................... 62
FIGURE 9. ARCHITECTURE FOR NG E-CALL IMS OVER SATELLITE THROUGH 5G CORE NETWORK. .................. 63
FIGURE 10. ARCHITECTURE
NG E-CALL IMS OVER SATELLITE WHERE IMS IS INTEGRATED WITHIN THE
SATELLITE NETWORK OPERATOR NETWORK. ......................................................................................... 64
FOR
FIGURE 11 : HIGH-LEVEL EMERGENCY SERVICES NETWORK ARCHITECTURE WITH FUNCTIONAL ENTITIES FOR NGECALLTHE ESINET REFERENCE POINTS AND PROTOCOLS ......................................................................... 66
Page 6
TABLES
TABLE 1: THE LIST OF USE CASES FROM THE EXTERNAL SOURCES .............................................................. 20
TABLE 2: THE LIST OF USE CASES DEFINED IN SAFE PROJECT ................................................................... 20
TABLE 3: DOMAIN SELECTION RULES FOR ECALL OVER IMS SESSION ATTEMPTS FOR E-UTRAN CONNECTED TO
EPC AND E-UTRAN OR E-UTRA CONNECTED TO 5GC RADIO ACCESS NETWORKS ..................................... 43
TABLE 6-1 REFERENCE POINTS FOR UNTRUSTED NON-3GPP IVS CONNECTIVITY (EPC). .............................. 63
TABLE 6-2. REFERENCE POINTS FOR UNTRUSTED NON-3GPP IVS CONNECTIVITY (5G CORE). ...................... 64
Page 7
PURPOSE OF THE DOCUMENT
This document summarises the results of the work undertaken under the Sub-activity 2.2 eCall support
over IMS. The requirements for this sub-activity, as stated in the grant agreement, are given below:
“eCall has to operate within an evolving communication network, as legacy networks (2G) get phased
out. What has remained unchanged is the support for IP traffic starting from 3G networks. 3GPP ‘IMS
based eCall’ together with CEN TS 17184 and CEN TS 17240 provides a sound basis to build Next
Generation NG112 eCall services for different requirements, whilst remaining relevant and compatible
with current and future networks.
Within I_HeERO the NG112 eCall requirements have been defined based on NG112 Use cases and stateof-the-art analysis. Migration path from 112 eCall to NG112 eCall has been proposed including the coexistence of 112 eCall and NG 112 eCall in parallel. The Architecture concepts over satellite and all-IP
networks have been introduced. Various NG112 eCall demonstrators have been realized using
opensource tools with the SIP based eCall. The NG eCall node demonstrator has proved the approach
for co-existence of SD eCall and NG 112 eCall in the emulated SIP environment. One of the I_HeERO
achievement is also the identified gaps, which are the base for sAFE Architecture study. The advanced
Architecture concepts of NG eCall Node in the area of ESInet will be studied, in coherence with emerging
and on-going NG eCall standardization, to support migration scenario from eCall to NG 112 eCall and
their parallel existence in the ETSI MANO compliant framework.
It is critical to progress development in this area with a view to providing sound evolution paths for the
eCall in different vehicle types. In addition, with the convergence of satellite and terrestrial networks
within full IP 5G networks, the reach and resilience of NG112 eCall will be greatly enhanced. sAFE will
directly address this in this activity by studying the impact and requirements for this development and
proposing a way forward. This activity deals with the additional requirements and challenges using IMS
for eCall transmission.
In the I_HeERO project this work was started, but not concluded, in addition the landscape concerning
the sunset of the 2G and 3G networks has become clearer, with an imperative to translate some parts
of architecture specification to standards to ensure the continuity of the 112 eCall service.”
Deliverable D2.2: Architecture specification eCall over IMS.
In the scope of Activity 2, and specifically Sub-activity 2.2, the present deliverable 2.2 specifies the highlevel reference architecture of eCall over IMS (e.g. NG-eCall). Inputs for this deliverable have been
gathered from the I_HeERO project, standards and relevant documents (3GPP, CEN, ETSI, EENA, IETF,
etc.) and from the sAFE/Activity 3 Use Cases.
Deliverable D2.2 is structured in the following chapters:
•
Chapter 1 provides the List of Use Cases with the reference to the Annex II of the already defined
Use Cases from the external sources that are supplemented with the additional generic or
specific Use Cases as a result of work within Sub-activity 2.2;
•
Chapter 2 is focused on the detailed generic and specific Architecture Requirements, developed
on the basis of the inputs from various standards and defined Use cases;
•
Chapter 3 specifies the high-level reference architecture together with architecture model and
reference points.
The outputs of this deliverable will be used in the Activity 3, especially in the Sub-activity 3.8.
Page 8
TERMS AND DEFINITIONS
For clarification, the definitions for all kind of eCall using legacy and novel technologies are explained
as follows:
AFTERMARKET eCall: The installation and/or use of a European 112-eCall system into a vehicle after
the first use of the vehicle, that is not a retrofit eCall system but that independently provides the
European 112 eCall service.
AFTERMARKET TPS-eCall: The installation and/or use of a third party eCall system into a vehicle after
the first use of the vehicle, that is not a retrofit eCall system but that independently provides a TPSeCall service.
eCall: A manually or automatically initiated emergency voice call supplemented with a minimum set of
emergency related initial data (MSD) providing location and other vehicle data, from a vehicle via an
audio link across a PLMN to the relevant Public Safety Answering Points (PSAP). eCall is Pan European
in-vehicle Emergency Call defined under the eSafety initiative of the European Commission. The service
is free for all the citizens of Europe.
NG-eCall (eCall over IMS): A manually or automatically initiated IMS emergency call, supplemented
with a minimum set of emergency related initial data (MSD) as a part of the call request, from a vehicle
to the relevant Public Safety Answering Points (PSAP).
RETROFIT eCall: The installation by a vehicle manufacturer or its authorised agent, prior to first sale of
a vehicle, or after the first sale of a vehicle, of an eCall in-vehicle system, approved for use in another
model of vehicle, or otherwise satisfactorily certified to meet regulatory performance and
conformance, that meets the requirements of EN 15722, EN 16062, EN 16072, and/or where
appropriate EN 16102, in a vehicle that is not required by Regulation to be equipped with European
112-eCall (example: new vehicles of models whose type approval test was before April 2018; eCall in a
vehicle that is not UNECE category M1/N1).
CS-eCall: Circuit Switched eCall may ingress from legacy CS access and core networks (2G/3G PLMN)
and/or egress to Circuit Switched PSAP network.
PS-eCall: Packet Switched eCall may ingress from all-IP access and originating networks (3G/4G/5G
PLMN or satellite networks) and/or egress to Packet Switched PSAP network.
TERM
3GPP
2G/ 3G / 4G / 5G
5G NR
5GC
ACK
AIeC
ANP
API
AS
BCF
BS
BGCF
BSC
Page 9
DEFINITION
Third generation mobile telecommunication system
Second/ Third/ Fourth/ Fifth Generation
5G New Radio
5G Core
ACKnowledgement
Automatic Initiated eCall
Access Network Provider
Application Program Interface
Application Server
Border Control Function
Bearer Services
Breakout Gateway Control Function
Base Station Controller
CA
CAN
CAP
CBN
cdma2000®
CLF
CRC
CS
CSCF
DVB- RCS2
E2E
E-CMR
E-CSCF
EATF
EC
ECRF
ECS
EENA
EPC
ePDG
eSafety
ESInet
ESRK
ESRN
ESRP
ESQK
ESRN
ETSI
EUCARIS
E-UTRA
E-UTRAN
DOCSIS®
E-CSCF
GERAN
GNSS
GSM
GTT
HGV
HLAP
HLR
HPLMN
Page 10
Certification Authority
Controller-Area Network
Common Alerting Protocol
Core Border Node
code-division multiple access version of IMT-2000 standard
Connectivity session Location and repository Function
Cyclic Redundancy Check
Circuit Switched
Call Session Control Function
Digital Video Broadcasting – Return Channel via Satellite or (Return
channel over system)
End to End
Contract for the International Carriage of Goods by Road
Electronic Consignment Note
Emergency Call session control function
Emergency Access Transfer Function
European Commission
Emergency Call Routing Function
Emergency Call Server
European Emergency Number Association
Evolved Packet Core
evolved Packet Data Gateway
A vehicle-based intelligent safety systems
Emergency Services IP network
Emergency Service Routing Key
Emergency Service Routing Number
Emergency Service Routing Proxy
Emergency service query key
Emergency Service Routing Number
European Telecommunications Standards Institute
European CAR and driving licence Information System
Evolved Universal Terrestrial Radio Access
Evolved Universal Terrestrial Radio Access Network
Data Over Cable Service Interface Specification
Emergency – Call Session Control Function
GSM Edge Radio Access Network supporting the EDGE (Enhanced Data
rates for Global Evolution)
Global Navigation Satellite System
Global System for Mobile Communications
Global Text Telephony
Heavy Goods Vehicle
High Level Application Protocols
Home Location Registry
Home Public Land Mobile Network
HRPD
HSS
IAM
IBCF
ICS
ID
IETF
IMCN
IMEI
IMS
IMS-MGW
IMSI
IP
IP-CAN
ISCF
IVS
IVST
LAN
LbyR
LbyV
LGV
LIS
LN
LRF
LRO
LS
LTE
MANO
MGCF
MGW
MIeC
MNO
MPC
MRB
MRFC
MRFP
MSC
MSD
MSISDN
N3IWF
NAD
NAS
NASS
Page 11
High Rate Packet Data
Home Subscriber Server
Initial Address message
Interconnection Border Control Functions
IP Multimedia Subsystem Service Control
Identity
Internet Engineering Task Force
IMS Core Network
International Mobile Equipment Identity
Internet Protocol Multimedia Core Network Subsystem
IMS Media Gateway
International Mobile Subscriber Identity
Internet Protocol
Internet Protocol- Connectivity Access Network
IPTV Service Control Function
In-Vehicle System
In-Vehicle System Satellite Terminal
Local Area Network
Location by Reference
Location by Value
Large Goods Vehicle
Location Information Service
Location Node
Location Retrieval Function
Last Routing Option
Location Server
Long Term Evolution
Management and Orchestration
Media Gateway Controller Function
Media Gateway
Manually Initiated eCall
Mobile Network Operator
Mobile Positioning Centre
Media Resource Broker
Multimedia Resource Function Controller
Multimedia Resource Function Processor
Mobile Switching Centre
Minimum Set of Data (EN 15722)
Mobile Subscriber ISDN (Integrated Services Digital Network)
Non-3GPP Inter-Working Function
Network Access Device (e.g. a GSM or UMTS module)
Non-Access Stratum
Network Attachment Sub-System
NCC
NENA
NG
P-CSCF
P-TMSI
PGW
P2W/P2WV
PAN
PCC
PCF
PCRF
PDS
PLMN
PPT
PS
PSAP
PSTN
RACS
RDF
REQ
RNC
RTP
TEL-URI
S-CSCF
SBC
SDF
SDS
SET
SIP
SLP
SLF
SMS
SUPL
SUT
TCP/UDP
TMSI
TPS
TPSP
TS (i)
TS (ii)
TS12
TTC
Tx
Page 12
Network Control Centre
National Emergency Numbering Association
Next Generation
Proxy-Call Session Control Function
Packet- Temporary Mobile Subscriber Identity
Packet Data Network Gateway
Powered 2 Wheeled Vehicle
Personal Area Network
Policy and Charging Control
Policy Control Function
Policy and Charging Rules Function
Packet Data Subsystem
Public Land Mobile Network
Point to Point Transport
Packet Switched
Public Safety Answering Point
Public Switched Telephone Network
Resource and Admission Control
Routing Determination Function
REQuest
Radio Network Controller
Real-time Transport Protocol
Telephone Uniform Resource Identifier
Serving Call State Control Function
Session Border Controller
Session Description Protocol
Supplemental Data and Database Access Service
SUPL Enabled Terminal
Session Initiation Protocol
SUPL Location Platform
Subscriber Location Function
Short Message Service
Secure User Plane for Location
System Under Test
Transmission Control Protocol / User Datagram Protocol
Temporary Mobile Subscriber Identity
Third Party Service
Third Party Service Provider
Technical Specification
Teleservice
Teleservice 12 ETSI TS 122 003
Time to Complete
Transmit
UE
UMTS
URI
URL
URN
USIM
UTRAN
VLR
VoIP
VoLTE
VPC
WiMAX™
WGS
WGS 84
Wi-Fi
WLAN
Page 13
User Equipment (ETSI/3GPP term which general refers to the IVS in the
context of eCall)
Universal Mobile Telecommunication System
Uniform Resource Identifier
Uniform Resource Locator
Uniform Resource Name
Universal Subscriber Identity Module
Universal Terrestrial Radio Access Network
Visited Location Register
Voice over Internet Protocol
Voice over Long Term Evolution
VOIP Positioning Centre
Worldwide Interoperability for Microwave Access
World Geodetic System
World Geodetic System; issue 1984 (last revised 2004]
“Wireless Fidelity”; wireless networking technology that allows
computers and other devices to communicate over a wireless signal
Wireless LAN
1 Introduction
1.1 sAFE Contractual References
1.1.1 Overview
sAFE stands for Aftermarket eCall For Europe.
sAFE is an action under the Grant Agreement number INEA/CEF/TRAN/M2018/1798161 with a project
duration of 24 months, effective from 01 January 2019 until 31 December 2020. It is a contract with
the Innovation and Networks Executive Agency (INEA), under the powers delegated by the European
Commission.
1.1.2 Communication details of the Agency
Any communication addressed to the Agency by post or e-mail shall be sent to the following address:
Innovation and Networks Executive Agency (INEA)
Department C – Connecting Europe Facility (CEF)
Unit C3 Transport
B - 1049 Brussels
Fax: +32 (0)2 297 37 27
E-mail addresses:
for general communication: inea@ec.europa.eu
For submission of requests for payment, reports (except ASRs) and financial
statements: INEA-C3@ec.europa.eu
Any communication addressed to the Agency by registered mail, courier service or hand-delivery shall
be sent to the following address:
Innovation and Networks Executive Agency (INEA)
Avenue du Bourget, 1
B-1140 Brussels (Evere)
Belgium
TEN-Tec shall be accessed via the following URL:
https://webgate.ec.europa.eu/tentec/
1.1.3 Any communication details of the beneficiaries
Any communication from the Agency to the beneficiaries shall be sent to the following addresses:
For OECON Products & Services GmbH:
Frank Brennecke
Hermann-Blenk-Straße 22a, 38108 Braunschweig,
Germany
E-mail address: brennecke@oecon-line.de
Page 14
1.2 An IMS based eCall
IMS is an all-IP system designed to assist mobile operators deliver next generation interactive and
interoperable services, cost-effectively, over an architecture providing the flexibility of the Internet. IMS
supports IP multimedia applications via IP multimedia sessions over a multitude of IP Connectivity
Access Networks, such as E-UTRA, E-UTRAN, UTRAN, GERAN, LAN, DOCSIS®, WiMAX™, cdma2000® and
DVB- RCS2 access. CEN TS 17312 shows how IMS can also be used to send eCall using satellite
communications. It is likely that all subsequent IP based packet switched will therefore be able to
support IMS, making migration to future, as yet undeveloped technologies, a simpler and easier to
achieve process.
IMS has a further advantage in that it can also be used over fixed lines. This makes the forwarding of
eCall / NG-eCall from 1st level PSAP responder to 2nd level PSAP responders and responding emergency
services via fixed lines, an easier and more simple process; and even enabling the call to then be
subsequently diverted to a handset of a responding ambulance, fire truck or police responder.
Figure 1: Compression of Circuit switched 112-eCALL and 112 IMS-eCall.
However, NG-eCall will only operate where there is an appropriate PLMN available with public IP-CAN
wireless access. ETSI TS 123 167 provides a facility whereby, if such a network is not available or viable
at the time of the call, the NG-eCall can revert to a GSM/UMTS circuit switched eCall, as specified in EN
16062, and this also reverts to a standard 112 emergency voice call when the PSAP is unable to support
a NG eCall.
Page 15
2 Methodology
In order to specify the E2E reference architecture of NG-eCall supporting different categories of vehicle
and various additional services sAFE/Sub-activity 2.2 aims to examine the current status from the
documentation and from the Use cases developed by the I_HeERO project, competent authorities,
standardization organisations and stakeholders. If this analysis shows a need to revise the existing Use
cases or add new Use cases referring to the architecture, sAFE/Sub-activity 2.2 will complete this work.
The use case description follows the structure introduced by the ISO TR 25102 “Intelligent transport
systems — System architecture — 'Use Case' pro-forma template” (see Annex II). The result of this
analysis and study is to determine the general Architecture Requirements.
After defining the general Architecture Requirements sAFE/Sub-activity 2.2 collects specific Use cases
and possible additional Architecture Requirements for different categories of vehicles and various
additional services as a result of work from Sub-activities 3.1-3.7 of the project sAFE.
The compiled specific Use Cases and specific Architecture Requirements together with generic ones are
the inputs for specification of a high-level reference architecture with architecture model and reference
points.
Page 16
3 Standards considered and used
The following relevant standards or recommendations (final or draft version) have been studied in order
to collect the NG-eCall Architecture requirements:
3GPP
The Referenced Documents are included in the corresponding ETSI references as the ETSI liaison
standards.
CEN
[1] CEN TS 17184:2018: “Intelligent transport systems - eSafety - eCall High level application
Protocols (HLAP) using IMS packet switched networks”
[2] CEN TS 17240: “Intelligent transport systems - ESafety - ECall end to end conformance testing
for IMS packet switched based system”
[3] CEN EN 16062:2015: ”Intelligent transport systems - ESafety - eCall high level application
requirements (HLAP) using GSM/UMTS circuit switched networks”
[4] CEN EN 16072:2015: “Intelligent transport systems - ESafety - Pan-European eCall operating
requirements”
[5] CEN EN 15722:2015: “Intelligent transport systems - ESafety - ECall minimum set of data”
[6] CEN TS 17249-2:2018: “Intelligent transport systems - eSafety - Part 2 : eCall for HGVs and
other commercial vehicles”
[7] CEN TS 17249-3:2018: “Intelligent transport systems - eSafety - Part 3: eCall for Coaches and
buses”
[8] CEN TS 17249-4:2019: “Intelligent transport systems - eSafety - Part 4: eCall for UNECE
Category T, R, S agricultural/forestry vehicles”
[9] CEN TS 17249-5:2019: “Intelligent transport systems - eSafety - Part 5: eCall for UNECE
Category L1 and L3 powered two-wheeled vehicles”
ETSI
[10]ETSI TS 123 167: “Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS) emergency sessions (3GPP TS 23.167)”
[11]ETSI TR 103 140: “Mobile Standards Group (MSG); eCall for VoIP
[12]ETSI TS 103 479: “Emergency Communications (EMTEL); Pan-European Mobile Emergency
Application”
[13]ETSI TS 102 855: “Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Interworking and Integration of BSM in Next Generation Networks (NGNs) (3GPP TS
22.855)”
[14]ETSI TS 122 101: “Universal Mobile Telecommunications System (UMTS); LTE; Service aspects;
Service principles (3GPP TS 22.101)”
[15]ETSI TS 122 228: “Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Service requirements for the Internet
Protocol (IP) multimedia core network subsystem (IMS); Stage 1 (3GPP TS 22.228)”
Page 17
[16]ETSI TS 123 060: “Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service description;
Stage 2 (3GPP TS 23.060)”
[17]ETSI TS 123 203: “Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Policy and charging control architecture
(3GPP TS 23.203)”
[18]ETSI TS 123 216: ”Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Single Radio Voice Call Continuity (SRVCC);
Stage 2 (3GPP TS 23.216)”
[19]ETSI TS 123 228: ”Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); Stage 2
(3GPP TS 23.228)”
[20]ETSI TS 123 237: ”Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS) Service
Continuity; Stage 2 (3GPP TS 23.237)”
[21]ETSI TS 123 292: ”Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS) centralized services;
Stage 2 (3GPP TS 23.292)”
[22]ETSI TS 123 401: ”LTE; General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access (3GPP TS 23.401)”
[23]ETSI TS 123 402: ”Universal Mobile Telecommunications System (UMTS); LTE; Architecture
enhancements for non-3GPP accesses (3GPP TS 23.402)”
[24]ETSI TS 103 479(DTS/EMTEL-00037): ”Emergency Communications (EMTEL); Core elements for
network independent access to emergency services”
[25]ETSI TS 123 501: ”5G; System architecture for the 5G System (5GS) (3GPP TS 23.501)”
[26]ETSI TS 123 502: ”5G; Procedures for the 5G System (5GS) (3GPP TS 23.502)”
[27]ETSI TS 124 501: ”5G; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 (3GPP
TS 24.501)”
[28]ETSI TS 126 114: ”Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS); Multimedia telephony; Media handling and interaction (3GPP TS 26.114)”
[29]ETSI TS 129 165: ”Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Inter-IMS Network to Network Interface
(NNI) (3GPP TS 29.165)”
[30]ETSI TS 129 238: ”Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Interconnection Border Control Functions
(IBCF) - Transition Gateway (TrGW) interface, Ix interface; Stage 3 (3GPP TS 29.238)”
[31]ETSI TS 129 332: ”Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Media Gateway Control Function (MGCF) - IM
Media Gateway; Mn interface (3GPP TS 29.332)”
[32]ETSI TS 136 300: ”LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP TS
36.300)”
Page 18
[33]ETSI EN 303 978: ”Satellite Earth Stations and Systems (SES); Harmonised Standard for Earth
Stations on Mobile Platforms (ESOMP) transmitting towards satellites in geostationary orbit,
operating in the 27,5 GHz to 30,0 GHz frequency bands covering the essential requirements of
article 3.2 of the Directive 2014/53/EU”
[34]ETSI EN 301 545-2: ”Digital Video Broadcasting (DVB); Second Generation DVB Interactive
Satellite System (DVB-RCS2); Part 2: Lower Layers for Satellite standard”
[35]ETSI TS 182 024: ”Telecommunications and Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Hosted Enterprise Services; Architecture, functional
description and signalling”
IETF
[36] RFC 8147: “Next-Generation Pan-European eCall”
[37]RFC 3261: “SIP: Session Initiation Protocol”
[38]RFC 8446: “The Transport Layer Security (TLS) Protocol Version 1.3”
[39]RFC 5985: “HTTP-Enabled Location Delivery (HELD)”
[40]RFC 4566: “SDP: Session Description Protocol”
[41]RFC 3550: “RTP: A Transport Protocol for Real-Time Applications”
[42]RFC 3711: “The Secure Real-time Transport Protocol (SRTP)”
[43]RFC 4568: “Session Description Protocol (SDP); Security Descriptions for Media Streams”
[44]RFC 768: “User Datagram Protocol”
[45]RFC 4961: “Symmetric RTP / RTP Control Protocol (RTCP)”
[46]RFC 3015: “Megaco Protocol Version 1.0”
[47]RFC 7296: “Internet Key Exchange Protocol Version 2 (IKEv2)”
EENA
[48]NG 112 LTD 1.1. Available at https://eena.org/wp-content/uploads/2018/11/NextGeneration-112-Long-Term-Definition-Standard-For-Emergency-Services.pdf. Approved date:
2013, March.
Page 19
4 USE CASES
4.1 Introduction
This section presents the use cases and the stakeholders’ needs derived from these use cases. They
describe real situation about how the users of the eCall/NG-eCall system will use the system and what
are their actions and needs.
The Use cases from the external sources as the results of other projects (e.g. I_HeERO) are listed in the
Sub-section 1.2 and available in the Annex I of this document. The Use cases prepared in the project
sAFE within Sub-Activity 2.2 and Activity 3 and their Sub-activities 3.1-3.7 are listed and specified in the
Sub-section 1.3.
The requirements listed in the Section 3 are derived from the Use cases and their Needs, the Needs are
specified for each Use case from the Sub-sections 1.2 and 1.3. Only the Use cases and the Needs relevant
to the reference architecture of NG-eCall are considered in this document.
The use case description follows the structure introduced by the ISO TR 25102 “Intelligent transport
systems — System architecture — 'Use Case' pro-forma template” according to Use case Template (see
Annex II in this document).
4.2 The list of Use Cases from the external sources
The Use cases from the external sources with the impact on the reference architecture are listed in the
table below:
Use case No.
Use case Name
Source
UC01-1
General NG112 eCall for vehicles
Project I_HeERO
UC01-2
NG112 eCall for vehicles with vehicle access
Project I_HeERO
UC01-3
eCall for Large Goods Vehicle
Project I_HeERO
Table 1: The list of Use cases from the external sources
4.3 Use Cases defined in sAFE project
4.3.1 The list of Use cases
The Use cases prepared within Activity 2 and Activity 3 and their Sub-activities referring to different
categories of vehicles and various additional services with the impact on the reference architecture are
listed in the table below:
Use case No.
Use case Name
Source
UC02-1
Forwarding NG-eCall from 1st level PSAP responder Prepared by CUT
to 2nd level PSAP responders
UC02-2
Satellite networks enhancements and support of Prepared by SA Catapult
satellite as an additional IP-CAN, deployed
autonomously or integrated with 4G and 5G Core
Networks
UC02-3
NG-eCall Supplemental Data from External Prepared by Iskratel
sources provided by Functional Elements in ESInet
Table 2: The list of Use cases defined in sAFE project
Page 20
4.3.2 The Use case UC02-1 – Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
M
Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
Use case reference Use case 02-1 / UC02-1
/id
Description This use case is concerned with the forwarding of eCall from the
1st level PSAP to a 2nd level PSAP.
The 1st level PSAP has received the NG-eCall and may
transfer/reroute/bridge it to a PS-eCall or CS-eCall capable PSAP as
determined by the national authority.
M
Page 21
Scope
A significant number of countries operate two-level PSAPs. The
first level PSAP receives the NG-eCall and operators decide to
forward them along with the respective location data to the most
appropriate second level PSAP using various methods. The
connection between two PSAPs could be all-IP (PS) or legacy (CS).
In the first case, a reference to caller data can be provided to the
second level PSAP whereas in the second case such information
may have to be conveyed manually or outside the call handling
system (e.g. through another communication platform). It is
important to note that as many countries are in a transitional
phase (i.e. upgrading their PSAP systems to all-IP) it is anticipated
that a significant number of call transfers will take place over the
CS network.
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
Scenario An NG-eCall is received by a 1st level PSAP operator who decides
to forward (transfer/reroute/bridge) it to a 2nd level PSAP. The 1st
and the 2nd level PSAPs can be connected over:
•
the traditional public switched telephone network in which
case a normal voice call will be established with the
no/limited/full MSD data, which are available at the 2nd level.
In these situations, where the two PSAPs are connected via the
CS network, caller information should be transferred through
other means. This makes the call handling process
complicated. Moreover, in case that the call is not transferred
to a PSAP but to an emergency response unit, information is
expected to be provided in different ways (e.g. through an
application relying on the mobile network for data
connectivity).
•
the All-IP network in a faster and more efficient way using a
voice call transfer/reroute/bridge together with complete
NG-eCall data readily available at the 1st level PSAP.
It is important to note that the first level PSAP should be able to
access data from an external database (e.g. EUCARIS) and as such
the data related to a call can be quite ‘rich’. Operating on the
assumption that second level PSAPs have IP network access, caller
data (i.e. MSD and any supplemental data retrieved from an
external database) could be transferred to the second level PSAP.
If the second level PSAP is not capable of receiving large amounts
of data beside the call a descriptive summary of the NG-eCall data
must be transferred.
M
Actors Involved
M
Stakeholders
M
Area of incident
M
Assumptions
Page 22
• Vehicle driver (or passenger)
• First level PSAP operator
• Second level PSAP operator
• 1st level PSAP operator
• 2nd level PSAP operator
• Emergency response unit personnel
• PSAP equipment manufacturer/supplier
Anywhere in Europe, where CS/NG-eCall is supported.
It is assumed that a multi-level PSAP structure is established in
the area/country where the NG-eCall is received.
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
Available Standards CEN TS 17184
CEN TS 17240
ETSI TR 103140
CEN EN 15722
CEN EN 16062
CEN EN 16072
NG-eCall to eCall transfer/reroute/briding
M
Standardisation
gaps identified*
O
"Use Case" level
O
Requirements
Reference
O
Data Minimum Set of Data (MSD)
Requirements
Additional data as a part of MSD (dereferenced if possible).
Data from other sources which is obtained via links provided with
the MSD.
O
O
Page 23
Relationships to This use case relates to UC02-3 as the 1st level PSAP may require
other "Use Case(s)" data from ESInet functional entity Supplemental Data Services.
Such data will be retrieved by the first level PSAP and it will either
be transferred fully to the second level PSAP along with other
important data or in the form of a link to enable subsequent
retrieval operations if available.
Triggers
NG-eCall is received by a 1st level PSAP in an EU country. The call
taker decides (based on the MSD data and potentially the
conversation with the caller) to transfer this call to the most
appropriate 2nd level PSAP.
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
Scenario 1. An accident is detected in a vehicle and the In-vehicle System
#Scenario1.
initiates an NG-eCall.
2. The IMS infrastructure routes the NG-eCall to the first level
PSAP responsible for its initial handling.
3. The 1st level PSAP operator takes this call. Based on the data in
the MSD and potentially any additional information obtained
from the vehicle driver/passengers the operator decides to
transfer the call to the appropriate second level PSAP.
4. The both PSAP systems have full NG-eCall capabilities via IPbased communication.
5. The NG-eCall and all incidents related data is seamlessly
transferred to the second level PSAP.
6. The second level PSAP takes NG-eCall with all available data.
O
Scenario 1. The steps 1-3 from the Scenario #1.
#Scenario2.
2. The 2nd level PSAP is not capable of taking NG-eCall, because
these two PSAP systems are connected via the CS network.
3. This implies that an eCall needs to be established to facilitate
the on-going emergency call transfer.
O
Scenario 1. The steps 1 and 2 from the Scenario #2.
#Scenario3.
2. An emergency voice call is established between the first and
second layer PSAPs using the legacy circuit switched
connection. MSD data is not transferred within this voice call.
3. Beside the legacy connection an online IP-based
communication exists to enable the transfer of the MSD either
with all supplemental data or with links to the original
additional data; the latter case implies that a data storage
mechanism is in place and that the first level PSAP will store
data for subsequent retrieval by the second level PSAPs.
O
Scenario 1. The steps 1 and 2 from the Scenario #2.
#Scenario4
2. An emergency voice call is established between the first and
second layer PSAPs using the legacy circuit switched
(Optional).
connection. MSD data is not transferred within this voice call.
3. Beside the legacy connection an online IP-based
communication exists to enable the transfer of the MSD with
links to the original additional data. The second level PSAP will
access this data from the original source.
Page 24
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
Scenario # 1. The steps 1 and 2 from Scenario #2.
Scenario5 2. As in Scenario #4, an emergency voice call is established
between the first and second layer PSAPs using the legacy
(Optional).
circuit switched connection. MSD data or any other data
available is not transferred within this voice call.
3. Besides the legacy voice connection, an IP-based
communication mechanism exists to enable the transfer of
links. These links will provide access to data from the original
source that includes the MSD and any other data (AOD) that
may have been made available from the IVS.
4. After the initial retrieval of the data, the 2nd level PSAP
managing the call may (at regular intervals) retrieve data
updates via the links mentioned above.
O
O
Expected
Under ideal circumstances all data received in the original NGOutcomes
eCall (irrespective of the communication medium used) should be
transferred to the 2nd level PSAP.
Extensions Data could be forwarded to any other PSAP in the hierarchy or to
any Emergency response team.
O
Inclusions
O
Business Rules
Template Version
O
151021 PT1701 consensus
Open Issues
User needs from the use case UC02-1
Only user needs that are NG-eCall specific and related to the architecture requirements are listed in
the table below.
Ref No
CN211
Page 25
Need
An
NG-eCall
shall
be
transferred from a Level-1 to a
Level-2 PSAP
Description and Comments
Reference
Assuming that the Level-1 PSAP UC02-1
taking an NG-eCall shall be
capable of transferring this call to
a Level-2 PSAP for further
handling. This can take place over
an IP connection (i.e. the call is
fully based on VoIP) or a CS
connection.
Ref No
CN212
Need
CN213
MSD and any additional
information
shall
be
transferred from Level-1 to
Level-2 PSAP connected via IP
network for data exchange
only.
MSD and any additional
information
shall
be
transferred as a part of the NGeCall request from Level-1 to
Level-2 PSAP connected via IP
network.
Description and Comments
Reference
Upon taking the NG-eCall the first UC02-1
level PSAP will decode the MSD.
In some cases, it will also try to
obtain other data available from
external sources (e.g. EUCARIS
database). All the information
gathered shall be passed on to
the Level-2 PSAP when the voice
call is transferred.
Assuming that the Level-2 PSAP UC02-1
has an IP connection, two
potential scenarios arise: a) in the
first scenario where the two PSAP
systems are fully integrated, all
the data is transferred in parallel
with the voice call establishment
b) in the second scenario the
Level-1 PSAP passes to the Level2 PSAP (e.g. via an operator chat
application or similar method) a
simple link to a local repository
where it stores the data or the
link to the additional data from
the original NG-eCall MSD he has
received.
4.3.3 The Use case No. 2, UC02 – Satellite networks enhancements and support as an
additional IP-CAN
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
Use Case Name Satellite networks enhancements and support of satellite as an
additional IP-CAN, deployed autonomously or integrated with
4G and 5G Core Networks
Use case reference Use case 02-2 / UC02 -2
/id
M
Description Satellite bearers to Enhance/Complement NG-eCall connectivity
either autonomously (as per TS 17312) or in a collaborative mode
with existing terrestrial 4G and 5G Core architectures.
M
Scope A satellite terminal to be deployed on the vehicle to support NGeCall connectivity through the IVS which, when appropriate, shall
direct the traffic over a satellite bearer.
Page 26
CEN TC278 PT1701 USE CASE TEMPLATE
M
Use Case Name Satellite networks enhancements and support of satellite as an
additional IP-CAN, deployed autonomously or integrated with
4G and 5G Core Networks
M
Scenario An agricultural/forestry vehicle activates the eCall, however no
terrestrial network is available. The vehicle IVS immediately
activates the satellite transceiver on the vehicle rooftop and NGeCall communication is diverted through the satellite bearer. IVS
continuously tries to re-establish connectivity to the terrestrial
network, it continues diverting traffic through the satellite link,
until the primary link becomes operational.
M
Actors Involved
M
Stakeholders
M
Area of incident
M
Assumptions
M
Standardisation
gaps identified*
O
"Use Case" level
O
Requirements
Reference
Vehicle driver
Vehicle OEM
IVS provider
On-vehicle satellite terminal provider
Satellite operator
Terrestrial Core network operator
As above except for the vehicle driver
Europe where the NG-eCall service is supported
The satellite operator shall allow pre-authorized NG-eCall devices
onto its network.
Available •
Standards •
•
•
M
Page 27
•
•
•
•
•
•
•
CEN/TS 17312
ETSI TS 123 402
ETSI TS 123 501
ETSI TS 123 502
Satellite operator involvement in NG-eCall activities (Satellite
operator network shall detect, process and forward NG-eCall
messaging).
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name Satellite networks enhancements and support of satellite as an
additional IP-CAN, deployed autonomously or integrated with
4G and 5G Core Networks
Where an Administration is prepared to provide a single central
Data
level 1 PSAP for satellite-IMS-112-eCall:
Requirements
1. The Administration shall make available an IP address of a
single central level 1 PSAP for satellite-IMS-112-eCall to the
satellite network operator in an agreement between the
PSAP and the satellite network operator.
2. Each satellite communication network operator shall
maintain a routing table with the geographical bounds and
the IP address of each Administration’s central level 1 PSAP.
3. When an NG-eCall is initiated, the network operator shall
route the 112-IMS-eCall call to the IP address appropriate to
the country identified by the GNSS position provided by the
caller in the SIP header, as per the routing table.
4. For satellite providers that do not support IMS, the satellite
operator network shall connect either to a CeIMS (as per TS
17312) or shall forward NG-eCall message to terrestrial
networks operating either under 4G or 5G architecture and
have an appropriate IMS unit that supports NG-eCall
operation.
O
Relationships to
other "Use Case(s)"
O
Triggers
Page 28
If no mobile network is available then an optional satellite
link may be used. This is linked to UC 01-1, “General NG eCall
for vehicles”.
Vehicle has an accident. IVS issues an NG-eCall to the most
appropriate PSAP through an L band or Ka band satellite
network
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name Satellite networks enhancements and support of satellite as an
additional IP-CAN, deployed autonomously or integrated with
4G and 5G Core Networks
Scenario 1. A commercial L6 type vehicle is involved in an accident when
#Scenario1.
moving from an urban to a rural area.
2. An NG-eCall is initiated automatically from the IVS in the
vehicle, trying to establish connection to an LTE/5G Core
network.
3. The IVS fails to connect to an LTE network and automatically
diverts the NG-eCall over the satellite network.
4. The in-vehicle satellite terminal communicates tracks and
establishes communication through L-band or Ka band carrier
to the satellite platform.
5. The satellite communicates the traffic to the operator’s hub
which communicates with an edge router that is part of the
operator’s network or belongs to a third-party network.
6. The routers divert the traffic to the MNO core network
through the secure gateway (ePDG).
7. The ePDG authenticates the NG-eCall and communicates
directly to the P-GW and in turn to the IMS where the NG-eCall
is forwarded to the most appropriate PSAP.
Page 29
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name Satellite networks enhancements and support of satellite as an
additional IP-CAN, deployed autonomously or integrated with
4G and 5G Core Networks
Scenario 1. A forestry/agricultural vehicle is involved in an accident in a
#Scenario2.
forestry environment and the passenger is inside the vehicle.
The vehicle supports NG-eCall through satellite connectivity.
2. An NG-eCall is initiated automatically from the in-vehicle
satellite terminal and connection is established to a satellite
operator network.
3. In the case that IMS is a part of a terrestrial MNO the steps 47 from scenario 1 are repeated. In the case that the IMS is
integrated within the satellite operator network the following
steps follow:
4. The satellite communicates the traffic to the operator’s hub
which in turn communicates with The Network Attachment
Subsystem (NAAS) and Resource and Admission Control
(RACS) in the satellite network operator.
5. The RACS reassigns resources in order to prioritize emergency
traffic through communication with satellite core network
control centre (NCC).
6. The RACS forwards the data in the IMS where the NG-eCall is
forwarded to the most appropriate PSAP.
O
Scenario 1. A forestry/agricultural vehicle is involved in an accident in a
forestry environment and the passenger is outside the vehicle.
#Scenario3.
The vehicle supports NG-eCall through satellite connectivity.
2. An NG-eCall is initiated automatically from the in-vehicle
satellite terminal and a connection is established to the
satellite network.
If IMS is deployed on a terrestrial 4G/5G Core Network:
3. The passenger uses a smart phone to connect to wireless
access point inside the vehicle.
4. The Wi-Fi access point (which will either be part of the invehicle terminal or will be an additional in-vehicle device)
communicates to the satellite terminal, which in turn
establishes communication through and L-band or Ka band
carrier to the satellite platform.
5. Steps 5-7 are implemented as per scenario 1.
In the case that the IMS is integrated within the satellite operator:
3. network steps 3-5 from scenario 2 are implemented.
Page 30
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name Satellite networks enhancements and support of satellite as an
additional IP-CAN, deployed autonomously or integrated with
4G and 5G Core Networks
Scenario
#Scenario4
(Optional).
O
O
Expected
The lack of terrestrial connectivity does not influence the
Outcomes
establishment and reliability of the eCall system, as NG eCall over
IMS can be now established by utilizing an additional satellite
bearer. This is achieved, locally in the satellite network if IMS is
integrated within the satellite operator’s network. If IMS is
implemented on a 4G or 5G network, then IMS can be reached
through the ePDG and N3IWF network functions for 4G and 5G
systems respectively.
Extensions The satellite capable IVS can be extended to other vehicles types
except from the agricultural/forestry vehicles for which is a
necessity. This mainly can include LGVs, buses and coaches. For
agricultural and forestry vehicles, and for the case where the
passengers (workers) are outside the vehicle, a mobile ecall
system can automatically be activated to establish the NG eCall
through satellite when terrestrial connectivity is unavailable
O
Inclusions
O
Business Rules
Template Version
O
151021 PT1701 consensus
Open Issues
User needs from the use case UC02-2
Only user needs that are NG-eCall specific and related to the architecture requirements are listed in
the table below.
Ref No
SN221
Page 31
Need
The user requires NG-eCall service
through satellite connectivity, in
locations where low population
density (such as rural areas, Northern
Scandinavia
and
mountainous
regions) does not justify the provision
of land-based cellular telephone
networks.
Description and Comments Reference
This is where satellite UC02-2
bearers can provide a
reliable and high-quality
NG-eCall
service,
complimentary
to
terrestrial bearers; when
terrestrial networks are
not supported at a certain
area.
Ref No
SN222
Need
SN223
The user requires NG-eCall service in
locations where low population
density (such as rural areas, Northern
Scandinavia
and
mountainous
regions) does not justify the provision
of land based cellular telephone
networks.
Page 32
The user requires from the satellite
telecommunications service provider
to route the NG-eCall via IMS to a
central 1st level PSAP address if
offered. If not, satellite NG-eCall can
be provided via a TPSP.
Description and Comments Reference
In countries where the UC02-2
Administration
is
prepared, the satellite
telecommunications
services will be provided
using a single central level
1 PSAP IP address for
satellite-IMS-112-eCall.
The central 1st level PSAP
can then identify the GNSS
location of the source of
the NG-eCall from the call
establishment and redirect
on the basis of the GNSS
location information. As
long as the satellite
operator is connected to a
4G or 5G terrestrial core
network through a secure
gateway (ePDG for 4G and
N3IWF for 5G systems) the
NG-eCall can be forwarded
to the IMS infrastructure of
the
terrestrial
core
network. In the case that
both options are not
available, a third-party
service provider can be
deployed using a satellite
telecommunications
service provider in order to
provide
Satellite-TPSPeCall.
NG-eCall can be provided UC02-2
via satellite bearers and
supported in locations
where there is limited or
no
2G/3G/LTE/4G
coverage available.
Ref No
SN224
Need
The user requires that the
geographical position of the vehicle is
always known.
SN225
The user requires that following the
activation of an NG-eCall, the
communication capability (voice and
data) between vehicle and PSAP can
be continued following an initial NGeCall being sent, until cancelled by
either the PSAP or vehicle occupant.
Description and Comments Reference
This is generally obtained UC02-2
through GNSS information
of the vehicle. Where the
GNSS location is not
available in the NG-eCall
establishment, the NGeCall is directed to the
nearest PSAP, which shall
be able to read the MSD to
find the location of the
vehicle
and
similarly
redirect the IMS call to the
“most appropriate PSAP”
on the basis of the location
data provided in the MSD.
The satellite operator shall UC02-2
have a continuous open
communication pipe in the
case of an NG-eCall
communication. The IVS
will seek to and reestablish connectivity to
the primary terrestrial
network, until this does
become available.
SN226
The user requires that emission levels
UC02-2
This is related to ITU-limits
from the satellite terminal shall be for off-axis radiation to
kept within the prescribed limits.
avoid interference to
adjacent satellites, as well
as to the ITU limits for
harmful radiation from
satellite communication
emissions
SN227
The user requires that the sAFE NGeCall system minimises latency for
sessions established through satellite
bearers.
This is related to TCP UC02-2
accelerations schemes to
be employed as described
in
the
architectural
requirements below.
4.3.4 The Use case UC02-3 – NG-eCall Supplemental Data from External sources provided
by Functional Elements in ESInet
Page 33
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
Use Case Name NG-eCall Supplemental Data from External sources provided by
Functional Elements in ESInet
Use case reference Use case 02-3 / UC02-3
/id
M
Description NG-eCall for some vehicle categories like Large Goods Vehicles
LGVs provides an optional additional data concept in MSD where
link to load information (off-vehicle) has to be fetched from other
data sources. PSAPs would require services for accessing this
supplemental data.
M
Scope To provide supplemental data with its reference (link) in MSD
“Optional additional data” as part of the initial MSD received by
'Public Safety Answering Point' (PSAP) in the event of a crash or
emergency via an NG-eCall communication transaction or any
other valuable data for faster disaster relief.
Communication between PSAP and Supplemental Data and
Database Access Services (SDS) in Emergency service IP network
(ESInet) in order to obtain data from internal or external
databases. In case of LGV IVS provides secure link to obtain load
information from ECMR Databases.
M
Scenario PSAP receives NG-eCall from LGV with IVS supporting Schema B.
After processing the MSD PSAP invokes Supplemental Data and
Database Access Services (SDS) with the access to the data systems
in order to get data about the load with its reference in the initial
MSD.
In addition to NG-eCall, PSAP may also receive traffic information
upon request or provide information about traffic accident to
DATEX2.
M
M
M
Page 34
• Large Goods Vehicle driver
• PSAP operator
• LGV operator
• ESInet service provider (SDS, ECRF, ESRP, LPG, LNG, etc.)
Stakeholders • PSAP operator
• LGV operator
• ESInet service provider
• Emergency response unit personnel
• DATEX2 organisation
• ECMR service organisation
• EUCARIS organisation
• Manufacturer/supplier
Anywhere in Europe where NG-eCall for LGV is available.
Area of incident
Actors Involved
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
Use Case Name NG-eCall Supplemental Data from External sources provided by
Functional Elements in ESInet
Assumptions
The LGV is equipped with IVS supporting MSD schema B.
Supplemental Data and Database Access Services are available in
ESInet.
PSAP can communicate with Supplemental Data and Database
Access Services.
M
Available Standards •
•
M
Standardisation gaps
identified*
O
"Use Case" level
O
Requirements
Reference
O
CEN TS 17249-2
CEN TS 17184
•
CEN TS 17240
•
EENA NG 112 LTD
•
ETSI TR 103140
•
CEN EN 15722
•
CEN EN 16062
•
CEN EN 16072
•
Supplemental Data and Database Access Services in ESInet
for supporting access to local or external data sources like
ECMR Databases, DATEX2.
Data Requirements MSD according to the Schema B with Optional Additional data in it
for obtaining data via secure link from other sources.
The data with the secure link in MSD from other sources (e.g. data
obtaining from internal or external databases via database access
services in ESInet).
O
O
Relationships to Linked to the Use Cases 02-1 and 01-3 and the Use case for LGV
other "Use Case(s)" Schema B as a result of the Sub-Activity 3.4.
Triggers Accident of large goods vehicle.
Manual NG-eCall from the LGV operator.
Page 35
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name NG-eCall Supplemental Data from External sources provided by
Functional Elements in ESInet
Scenario 1. A commercial Large Goods Vehicles LGV is involved in an
#Scenario1.
accident.
2. A CS-eCall is initiated automatically from the IVS in this vehicle.
3. The Legacy Network Gateway receives the CS-eCall and
interworks with the PS PSAP via ESInet and its routing entities.
4. The PSAP operator takes the NG-eCall and parses the MSD
according to the Schema B.
5. After processing the MSD PSAP invokes Supplemental Data
and Database Access Services (SDS) via CAP protocol.
6. PSAP sends the secure links from MSD in the CAP message to
SDS for accessing the ECMR databases.
7. SDS obtains supplemental data from the ECMR Database with
EU Electronic Node and Information detailing Load.
8. Based on the data in MSD about presence of Hazardous Goods
SDS obtains also supplemental data in conjunction to
Hazardous Goods.
9. The PSAP operator presents this supplemental data together
with MSD data in the graphical format on screen.
10. Upon data the operator assigns the rescue mission to most
relevant emergency response teams who are well-prepared
for disaster relief.
Scenario 1. A commercial Large Goods Vehicles LGV is involved in an
accident.
#Scenario2.
2. An NG-eCall is initiated automatically from the IVS in this
vehicle.
3. The steps 4-11 from Scenario 1 are implemented.
Page 36
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name NG-eCall Supplemental Data from External sources provided by
Functional Elements in ESInet
Scenario 1. The steps 1-11 from Scenario 1 or the steps 1-3 from Scenario
#Scenario3.
2.
'Use Case Extension'
2. If possible, the PSAP operator has conversation with the
occupants of the vehicle involved in accident to get additional
data and to enhance situational awareness in order to activate
the most relevant PSAP and/or emergency responders.
3.
Based on the load the operator may transfer/bridge this NGeCall with MSD and supplemental data to another PSAP or
TPSP.
4. The operator can also establish a call to the contact person of
the load (Consignor or contact in shipping remarks in ECMR
document). The operator can invoke in this call the relevant
emergency responders, and, if needed, the special units for
disaster relief.
O
Scenario 1. The steps 1-11 from Scenario1 or the steps 1-3 from Scenario
#Scenario4.
2.
'Use Case Extension'
12. While selecting emergency response units, the PSAP operator
may request traffic information from an external data system
for given area/locations of response units, accident site.
13. The PSAP operator invokes the SDS from ESInet to obtain this
data from relevant external data system.
14. The operator forwards this information to the selected
emergency response teams to provide information about the
most appropriate route to the accident area.
O
Scenario 1. The steps 1-11 from Scenario1 or the steps 1-3 from Scenario 2
#Scenario5.
and the steps 12-14 from the Scenario4.
'Use Case Extension'
O
Expected
Under ideal circumstances the PSAP operator has obtained the
Outcomes
MSD data from the original NG-eCall and supplemental data about
the load from the secure links in this MSD.
Extensions
O
Inclusions
O
Business Rules
Page 37
15. According to the received information from rescue teams on
the site, the operator may update the relevant external
systems with this traffic information.
See the scenarios 3, 4 and 5 above.
CEN TC278 PT1701 USE CASE TEMPLATE
M
Use Case Name NG-eCall Supplemental Data from External sources provided by
Functional Elements in ESInet
Template Version
O
151021 PT1701 consensus
Open Issues
User needs from the use case UC02-3
Only user needs that are NG-eCall specific and related to the architecture requirements are listed in
the table below.
Ref No
SN231
SN232
SN233
SN234
Page 38
Need
The functional elements in
ESInet shall be able to
provide interworking and
routing
to
NG-eCall
capable PSAP.
Description and Comments
The functional element LNG in the ESInet
connects CS-eCall capable IVS to a NGeCall capable PSAP, the functional
element ECRF and ESRP route the NG-Call
to the most relevant PSAP based on the
IVS location in MSD and/or based on
policy rule set (time of day, PSAP state,
etc.).
The functional element The functional element SDS in ESInet
SDS in ESInet shall be able provides access to external data systems
to provide access to for all PSAPs, TPSPs according to
external data system and authentication and authorisation rules.
obtaining load information The digital data hub at the national,
in
machine-readable regional or PSAP level for accessing local
format via secure links in and external databases will be
MSD.
implemented by using the functional
element SDS with the specified protocols.
The functional element The functional element SDS in ESInet
SDS in ESInet shall be able provides access to external data systems
to provide access to and obtaining the additional valuable
external data system and information in machine-readable format
obtaining
additional for all PSAPs, TPSPs according to
valuable information in authentication and authorisation rules.
machine-readable format.
An NG-eCall capable PSAP The NG-eCall capable PSAP with IP
shall be able to provide a Connectivity uses CAP protocol or any
standard and reliable other standard and reliable protocol to
protocol to invoke an SDS invoke the SDS service. The necessary data
service.
(secure links, etc.) is transferred in the
message body of this protocol.
Reference
UC02-3
UC02-3
UC02-3
UC02-4
5 THE ARCHITECTURE REQUIREMENTS FOR NG 112 ECALL
5.1 Introduction
The Architecture requirements include requirements derived from the needs based on Use cases and
technical requirements coming from different standards. The architecture requirements consider coexistence of CS-eCall and NG-eCall and potential migration and fall-back/handover scenarios from PS
to CS-eCall. Depending on the capabilities of the IVS, access network, core network and ESInet and/or
PSAP to carry the CS or NG-eCall, the eCall session can be established in several ways:
IVS
CS
eCall
CS or PS Core Networks
CS Access
Network
IP-CAN
CS ecall
CS Core
CS Voice/inband modem
PS to CS
transfer
PS to CS ecall
S2
S4
Network
CS
eCall
S1
NG
eCall
PS Access
PSAP
PS Core
VoLTE/VoIP
S3
CS to PS ecall
NG
S5
eCall
ESINet
NG ecall
SIP
Figure 2: End-to-end scenarios for co-existed CS in NG-eCall.
•
Scenario S1 (CS-eCall): Scenario S1 corresponds to the 112 eCall, where eCall is established between
IVS and PSAP using CS Access and Core network. MSD data is transferred from IVS to PSAP in the
voice channel using the in-band modem transcoding capability of the IVS and PSAP. This scenario
will also cover the case, when an IMS based PSAP is available, but there is no IMS core available to
carry NG eCall, so the IVS would make a CS call. It is therefore required that PS based PSAP has to
be also CS capable.
•
Scenario S2 (PS to CS-eCall migration scenario): The IMS core network provides an indication that
it is capable to carry NG eCall, therefore the PS capable IVS initiated NG eCall, but the PSAP has
only CS capability and cannot accept PS-based eCall. Therefore NG eCall is established between the
IVS with PS-eCall capability and PSAP with CS capability, using PS Access network and IMS Core
network, and Legacy PSAP Gateway (LPG) to transcode voice from VoIP into CS Voice together with
SIP-SS7 interworking and MSD from SIP message into in-band data MSD message, which is
transferred to PSAP in the CS Voice channel.
•
Scenario S3 (NG eCall): In scenario S3 the NG eCall is established between IVS and PSAP, both with
PS-eCall functionality using PS Access and IMS Core network, using SIP signalling protocol and
Voice-over-LTE (VoLTE) communication. MSD data is transferred from IVS to PSAP within SIP
message body.
•
Scenario 4 (PS to CS transfer): In this scenario the IMS Core network transfers NG-eCall to CS
network, such that after transfer, the CS-eCall is established between IVS and PSAP, both with CS
capabilities.
Page 39
•
Scenario 5 (CS to PS-eCall scenario): This is an optional scenario, in which the CS-eCall is converted
by the functional element Legacy Network Gateway (LNG) in ESINet into NG-eCall and further
routed to NG PSAP using the functional elements ESRP and ECRF in ESInet. This scenario can only
exist in the presence of ESINet service network, e.g. IMS Core network itself does not support CS to
PS-eCall scenario.
Note, that both, NG-based IVS and PSAP, must provide CS-eCall capability. If CS-eCall is initiated and
no ESInet exists, then it is accepted by PSAP as CS-eCall, e.g. the use of gateway functionality within
IMS Core network to transcode CS into PS-eCall is not foreseen. However, such capability may exist
within ESInet network as defined in the Scenario 5.
In a simplified configuration, PSAP can be directly connected to CS or PS networks as CS voice terminal
or as IMS client, respectively. In such cases, CS and PS core networks use location information extracted
from MSD or from Access/Core network to route the call to appropriate PSAP. PSAP is usually, but not
necessary a part of a secured, managed IP network, called ESInet, which is used for emergency services
communications, and which can be shared by all public safety agencies. ESInet may further refine
routing to appropriate PSAP using ESInet routing policies based on in-depth inspection of MSD data.
5.2 High-level Architecture requirements based on use cases and end-to-end
scenarios
5.2.1 High-level Architecture requirements based on Standards
Figure 3 shows high-level mapping of essential functional elements (indicated with blue rectangles) used
by legacy or NG eCall emergency service to end-to-end network elements.
IVS
LIS
CS or PS Core Networks
ECRF
LDAF
CS
eCall
FBF
PSAP
CS Access
Network
SDS
CS Voice/inband modem
CS Core
LPG
LNG
IP-CAN
ECRF
NG
eCall
BCF
PS Access
PS Core
ESRP
CS
eCall
NG
eCall
ESINet
VoIP/VoLTE
Network
SIP
LVF
Figure 3: Essential functional elements required to implement eCall scenarios.
The end-to-end network elements are defined as:
•
IVS – In-Vehicle System is responsible for initiation of the eCall emergency service request either
automatically, without user intervention or manually by user. Legacy IVS can initiate Circuit
Switch (legacy) eCall, while NG IVS may initiate both, CS-eCall and also Packed Switch eCall
request.
Page 40
•
CS Access network – Circuit Switch access network is a legacy cellular wireless access network
which intercepts an eCall request from legacy, non-IP IVS device.
•
IP-CAN - Internet Protocol Communication Access Network is all-IP wireless access network
which intercepts an NG-eCall request from an NG IVS device.
•
CS Core – Circuit Switch Core is a legacy, TDM-based, mobile network core, which routes eCall
requests from legacy IVS to appropriate legacy PSAP or to a Legacy Network Gateway as a
point-of-interconnect to Emergency Service network (ESInet).
•
PS Core – Packed Switch Core is an all-IP Multimedia Subsystem (IMS) Core network, which
route NG-eCall requests from NG IVS to appropriate NG PSAP or to an appropriate point-ofinterconnect to Emergency Service network (ESInet).
•
ESInet - The emergency services IP network is an all-IP network that makes routing decisions
and forwards the NG-eCall to appropriate PSAP or to another ESInet.
•
PSAP - The Public Safety Answering Point is capable of receiving either legacy signalling or IPbased signalling for delivery of eCall, for accepting eCall media and for originating calls.
Taking into consideration the use cases defined in section 4.3 and the eCall scenarios defined in section
5.1, the essential eCall and NG-eCall functional elements are defined as:
•
LDAF - Location Determination and Accessibility Function includes the functions necessary to
accurately and automatically, without input from the user, determine the position of the IVS
device and associate that location information uniquely with that device. Location acquisition
refers to the functions necessary to make that location information available to the device on
request so that location information can be used for eCall/NG-eCall service.
•
LIS - A Location Information Service is a functional element that provides locations of IVS. A LIS
is queried by the IVS for its own location, LIS can provide Location-by-Reference, or Locationby-Value, and, if the latter, in geo or civic forms.
•
FBF – Fallback Function provides fall-back to standard European eCall with in-band modem, if
NG-eCall is neither supported by the network nor the PSAP.
•
LNG – Legacy Network Gateway may be needed to connect NG PSAP to a legacy network who
retains a TDM interface from CS IVS.
•
BCF - The BCF provides a secure entry into the ESInet for NG-eCall presented to the network.
The BCF incorporates firewall, admission control, and may include anchoring of session and
media as well as other security mechanisms to prevent deliberate or malicious attacks on PSAPs
or other entities connected to the ESInet.
•
LPG – Legacy PSAP Gateway may be needed to connect a legacy PSAP to an IP-based
Emergency Service Network.
•
ECRF - The Emergency Call Routing Function (ECRF) receives location information (either civic
address or geo-coordinates) as input and uses this information to provide an URI that can be
used to route an emergency call toward the appropriate PSAP for the caller’s location.
Depending on the identity and credentials of the entity requesting the routing information, the
response may identify the PSAP, or an Emergency Service Routing Proxy (ESRP) that acts on
behalf of the PSAP to provide final routing to the PSAP itself.
•
ESRP – Emergency Service Routing Proxy is an optional functional element which acts as a proxy
server that selects the next hop routing within the ESInet based on location and policy.
Page 41
•
LVF - The LVF is used to validate location objects against the street addresses and
corresponding Emergency Service Numbers. Pre-validation of the location information ensures
that the calls can be routed to the appropriate PSAP and that emergency services can be
dispatched to the correct location.
•
SDS - Supplemental Databases and Database Access Services provide information requested by
PSAPs and other entities on the ESInet in support of emergency services handling.
Figure 4 shows high level network architecture when PSAP is directly connected to CS or IMS core
network, e.g. routing to PSAPs is entirely based on the routing functionality of CS or IMS Core network.
For simplicity, only those functional entities of the IMS core network are shown that are used in the
establishment of the NG-eCall. Detailed description of the IMS architecture with interfaces is provided
in Section 6.
CS or PS Core Networks
IVS
CS
eCall
CS Voice/
inband
modem
CS Voice/
Inband
modem
2G/3G
CS Access
Network
CS Core
S1
PSAP
CS
eCall
S4
IP-CAN
SIP
I-CSCF
3GPP
PS Access
Network
(3.5G/4G/5G)
BGCF
SIP
P-CSCF
Un-trusted*
PS Access
Network
ISUP
S2
EATF
NG
eCall
SIP
LPG
SIP
E-CSCF
IBCF
S3
SIP
IMS Core
NG
eCall
SIP
PS Voice (VoLTE/VoIP)
CS Voice (inband MSD)
SS7/ISUP
(e.g. SATCOM)
VoLTE/VoIP
BGW
Figure 4: Overview of network entities for CS-eCall and NG eCall.
With respect to scenarios, described in Section 5.1, the following network entities may be involved in
eCall establishment:
•
Scenario S1 (CS-eCall): eCall is established between IVS and PSAP, both with CS-eCall functionality
using 2G/3G CS Access network and CS Core network, using ISUP/SS7 signalling protocol and CS
voice (e.g. PCM voice). MSD data is transferred from IVS to PSAP in the voice channel using the inband modem transcoding capability of the IVS and PSAP. In this scenario, the eCall ECRF function
is implemented by CS Core network functions.
•
Scenario S2 (PS to CS-eCall migration scenario): In scenario S2 the NG-eCall is established between
the IVS with PS-eCall capability and PSAP with CS capability, using PS Access network and IMS Core
network. The LPG is used to transcode voice from PS Voice into CS Voice and SIP into ISUP signalling
protocol. The MSD shall be transcoded from SIP message into in-band data message transferred to
PSAP in the CS Voice channel. The BGCF function is used as eCall BCF function.
•
Scenario S3 (NG-eCall): In scenario S3 the NG eCall is established between IVS and PSAP, both with
PS-eCall functionality using 3GPP PS (e.g. 3G/4G/5G) Access Network, or alternatively non-3GPP PS
Access network, with un-trusted access to IMS Core network, using SIP signalling protocol and
Voice-over-IP (VoIP) communication. MSD data is transferred from IVS to PSAP within the SIP
message body.
Page 42
•
Scenario 4 (PS to CS transfer): In scenario S4 the IMS Core network transfers NG eCall to CS network
using EATF (Emergency Access Transfer Function) and I-CSCF (Interrogation CSCF), such that after
transfer, the 112 eCall is established between IVS and PSAP, both with CS capabilities.
In NG-eCall scenarios (2,3, and 4) the P-CSCF (Proxy CSCF) is used to accept the eCall request from the
PS Access network, E-CSCF (Emergency CSCF) is the IMS network entity, which is responsible to retrieve
the location information and route the request to an appropriate emergency network (e.g. ESInet)
or/and PSAP via IBCF (Interface Border Control Function) or BGCF (Border Gateway Control Function).
NOTE*: In accordance to Annex L of the ETSI TS 123 167, the IVS may issue an eCall over untrusted non3GPP access (e.g. via Satellite IP access network) to IMS Core network only when 3GPP access for
emergency call is not possible or available (e.g. no 3GPP coverage).In remote areas, where terrestrial
connectivity is limited, the priority can be reversed with the IVS primarily issuing the eCall over the non3GPP satellite bearer. Such scenarios are discussed in use case UC 02, where an NG eCall shall be
activated where an accident occurs in a forestry/agricultural vehicle. Implementation can follow either
a bespoke solution of the user and a satellite operator which could act similarly to a third-party
provider, or the service can be offered by collaboration of the MNO and the satellite operator.
To initiate an NG-eCall the IVS responsible for the eCall system shall initiate an IMS emergency call in
accordance with ETSI TS 123 167 Release 14. If the IVS cannot detect a viable IMS network, the NGeCall process shall default to the circuit switched GSM/UMTS system defined in EN 16062.
The receiving PSAP also requires an IMS /IP supporting interface. The process by which the IVS decides
whether to attempt the eCall using IMS or circuit switched emergency call is summarized in the table
below (Table 1) as defined in ETSI 123 167 V15 (2018-12), Annex H.6.
A
B
PS Available
Y
Y
VoIMS
Y
Y
EMS
Y
Y
ECL
Y
N
C
Y
Y or N
N
N
CS if available
D
Y
N
Y
Y
PS or CS if available
E
Y
N
Y
N
CS if available
F
VoIMS =
EMS =
ECL
=
First eCall Attempt
PS
CS if available
Second eCall Attempt
CS if available
PS (UE establishes IMS
emergency session)
No attempt is made in
the PS domain
CS if first attempt in PS
PS if first attempt in CS
PS (UE establishes IMS
emergency session)
N
CS if available
Voice over IMS over PS sessions support as indicated by IMS Voice over PS session supported indication as
defined in ETSI TS 123 401 for E-UTRAN connected to EPC and ETSI TS 123 502 for E-UTRA connected to 5GC
only.
IMS Emergency Services supported as indicated by Emergency Service Support indicator as defined in ETSI
TS 123 401 for E-UTRAN connected to EPC and ETSI TS 123 501 and ETSI TS 123 502 for E-UTRA connected to
5GC only.
eCall Over IMS support as indicated by the eCall support indicator defined in ETSI TS 123 401 for E-UTRAN
connected to EPC and ETSI TS 123 501 for E-UTRA connected to 5GC only.
Table 3: Domain Selection Rules for eCall over IMS session attempts for E-UTRAN connected to EPC and
E-UTRAN or E-UTRA connected to 5GC radio access networks
NG-eCall originating in an Access network provider infrastructure is forwarded via a Voice Service
Provider supporting NG-eCall to an NG-eCall Service Provider where the appropriate PSAP or, in general
terms, the Point-of-Interconnect to a PSAP service provider infrastructure is determined. The definition
of core elements for network independent access to emergency services (e.g. NG-eCall and eCall
service) is based on the core concept of the NG 112 architecture as introduced in (ref. EENA, Next
generation 112 LTD, Version 1.1), a part of which are the Emergency Services IP Network (ESINet) and
its Core elements (ref. ETSI TS 103 479 V0.0.6 (2019-04). The ESINet is a private, managed and routed
Page 43
emergency services network or network of networks that utilizes All-IP technology. An ESINet can serve
a single PSAP, a set of PSAPs, a region, a state, or a set of states (e.g. can be Pan-European).
In cases, when the ESInet is used as a Point-of-Interconnect for Voice Service Provider CS or IMS Core
network, the legacy Network Gateway (LNG) is used as an interworking function, which transcodes CS
Voice with in-band MSD data and ISUP signalling into all-IP data managed within ESInet, e.g. VoIP and
SIP signalling.
IVS
CS
eCall
CS or PS Core Networks
CS Voice/
inband
modem
2G/3G
CS Access
Network
CS Core
PSAP
LNG
LPG
S5
IP-CAN
SIP
(3.5G/4G/5G)
SIP
SIP
NG
eCall
Un-trusted*
PS Access
Network
(e.g. SATCOM)
SIP
B
C
F
LIS
VoLTE/VoIP
ESRP
VoLTE/VoIP
P-CSCF
SIP
SIP
ECRF
3GPP
PS Access
Network
CS
eCall
E-CSCF
IBCF
S3
IMS Core
SIP
ESInet
NG
eCall
SIP
VoLTE/VoIP
CS Voice (inband MSD)
ISUP
Figure 5: NG-eCall with ESInet as a point-of-interconnect to CS and/or IMS network.
Border Control Function (BCF) is used as a Point-of-Interconnect to ESInet network, which intercepts all
signalling and data traffic from Voice Service Provider network. Emergency Call Routing Function
(ECRF) is used to further refine routing to appropriate PSAP based on ESInet routing policies and based
on the location information of the caller provided by CS or IMS Core network or retrieved from Location
Information Server (LIS). The routing function is implemented by Emergency Service Routing Proxy
(ESRP).
When the CS-eCall is delivered to ESInet by CS Core network, as indicated by scenario S5, the Legacy
Network Gateway (LNG) within the ESInet accepts the CS-eCall, converts it into PS-eCall, and the PSeCall is further routed by ESInet to appropriate PS PSAP.
When the eCall within ESInet is routed to CS PSAP, the Legacy PSAP Gateway (LPG) is used to convert
all-IP signalling (SIP) and data (VoIP) into CS voice and in-band MSD, and ISUP signalling.
5.3 Architecture principles apply to NG-eCall sessions
According to ETSI TS 123 167, the NG-eCall is a variant of IMS emergency services and follows the same
principles, architecture, and procedures as other emergency services over IMS. Hence, the Architecture
principles apply to IMS emergency sessions also apply to NG-eCall:
P1 The IMS network shall be able to discriminate between emergency sessions and other sessions. This
shall allow special treatment (e.g. with respect to filtering, higher priority, routing, QoS,
supplementary services interactions) of emergency sessions.
P2 If a visited network can support a PS emergency service, the emergency session shall be established
in the visited network whether or not the IVS is registered in IMS in the home network.
P3 When an IVS using public network, traffic initiates an emergency session, the P-CSCF is the IMS
network entity, which is responsible to detect the request for emergency session. The P-CSCF then
Page 44
forwards the request to E-CSCF in the same network, unless authentication and security procedures
(see principle P1 above) require the request to be forwarded to the S-CSCF in the same network.
NOTE 1:
While in the home network, forwarding of an emergency session to the S-CSCF is only
expected over a non-emergency registration.
P4 The P-CSCF serving the emergency call is the IMS network entity which may retrieve the location
identifier from the IP-CAN. For emergency sessions initiated by a trusted AS on behalf of a nonroaming subscriber, the AS may provide the location identifier.
P5 The P-CSCF serving the emergency call is the IMS network entity which may receive additional caller
related identifier(s) from the IP-CAN (e.g. IP-CAN level's subscriber ID). If required by local
regulation, these additional identifier(s) shall be forwarded by the IMS network to the emergency
control centre/PSAP for those IVSs that have not been authenticated by IMS network and are
requesting to establish an emergency session.
P6 If required, the E-CSCF shall be able to forward the location information to the LRF for validation of
geographical location information in the case that the geographical location information is
included by the IVS over any access network type.
P7 The E-CSCF is the IMS network entity, which is responsible to route the request to an emergency
centre/PSAP via or BGCF, IBCF or IP multimedia network based on location information and
additionally other information such as type of emergency service in the request.
P8 As a regional option where the emergency centre/PSAP is connected to the IMS of another network
(e.g. TTC spec), emergency sessions may be routed over Inter-IMS Network to Network Interface
between two IM CN subsystem networks.
P9 The architecture shall allow for compliance with other regional regulations in which the originating
network shall have the ability to route an emergency call via an IBCF to an emergency services
network.
5.4 Detailed Architecture Requirements for NG-eCall
5.4.1 IMS network requirements for NG-eCall
The solution for NG-eCall is a variant of emergency session in the IMS, which fulfils the emergency
principles and requirements of ETSI TS 122 101, ETSI TS 122 228. In addition, the following Architecture
requirements shall apply for NG-eCall:
IMS.Req1
NG-eCall is not a subscription service.
IMS.Req2
In general, the emergency services are independent from the IP-CAN with respect to the
detection and routing of emergency sessions. The NG-eCall services shall be possible over
at least a cellular access network , namely E-UTRAN access connected to EPC and E-UTRAN
or E-UTRA connected to 5GC, or untrusted non-3GPP access to EPC or 5GC (using
procedures for un-trusted access to EPC/5GC).
IMS.Req3
NG-eCall sessions should be prioritized over non-emergency sessions by the system, in
accordance with IETF RFC 8147.
IMS.Req4
The establishment of NG-eCall shall be possible for users with a barred public user identity.
IMS.Req5
The solution shall work in case the IVS has sufficient credentials to authenticate with the
IMS and is registered to the IMS or is not registered with the IMS. The case where the IVS
Page 45
does not have sufficient credentials to authenticate with the IMS shall also be supported
if required by local regulation.
In the case that IVS is not already IMS registered, it shall perform a registration for the
support of emergency services (emergency registration).
In the case an IVS is already IMS registered, the IVS may skip the additional emergency
registration if the IVS is aware that it is in its home network (e.g. including IP-CANs where
roaming outside the home network is not supported).
If the IVS does not have sufficient credentials to authenticate with the IMS it shall be
possible to perform session establishment without an existing security association
between IVS and P-CSCF, and the IVS shall include an equipment identifier (the specific
details of the equipment identifier to use may depend upon the IP-CAN) in the request to
establish an emergency session.
Subject to local regulation or operator policy, the network and the IVS shall support the
same authentication and security methods for an emergency service request as for nonemergency requests.
IMS.Req6
Where NG-eCall request from IVS with sufficient credentials to authenticate with the IMS
is required, it shall be possible to reject NG-eCall service requests from an IVS that does
not provide sufficient credentials to authenticate with the IMS in networks.
IMS.Req7
When the IVS has roamed out of its home network and the roamed-to network supports
emergency sessions, the NG-eCall service shall not be provided by the home network, but
shall be provided in the roamed-to network:
-
If an IVS has sufficient credentials, it shall initiate an emergency registration with
the roamed-to network (requiring the involvement of the home network). The CSCFs
providing service for emergency sessions may be different from the CSCFs involved
in the other IMS services.
-
If the registration fails and if the serving IMS has indicated support for anonymous
IMS emergency sessions as part of the IMS registration failure, the IVS shall attempt
an anonymous emergency session.
-
If the IMS registration fails and if the serving IMS has not indicated support for
anonymous IMS emergency sessions as part of the IMS registration failure, the IVS
may attempt an anonymous IMS emergency session.
NOTE 3: IVSs compliant with pre-Rel14 versions are unable to interpret this
indication and ignore the indication. Such IVS-s might attempt an anonymous IMS
emergency session or proceed according to Annex H.5 of ETSI TS 123 167.
IMS.Req8 If a NG eCall session establishment request is routed to a P-CSCF located in the home
network, the home network should be able to detect that the session is for emergency
service (whether indicated as such or not) and respond to the IVS indicating that the IVS
should initiate an emergency session in the visited network (e.g. via the CS domain of the
visited network).
IMS.Req9 Emergency centres and PSAPs may be connected to CS and/or PS networks.
Page 46
IMS.Req10 The architecture shall enable emergency centres and PSAPs to request a PSAP call back to
an IVS with which the Emergency centres or PSAPs had an emergency session. The serving
network of the IVS shall use the appropriate call termination procedures e.g. IMS if the IVS
is available for voice over PS, or ICS if the user is available over CS. PSAP call back is subject
to local regulation.
NOTE 4:
PSAP call back sessions are treated as normal calls.
NOTE 5: Subject to local regulation, any supported media can be used during a call back
attempt from a PSAP.
IMS.Req11 The IMS core network shall be able to transport information on the location of the
subscriber.
IMS.Req12 The network shall be able to retrieve the caller's location;
IMS.Req13 The network shall provide the caller's location information to the PSAP upon query from
the PSAP.
IMS.Req14 The network shall provide the possibility to route to a default answering point given the
scenario where the local PSAP cannot be determined.
IMS.Req15 Subject to local regulation, for non-roaming subscribers the network shall apply normal
routing procedures for private network traffic even if that is marked as emergency session.
IMS.Req16 When a call is established with a PSAP that supports voice only, voice media is supported
and GTT if required by local regulation or operator policy.
IMS.Req17 When a call is established with a PSAP that supports voice and other media, voice, GTT
and other media according to ETSI TS 122 101 (e.g. video, session mode text-based instant
messaging) can be used during a NG-eCall if required by local regulation. This media may
be used in addition to or instead of voice and/or GTT.
IMS.Req18 For the media supported during NG-eCall, which fulfils IMS emergency session
requirement as specified in ETSI TS 122 101 clause 10.4, media codec and format support
is specified in ETSI TS 126 114.
5.4.2 Location information for NG eCall
In general, the location information within NG eCall service is provided by IVS, as part of its mandatory
requirements, and by the network (3GPP, IMS). The requirements within this section are related to the
location provided by the network, which is used for call routing within IMS network to PSAP point of
interconnect.
Location information is needed for 2 main reasons in NG-eCall services:
•
The initial purpose of the location information is to enable the IMS and/or ESInet network to
determine which PSAP or, in general terms, the Point-of-Interconnect to a PSAP infrastructure,
serves the area where the IVS is currently located, so that the IMS and/or ESInet network can route
the NG-eCall session to the correct PSAP/Point-of-Interconnect to a PSAP infrastructure.
•
The second purpose is for the PSAP to get more accurate or updated location information for the
IVS during or after the NG-eCall session where required by local regulation.
The following general principles shall apply regarding the handling of location information by the IMS
network:
Page 47
LOC.Req1 The IVS shall include the location information in the request to establish an emergency
session. The location information may consist of network location information, that is the
location Identifier, and/or the Geographical location information.
NOTE 1: According to ETSI TS 123 167, routing within the IMS core is based on the UE
location and the eCall type of emergency service indication, but not on the content of the
initial MSD.
LOC.Req2 The P-CSCF may query the IP-CAN to obtain location identifier.
LOC.Req3 When an emergency session is coming from a TPS service, it is assumed that the TPS service
includes the initial location information in the request to establish an emergency session
and subsequent location information as requested.
LOC.Req4 The E-CSCF, if required, may query the LRF for additional location information.
LOC.Req5 The E-CSCF shall be able to query the LRF to validate the location information provided
initially by the IVS.
LOC.Req6 The E-CSCF routes the emergency request to the PSAP/Emergency Centre/Point-ofInterconnect to a PSAP infrastructure agreed with the local administration.
LOC.Req7 The E-CSCF forwards the SIP to the PSAP/Emergency Centre/Point-of-Interconnect to a
PSAP infrastructure via PS domain or via BGCF/MGCF through the CS domain. Location
information is present in the MSD.
5.4.3 Media
MEDIA.Req1 When the call is established with a PSAP that supports voice only, voice is subject to local
regulation, GTT media is allowed during the IMS emergency session.
MEDIA.Req2 When the call is established with a PSAP that supports voice and other media, subject to
IVS and network support for the other media and local regulation, voice, GTT and other
media according to ETSI TS 122 101 can be used during the IMS emergency session.
MEDIA.Req3 For sessions with a PSAP that supports voice and other media, post the NG-eCall (receipt
of MSD and establishment of voice connection with the vehicle), media can be added,
modified or removed during the IMS emergency session (e.g. adding video to a voice call)
per media negotiation in ETSI TS 123 228, as an incident management service.
MEDIA.Req4 When a PSAP that supports voice and other media attempts to add media, the media
shall be added if accepted by the IVS.
5.4.4 IP-CAN
Given that the NG eCall is a variant of IMS emergency services, the following expectations shall be taken
into account on the IP-CAN:
IPCAN.Req1 It shall be possible to reject requests from IVS without sufficient security credentials to
establish bearer resources.
IPCAN.Req2 In the case that the IP-CAN receives a request to establish bearer resources for
emergency services, it shall be possible for the IP-CAN to prioritise emergency services
traffic. PCC (Policy and Charging Control) methods may be used to inform the IP-CAN and
request appropriate handling of the emergency service. The QoS information for
emergency traffic is specified in ETSI TS 123 203.
IPCAN.Req3 In the case that the IP-CAN receives a request to establish bearer resources for
emergency services, the IP-CAN shall ensure that the IP flows using the requested
Page 48
resources are only for communication with the network entities involved in the support
of the emergency services. Applicable service data flow filters for emergency traffic need
to be defined by the operator according to the details described in ETSI TS 123 203.
IPCAN.Req4 In the case that the IP-CAN receives a request to establish bearer resources for
emergency services, the IP-CAN may provide additional identifier(s) to IMS network (e.g.
IP-CAN level's subscriber ID).
IPCAN.Req5 The IP-CAN may support emergency services free of charge. Applicable PCC rules need to
be defined by the operator according to the details described in ETSI TS 123 203.
For NG-eCall established via 3GPP (3.5G/4G/5G) access network, namely E-UTRAN/EPC, NG-RAN/5GC,
the detailed procedures are described in ETSI TS 123 060 , ETSI TS 123 401, ETSI TS 123 167 and ETSI TS
123 501 , while for a NG-eCall request placed via non-3GPP un-trusted access to EPC and 5GC, the
procedures are described in ETSI TS 123 402 and ETSI TS 123 501 and ETSI TS 123 167.
General information of the emergency support in different IP-CAN scenarios is described in the
Informative Annex E of ETSI TS 123 167.
5.4.5 NG-eCall enabled IVS requirements
The following requirements apply to an IVS responsible for initiation of the eCall emergency service
request:
IVS.Req1 As specified in ETSI TS 122 101 Release 14, an NG-eCall IVS responsible for initiation of the
NG-eCall emergency service request shall have a valid USIM. The USIM enables the provision
of the eCall service. The USIM can be configured only for eCall, or a combination of TPS-eCall
and other service provision.
IVS.Req2 The NG-eCall system shall operate so long as the engine control is activated (ignition
switched on for thermal engine vehicles, other activation for electric, hybrid and stop/start
technologies). If the engine control is deactivated (ignition switched off for thermal engine
only vehicles) the NG-eCall system shall continue with any ongoing NG-eCall in progress, but
if there are no NG-eCall in progress the system may shut down at engine control
deactivation / ignition-off, although system manufacturers have the freedom to make other
provision of service after ignition off (CEN EN 16072). NG-eCall systems shall continue to
refresh the MSD so long as the engine control is activated / ignition is on, at a frequency to
be determined by the system manufacturers, but at a frequency of no less than once per
minute. In accordance with the latest revision of CEN EN 15722 (MSD), three location
positions within the last 15 seconds are required. The three location data elements of the
MSD shall reflect three locations within the previous 15 seconds.
IVS.Req3 An IVS which supports NG-eCall shall have reliable back-up power supply (such as a backup battery), capable of providing power to the IVS to perform two-way communication for
at least 60 minutes according to CEN EN16062.
IVS.Req4 An IVS which supports NG-eCall shall support both IPv4 and IPv6.
IVS.Req5 When an NG-eCall is issued, the IVS shall prepare the MSD compliant with the latest
published revision of CEN EN 15722 at the time of certification and include it in the initial
SIP Invite message to set up the call.
IVS.Req6 Considering that the IVS shall be also supporting the legacy CS communication profile, the
IVS responsible of the eCall system supporting NG-eCall shall be equipped with the
communication profile which supports thrusted connection to 3GPP infrastructure through
E-UTRAN (Evolved Universal Terrestrial Radio Access Network) for 3.5G and 4G access,
Page 49
or/and NG-RAN (Next Generation Radio Access Network) for 5G access. The IVS may support
connection via satellite access network.
IVS.Req7 An IVS supporting NG-eCall shall have the capability to automatically select the most
appropriate communication profile according to this HLAP standard and the IMS network
capabilities.
Figure 6: IVS supporting eCall using IMS required communication capabilities.
5.4.6 NG-eCall enabled PSAP Requirements
The following requirements apply to a PSAP for the NG-eCall system:
PSAP.Req1 To be “eCall enabled”, a PSAP needs to be equipped with the necessary hardware, a secure
internet connection, and a software application that can receive, process and make the
MSD contents immediately available to its operators. This can either be a dedicated eCall
application or integration in the existing PSAP application.
PSAP.Req2 An NG-eCall enabled PSAP shall conform in all respects to the high-level application
protocols as specified in CEN TS 17184 and an NG-eCall enabled PSAP shall also conform in
all respects to the high-level application protocols in CEN EN 16062 (to cover the event that
the NG-call reverts to a GSM/UMTS call because at the point of making the eCall an NGeCall is not viable).
PSAP.Req3 Since eCall/NG-eCall ‘arrive’ at the PSAP through specific mechanisms and provide MSD
data, the PSAP shall have the capability to manage them in a different way compared to
other 112 calls (e.g. from landlines). Such management strategies (e.g. assignment of
different priority, allocation to specific call takers etc.) should be defined locally as different
PSAPs have different organisational structures and policies.
PSAP.Req4 The call-handling is to be achieved in line with local/national procedures/regulations,
including the regulations on confidentiality.
PSAP.Req5 A PSAP which supports NG-eCall shall support both IPv4 and IPv6.
PSAP.Req6 A PSAP which supports NG-eCall shall also support legacy CS-eCall.
PSAP.Req7 A PSAP which supports NG-eCall may also support NG-eCall transfer/bridge to other PSAPs.
Page 50
PSAP.Req8 A PSAP which supports NG-eCall may also support invoking supplemental data and
database access services from ESInet if available.
5.4.7 The ESInet and its Core Elements Requirements
The following requirements apply to the ESInets and the elements located within or accessed from a
PSAP Service Provider infrastructure.
ESINET.Req1
ESInets, supporting NG-eCall, may be interconnected and shall be built upon
common functions, core elements and interfaces making ESInets interoperable.
ESINET.Req2
The eCall Regulations (Reg 305-2013 Article 6 and Reg 758-2105 Article 6)
determine that eCall data must be restricted. ESInet may provide communication
and ESInet functional elements may provide data exchange among authorized
representatives responsible for handling NG-eCall, e.g. among PSAPs, national
authorities like disaster relief office, emergency control centre, TPSP, first
responders, etc only in full compliance with these regulations.
ESINET.Req3
NG-eCall shall be presented by the Origination Network to the ESInet, possibly
through a Border Control Function (BCF) either directly to the PSAP or to an ESRP.
ESINET.Req4
ESInet Core elements shall have the capabilities to handle all NG-eCall as IP calls
(e.g. SIP) via specific purpose gateways connecting non-IP based IVS (e.g. Legacy
Gateway) and/or non-IP based PSAP (e.g. Legacy PSAP).
ESINET.Req5
ESInet Core elements shall implement the external interfaces to systems and
databases not in the PSAP that supply data and assistance in processing a NG-eCall.
(e.g. authorized representatives having vehicle data (EUCARIS), freight exchange (eCMR), traffic related data (DATEX II)).
ESINET.Req6
An ESInet may provide location-based routing and/or policy-based routing,
depending on whether it is an intermediate or terminating network. An ESRP, if
present in the ESInet, will be responsible for generating routing requests and using
the routing information provided in the responses to those requests to route the NGeCall forward. The ESRP might also provide default routing functions, when location
information is not present or specific enough for accurate routing. In addition, the
ESRP will provide backup routing functionality under conditions of network
congestion (e.g. PSAP overload, a specific element overload) or failure.
ESINET.Req7
ESInet and its Core elements shall have the capabilities to provide recording and
logging any type of communication.
ESINET.Req8
ESInet shall have the capabilities to convey any type (LGV, P2W) of MSD data by
values, alerting messages (according to CAP), SMS;
ESINET.Req9
ESInet shall provide sufficient QoS and capacity to support the MSD data together
with all referenced data, including video or other streaming/broadband services.
ESINET.Req10 Traffic management is essential, especially in cases where public and private
networks are affected, and the bulk of traffic is caused by the crises. Priority and
access restriction to emergency authorities shall be handled in a proper way.
ESINET.Req11 Data protection and privacy of all users should be considered. For all emergency
communication, data is protected according to its sensitivity level during
transmission, processing and storage and that access to communication channels
and critical systems is only granted to authorize persons. This includes
confidentiality of data, protection of signalling information, authentication of
Page 51
persons or devices, access authorization, integrity of data, non-repudiation, logging
records of communications.
5.4.8 NG-eCall Satellite connectivity requirements
The satellite connectivity requirements can be split into additional IVS requirements to support satellite
bearers, as well as satellite network operator requirements for integration with the IMS architecture
SatCom.Req1
The IVS shall support satellite connectivity through a GEO and/or MEO and/ or LEO
In-Vehicle System Satellite Terminal (IVST).
SatCom.Req2
The IVS should be safe to use by the vehicle occupants and those within its vicinity.
SatCom.Req3
The IVST shall support high quality data, video and IP multimedia services delivery
through the IMS
SatCom.Req4
The IVST shall be designed to be mounted on the vehicle roof top, or in a position to
be specified by vehicle OEM. The mounting location on the vehicle should be such
that the terminal meets the criteria in Req.3
SatCom.Req5
Through the IVST, the IVS shall support both satellite and terrestrial connectivity,
with priority to terrestrial service networks. Smart routing [ref1] utilizing both
satellite and terrestrial bearers is desirable, when IVS inherits smart routing
capabilities.
SatCom.Req6
The IVS shall provide an external wired service interface to the satellite terminal
based upon Ethernet (802.3 100/1000BaseT).
SatCom.Req7
The IVST shall be independently connected to an external power supply interface
from the vehicle's electric system.
SatCom.Req8
On the uplink, the IVST emission levels should be kept within the frequency
dependent ETSI and ITU-R limitations (i.e. ETSI EN 303 978).
SatCom.Req9
The IVST shall comply with specific functional, design, power, performance and
environmental requirements in order to align with Req.3.
SatCom.Req10 The IVST shall not cause EMC interference to the electrical equipment of the vehicle.
SatCom.Req11 The IVST shall support end to end secure service delivery (authentication, integrity,
confidentiality) over both satellite and terrestrial networks.
SatCom.Req12 The IVST modem should support the Session initiation protocol.
SatCom.Req13 NG-eCall messaging shall be transparent to the authentication procedures of
satellite operator network. No billing should be applied, to terminal emissions.
SatCom.Req14 The NG-eCall video and audio communication shall be provided with the highest
capacity request for critical applications, as defined in DVB RCS2 standards (ETSI EN
301 545-2)
SatCom.Req15 TCP acceleration should be employed between IVST and hub communication. In
addition to TCP acceleration, header compression techniques should be employed
to further improve the efficiency of the satellite link.
SatCom.Req16 IP-Sec or AES256 should be used in the satellite link (from the IVST to the hub). For
optimum performance under TCP acceleration, AES256 shall be used as IPsec
encryption encapsulating TCP messages.
Page 52
SatCom.Req17 Ground station hub should be compatible with multiple spot beams to optimize link
and coverage, supporting high QoS service. In addition, the primary hub should
support management functionality and support multi-network functionality.
SatCom.Req18 The hub output data shall be securely IPSEc encrypted and routed towards the ePDG
gateway of the MNO EPC network where is subsequently diverted to IMS P-CSCF
(Call Session Control Function)
SatCom.Req19 If available, the satellite operator may connect directly to a proprietary IMS
framework. Otherwise, the data should be merged with existing IMS enabled Core
Network
SatCom.Req20 The data flow in the forward link (hub to IVST) should follow the DVB-S2X standard.
The return link should employ a MF-TDMA scheme according to DVB-RCS2 standard.
This is to optimize the link capacity under various channel conditions, regulate the
optimizing inbound transmissions and provide IP connectivity to external networks.
SatCom.Req21 The emergency response channel (forward link) shall have a minimum capacity of
10 Mbps per site. The return channel shall have an uplink throughput equal or above
1 Mbps.
SatCom.Req22 The emergency response channel (forward) should have a minimum capacity of
20M bps per site. The return channel shall have an uplink throughput equal or above
5 Mbps.
SatCom.Req23 The link availability of 99.9% shall be provided at both forward and return link
during an NG-eCall session.
SatCom.Req24 Dual Site diversity shall be supported at the hub (gateway). In the event of deep
fading at the prime site RF over fibre shall be used for connectivity with the
secondary station.
SatCom.Req25 Both ground stations should employ power control to optimize connectivity based
on atmospheric attenuation to optimize link throughput.
SatCom.Req26 At the network edges of the satellite operator and the MNO core, universal edge
routers shall be employed having hardware and software redundancy features. The
router will direct the data flow to the secure gateway on the MNO core (ePDG).
SatCom.Req27 10 Gbps optical Ethernet interfaces should be deployed between on the networks'
edges. This infrastructure can be supported by the satellite operator, the MNO or a
third-party ISP.
SatCom.Req28 To access the EPC network, an untrusted non-3GPP access should be established
between the satellite ground station hub and the MNO secure gateway.
SatCom.Req29 To switchback to terrestrial operation, the IVS continuously tries to re-establish
connectivity to the terrestrial network - it continues diverting traffic through the
satellite link - until the primary link becomes operational.
SatCom.Req30 To improve link stability, a timer needs to be set to include a stability period after
which the switchback will happen. A similar process shall be followed for switchover
operation.
Satellite and 5G connectivity requirements:
SatCom.Req31 The satellite access network shall access the 5G core network over untrusted non3GPP access (ETSI TS 123 501).
Page 53
SatCom.Req32 Non-3GPP access networks shall be connected to the 5G Core Network via a Non3GPP Interworking Function (N3IWF). The N3IWF interfaces the 5G Core Network
control and user plane functions via N2 and N3 interfaces, respectively.
SatCom.Req33 Through the IVST, the IVS shall establish an IPSec tunnel with the N3IWF to attach
to the 5G core.
SatCom.Req34 After attachment, the IVS shall support NAS signalling with 5G core control plane
functions using the N1 reference point.
SatCom.Req35 Multiple N1 instances shall be supported by the IVS (i.e. one for the NG-RAN and
one over the satellite).
SatCom.Req36 It shall be possible to maintain the IVS NAS signalling connection with the AMF over
the satellite RAN access after all the PDU Sessions for the IVS over that access have
been released or handed over to 3GPP access.
SatCom.Req37 NG-eCall data flow plane should be supported over the highest QoS between the IVS
and N3IWF as described in ETSI TS 123 502.
5.4.9 NG eCall enabled Data Requirements
The following requirements apply to data/information for the NG eCall system:
DATA.Req1
The data-handling is to be achieved in line with local/national
procedures/regulations, including the regulations on confidentiality, security and
privacy.
DATA.Req2
Some elements within MSD data that are associated with the NG-eCall could be
carried “by-Value” or “by-Reference”. If carried “by-Reference” a successful dereference of the identifier will result in providing data “by-Value”.
DATA.Req3
The MSD is defined in CEN EN 15722. The MSD for NG-eCall is identical to that for
CS-eCall.
Optional additional data fits within the OAD section of the MSD and does not
change the length of the OAD.
CEN TS 17249-2 defines OAD for LGV. In the case of CEN TS 17249-2 OAD contains
actual data and may also contain a reference to a location where that data is
available as defined in CEN TS 16405).
CEN TS 17249-3 defines OAD for coaches & Buses.
CEN TS 17249-4 defines OAD for agricultural vehicles.
CEN TS 17249-5 defines OAD for P2WV and some other variations.
CEN TS 17249-3 contains actual data and may also contain a reference to a location
where that data is available.
DATA.Req4
DATA.Req5
DATA.Req6
DATA.Req7
DATA.Req8
DATA.Req9
5.4.10 NG-eCall enabled Security/Privacy Requirements
The following requirements apply to security/privacy for the NG-eCall system:
SECPRIV.Req1 IVS device hardening is in such a way that it includes Security by Design
comparable to the standards accepted and adopted by OEM devices.
SECPRIV.Req2 IP-CAS, IMS or vIMS must be secured according to latest industry standards.
SECPRIV.Req3 ESInet protection against DoS and DDoS attacks or any other SIP attacks.
SECPRIV.Req4 PSAP systems must have built-in security mechanisms according to corporate
security standards and best practices (e.g. security hardening, patching/updating,
incident detection and response, etc.).
Page 54
SECPRIV.Req5 The eCall Regulations determine that eCall data must be restricted (Regulation
305-2013 Article 6 Rules on privacy and data protection and Regulation 758-2105
Article 6 Rules on privacy and data protection).
5.4.11 Freight and other additional Information from external databases
The following requirements apply to the access to freight information from external databases:
EXTDB.Req1
Information provided from the external database shall be ‘machine interpretable’
– a scanned pdf as it is provided today is not acceptable.
EXTDB.Req2
Information shall either be sent in human readable form, or automatically be
translated into this.
EXTDB.Req3
Information shall be concise and well structured.
EXTDB.Req4
Information shall be accurate and up to date.
EXTDB.Req5
The information provided should at least include the following information:
1. Vehicle Cargo
• Contains Dangerous Goods?
• If yes:
o
UN-Number
o
Quantity
o
Packaging danger level code (optional)
o
Kemmler Code (optional)
• If no:
o
Quantity
o
Type of good (optional)
• Regardless:
o
Phone number of Expert (optional)
o
Sender details (optional)
o
Receiver details (optional)
EXTDB.Req6
The PSAP should use the access protocol as defined in the protocol id field of the
MSD OAD. The PSAP should support all protocols that are defined as mandatory.
EXTDB.Req7
Only certified PSAPs are allowed to access the external databases.
EXTDB.Req8
A PSAP is only allowed to request data from an external database when NG-eCall
was received.
EXTDB.Req9
To ensure that a request is only made in case an NG-eCall was received, the
exchange protocol should involve one or more key elements that come from the
MSD provided by an IVS in a vehicle and are not otherwise known, other than by
the freight information service provider. A random number serves this purpose, but
well-known keys like VIN or the license plate number cannot be used as a key
(although the key can be the VIN encrypted with the private key of the service
provider).
Page 55
Page 56
6 ARCHITECTURE MODEL AND REFERENCE POINTS
6.1 Deployment scenarios for NG eCall architectures
IMS standards for Emergency Services have been under development and enhancement in 3GPP since
3GPP Release 9. From the Next Generation Emergency Services (NG112 ESInet) network perspective,
the IMS architecture only defined Emergency Service call processing for the originating network.
However, 3GPP R15 standards for Emergency services define NG emergency network architecture that
may deliver NG-eCall service from IVS to PSAP endpoints.
The purpose of this document is to examine and define the architecture and reference points of 3GPP
IMS-based Emergency Network architecture to enable pan-European deployment of NG eCall service
considering two possible deployment scenarios, e.g.
a) IMS Core Network as Emergency Service Network for NG-eCall service;
b) IMS Core Network as originating network to NG112 ESInet.
6.2 IMS Core Network as Emergency Service Network for NG eCall service
The Figure 7 shows a reference architecture of an Emergency Service Architecture for eCall service
based on 3GPP R15 reference architecture for IMS emergency sessions.
MSC
CS
eCall
CS Voice/
inband
modem
CS Voice/
Inband
modem
CS or PS Core Networks
2G/3G
CS Access
Network
ss7CS Core
ss7
LNG
CS
eCall
CS Voice
I6
MGW
ici
MGCF*
IP-CAN
IVS
Un-trusted*
PS Access
Network
(e.g. SATCOM)
NG
eCall
Uu
Mg
Mx
I-CSCF
Mi
EATF
Gm
izi
Mw
Mx
I4
Gm
P-CSCF
AS
PSAP
Mj
BGCF
I5
Uu
3GPP
PS Access
Network
(3.5G/4G/5G)
ss7
IBCF
Mw
E-CSCF
Mw
Mw
ISC
Mx
Mi
IBCF
NG
eCall
ici
MX
S-CSCF
Cx
Sh
HSS
LRF
Sh
Le
Ix
Iq
RTP
Iq
BGW
Mb
PS Voice
CS Voice (inband MSD)
SS7/ISUP
Figure 7: IMS Core as Emergency Service Network for NG eCall.
6.2.1 Reference Points
Emergency services as NG-eCall are using following reference points between different IMS entities and
other IP Networks:
•
Gm is a reference point between a UE and P-CSCF. See ETSI TS 123 228.
•
Ici is a reference point between two IBCFs belonging to different networks. See ETSI TS 123 228.
Page 57
•
Mb is a reference point between UEs and network elements that interact with the bearer. See
IETF RFC 3550, IETF RFC 768 and IETF RFC 4961.
•
Mi is a reference point between a S-CSCF/E-CSCF and BGCF. See ETSI TS 123 228.
•
Mg is a reference point between a S-CSCF/I-CSCF/E-CSCF and MGCF. See ETSI TS 123 228.
•
Mn is a reference point between a MGCF and MGW. See ETSI TS 129 332.
•
Mm is a reference point which supports exchange of messages between IMS and external IP
networks and is located between a CSCF and IBCF. See ETSI TS 123 228.
•
Mx is a reference point between a E-CSCF/I-CSCF and BGCF. See ETSI TS 123 228.
•
Mw is a reference point between a P-CSCF, I-CSCF, S-CSCF and E-CSCF. See ETSI TS 123 228.
•
ISC is a reference point between a AS and I-CSCF/S-CSCF. See ETSI TS 123 228.
•
I4 is a reference point between an E-CSCF and an EATF. See ETSI TS 123 237.
•
I5 is a reference point between an I-CSCF and an EATF. See ETSI TS 123 237.
•
I6 is a reference point between an MSC Server enhanced for ICS and E-CSCF. See ETSI TS 123
292.
•
Iq is a reference point between a IMS-ALG and another IMS-ALG and provides information to
allocate, modify and release media paths between the IP-CAN and IMS core. See RFC 3015.
•
Ix is a reference point between IBCF and TrGW or CS-IBCF and CS-TrGW. See ETSI TS 129 238.
•
Izi is a reference point between a TrGW and another TrGW or media handling node belonging
to a different IMS network. See ETSI TS 129 165.
•
Cx is a reference point between CSCF and HSS. See ETSI TS 123 228.
•
Sh is a reference point between LRF pr AS and HSS. See ETSI TS 123 228.
•
Uu is a is the radio interface between the eNodeB and the User Equipment. It is defined in ETSI
TS 136 300.
6.2.2 Functional Description of IMS functional entities
6.2.2.1
Emergency-CSCF
-
Receive an emergency session establishment request from a P-CSCF or an S-CSCF.
-
If the IVS does not have credentials, a non-dialable call-back number shall be derived where
required by local regulation.
-
If location information is not included in the emergency request or additional location
information is required, the E-CSCF may request the LRF to retrieve location information as
described in ETSI TS 123 167 clause 7.6 Retrieving Location information for Emergency
Session.
-
If required, the E-CSCF requests the LRF to validate the location information if included by
the IVS.
-
Determines or queries the LRF for the proper routing information/PSAP destination.
-
Route emergency session establishment requests to an appropriate destination including
anonymous session establishment requests.
Page 58
-
Subject to local regulation, the E-CSCF may send the contents of the P-asserted ID or IVS
identification to the LRF.
-
Based on operator policy, the E-CSCF may route the emergency IMS call to ECS for further
call process.
-
For supporting SRVCC and/or DRVCC, See ETSI TS 123 237 and ETSI TS 123 216, the E-CSCF
forwards the session establishment request to the EATF in the serving IMS network for
anchoring.
-
Generation of CDRs.
-
For an NG-eCall and if an LRF/RDF is not deployed, the E-CSCF may use an indication of an
automatic eCall or a manual eCall to assist routing of an emergency session establishment
request.
-
For supporting emergency session request from MSC Server enhanced with ICS, See ETSI TS
123 292. E-CSCF follows the same procedure as defined for handling emergency session
request from P-CSCF.
6.2.2.2
Proxy-CSCF
-
Handle registration requests with an emergency registration indication like any other
registration request, except that it may reject an emergency registration request if the IM
CN subsystem that the P-CSCF belongs to cannot support emergency sessions for the IVS
(e.g., due to operator policy or IVS is not within IM CN subsystem's geographical area or IPCAN not supported).
-
Detect an emergency session establishment request.
-
Reject/allow unmarked emergency requests.
-
Reject/allow anonymous emergency requests.
-
Prevent non-emergency requests that are associated with an emergency registration.
-
May query IP-CAN for location identifier.
-
May query IP-CAN for additional subscriber related identifier(s).
-
Select an Emergency CSCF in the same network to handle the emergency session request.
The selection method is not standardized in the ETSI TS 123 167.
-
Alternatively, for non-roaming subscribers and when the request is received over a nonemergency registration, the P-CSCF may forward an emergency session to an S-CSCF if so
instructed by operator policy or local regulation.
-
Do not apply emergency session detection if requested using private network traffic and
forward the session to the S-CSCF, except if operator policy requires the P-CSCF to detect
emergency session requests and treat detected emergency session requests as if they are
part of public network traffic.
-
For IVSs without credentials, forward the equipment identifier to the E-CSCF that was
received from the IVS.
-
For IVSs without credentials and subjected to local regulation, forward the additional
subscriber related identifier(s) received from IP-CAN to the E-CSCF.
-
Prioritize the emergency session.
Page 59
-
May respond to an IVS with an emergency service indication as a result of detecting a non
IVS detectable emergency session establishment request
-
May respond to the IVS with an indication, IMS emergency registration required as a result
of processing the emergency session establishment attempt.
-
Should be able to identify the service data flow associated with emergency service and
inform PCRF accordingly.
-
Upon IMS registration failure the P-CSCF may indicate to the IVS whether anonymous IMS
emergency sessions are supported.
6.2.2.3
Serving-CSCF
When the S-CSCF receives an Emergency Registration, the S-CSCF determine the duration of the
registration by checking the value of the Expires header in the received REGISTER request and based on
local regulation or operator policy of the serving system.
NOTE 1: The value of the emergency registration time is subject to local regulation and can be subject
to roaming agreements.
The emergency registration shall be handled as normal IMS registrations with the following
considerations:
-
-
Upon emergency registration:
-
If a normal registration for the user does not exist, the S-CSCF shall download
corresponding user profile from HSS to ensure that HSS allocates S-CSCF name to
this subscriber and the registration status is set to UNREGISTERED.
-
Otherwise, S-CSCF shall ensure that the registration status of the user is not
changed in the HSS.
Upon deregistration or expiration of the last normal session:
-
-
If an emergency registration for the user still exists, the S-CSCF shall ensure that the
HSS keeps S-CSCF name allocated to this subscriber and the registration status is set
to UNREGISTERED.
Upon expiration of an emergency registration:
-
If a normal registration for the user still exists, the S-CSCF shall ensure that the
registration status of the user is not changed in the HSS.
-
Otherwise, the S-CSCF can either de-register the user in HSS or keep the registration
status of the user unchanged in the HSS.
When an S-CSCF receives a session initiated by a non-roaming subscriber marked as emergency session
from a P-CSCF, the S-CSCF:
-
performs caller authentication in the same way as for any other sessions;
-
if required, uses filter criteria to route to AS;
-
and forwards the request to an E-CSCF.
When an S-CSCF receives a session marked as emergency session from an AS, the S-CSCF:
-
- if required, uses filter criteria to route to another ASs;
-
- and forwards the request to an E-CSCF.
Page 60
NOTE 2: The AS can initiate an emergency request on behalf of a non-roaming user, can convert private
network traffic to public network traffic, or can interpret a number in private numbering plan and
detect that the request is for emergency session.
NOTE 3: Reception of a session initiation request marked as an emergency session from a P-CSCF and/or
an AS by the S-CSCF is only expected over a non-emergency registration.
6.2.2.4
Interrogating-CSCF
I-CSCF supports IMS emergency session continuity which is specified in ETSI TS 123 237.
6.2.2.5
Location Retrieval Function (LRF)
The Location Retrieval Function (LRF) is responsible for retrieving the location information of the UE
that has initiated an IMS emergency session. It shall be possible to support configurations where the
Location Retrieval Function (LRF) may consist of a Routing Determination Function (RDF) and a LS, the
interface between Location Server and RDF is out of scope of this specification. For non-roaming UEs,
if the LRF is configured then it may interact with HSS to provide an NPLI before interacting with the
RDF.
The LRF utilizes the RDF to provide the routing information to the E-CSCF for routing the emergency
request. The RDF can interact with a LS and manage ESQK allocation and management. The ESQK is
used by the PSAP to query the LRF for location information and optionally a call-back number. The LRFPSAP interactions are outside the scope of this specification.
Information provided by the LRF to the E-CSCF includes the routing information and other parameters
necessary for emergency services, which are subject to local regulation. For example, this information
may include the ESQK, ESRN, location number, PSAP SIP-URI or TEL-URI.
In order to provide the correct PSAP destination address to the E-CSCF, the LRF may require interim
location information for the UE.
It may be a requirement to provide the PSAP with an accurate initial location estimate for the UE and
possibly to provide an accurate updated location estimate for the IVS if requested by the PSAP. When
this requirement exists, the LRF may store a record of the emergency session including all information
provided by the E-CSCF and shall only release this record when informed by the E-CSCF that the
emergency session has terminated. The information provided by the LRF to the E-CSCF (e.g. ESQK) shall
then include correlation information identifying both the LRF and the emergency session record in the
LRF. This correlation information shall be transferred to the PSAP during session establishment (e.g. in
a SIP INVITE or via SS7 ISUP signalling from the MGCF). The PSAP may use this information to request
an initial location estimate from the LRF and/or to request an updated location estimate.
6.2.2.6
Emergency Access Transfer Function (EATF)
The EATF provides IMS emergency session continuity which is specified in ETSI TS 123 237.
6.2.2.7
AS
An AS can be involved in emergency session handling (e.g. for emergency sessions made via hosted
enterprise services ETSI TS 182 024, or for AS initiated session).
NOTE 1: The participation of an AS in emergency session handling is only expected over a nonemergency registration. Before NG eCall session emergency registration should be done.
6.2.2.8
HSS
In the course of an emergency registration, the HSS shall not apply any barring condition and/or
roaming restriction associated with the Public User Identity received in the emergency registration
request.
Page 61
The emergency registration shall be handled with the considerations defined in ETSI TS 123 167 clause
6.2.4.
6.2.2.9
Media Gateway Control Function (MGCF)
For NG-eCall MGCF handles the emergency session as normal emergency call establishment.
NOTE: The MGCF does not forward the initial MSD, if received in the emergency session request.
6.2.2.10 IBCF
-
Forward emergency session establishment requests.
-
Prioritize the emergency session based on operator policy.
6.2.2.11 MSC Server enhanced with ICS
The MSC Server enhanced with ICS may provide interworking mechanisms to support emergency call
using CS media bearer and using IMS for routing/handling the emergency call toward PSAP. From the
viewpoint of E-CSCF, MSC Server enhanced with ICS behaves like a P-CSCF. Further details on MSC Server
procedure are defined in ETSI TS 123 292.
6.2.2.12 Breakout Gateway Control Function
BGCF processes requests for routing from an S-CSCF for the case were the S-CSCF has determined that
the session cannot be routed using DNS or ENUM/DNS as specified in ETSI TS 123 228.
6.2.3 NG e-call IMS over satellite through EPC
Figure 8. Architecture for NG e-call IMS over satellite through EPC network
The untrusted non 3GPP satellite access transmission enters the EPC network through the ePDG
element. The ePDG uses IKEv2 signalling to establish IPSec tunnels between the in-vehicle system and
the ePDG through the untrusted non-3GPP IP access network, the SWu interface. It also supports the
negotiation of configuration attributes such as IP address, DNS, and P-CSCF in the Configuration
Parameters payload of IKE authorization request and response messages. The satellite terminal should
be configured to employ as destination address the ePDG network of the core network.
In the case that the satellite service does not provide internet connectivity, it can operate as a backhaul
where the IVS will communicate as a Wi-Fi access point and all Wi-Fi user traffic will be transferred
through the satellite backhaul to an Internet gateway at the core network and sequentially to the ePDG
element, through the processes of Wi-Fi calling.
Page 62
The ePDG communicates directly with the PGW through the PMIPv6/GTPv2 S2b interface. The
interface to the 3GPP Diameter AAA server, the SWm interface will be used for authentication. It
supports the transport of mobility parameters, tunnel authentication, and authorization data. The EAPAKA (Extensible Authentication Protocol - Authentication and Key Agreement) method is used for
authenticating the IVS over this interface. User plane data flow is established between the ePDG and
the PGW, whereas control plane data flow is employed between the ePDG and the AA.
Table 6-1 Reference points for untrusted non-3GPP IVS connectivity (EPC).
Reference Point
Description
SWu
The SWu interface transfers IPSec tunnels by utilizing IKEv2 signalling to
establish IPSec tunnels between the IVS and the ePDG. It is also used to support
the various configuration attributes such as IP address, DNS, and P-CSCF in the
Configuration Parameters payload of IKE authorization Request and Response
messages.
SWm
The 3GPP AAA server provides IVS authentication via the EAP-AKA (Extensible
Authentication Protocol - Authentication and Key Agreement) authentication
method through the SWm interface. ePDG facilitates the exchange of
authentication parameters between the IVS and AAA server. EAP is the payload
to the IKEv2 message/response sent from user to ePDG. SWm supports both
TCP and SCTP protocols
S2b
The ePDG interface to the P-GW is the S2b interface that runs PMIPv6 (Proxy
Mobile IP version 6)/GTPv2 protocol to establish sessions with the P-GW. It also
supports the transport of P-CSCF and DNS attributes of the ‘Create Session
Request’ and ‘Create Session Response’ messages as part of the P-CSCF
discovery performed by the IVS
6.2.4 NG e-call IMS over satellite through 5G Core Network
Figure 9. Architecture for NG e-call IMS over satellite through 5G Core Network.
The untrusted non 3GPP satellite access transmission, enters the 5G Core network through the non3GPP internetworking function element N3IWF. Like the EPC network, the N3IWF uses IKEv2 signalling
Page 63
to establish IPSec tunnels between the in-vehicle system and the N3IWF. The UE performs registration
to the 5G core network during the IKEv2 SA establishment procedure as specified in ETSI TS 124 501
and IETF RFC 7296.
After the registration, the UE supports NAS signalling with 5GCN using the N1 reference point as
specified in ETSI TS 124 501. The N3IWF interfaces to the 5G Core Network control and user plane
functions via the N2 (IN3IWF to AMF) and N3 (N3IWF to UPF) interfaces, respectively. The NWu
interface (Reference point) is established between the in-vehicle system and N3IWF for establishing
secure tunnels, so that control-plane and user-plane exchanged between the UE and the 5G Core
Network is transferred securely over untrusted non-3GPP access.
Table 6-2. Reference points for untrusted non-3GPP IVS connectivity (5G Core).
Reference Point
Description
N1
Reference point between IVS(UE) and AMF
N2
Interface between N3IWF and CP function (AMF)
N3
Interface between N3IWF and UP function (UPF)
NWu
Reference point between the UE and N3IWF for establishing secure tunnel(s)
between the UE and N3IWF so that control-plane and user-plane exchanged
between the UE and the 5G Core Network is transferred securely over
untrusted non-3GPP access.
N6
Reference point between UPF and IMS
N11
Reference point between AMF and SMF
Rx/N5
Reference point between PCF and P-CSCF to enable IMS service
Figure 10. Architecture for NG e-call IMS over satellite where IMS is integrated within the satellite network operator
network.
The Network Attachment Subsystem (NASS) provides registration at access level and initialisation of
user equipment for accessing IMS service. The NASS provides network level identification and
authentication, manages the IP address space of the Access Network and authenticates access
Page 64
sessions. The NASS also announces the contact point Applications Subsystems to the IVS-through the
satellite terminal (the proxies and application servers that enable specific services). These will be used
subsequently for individual subscriber sessions to be initiated over the satellite core network without
direct implication of the NCC except that is being used for resource management.
The Resource and admission control subsystem (RACS) is responsible for policy-based resource
reservation and admission control (unicast and multicast). The RACS also supports Network Address
and Port Translation (NAPT) at the edge of the satellite core network. Furthermore, the RACS covers
aspects related to the setting and modification of traffic policies, end-to-end QoS and transport-level
charging. For the emergency services, the RACS will be used to reassign resources in order to prioritize
emergency traffic through communication with satellite core network control centre. The process data
flow is described in ETSI TS 102 855 V1.1.1.
Reference Point
Description
a1
The Network Access Configuration Function of the NAAS is responsible for the
IP address allocation to the UE. It may also distribute other network
configuration parameters such as address of DNS server(s), address of signalling
proxies for specific protocols (e.g. address of the P-CSCF when accessing to the
IMS).It id the interface communications with Management centre (NMC) so
that the latter releases adequate resources to UE
a3
NMC requests the NASS for user authentication and network subscription
checking
e4
Communications between RACS and NASS so that RACS verifies network
credentials and communicates with RCEF to impose specific policies and packet
classification rules.
Re
RACS receives requests for QoS resources from RCEF. Based on these requests
and policy information stored in the A-RACF, the A-RACF may accept or reject
these requests for the transport resources within its control.
Gq’
IMS offers services that require control of IP bearer resources. P-CSCF maps the
application layer QoS Information, e.g. the P-CSCF maps parameters defined in
SDP, into QoS request information to be sent via the Gq' reference point to the
RACS subsystem .
6.3
NG-eCall over ESInet including IMS Core as originating network
The Figure 11 shows a reference architecture of NG-eCall based on EENA NG 112 Emergency Service
Network Architecture and ETSI EM-TEL pre-standard document about the Core elements for network
independent access to emergency services. The NG-eCall emergency sessions originate from CS or PS
access networks. ESInet could be also implemented using IMS functional elements.
Page 65
Figure 11 : High-Level Emergency Services Network architecture with functional entities for NG-eCallThe ESInet reference
points and protocols
NG-eCall as an Emergency service is using following reference points and interfaces between different
ESInet functional elements and other IP Networks (e.g. IMS networks, PSAP networks):
•
SIP interface
SIP interface is between BCF and (ESRP or LNG or LPG or NG-eCall PSAP elements) that defines
transport and signalling capabilities as specified in RFC 8446 [38], RFC 3261[37] and RFC 8147
[36]. Each SIP session initiation message response should describe the media using Session
Description Protocol as defined in RFC 4566 [40].
•
Ici
The Ici reference point of IMS network is used by the IBCF to deliver emergency sessions
requests toward the PSAP via the BCF. This reference point uses the SIP protocol. See ETSI TS
123 228.
•
Izi
The Izi reference point of PS (IMS) network is used by the BGW to forward media streams
toward the PSAP via the LNG. This reference point uses the RTP protocol. See ETSI TS 129 165.
•
RTP interface
Used as interface between BCF and (LNG or LPG or NG eCall PSAP elements) that defines media
transport capabilities and media types for audio, video and real-time text as specified in RFC
3550 [41]. All media processing elements should implement media security with SRTP as
defined in RFC 3711 [42] and SDES as defined in RFC 4568 [43]. SRTP security should be
requested in all calls originated within an ESInet. RTCP as defined in RFC 3550 [41] shall be, and
SRTCP as defined in RFC 3711 [42] should be supported within the ESInet.
Note: Media streams may be carried also on RTSP over UDP.
Page 66
•
HELD interface
HTTP Enabled Location Delivery is used as interface between BCF, LNG, LPG, E-CSCF (LIS) and
NG eCall PSAP elements that provides location information from access network as specified in
ETSI TS 103 479[12].
•
CAP interface
Common Alerting Protocol is the interface between BCF, SDS and NG eCall PSAP elements to
deliver supplementary data from different resources required by NG eCall PSAP. It is a format
of information that ensures easy extension for future data systems or agencies interconnected
to SDS. According to NG 112 LTD 1.1. [48] CAP protocol is also intended to be used to exchange
data between agencies without a call.
•
LoST interface
Location to Service Translation protocol is an interface between ESRP, ECRF, LNG, LPG
elements that is used for call routing and location validation (out of scope) and should be
implemented according to NG 112 LTD 1.1. [48].
•
SS7interface
SS7 is the protocol between a legacy network and LNG or LPG and network toward CS eCall
PSAP. It is signalling protocol, defined in the International Telecommunication Union (ITU) ITUT REC. Q761, Q762, Q763, Q764 and specifics as defined in NG 112 LTD 1.1. [48].
6.3.1 The ESInet Functional Elements
The functional description of the ESInet functional elements in the Figure 11 are as following:
6.3.1.1
Border Control Function (BCF)
A BCF sits between Origination networks (e.g. IMS network) and the ESInet and between the ESInet
and NG PSAP networks to perform the interconnection between two operator domains. The BCF
comprises several distinct elements pertaining to network edge control, SIP message handling and
media forwarding (RTP relay):
•
•
Border Firewall for inspecting ingress and egress traffic running through it with the typical
roles of network and/or application layers firewalls;
Session Border Control to control borders to resolve multiple VoIP related problems such as
Network Address Translation (NAT) or firewall traversal.
6.3.1.2
Emergency Call Routing Function (ECRF)
In ESInet, emergency calls will be routed to the appropriate PSAP based on the location of the caller.
The ESInet functional element responsible for providing the routing information is the Emergency Call
Routing Function (ECRF). In short, the ECRF takes the location information and Service URN received
in a routing query and maps it to the destination URI for the call. The LoST protocol supports this
functional interface in ESInet. The LoST protocol is flexible and defined with many options that are not
all required to support emergency call routing.
6.3.1.3
Emergency Services Routing Proxy (ESRP)
The ESRP is the base routing function for emergency calls. The function of the ESRP is to route a call to
the next hop. It might be possible that one or more "Intermediate ESRPs" will exist at various
hierarchical levels in the ESInet. The ESRP will speak SIP and perform functionalities such as to:
•
Evaluate a policy “rule set” for the queue the call arrives on
Page 67
•
•
Query the location-based routing function (ECRF) with the location included with the call to
determine the "normal" next hop URI
Evaluate a policy rule set for that URI using other inputs available to it such as headers in the
SIP message, time of day, PSAP state, etc.
6.3.1.4
Legacy Network Gateway (LNG)
For the transition period the ESInet will employ a Legacy Network Gateway (LNG) at the
interconnection point between the ESInet that uses SIP signalling and a legacy network provider that
has the SS7 signalling. It allows NG eCall PSAPs to receive emergency calls from legacy originating
networks. It is a signalling and media interconnection point between callers in legacy wireless/wireline
originating networks and the NG architecture.
The Legacy Network Gateway is also responsible for routing emergency calls to the appropriate ESRP
in the ESInet. To support this routing, the Legacy Network Gateway must apply specific interworking
functionality to legacy emergency calls that will allow the information provided in the call setup
signalling and in-band MSD to be used as input data for the retrieval of location information.
The Legacy Network Gateway uses this location information to query an ECRF, to obtain routing
information in the form of a URI. Based on URI provided by ECRF, the Legacy Network Gateway then
forwards the call/session request to an ESRP in the ESInet and includes call-back and location
information in the outgoing signalling.
The Legacy Network Gateway functional element contains three functional components- LIF, PIF and
NIF. These functional components are described below.
6.3.1.5
Legacy PSAP Gateway (LPG)
The ESInet will employ a Legacy PSAP Gateway (LPG) at the interconnection point between the ESInet
and a PSAP that is not yet capable of NG112 call handling. It is a signalling and media interconnection
point between an ESInet and a legacy PSAP. It plays a role in the delivery of emergency calls that
traverse an ESInet to get to a legacy PSAP, as well as in the transfer and alternate routing of emergency
calls between legacy PSAPs and NG PSAPs.
The Legacy PSAP Gateway supports an IP (i.e., SIP) interface towards the ESInet on one side, and SS7
or BRI/PRI on the other legacy side.
If the emergency call routed via the ESInet contains a location by value, the Legacy PSAP Gateway
responds with that value. If the ESInet provides a location by reference, the ALI query to the Legacy
PSAP Gateway results in a dereference operation from the Legacy PSAP Gateway to the LIS or Legacy
Network Gateway.
The LPG must also apply specific interworking functionality that will provide MSD in-band transfer
support legacy interface.
The Legacy PSAP Gateway functional element consists of the three functional components PIF, NIF and
LIF, as illustrated in the Figure 11.
•
Protocol Interworking Function (PIF).
The PIF functional component of the LNG performs a standard interworking function that converts the
incoming SS7 protocol from the legacy network to the SIP protocol expected by the ESInet and also it
converts the incoming TDM voice to the RTP data required by the ESInet. Moreover, to eCall type of
emergency calls it provides also decoding of in-band transferred MSD and conveying it forward as
MIME body part within SIP message. The PIF as functional component for LPG interworks the SIP
protocol to traditional SS7 or ISDN and other protocols, as appropriate for the interconnected PSAP. It
Page 68
allows the MSD information conveyed in SIP messages to be converted and encoded as in-band signal
to allow legacy CS eCall PSAPs to receive it in the acceptable form.
•
NG specific Interwork Function (NIF).
This functional component provides NG eCall 112 specific processing of the call signalling, which
includes special handling of available location information, selection of trunk groups, identification of
the ESRP address (i.e., via a query to the ECRF), and call-back number mapping, etc. This functional
component should be viewed as a Back-to-Back User Agent (B2BUA) in front (from the perspective of
the ESINet) of the PIF.
The NIF is also responsible for taking any non-location call information provided by the LIF and
generating a data structure that contains additional data about the call, along with a pointer/reference
to that data structure.
•
Location Interwork Function (LIF).
At the request of the NIF, the LIF will invoke location retrieval functionality to obtain the location
information that will be used as the basis for call routing and that will be delivered to the PSAP.
Specifically, the LIF will query an associated location server/database.
6.3.1.6
Location Retrieval Function and Location Information Server (LRF/LIS)
For Location Retrieval Function definition see the Clause 6.2.2.5 . A Location Information Server (LIS)
is a functional element that provides locations of endpoints. A LIS can provide Location-by-Reference,
or Location-by-Value, and, if the latter, in geo or civic forms. A LIS can be queried by an endpoint for
its own location, or by another entity for the location of an endpoint. In either case, the LIS receives a
unique identifier that represents the endpoint, for example an IP address, circuit-ID or MAC address,
and returns the location associated with that identifier. The LIS is also the element that provides the
dereferencing service, exchanging a location reference for a location value.
6.3.1.7
Supplemental Data Access Services (SDS)
Supplemental Data Access Services (SDS) are the single point of access to the external data sources
(Databases and Database Access Services) that provide information requested by NG eCall PSAPs or
any other entities/services in the ESInet. One of the most relevant protocol to access and exchange
data is the CAP protocol, also seen in the Figure 11. Based on the user access rights SDS provides
supplemental data for emergency services handling. The most relevant data for NG-eCall service will
be offered by a wide variety of internal and external databases or agencies like ECMR, EUCARIS or
DATEX2 via national or European access points in accordance with national and/or international policy.
Page 69
7 Conclusions
This deliverable aims at specifying the Reference Architecture for eCall over IMS and presents the results
of the activity carried out by the sAFE project team in the Sub-activity 2.2, focused on the processing
and delivery of the eCall over IMS.
In the frame of the evolution and extension of the eCall service provision, Next Generation NG112 eCall
deployment will have to enable a seamless operational transition from the current CS-based
architecture relying on legacy 2G networks to a full support of the PS-based architectures. Therefore,
to be realistically fulfilled, this objective has to be achieved by ensuring the backward compatibility with
the legacy solutions while gradually deploying the new NG112 solution needed to extend the scope,
coverage and reliance of the overall eCall services.
The Reference Architecture described in this deliverable finalized by the Sub-Activity 2.2 team is
intended to reliably support the evolution of the eCall supporting service for as many different types of
vehicles as possible. In addition, the complement in terms of geographical coverage and diversity
provided by satellite networks has also been considered to increase the overall resilience of the system.
In order to ensure a credible deployment and migration roadmap, the architecture proposed considers
the co-existence of CS-eCall and NG-eCall making possible handover scenarios from PS to CS-eCall and
vice-versa. In general, the end-to-end architecture has to accommodate all possible instances of IVS
(e.g. based on mobile network connectivity only, based on satellite-connectivity only, supporting both
mobile and satellite connectivity) installed on any type of vehicle, any combination of access and core
networks, the presence of the ESInet functionality, an heterogeneous generation of PSAPs (supporting
CS only, CS and PS, PS only)
The activity carried out by the sAFE project started from the outcome of the previous European HeERO
and I_HeERO projects where several gap analysis, prototyping, demonstrations and tests were
successfully carried out by involving all the different stakeholders of the eCall domain in many EU
member states.
In particular, starting from the use cases and the recommendations originated by the previous EU
project I_HeERO, the sAFE sub-activity 2.2 has first identified and detailed three significant additional
use cases addressing:
• the forwarding of the NG-eCall from 1st level PSAP to 2nd level PSAP,
• the satellite networks enhancements and support as an additional IP-CAN,
• the provision of Supplementary Data from External sources by Functional Elements in ESInet.
Section 1 provides an extensive description of all the new use cases to be considered in the identification
of the NG-eCall reference architecture. In order to use a systematic methodology, the use cases have
been described by adopting the structure introduced by the ISO TR 25102 “Intelligent transport systems
— System architecture — 'Use Case' pro-forma template”, attached for reference in Annex II of this
deliverable.
These use cases have then been further developed by also taking into account the status and the
outcome of the relevant ongoing standardization activities and sector recommendations (3GPP, ETSI,
CEN, IETF, EENA) so that the main end-to-end architectural requirements for the NG112 eCall have been
developed, discussed and eventually consolidated. The architectural requirements have been
summarized in Section 2.
Finally, based on the architectural requirements reported in Section 2, the NG-eCall Reference
Architecture has been developed by also identifying all related reference points defining the interfaces
among the different parts of the overall architecture. The result of this activity has been summarized in
Section 3 which, on top of being made available to the whole sAFE project team as input for the
Page 70
development of the other Sub-Activities to be carried out, provides a valuable contribution in terms of
input, advice and recommendation to the standardization, certification and regulatory processes.
As a matter of fact, the relevant bodies, entities and policy makers involved will have to finalize these
processes in order to establish a stable technical, regulatory and investment framework, needed in
order to consolidate a realistic and sustainable deployment roadmap for EU, enabling a smooth
transition from the current emergency management architectures to the new ones that will be enabled
by the NG-eCall.
In particular, the Annex III of this deliverable, reports the architectural recommendations suitable for
the future work aiming at defining the roadmap for future developments in the NG-eCall technical
domain. The recommendations suggest that, thanks to the gradual introduction of new media streams
and data, supported by the availability of multiple communications interfaces and connectivity options,
and with the availability of innovative smart sensors, the future IVS will become increasingly able to
gather, make available and upload to remote servers additional data that, when suitably processed,
could assist the emergency services in the initial assessment and overall management of the incident.
In this scenario, in order to make available consistent data and improve the capabilities of the PSAPs
across Europe to respond to the different emergency situations, it will be important to achieve a very
high degree of interoperability between sensors/vehicle components and IVS units from different
manufacturers.
Page 71
REFERENCES
1609/06/EN WP125 (2006) Article 29 Working Party: Working document on data protection and
privacy implications in eCall initiative. Available at: https://ec.europa.eu/justice/article29/documentation/opinion-recommendation/files/2006/wp125_en.pdf (Accessed: 16 July 2019).
EC (2018) European Commission (EC) - Fact Sheet: Questions and Answers. General Data Protection
Regulation, Press release database. Available at: http://europa.eu/rapid/press-release_MEMO-18387_en.htm (Accessed: 16 July 2019).
EU (2013) Commission Delegated Regulation (EU) No 305/2013 of 26 November 2012 supplementing
Directive 2010/40/EU of the European Parliament and of the Council with regard to the harmonised
provision for an interoperable EU-wide eCall, Official Journal of the European Union. Available at:
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013R0305&from=GA (Accessed:
16 July 2019).
EU (2014) Decision no 585/2014/EU of the European Parliament and of the Council of 15 May 2014 on
the deployment of the interoperable EU-wide eCall service, Official Journal of the European Union.
Available
at:
https://eur-lex.europa.eu/legalcontent/EN/TXT/HTML/?uri=CELEX:32014D0585&from=EN (Accessed: 17 July 2019).
EU (2015) Regulation (EU) 2015/758 of the European Parliament and of the council of 29 April 2015
concerning type-approval requirements for the deployment of the eCall in-vehicle system based on the
112 service and amending Directive 2007/46/EC, Official Journal of the European Union. Available at:
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015R0758&from=EN (Accessed:
18 July 2019).
EU (2016) Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 in
the protection of natural persons with regard to the processing of personal data and on the free
movement of such data and repealing Directive 95/46/EC. Available at: https://eurlex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504&from=EN (Accessed:
17 July 2019).
EU (2017) Commission Implementing Regulation (EU) 2017/78 of 15 July 2016 establishing
administrative provisions for the EC type-approval of motor vehicles with respect to their 112-based
eCall in-vehicle systems and uniform conditions for the implementation of Reg. Available at:
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R0078&from=EN (Accessed:
18 July 2019).
Page 72
ANNEX I - THE USE CASES FROM THE EXTERNAL SOURCES
To following Use Cases defined in the external documents have been considered:
Use cases from I_HeERO project
Use case 01-1 – General NG112 eCall for vehicles
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
Use Case Name General NG eCall for vehicles
Use case reference Use case 01-1 / UC 01-1
/id
M
Description An important functionality that differentiates a NG eCall from a
standard eCall is that the MSD can be transferred as part of the call
setup without blocking the voice call
M
Scope (MSD) to be transferred from a vehicle to a 'Public Safety
Answering Point' (PSAP) in the event of a crash or emergency via
an 'eCall' communication transaction.
This Use Case defines:
a) Protocol requirements
c) Example of an in-vehicle sequence generating the MSD
d) Privacy provisions
e) Advice to PSAPs on the use of the MSD
For clarity, the communications media protocols and methods for
the transmission of the eCall message are not specified in this Use
Case
M
M
M
M
Page 73
Scenario A vehicle has an accident and the IVS is connected to an IP capable
(packet-switched) network.
Actors Involved
Stakeholders
•
Vehicle driver
•
PSAP operator
•
Vehicle driver
•
Other vehicle occupants
•
PSAP operator
•
IVS equipment manufacturer/supplier
Area of incident •
Anywhere in Europe, where eCall is supported.
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
Use Case Name General NG eCall for vehicles
Assumptions
•
The vehicle is equipped with an eCall IVS supporting NG 112
eCall.
•
The IVS may equally support the standard European eCall.
•
The PSAP is equipped with an NG112 eCall compliant system
that supports the Next Generation eCall protocol and the
Software to display eCall information.
•
The IP network understands NG112 eCall and prioritises the
call.
•
The network should ensure an appropriate QoS for the call.
•
A connectivity prioritisation exists for selection of suitable
communication bearers within the LTE network in first
priority.
•
As a result of the previous point, the eCall IVS radio is camped
on the LTE network, if available.
M
Available Standards Standard European eCall: EN 16072; EN 16062; EN 15722; EN
16454
NG 112 eCall: IETF RFC 6086, IETF RFC 3261, ETSI TS 122 101, ETSI
TS 123 122, ETSI TS 123 167, ETSI TS 123 401, ETSI TS 124 229, ETSI
TS 123 216, ETSI TS 123 237, ETSI TS 124 301, ETSI TS 126 267, ETSI
TS 136 331, ETSI TR 103.140 V1.1.1 (2014-04)
M
Standardisation •
gaps identified*
O
"Use Case" level Data
O
Page 74
Requirements
Reference
MSD should be sent in the initial SIP invite on IP network to
avoid voice call blocking.
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
O
O
O
Use Case Name General NG eCall for vehicles
Data •
Requirements •
MSD should be sent in the initial SIP invite on IP network.
On GSM networks the fall-back should be the standard eCall
with in-band modem.
•
Acknowledgement of MSD with no voice connection should be
possible (not NG112).
•
In all cases a call back to the IVS needs to be possible.
Relationships to Related to all IVS triggered eCall use cases
other "Use Case(s)"
Triggers
Vehicle has an accident. IVS issues an eCall to the most
appropriate PSAP
Scenario 1. The vehicle is involved in an accident
#Scenario1.
2. An eCall is initiated automatically from the IVS in the vehicle
3. As the IVS is connected to a LTE network a voice over IP voice
call is established between IVS and PSAP
4. As part of establishing the NG 112 eCall connection, the IVS
sends the MSD to the PSAP
5. A voice connection is established as part of NG 112 eCall
establishment (e.g. without any delay due to MSD transfer)
O
Page 75
Scenario 1. The IVS is connected to a GSM network only.
#Scenario2.
2. After establishing the call connection, the IVS sends the MSD
to the PSAP using the in-band modem over the GSM
connection.
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name General NG eCall for vehicles
Scenario 1. The PSAP answering equipment obtains the MSD but is unable
#Scenario3.
to answer the voice call as all PSAP operators are busy
servicing other emergency calls.
2. The PSAP acknowledges receipt of the MSD to the IVSU, but
the PSAP rejects the NG eCall initiation (without establishing a
voice path), indicating that all PSAP operators are busy.
3. When an operator becomes available to process the received
NG eCall he reads the MSD information from the IVS stored at
the PSAP.
4. The PSAP operator calls the IVS to gather any additional
information about the accident
5. The PSAP operator provides the rescue services with the
location and the information he received from the MSD.
6. The PSAP operator stays on the line until the rescue services
reach the accident place and the rescue team takes care of
the driver.
O
O
O
Scenario 1. The IVS cannot connect to the LTE/GSM network
#Scenario4
2. The IVS is able to connect to the satellite network (e.g. L-Band)
(Optional).
3. After establishing the call connection, the IVS sends the MSD
to the PSAP through the satellite network
Expected •
Outcomes
The automatic way of initiating the call will cause a quicker
reaction by the Rescue Service
Extensions The IVS has no connection to a wide area network
Additional communication options like roadside infrastructure
and vehicle to vehicle communication should be considered.
O
Inclusions
O
Business Rules
Template Version
O
Page 76
Open Issues
151021 PT1701 consensus
User needs from use case UC01-1
Only user needs that are NG eCall specific are listed
Ref No
CN101
CN102
CN103
SN101
SN102
Page 77
Need
MSD should be sent in the
initial SIP invite on IP
network to avoid voice call
blocking
Fallback
to
standard
European eCall if NG eCall
is not supported by the
network or the PSAP
A call back from the PSAP
to the IVS must be possible
via NG112 or standard
eCall
Acknowledgement of MSD
successful reception by the
PSAP
Description and Comments
Reference
To avoid voice call blocking the MSD UC01-1
should be send in parallel to the call setup
to the PSAP
On GSM networks the fallback should be
the standard European eCall with in-band
modem
UC01-1
When the connection between the PSAP UC01-1
and the IVS was closed it must be possible
for the PSAP to call the IVS back during at
least 30 minutes after the initial call.
The user in the vehicle should get a UC01-1
feedback that the MSD was received
successfully by the PSAP even if the
establishment of a voice call is not
possible (e.g. due to overload of the PSAP
or network issues)
Backup to satellite if no If no mobile network is available then an UC01-1
mobile network is available optional satellite link may be used. Delays
specified for eCall need to take the
possible delay of a satellite connection
into account
Use case 01-2 – General Accident with vehicle access
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
M
M
Use Case Name NG eCall for vehicles with vehicle access
Use case reference Use case 01-2 /UC 01-2
/id
Description NG112 eCall operates over PS/IP network. In addition to the
‘standard’ eCall transaction of MSD and voice call establishment,
PSAPs would require the ability to subsequently interrogate the
vehicle for further information
Scope
(MSD) to be transferred from a vehicle to a 'Public Safety
Answering Point' (PSAP) in the event of a crash or emergency via
an 'eCall' communication transaction.
This Use Case defines:
a) Protocol requirements
b) Example of a PSAP/in-vehicle sequence
For clarity, the communications bearer, media protocols and
methods for the transmission of the eCall message are not
specified in this Use Case.
M
M
Scenario A vehicle has an accident and the IVS is connected to an IP capable
(packet-switched) network
Actors Involved
Vehicle driver
PSAP operator
M
Stakeholders
Vehicle driver
Other vehicle occupants
PSAP operator
IVS equipment manufacturer/supplier
M
Page 78
Indicate Areas •
Involved
Anywhere in Europe, where eCall is supported
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
M
Use Case Name NG eCall for vehicles with vehicle access
Assumptions
•
The vehicle is equipped with an eCall IVS supporting NG 112
eCall
•
The IVS may equally support the standard European eCall
•
The PSAP is equipped with an NG112 eCall compliant system
that supports the Next Generation eCall protocol and the
Software to display eCall information
•
The IP network understands NG112 eCall and prioritises the
call
•
The network should ensure an appropriate QoS for the call
•
A connectivity prioritisation exists for selection of suitable
communication bearers within the LTE network in first priority
•
As a result of the previous point, the eCall IVS radio is camped
on the LTE network, if available
•
The eCall IVS has access to sensors on the vehicle
Available Standards Standard European eCall: EN 16072; EN 16062; EN 15722; EN
16454
NG 112 eCall: IETF RFC 6086, IETF RFC 3261, ETSI TS 122 101, ETSI
TS 123 122, ETSI TS 123 167, ETSI TS 123 401, ETSI TS 124 229, ETSI
TS 123 216, ETSI TS 123 237, ETSI TS 124 301, ETSI TS 126 267, ETSI
TS 136 331, ETSI TR 103.140 V1.1.1 (2014-04)
M
Standardisation •
gaps identified*
•
•
O
O
Page 79
Need to support mechanism for PSAP to interrogate vehicle to
post the data sources (including sensors) available on vehicle
Need to support mechanism for PSAP to interrogate vehicle
sensors through a query
Additional sensor information could be
"Use Case" level Data
Requirements
Reference
o
Cameras (video or still image)
o
Special sensors e.g. gas or leakage
o
Passenger detection sensors
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name NG eCall for vehicles with vehicle access
Data MSD should be sent in the initial SIP invite on IP network
Requirements
IVS must be able to provide a list of available additional
information
IVS must be able to provide additional information on request
O
O
O
Relationships to Related to all IVS triggered eCall use cases
other "Use Case(s)"
Based on use case 01 – general accident
Triggers
Vehicle has an accident. IVS issues an eCall to the nearest PSAP
Scenario 1. The vehicle is involved in an accident
#Scenario1.
2. An eCall is initiated automatically from the IVS in the vehicle
3. As the IVS is connected to an IP network, a voice over IP call
is established between IVS and PSAP
4. As part of establishing the NG eCall connection, the IVS sends
the MSD to the PSAP
5. A voice connection is established as part of NG eCall
establishment
6. PSAP operator identifies the vehicle as being an LGV from the
corresponding flag in the MSD
7. PSAP operator initiates a query to get a list of all accessible
data sources (including sensors) on the vehicle
8. The IVS accepts the request and posts all available data
sources including sensors
9. PSAP notes that an external camera is available for query
10. PSAP operator initiates a query to access the vehicles
external camera for a still image for better situational
information
11. The IVS accepts the request and sends the still image
12. PSAP operator sees the cargo is compromised with possible
spillage
13. PSAP informs the first responders
Page 80
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name NG eCall for vehicles with vehicle access
Scenario 5. A voice connection is not established.
#Scenario2.
6. PSAP operator identifies the vehicle as being an LGV from the
corresponding flag in the MSD
7. PSAP operator initiates a query to get a list of all accessible
data sources (including sensors) on the vehicle
8. The IVS accepts the request and posts all available data
sources including sensors
9. PSAP notes that an internal camera in the cabin is available
for query
10. PSAP operator initiates a query to access the vehicles cabin
camera
11. The IVS accepts the request and sends the still image
12. PSAP operator sees the driver is badly injured and the cabin
is heavily damaged
13. PSAP informs the first responders
14. PSAP relays the image to the first responders
O
Scenario 6. PSAP operator identifies the vehicle as being an LGV with
#Scenario3.
Hazardous goods from the corresponding flag in the MSD
7. PSAP operator initiates a query to get a list of all accessible
data sources on the vehicle
8. The IVS accepts the request and posts all available data
sources
9. PSAP operator acquires additional information about the
cargo and realises the cargo is highly reactive to water
10. PSAP initiates a query to access the vehicles wiper sensors
11. The IVS accepts the request and sends the sensor status
indicating rainy weather
12. PSAP informs the first responders and requests dispatch of
additional responders and warns them about the water
reactivity of the cargo.
Scenario 9. PSAP initiates a query to access the vehicles sensors to find
#Scenario4.
the fuel level in the vehicle
10. The IVS accepts the request and sends the sensor status
indicating decreasing fuel level – suggesting a leak in the tank
11. PSAP informs the first responders
Page 81
CEN TC278 PT1701 USE CASE TEMPLATE
M
O
Use Case Name NG eCall for vehicles with vehicle access
Scenario 6. PSAP operator identifies the vehicle as being a power-2#Scenario5.
wheeler
7. PSAP is unable to establish a voice call with the vehicle
8. PSAP initiates a query to the vehicle for information whether
there was a passenger and if there was a detachment of the
rider
Scenario 15. PSAP operator identifies the vehicle as being an Bus from the
#Scenario6.
corresponding flag in the MSD
16. PSAP operator initiates a query to get a list of all accessible
data sources (including sensors) on the vehicle
17. The IVS accepts the request and posts all available data
sources including sensors
18. PSAP notes that an internal camera in the bus is available for
query
19. PSAP operator initiates a query to access the vehicles cabin
camera
20. The IVS accepts the request and sends the still image
21. PSAP operator sees that several passengers are badly injured
and the number of passengers
22. PSAP informs the first responders
23. PSAP relays the image to the first responders
O
Expected •
Outcomes
•
O
The Rescue Service will have a clearer view on the accident
using the MSD data
Extensions Instead of LGV the vehicle can be a normal car or a bus
O
Inclusions
O
Business Rules
Template Version
O
The automatic way to query the vehicle will support the
PSAPs better situational awareness
151021 PT1701 consensus
Open Issues
*Attached: Characterisation page for each identified Standard that needs to be developed.
Page 82
User needs from use case 01-2
All needs from use case 01 are valid for this use case too.
Ref No
SN201
Need
SN202
IVS must be able to provide
additional information on
request
Page 83
IVS must be able to provide
a list of available additional
information
Description and Comments
Reference
There is a need to support mechanism for UC01-2
PSAP to interrogate vehicles to post the
data sources (including sensors) available
on vehicle
There is a need to support a mechanism UC01-2
for PSAP to interrogate vehicle sensors
through a query
Additional sensor information could be
•
Cameras (video or still image)
•
Special sensors e.g. gas or leakage
•
Passenger detection sensors
Use case 01-3 – eCall for Large Goods Vehicle
CEN TC278 PT1701 USE CASE TEMPLATE
M
M
M
Use Case Name eCall for large goods vehicle
Use case reference UC 01-3
/id
Description Important parameters that makes an accident with large goods
significant are the following:
1. Extent of damage to the infrastructure
2. Extent of impact on other vehicles involved
3. Vehicle details that would facilitate recovery of vehicle
M
Scope Provide additional information as part of the initial MSD to a
'Public Safety Answering Point' (PSAP) in the event of a crash or
emergency via an 'eCall' communication transaction.
This Use Case defines:
M
M
M
M
•
Suitable triggering mechanism for such vehicles
•
Protocol requirements to vehicle cargo details to be available
to PSAP in the initial communication
•
Protocol requirements for PSAP to access additional vehicle
and cargo information from third party services
Scenario PSAP has received MSD with preliminary vehicle and cargo
information
Actors Involved
Stakeholders
•
Vehicle driver
•
PSAP operator
•
Vehicle driver
•
PSAP operator
•
Dangerous Goods tracking service
•
IVS equipment manufacturer/supplier
MIS / TM / UL Scene of incident
PSAP Call Centre
Rescue Service provider
M
Assumptions
Vehicle is equipped for standard eCall
Vehicle is pulling an additional trailer
Vehicle is tracked by a fleet management/tracking service
M
Page 84
Available Standards
M
O
Standardisation
gaps identified*
"Use Case" level
1. Need to define suitable types of triggering mechanisms for
LGVs – covering both vehicle and trailer impact – for
automatic initiation of the eCall
2. Need to define suitable use of extended data in MSD for
sending URL and/or additional vehicle information
3. Need to define the interface between a PSAP and a thirdparty tracking/fleet management service
Data
O
Requirements
Reference
O
Data Vehicle information accessible to PSAP
Requirements
URL to dangerous goods tracking service as part of the MSD OAD
O
O
Relationships to Related to all IVS triggered eCall use cases
other "Use Case(s)"
Triggers
Accident of vehicle with large goods
Mechanism to initiate the eCall after the accident.
O
Scenario 1. The vehicle is involved in an accident
#Scenario1.
2. An eCall is initiated automatically from the IVS in the vehicle
3. After establishing the call connection, the IVS sends the MSD
to the PSAP using the available IP network
4. The MSD includes the link to a vehicle cargo or tracking
service
5. The PSAP operator takes the call and automatically gets the
MSD data on his screen (including the location of the
accident).
6. The PSAP eCall software extracts the link from the MSD and
queries the vehicle cargo/tracking service for additional
information regarding the vehicle and its cargo. The PSAP
provides the licence plate number, registration country and
the location of the accident to the server.
7. The server checks if the vehicle with the provided licence plate
number is registered in the database and is part of an active
transport.
8. As the vehicle is registered in an active transport the server
compares the provided location with the last location noted in
the database. As both locations are near to each other, the
information request is accepted (privacy reasons).
9. The service returns the details about the cargo and the contact
information of the responsible dispatcher
Page 85
10. The PSAP operator alerts the ambulance and a rescue team
and provides them with the location and the information
about the dangerous goods he received
11. The rescue teams arrive at the accident site and are prepared
for the handling of the dangerous good.
Scenario 1. The PSAP operator also receives an alert that the vehicle has
#Scenario2.
dangerous goods loaded. When opening the alert, the PSAP
operator receives the UN-Number of the dangerous goods
loaded, the amount of dangerous goods loaded and the
contact information of the transport dispatcher.
2. The PSAP coordinates with the transport dispatcher to
request the right handling information about the cargo and
scales the first responders’ team accordingly.
3. The PSAP operator also informs the relevant stakeholders
(e.g. road operator about the hazard) to have their support
O
Scenario 3. The PSAP operator needs some more details on the vehicle
#Scenario3.
following the receipt of the MSD which indicates a tyre
explosion and the position of the vehicle to be partially off the
road
4. The PSAP operator queries the dispatcher for more
information about the vehicle itself and the cargo
5. The PSAP coordinates with the first responders with the
information
6. The PSAP sends the information to the vehicle transporter so
they can coordinate a vehicle recovery
O
Scenario 1. The PSAP operator needs some more details on the goods and
#Scenario4.
calls the responsible dispatcher of the transport.
2. The PSAP operator finds out that one of the parcels being
carried is of very high value.
3. The PSAP operator scales up the first responder team to
include security for the content.
O
Expected •
Outcomes
•
O
Extensions
Improved situational awareness supports an appropriate
scaling of the Rescue Service
The Rescue Service will have a clearer view on the dangerous
goods loaded in the vehicle and can prepare themselves
1. Inclusion of URL for the cargo information or vehicle
tracking system to be included in the MSD
2. Inclusion of additional information could be supported in
the MSD
O
Page 86
Inclusions
O
Business Rules
Template Version
O
Page 87
Open Issues
151021 PT1701 consensus
ANNEX II - THE USE CASE TEMPLATE
Use case description
The use case description follows the structure introduced by the ISO TR 25102 “Intelligent transport
systems — System architecture — 'Use Case' pro-forma template”.
Use case elements
General
The following describes the sections proposed for use in a typical text-based "Use Case". For consistency
and the convenience of any subsequent standardisation activities, this study has adopted the format of
the standard ISO ITS Template for use cases. However, the elements may be augmented or omitted as
applicable. When an element is used then it is strongly recommended that it be used in the manner
described below.
If the required element differs from that stated then it is recommended that a new and differentiated
element is created with a unique element title that does not overload any title already stated below
Normal use cases description
A normal "Use Case" includes a Title, a Primary Actor field, a Participants field, a Goal field, a
Precondition, a Postcondition, a sequence of Steps, a set of Any Extensions, and a set of Extension
Points. The description of these elements is as follow.
A use case description can be seen as a two parts description with:
•
a static part that includes the use case 'Title', 'Primary Actor', 'Participants', 'Goal',
'Precondition' and 'Postcondition' fields, and -
•
a dynamic or procedural part that consists of the use case 'Steps'.
"Use Case" template
This pro-forma template has been created by amalgamation of several recommended templates
together with practical experience of the drafting committee.
We use a simplified template proposed by CEN 278 WG 15 based on ISO TR 25102 Intelligent transport
systems — System architecture — 'Use Case' pro-forma template
"Use Case" name
The name of the "Use Case" normally expressed as a short verb phrase e.g. "Monitor Pedestrian Traffic"
and should be chosen from the viewpoint of the user.
•
Title: a label that uniquely identifies the "Use Case" within the use case model.
"Use Case" description
A short abstract of the intent and scope of the "Use Case".
"Use Case" scope
A concise specification of what is included in the "Use Case" (and by implication what is excluded).
•
Scope: specifies what system is being considered black box under design (e.g. whole business,
system, sub-system, function).
Page 88
Use Case scenario
•
A short description of the use case scenario.
"Use Case” actors involved
•
Define the actors involved in the use case
Primary "Actors" should be identified. An "Actor" is a role that an entity enacts (e.g. driver, passenger,
manager, etc). The same entity may perform several roles and hence appear as several actors (e.g. a
driver of a vehicle may, from a slightly different perspective, also be considered (modelled) as a vehicle
occupant (see Figure 2).
"Use Case" stakeholders
•
An explicit listing of the stakeholders with a primary interest in this "Use Case". This list shall
include the stakeholders, which have a primary relationship with this "Use Case". The approver of
the "Use Case" should be one of the stakeholders
“Use Case” Areas involved
•
Indicate the areas involved in this use case.
"Use Case" assumptions
•
Any assumptions that are implicit in the "Use Case" should be stated explicitly so they may be
reviewed and agreed by stakeholders.
“Use Case” Standardisation Gaps identified
•
What is missing in the existing standards to make the use case possible
Relationship to other "Use Cases"
•
This is the textual form of the "Use Case" model and should be expressed in tabular form (as well
as the usual UML diagram if required).
"Use Case" triggers
•
The events that give rise to the start of the scenario.
"Use Case" scenarios
•
A "Use Case" will comprise one or more concurrent or alternative scenarios.
Scenario (S)
•
The single thread of activity within a scenario comprising a series of consecutive steps.
Step (S.t)
Page 89
•
•
One of many steps within a single scenario
Steps: a sequence of steps. Each step references a use case step operation.
A use case step operation may be a 'concept operation instance', a 'branching
statement' or a 'reference to an included use case'.
"Use Case" expected outcomes
•
The expected or desired normal outcome of the "Use Case" – when all things go as intended.
"Use Case" extensions
•
UML and general practice allow for further stages to follow a "Use Case" and these can be
usefully provided by extensions.
A 'Use Case Extension' is
•
•
Any extensions: a set of 'step extensions' that applies to all the steps in the use case.
Extension points: a set of locations in the use case steps where additional behaviours defined in
extension use cases might be inserted.
"Use Case" inclusions
•
•
•
Similarly, a discrete "Use Case" may form part of a more extensive "Use Case" that has already
been developed. This can be shown in a "Use Case" model as an inclusion.
A use case inclusion statement refers to an included use case. The meaning of a use case inclusion
is that the steps of the included "Use Case" replace the inclusion statement in the base use case.
The remaining steps of the base "Use Case" are normally executed after the included steps.
The various forms of user interfaces used by the actors should be described, with special attention
to avoid overlooking the less obvious interfaces.
"Use Case" business rules
•
There may be important business rules required by stakeholders and these should be stated
explicitly.
CEN TC278 PT1701 USE CASE TEMPLATE
M
Use Case Name
M
Use case reference
/id
M
Description
M
Scope
Page 90
CEN TC278 PT1701 USE CASE TEMPLATE
M
Use Case Name
M
Scenario
M
Actors Involved
M
Stakeholders
M
Area of incident
M
Assumptions
M
Available Standards
M
Standardisation
gaps identified*
O
"Use Case" level
O
Requirements
Reference
O
Data
Requirements
O
Relationships to
other "Use Case(s)"
O
Triggers
O
Scenario
#Scenario1.
O
Scenario
#Scenario2.
O
Scenario
#Scenario3.
O
Scenario
#Scenario4
(Optional).
O
O
Page 91
Expected
Outcomes
Extensions
CEN TC278 PT1701 USE CASE TEMPLATE
M
Use Case Name
O
Inclusions
O
Business Rules
Template Version
O
151021 PT1701 consensus
Open Issues
7.1 The needs derived from the Use Cases
The needs derived from the use cases are classified as follows:
Core Needs
From the user’s perspective, these needs hold the highest importance. They
are central to user’s expectation from the minimum service. If the service
does not meet these requirements it will not be accepted by the users.
Should-Have Needs
These are the needs which users feel should be met by the service. If they are
not met, it is uncertain that the users will adopt the service. These needs
address pertinent operational issues faced by the user.
Desirable Needs
Needs that have been mentioned but have not been rated as high priority for
the users. If met, they will help to increase the value of the service
proposition but are not critical to the user’s acceptance of the service.
Reading the needs table
The following is a fragment of a needs table. The meaning of each column heading is explained
subsequently.
Ref No
CN101
Need
The user requires that the
geographical position of
the coaches is known at all
times
Description and Comments
Reference
In the event of delays, breakdowns and UC01
accidents, if the exact position of the
vehicle is known remedial action can be
taken.
Example Table Entry
Column Heading
Meaning
Ref No
This is a unique identifier for the need.
The first two letters refer to the type of the need and can be
CN – Core Need, SHN – Should-Have Need, DN – Desirable Need
Page 92
Need
This is a short description of the need of the user
Description
Comments
Reference
and This gives a longer descriptive about the particular need, for e.g., explaining
why the need is important to the user
Reference is a reference to the use case or another source of information as
listed in Annex XX
Each needs table is then followed by a more detailed description of each of the needs.
The needs can be described from different view angles:
•
PSAP and Emergency Services
•
Communication providers
•
IVS manufacturers
•
Vehicles manufacturers
•
Third Party Service Providers
Not all views may be applicable or needed.
Based on the needs, the requirements will be defined.
Page 93
ANNEX III – RECOMMENDATIONS FOR NG-ECALL ARCHITECTURE
The following describes the recommendations for the architecture resulting from analysis for future
work.
Additional services using media streams and data
General
As IVS devices are becoming more advanced in terms of data acquisition technologies (e.g. sensors)
and communication capabilities (e.g. 5G and satellite) it is naturally anticipated that interactions with
PSAPs will include additional media streams and data. The availability of this extra information is
deemed to be important in the management of the emergency event on behalf of the services
responsible.
Based on the conclusions of the thorough analysis conducted on the NG-112 related requirements
identified in the context of Activity 3, regarding additional media streams and data we provide a set of
recommendations that can potentially be considered as a roadmap for future developments in the eCall
technical domain.
As today’s users are frequently enriching their personal interactions with additional media, it is
perfectly feasible and potentially advisable to enable them to have media-rich interactions with the
emergency services. Moreover, the emergency services are also likely to find the additional information
useful. So, in addition to the traditional audio, media streams enhancing the communication include
still pictures and video which is either live or potentially recorded (and uploaded on a repository). In
addition to the media data, we observe other additional data that can comprise of readings from
sensors installed in the vehicle; such data is expected to be low in terms of size.
Recommendations
In the table below we present the requirements and features which stem from the anticipated use of
multiple media in NG112 calls and the need for the introduction of new services which result from the
technological advances in vehicle on-board equipment. We assess their impact on the current definition
of NG112 and the architecture implementations currently in place or in the development phase.
User requirements and features of new
services
Impact
The IVS has the capability to transmit real-time Compared to Voice-over-LTE (VoLTE), Videovideo to the PSAP
over-LTE (ViLTE) requires significantly higher
bandwidth. This has an impact on the ISP’s
underlying network infrastructure (especially
during a major incident) as well as on PSAP
network connectivity.
It is not guaranteed that all PSAPs will have high
speed internet connectivity. This issue is similar
to the situation where a PSAP does not have
enough lines to cope with incoming calls. To
alleviate this effect, three options are suggested:
a) the PSAP should be able to request from IVS
units to suppress video transmission to avoid
Page 94
congesting the network and thereby preventing
other calls from going through b) the PSAP
should be able to request from the IVS to switch
to video recording (as described below) and c)
the video call is transferred to a PSAP that has
the required network capacity available; this
requires that PSAPs communicate their status to
each other.
The IVS has the capability to record a video clip There are two potential methods with which such
and upload it to an online repository.
activity can be supported. In the first, once the
NG112 call is established, the IVS starts recording
video (for a predefined time period e.g. 30
seconds) which is then uploaded to an online
repository. In the second, the PSAP requests the
IVS unit to make this recording. In either, the link
to the clip must be provided to the PSAP as
additional data with the MSD (either as part of
the initial invite or in a resend). It is important to
take into account here that the recording or the
upload process may fail.
The IVS has access to a number of on-board In their current state, IVS units are waiting for
sensors.
airbag deployment events in order to initiate a
call. There may be situations where information
from other on-board sensors leads to the
conclusion that an NG112 call must be initiated.
Readings from the sensors could be provided to
the PSAP in two ways: a) as additional data
(appropriately formatted to be recognised by the
receiving PSAP) within the MSD b) as a link to an
online repository for subsequent access by the
PSAP. The PSAP should be able to recognise the
values from the various sensor types and present
the information to the call handling operator in a
meaningful way. The readings from the sensors
should be sent (potentially at regular intervals)
automatically from the IVS unit or upon the
request of the PSAP (such a request should be
contained within an MSD resend request)
Expanding this scenario even further,
consecutive sensor readings could be analysed
automatically (either at the IVS or the PSAP) and
alerts could be generated e.g. rapidly rising
temperature sensor readings which potentially
indicate a fire in the vehicle or its vicinity.
Page 95
It is obvious from the scenarios analysed above that significant changes would be required for the full
support of the services included. More specifically:
a) there are increased processing requirements at the IVS; these relate to video encoding and sensor
data acquisition and processing
b) there are significantly increased storage requirements at the IVS especially when video is involved;
this is important if for example the IVS must create and upload a recording and its internet connection
is slow or unavailable
c) there may be a need to modify the existing definition of NG112 (RFC8147). The current NG112
definition can support the submission of additional data from the IVS to the PSAP in the form of an
external secure link. This allows for a subset of the features mentioned above to be supported.
Indicatively, sensor readings can be provided in the MSD additional optional data part. The formatting
of such data has to be defined so that the readings can be interpreted by the receiving PSAPs.
d) there is a need for common information space, a secure online repository for data and video that is
accessible by IVS units as a data provider and PSAPs as a data consumer. In a fully distributed
architecture, each PSAP might have its own repository with its details being communicated to the IVS
during the call setup phase (to enable it for example to upload a video recording). Incident data in this
repository will consist of sensor readings, the video recordings uploaded by IVS units and the recordings
of the real-time multimedia conversations between passengers and call takers; recorded data should
be kept according to current practices.
e) to support the enhancements described above, it is imperative that interoperability between
sensors/vehicle components and IVS units from different manufacturers should exist. This extends to
the capabilities of the various PSAPs across Europe which are anticipated to vary greatly.
Page 96