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 Requirements Pintar, Iztok Juvančič Sintesio 0.2.2 02.08.2019 Ana Robnik, Primož Žnidar Requirements Iskratel 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 9.12.2019 Lambros Lambrinos ANNEX III Recommendations Marco Annoni Conclusions 0.7.0 19.12.2019 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 Ana Robnik Extensions UC02-2 & UC02-3 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 sAFE Contractual References ...... 14 1.1.1 Overview...... 14 1.1.2 Communication details of the Agency ...... 14 1.1.3 Any communication details of the beneficiaries ...... 14 1.2 An IMS based eCall ...... 15 2 Methodology ...... 16 3 Standards considered and used ...... 17 4 USE CASES ...... 20 4.1 Introduction ...... 20 4.2 The list of Use Cases from the external sources ...... 20 4.3 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 Introduction ...... 39 5.2 High-level Architecture requirements based on use cases and end-to-end scenarios 40 5.2.1 High-level Architecture requirements based on Standards ...... 40 5.3 Architecture principles apply to NG-eCall sessions ...... 44 5.4 Detailed Architecture Requirements for NG-eCall...... 45 5.4.1 IMS network requirements for NG-eCall ...... 45 5.4.2 Location information for NG eCall ...... 47 5.4.3 Media ...... 48 5.4.4 IP-CAN ...... 48 5.4.5 NG-eCall enabled IVS requirements ...... 49
Page 4
5.4.6 NG-eCall enabled PSAP Requirements ...... 50 5.4.7 The ESInet and its Core Elements Requirements ...... 51 5.4.8 NG-eCall Satellite connectivity requirements ...... 52 5.4.9 NG eCall enabled Data Requirements ...... 54 5.4.10 NG-eCall enabled Security/Privacy Requirements...... 54 5.4.11 Freight and other additional Information from external databases ...... 55 6 ARCHITECTURE MODEL AND REFERENCE POINTS ...... 57 6.1 Deployment scenarios for NG eCall architectures ...... 57 6.2 IMS Core Network as Emergency Service Network for NG eCall service ...... 57 6.2.1 Reference Points ...... 57 6.2.2 Functional Description of IMS functional entities ...... 58 6.2.3 NG e-call IMS over satellite through EPC ...... 62 6.2.4 NG e-call IMS over satellite through 5G Core Network ...... 63 6.3 NG-eCall over ESInet including IMS Core as originating network ...... 65 6.3.1 The ESInet Functional Elements ...... 67 7 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 FOR NG E-CALL IMS OVER SATELLITE WHERE IMS IS INTEGRATED WITHIN THE SATELLITE NETWORK OPERATOR NETWORK...... 64
FIGURE 11 : HIGH-LEVEL EMERGENCY SERVICES NETWORK ARCHITECTURE WITH FUNCTIONAL ENTITIES FOR NG- ECALLTHE 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 state- of-the-art analysis. Migration path from 112 eCall to NG112 eCall has been proposed including the co- existence 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 high- level 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 TPS- eCall 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 DEFINITION 3GPP Third generation mobile telecommunication system 2G/ 3G / 4G / 5G Second/ Third/ Fourth/ Fifth Generation 5G NR 5G New Radio 5GC 5G Core ACK ACKnowledgement AIeC Automatic Initiated eCall ANP Access Network Provider API Application Program Interface AS Application Server BCF Border Control Function BS Bearer Services BGCF Breakout Gateway Control Function BSC Base Station Controller
Page 9
CA Certification Authority CAN Controller-Area Network CAP Common Alerting Protocol CBN Core Border Node cdma2000® code-division multiple access version of IMT-2000 standard CLF Connectivity session Location and repository Function CRC Cyclic Redundancy Check CS Circuit Switched CSCF Call Session Control Function DVB- RCS2 Digital Video Broadcasting – Return Channel via Satellite or (Return channel over system) E2E End to End E-CMR Contract for the International Carriage of Goods by Road Electronic Consignment Note E-CSCF Emergency Call session control function EATF Emergency Access Transfer Function EC European Commission ECRF Emergency Call Routing Function ECS Emergency Call Server EENA European Emergency Number Association EPC Evolved Packet Core ePDG evolved Packet Data Gateway eSafety A vehicle-based intelligent safety systems ESInet Emergency Services IP network ESRK Emergency Service Routing Key ESRN Emergency Service Routing Number ESRP Emergency Service Routing Proxy ESQK Emergency service query key ESRN Emergency Service Routing Number ETSI European Telecommunications Standards Institute EUCARIS European CAR and driving licence Information System E-UTRA Evolved Universal Terrestrial Radio Access E-UTRAN Evolved Universal Terrestrial Radio Access Network DOCSIS® Data Over Cable Service Interface Specification E-CSCF Emergency – Call Session Control Function GERAN GSM Edge Radio Access Network supporting the EDGE (Enhanced Data rates for Global Evolution) GNSS Global Navigation Satellite System GSM Global System for Mobile Communications GTT Global Text Telephony HGV Heavy Goods Vehicle HLAP High Level Application Protocols HLR Home Location Registry HPLMN Home Public Land Mobile Network
Page 10
HRPD High Rate Packet Data HSS Home Subscriber Server IAM Initial Address message IBCF Interconnection Border Control Functions ICS IP Multimedia Subsystem Service Control ID Identity IETF Internet Engineering Task Force IMCN IMS Core Network IMEI International Mobile Equipment Identity IMS Internet Protocol Multimedia Core Network Subsystem IMS-MGW IMS Media Gateway IMSI International Mobile Subscriber Identity IP Internet Protocol IP-CAN Internet Protocol- Connectivity Access Network ISCF IPTV Service Control Function IVS In-Vehicle System IVST In-Vehicle System Satellite Terminal LAN Local Area Network LbyR Location by Reference LbyV Location by Value LGV Large Goods Vehicle LIS Location Information Service LN Location Node LRF Location Retrieval Function LRO Last Routing Option LS Location Server LTE Long Term Evolution MANO Management and Orchestration MGCF Media Gateway Controller Function MGW Media Gateway MIeC Manually Initiated eCall MNO Mobile Network Operator MPC Mobile Positioning Centre MRB Media Resource Broker MRFC Multimedia Resource Function Controller MRFP Multimedia Resource Function Processor MSC Mobile Switching Centre MSD Minimum Set of Data (EN 15722) MSISDN Mobile Subscriber ISDN (Integrated Services Digital Network) N3IWF Non-3GPP Inter-Working Function NAD Network Access Device (e.g. a GSM or UMTS module) NAS Non-Access Stratum NASS Network Attachment Sub-System
Page 11
NCC Network Control Centre NENA National Emergency Numbering Association NG Next Generation P-CSCF Proxy-Call Session Control Function P-TMSI Packet- Temporary Mobile Subscriber Identity PGW Packet Data Network Gateway P2W/P2WV Powered 2 Wheeled Vehicle PAN Personal Area Network PCC Policy and Charging Control PCF Policy Control Function PCRF Policy and Charging Rules Function PDS Packet Data Subsystem PLMN Public Land Mobile Network PPT Point to Point Transport PS Packet Switched PSAP Public Safety Answering Point PSTN Public Switched Telephone Network RACS Resource and Admission Control RDF Routing Determination Function REQ REQuest RNC Radio Network Controller RTP Real-time Transport Protocol TEL-URI Telephone Uniform Resource Identifier S-CSCF Serving Call State Control Function SBC Session Border Controller SDF Session Description Protocol SDS Supplemental Data and Database Access Service SET SUPL Enabled Terminal SIP Session Initiation Protocol SLP SUPL Location Platform SLF Subscriber Location Function SMS Short Message Service SUPL Secure User Plane for Location SUT System Under Test TCP/UDP Transmission Control Protocol / User Datagram Protocol TMSI Temporary Mobile Subscriber Identity TPS Third Party Service TPSP Third Party Service Provider TS (i) Technical Specification TS (ii) Teleservice TS12 Teleservice 12 ETSI TS 122 003 TTC Time to Complete Tx Transmit
Page 12
UE User Equipment (ETSI/3GPP term which general refers to the IVS in the context of eCall) UMTS Universal Mobile Telecommunication System URI Uniform Resource Identifier URL Uniform Resource Locator URN Uniform Resource Name USIM Universal Subscriber Identity Module UTRAN Universal Terrestrial Radio Access Network VLR Visited Location Register VoIP Voice over Internet Protocol VoLTE Voice over Long Term Evolution VPC VOIP Positioning Centre WiMAX™ Worldwide Interoperability for Microwave Access WGS World Geodetic System WGS 84 World Geodetic System; issue 1984 (last revised 2004] Wi-Fi “Wireless Fidelity”; wireless networking technology that allows computers and other devices to communicate over a wireless signal WLAN Wireless LAN
Page 13
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: [email protected]
For submission of requests for payment, reports (except ASRs) and financial statements: [email protected]
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: [email protected]
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/Next- Generation-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 Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
M Use case reference Use case 02-1 / UC02-1 /id
M 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. A significant number of countries operate two-level PSAPs. The M Scope 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.
Page 21
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
M 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 Vehicle driver (or passenger) • First level PSAP operator • Second level PSAP operator • st M Stakeholders 1 level PSAP operator • 2nd level PSAP operator • Emergency response unit personnel • PSAP equipment manufacturer/supplier Anywhere in Europe, where CS/NG-eCall is supported. M Area of incident It is assumed that a multi-level PSAP structure is established in M Assumptions the area/country where the NG-eCall is received.
Page 22
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP
M 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 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. NG-eCall is received by a 1st level PSAP in an EU country. The call O Triggers 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.
Page 23
CEN TC278 PT1701 USE CASE TEMPLATE
M 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 O #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 IP- based 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. Scenario 1. The steps 1-3 from the Scenario #1. O #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. Scenario 1. The steps 1 and 2 from the Scenario #2. O #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. Scenario 1. The steps 1 and 2 from the Scenario #2. O #Scenario4 2. An emergency voice call is established between the first and (Optional). 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 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 Use Case Name Forwarding NG-eCall from 1st level PSAP to 2nd level PSAP Scenario # 1. The steps 1 and 2 from Scenario #2. O 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. Expected O Under ideal circumstances all data received in the original NG- Outcomes 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 O any Emergency response team. O Inclusions
O Business Rules
Template Version 151021 PT1701 consensus
O 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 Need Description and Comments Reference CN211 An NG-eCall shall be Assuming that the Level-1 PSAP UC02-1 transferred from a Level-1 to a taking an NG-eCall shall be Level-2 PSAP 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.
Page 25
Ref No Need Description and Comments Reference CN212 MSD and any additional Upon taking the NG-eCall the first UC02-1 information shall be level PSAP will decode the MSD. transferred as a part of the NG- In some cases, it will also try to eCall request from Level-1 to obtain other data available from Level-2 PSAP connected via IP external sources (e.g. EUCARIS network. database). All the information gathered shall be passed on to the Level-2 PSAP when the voice call is transferred. CN213 MSD and any additional Assuming that the Level-2 PSAP UC02-1 information shall be has an IP connection, two transferred from Level-1 to potential scenarios arise: a) in the Level-2 PSAP connected via IP first scenario where the two PSAP network for data exchange systems are fully integrated, all only. the data is transferred in parallel with the voice call establishment
b) in the second scenario the Level-1 PSAP passes to the Level- 2 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 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 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 NG- eCall 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 NG- eCall 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. • Vehicle driver M Actors Involved • Vehicle OEM • IVS provider • On-vehicle satellite terminal provider • Satellite operator • Terrestrial Core network operator
As above except for the vehicle driver M Stakeholders Europe where the NG-eCall service is supported M Area of incident
M Assumptions The satellite operator shall allow pre-authorized NG-eCall devices onto its network. Available • CEN/TS 17312 M Standards • ETSI TS 123 402 • ETSI TS 123 501 • ETSI TS 123 502 • Satellite operator involvement in NG-eCall activities (Satellite M Standardisation operator network shall detect, process and forward NG-eCall gaps identified* messaging).
O "Use Case" level
O Requirements Reference
Page 27
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 Where an Administration is prepared to provide a single central O 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. If no mobile network is available then an optional satellite O Relationships to link may be used. This is linked to UC 01-1, “General NG eCall other "Use Case(s)" for vehicles”. Vehicle has an accident. IVS issues an NG-eCall to the most O Triggers appropriate PSAP through an L band or Ka band satellite network
Page 28
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 Scenario 1. A commercial L6 type vehicle is involved in an accident when O #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 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 O #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 4- 7 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.
Scenario 1. A forestry/agricultural vehicle is involved in an accident in a O #Scenario3. forestry environment and the passenger is outside the vehicle. 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 in- vehicle 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 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 O #Scenario4 (Optional). Expected O 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 O 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 151021 PT1701 consensus
O 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 Need Description and Comments Reference SN221 The user requires NG-eCall service This is where satellite UC02-2 through satellite connectivity, in bearers can provide a locations where low population reliable and high-quality density (such as rural areas, Northern NG-eCall service, Scandinavia and mountainous complimentary to regions) does not justify the provision terrestrial bearers; when of land-based cellular telephone terrestrial networks are networks. not supported at a certain area.
Page 31
Ref No Need Description and Comments Reference SN222 The user requires from the satellite In countries where the UC02-2 telecommunications service provider Administration is to route the NG-eCall via IMS to a prepared, the satellite central 1st level PSAP address if telecommunications offered. If not, satellite NG-eCall can services will be provided be provided via a TPSP. 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-TPSP- eCall. SN223 The user requires NG-eCall service in NG-eCall can be provided UC02-2 locations where low population via satellite bearers and density (such as rural areas, Northern supported in locations Scandinavia and mountainous where there is limited or regions) does not justify the provision no 2G/3G/LTE/4G of land based cellular telephone coverage available. networks.
Page 32
Ref No Need Description and Comments Reference SN224 The user requires that the This is generally obtained UC02-2 geographical position of the vehicle is through GNSS information always known. of the vehicle. Where the GNSS location is not available in the NG-eCall establishment, the NG- eCall 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. SN225 The user requires that following the The satellite operator shall UC02-2 activation of an NG-eCall, the have a continuous open communication capability (voice and communication pipe in the data) between vehicle and PSAP can case of an NG-eCall be continued following an initial NG- communication. The IVS eCall being sent, until cancelled by will seek to and re- either the PSAP or vehicle occupant. establish 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 NG- This is related to TCP UC02-2 eCall system minimises latency for accelerations schemes to sessions established through satellite be employed as described bearers. 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 Use Case Name NG-eCall Supplemental Data from External sources provided by Functional Elements in ESInet
M 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. • Large Goods Vehicle driver M Actors Involved • PSAP operator • LGV operator • ESInet service provider (SDS, ECRF, ESRP, LPG, LNG, etc.) • M 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. M Area of incident
Page 34
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name NG-eCall Supplemental Data from External sources provided by Functional Elements in ESInet
M 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 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 M Standardisation gaps for supporting access to local or external data sources like identified* ECMR Databases, DATEX2.
O "Use Case" level
O Requirements Reference
O 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 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.
O Triggers Accident of large goods vehicle. Manual NG-eCall from the LGV operator.
Page 35
CEN TC278 PT1701 USE CASE TEMPLATE
M 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 O #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 Use Case Name NG-eCall Supplemental Data from External sources provided by Functional Elements in ESInet Scenario O 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 NG- eCall 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. Scenario O 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. Scenario O 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' 15. According to the received information from rescue teams on the site, the operator may update the relevant external systems with this traffic information. Expected O 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 See the scenarios 3, 4 and 5 above.
O Inclusions
O Business Rules
Page 37
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 151021 PT1701 consensus
O 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 Need Description and Comments Reference SN231 The functional elements in The functional element LNG in the ESInet UC02-3 ESInet shall be able to connects CS-eCall capable IVS to a NG- provide interworking and eCall capable PSAP, the functional routing to NG-eCall element ECRF and ESRP route the NG-Call capable PSAP. 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.). SN232 The functional element The functional element SDS in ESInet UC02-3 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. SN233 The functional element The functional element SDS in ESInet UC02-3 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. SN234 An NG-eCall capable PSAP The NG-eCall capable PSAP with IP UC02-4 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.
Page 38
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 co- existence 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 or PS Core Networks PSAP
CS ecall CS Access CS Voice/inband modem CS Core CS CS S1 eCall Network eCall PS to CS transfer PS to CS ecall CS to PS ecall IP-CAN NG S4 S2 S5 NG eCall eCall ESINet
PS Access PS Core VoLTE/VoIP S3 NG ecall
Network 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 PSAP
LDAF ECRF SDS CS Voice/inband modem CS CS Access CS CS Core eCall Network eCall LNG LPG
FBF IP-CAN NG eCall NG ECRF ESRP eCall BCF ESINet PS Access PS Core 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-of- interconnect 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 IP- based 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 Location- by-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.
IVS CS or PS Core Networks PSAP CS Voice/ Inband CS Voice/ 2G/3G modem CS inband CS Access CS Core S1 CS eCall modem Network eCall S4
IP-CAN LPG ISUP I-CSCF S2 3GPP PS Access EATF Network SIP (3.5G/4G/5G) BGCF SIP NG NG P-CSCF E-CSCF IBCF S3 SIP eCall eCall IMS Core SIP Un-trusted* SIP PS Access Network SIP (e.g. SATCOM) PS Voice (VoLTE/VoIP) CS Voice (inband MSD) SS7/ISUP 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 in- band 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 non- 3GPP 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 non- 3GPP 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 NG- eCall 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. PS Available VoIMS EMS ECL First eCall Attempt Second eCall Attempt A Y Y Y Y PS CS if available B Y Y Y N CS if available PS (UE establishes IMS emergency session) C Y Y or N N N CS if available No attempt is made in the PS domain D Y N Y Y PS or CS if available CS if first attempt in PS PS if first attempt in CS E Y N Y N CS if available PS (UE establishes IMS emergency session) F N - - CS if available VoIMS = 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. EMS = 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. ECL = 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 or PS Core Networks PSAP CS Voice/ inband modem 2G/3G CS CS Access CS Core LNG CS LPG eCall Network eCall S5 SIP
IP-CAN ECRF LIS
3GPP VoLTE/VoIP PS Access SIP B Network C SIP ESRP (3.5G/4G/5G) F SIP VoLTE/VoIP NG NG P-CSCF E-CSCF IBCF eCall S3 SIP eCall IMS Core ESInet SIP Un-trusted* SIP PS Access Network SIP (e.g. SATCOM) 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 PS- eCall 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 non- roaming 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 non- emergency 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-of- Interconnect 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 back- up 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 NG- eCall 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 (e- CMR), 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 NG- eCall 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 non- 3GPP access (ETSI TS 123 501).
Page 53
SatCom.Req32 Non-3GPP access networks shall be connected to the 5G Core Network via a Non- 3GPP 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 de- reference 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. DATA.Req4 Optional additional data fits within the OAD section of the MSD and does not change the length of the OAD. DATA.Req5 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). DATA.Req6 CEN TS 17249-3 defines OAD for coaches & Buses. DATA.Req7 CEN TS 17249-4 defines OAD for agricultural vehicles. DATA.Req8 CEN TS 17249-5 defines OAD for P2WV and some other variations. DATA.Req9 CEN TS 17249-3 contains actual data and may also contain a reference to a location where that data is available. 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 Voice/ CS Voice/ CS or PS Core Networks 2G/3G ss 7 CS Core Inband CS CS inband CS Access modem eCall modem Network ss7 eCall LNG I6 CS Voice MGW ici MGCF* ss7 IP-CAN IBCF IVS PSAP Un-trusted* Mj Mx Mg PS Access Network I-CSCF (e.g. SATCOM) BGCF I5 Mi Uu EATF izi Gm Mw 3GPP I4 Mx NG PS Access NG Network Gm P-CSCF Mw E-CSCF Mx IBCF ici eCall Uu (3.5G/4G/5G) eCall MX Mw Mw Mi
AS ISC S-CSCF Cx Sh HSS Sh LRF Le Ix
Iq Iq Mb RTP BGW 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 IP- CAN 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 non- emergency 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 LRF- PSAP 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 non- emergency 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 EAP- AKA (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 non- 3GPP 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) ITU- T 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/article- 29/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-18- 387_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/legal- content/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://eur- lex.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 Use Case Name General NG eCall for vehicles
M 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 Scenario A vehicle has an accident and the IVS is connected to an IP capable (packet-switched) network. • Vehicle driver M Actors Involved • PSAP operator • M Stakeholders Vehicle driver • Other vehicle occupants • PSAP operator • IVS equipment manufacturer/supplier • M Area of incident Anywhere in Europe, where eCall is supported.
Page 73
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name General NG eCall for vehicles • M 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 MSD should be sent in the initial SIP invite on IP network to gaps identified* avoid voice call blocking.
O "Use Case" level Data
O Requirements Reference
Page 74
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name General NG eCall for vehicles • O Data MSD should be sent in the initial SIP invite on IP network. Requirements • 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.
O Relationships to Related to all IVS triggered eCall use cases other "Use Case(s)" Vehicle has an accident. IVS issues an eCall to the most O Triggers appropriate PSAP Scenario 1. The vehicle is involved in an accident O #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) Scenario 1. The IVS is connected to a GSM network only. O #Scenario2. 2. After establishing the call connection, the IVS sends the MSD to the PSAP using the in-band modem over the GSM connection.
Page 75
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name General NG eCall for vehicles Scenario O 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. Scenario O 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 • O The automatic way of initiating the call will cause a quicker Outcomes reaction by the Rescue Service Extensions The IVS has no connection to a wide area network O Additional communication options like roadside infrastructure and vehicle to vehicle communication should be considered.
O Inclusions
O Business Rules
Template Version 151021 PT1701 consensus
O Open Issues
Page 76
User needs from use case UC01-1 Only user needs that are NG eCall specific are listed Ref No Need Description and Comments Reference CN101 MSD should be sent in the To avoid voice call blocking the MSD UC01-1 initial SIP invite on IP should be send in parallel to the call setup network to avoid voice call to the PSAP blocking CN102 Fallback to standard On GSM networks the fallback should be UC01-1 European eCall if NG eCall the standard European eCall with in-band is not supported by the modem network or the PSAP CN103 A call back from the PSAP When the connection between the PSAP UC01-1 to the IVS must be possible and the IVS was closed it must be possible via NG112 or standard for the PSAP to call the IVS back during at eCall least 30 minutes after the initial call. SN101 Acknowledgement of MSD The user in the vehicle should get a UC01-1 successful reception by the feedback that the MSD was received PSAP 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) SN102 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
Page 77
Use case 01-2 – General Accident with vehicle access
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name NG eCall for vehicles with vehicle access
M Use case reference Use case 01-2 /UC 01-2 /id
M 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 (MSD) to be transferred from a vehicle to a 'Public Safety M Scope 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 Scenario A vehicle has an accident and the IVS is connected to an IP capable (packet-switched) network
M Actors Involved Vehicle driver PSAP operator
M Stakeholders Vehicle driver Other vehicle occupants PSAP operator IVS equipment manufacturer/supplier • M Indicate Areas Anywhere in Europe, where eCall is supported Involved
Page 78
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name NG eCall for vehicles with vehicle access • M 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
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 Need to support mechanism for PSAP to interrogate vehicle to gaps identified* 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 o Cameras (video or still image) o Special sensors e.g. gas or leakage o Passenger detection sensors
O "Use Case" level Data
O Requirements Reference
Page 79
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name NG eCall for vehicles with vehicle access
O 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 Relationships to Related to all IVS triggered eCall use cases other "Use Case(s)" Based on use case 01 – general accident Vehicle has an accident. IVS issues an eCall to the nearest PSAP O Triggers
Scenario 1. The vehicle is involved in an accident O #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 Use Case Name NG eCall for vehicles with vehicle access Scenario 5. A voice connection is not established. O #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 Scenario 6. PSAP operator identifies the vehicle as being an LGV with O #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 Use Case Name NG eCall for vehicles with vehicle access Scenario O 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 Expected • O The automatic way to query the vehicle will support the Outcomes PSAPs better situational awareness • 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
O Inclusions
O Business Rules
Template Version 151021 PT1701 consensus
O 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 Need Description and Comments Reference SN201 IVS must be able to provide There is a need to support mechanism for UC01-2 a list of available additional PSAP to interrogate vehicles to post the information data sources (including sensors) available on vehicle SN202 IVS must be able to provide There is a need to support a mechanism UC01-2 additional information on for PSAP to interrogate vehicle sensors request through a query Additional sensor information could be • Cameras (video or still image) • Special sensors e.g. gas or leakage • Passenger detection sensors
Page 83
Use case 01-3 – eCall for Large Goods Vehicle
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name eCall for large goods vehicle
M Use case reference UC 01-3 /id
M 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: • 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
M Scenario PSAP has received MSD with preliminary vehicle and cargo information • M Actors Involved Vehicle driver • PSAP operator • M Stakeholders Vehicle driver • PSAP operator • Dangerous Goods tracking service • IVS equipment manufacturer/supplier
M 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 Available Standards
Page 84
1. Need to define suitable types of triggering mechanisms for M Standardisation LGVs – covering both vehicle and trailer impact – for gaps identified* 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 third- party tracking/fleet management service
O "Use Case" level 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 Relationships to Related to all IVS triggered eCall use cases other "Use Case(s)" Accident of vehicle with large goods O Triggers Mechanism to initiate the eCall after the accident. Scenario 1. The vehicle is involved in an accident O #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 Scenario O 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 Scenario O 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. Expected • O Improved situational awareness supports an appropriate Outcomes 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 Extensions 1. Inclusion of URL for the cargo information or vehicle O tracking system to be included in the MSD 2. Inclusion of additional information could be supported in the MSD
O Inclusions
Page 86
O Business Rules
Template Version 151021 PT1701 consensus
O Open Issues
Page 87
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 Scenario O #Scenario1. Scenario O #Scenario2. Scenario O #Scenario3. Scenario O #Scenario4 (Optional). Expected O Outcomes Extensions O
Page 91
CEN TC278 PT1701 USE CASE TEMPLATE
M Use Case Name
O Inclusions
O Business Rules
Template Version 151021 PT1701 consensus
O 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 Need Description and Comments Reference CN101 The user requires that the In the event of delays, breakdowns and UC01 geographical position of accidents, if the exact position of the the coaches is known at all vehicle is known remedial action can be times 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 and This gives a longer descriptive about the particular need, for e.g., explaining Comments why the need is important to the user
Reference 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 Impact services The IVS has the capability to transmit real-time Compared to Voice-over-LTE (VoLTE), Video- video 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