Upload
dolien
View
249
Download
4
Embed Size (px)
Citation preview
31/07/2013
Information and Communications Technologies Policy Support Programme (the “ICT PSP”) Information Society and Media Directorate-General Grant agreement no.: 270906 Pilot type A
D3.1Pilot operation preparation report
Version number: 1.0 Main author: Victor Grigoriu Dissemination level: PU Lead contractor: ERTICO – ITS Europe Due date: 31.07.2013 Delivery date: 02.09.2013 Delivery date updated document
00.00.0000
31/07/2013 2 Version 0.12
Page left intentionally blank
D3.1Pilot operation preparation report
02/09/2013 3 Version 1.0
Control sheet
Version history
Version Date Main author Summary of changes
Template 25th May 2013 Victor Grigoriu First draft
0.1 25th June 2013 Victor Grigoriu Input from BE, BG, ES, LU
0.2 5th July 2013 Victor Grigoriu Input from TR
0.3 15th July 2013 Victor Grigoriu Input from GR
0.4 16th July 2013 Victor Grigoriu Input from DK
0.5 22nd July 2013 Victor Grigoriu Corrections from GR, ES
0.6 26th July 2013 Victor Grigoriu Minor corrections
0.7 30th July 2013 Victor Grigoriu Updates from BE, TR
0.8 30th July 2013 Victor Grigoriu Updates from GR, LU; minor corrections
0.9 30th July 2013 Victor Grigoriu Updates from DK
0.10 31st July 2013 Victor Grigoriu Caption cleanup
0.11 26th August 2013 Victor Grigoriu Corrections
0.12 29th August 2013 Victor Grigoriu Filled in the inter-operability tests matrix
Name Date
Prepared Victor Grigoriu 31/07/2013
Reviewed Cristian Mandragiu, Andy Rooke 31/07/2013
Authorized Andy Rooke 09/02/2013
Circulation
Recipient Date of submission
Project partners 02/09/2013
European Commission 02/09/2013
D3.1Pilot operation preparation report
02/09/2013 4 Version 1.0
D3.1Pilot operation preparation report
02/09/2013 5 Version 1.0
TABLE OF CONTENTS
CONTROL SHEET ............................................................................................................................................... 3
FIGURES ........................................................................................................................................................... 7
TABLES ............................................................................................................................................................. 8
TERMS AND ABBREVIATIONS ........................................................................................................................... 9
1 INTRODUCTION ..................................................................................................................................... 11
1.1 PURPOSE OF DOCUMENT...................................................................................................................... 11
1.2 STRUCTURE OF DOCUMENT .................................................................................................................. 11
1.3 HEERO CONTRACTUAL REFERENCES ..................................................................................................... 11
2 GENERAL ISSUES .................................................................................................................................... 13
4 NATIONAL PILOT STRUCTURE ................................................................................................................ 20
4.1 BELGIUM ............................................................................................................................................... 20
4.1.1 SHORT DESCRIPTION ..................................................................................................................... 20
4.1.2 FUNCTIONAL DESCRIPTION ........................................................................................................... 20
4.1.3 FOCUS POINT FOR BELGIAN PILOT-SITE ........................................................................................ 22
4.1.4 INVOLVED PARTIES ........................................................................................................................ 23
4.2 BULGARIA .............................................................................................................................................. 23
4.2.1 SHORT DESCRIPTION ..................................................................................................................... 23
4.2.2 INVOLVED PARTIES ........................................................................................................................ 25
4.3 DENMARK .............................................................................................................................................. 26
4.3.1 SHORT DESCRIPTION ..................................................................................................................... 26
4.3.2 INVOLVED PARTIES ........................................................................................................................ 30
4.4 GREECE .................................................................................................................................................. 31
4.4.1 SHORT DESCRIPTION ..................................................................................................................... 31
4.4.2 .............................................................................................................................................................. 34
4.4.3 INVOLVED PARTIES ........................................................................................................................ 35
4.5 LUXEMBOURG ....................................................................................................................................... 35
4.5.1 SHORT DESCRIPTION ..................................................................................................................... 35
4.5.2 INVOLVED PARTIES ........................................................................................................................ 41
4.6 SPAIN ..................................................................................................................................................... 42
4.6.1 SHORT DESCRIPTION ..................................................................................................................... 42
4.6.2 INVOLVED PARTIES ........................................................................................................................ 50
4.7 TURKEY .................................................................................................................................................. 53
4.7.1 SHORT DESCRIPTION ..................................................................................................................... 53
D3.1Pilot operation preparation report
02/09/2013 6 Version 1.0
4.7.2 INVOLVED PARTIES ........................................................................................................................ 54
5 CASE FILE DATA ...................................................................................................................................... 56
5.1 BELGIUM ............................................................................................................................................... 56
5.2 BULGARIA .............................................................................................................................................. 57
5.3 DENMARK .............................................................................................................................................. 58
5.4 GREECE .................................................................................................................................................. 59
5.5 LUXEMBOURG ....................................................................................................................................... 59
5.6 SPAIN ..................................................................................................................................................... 60
5.7 TURKEY .................................................................................................................................................. 61
6 GENERAL WORKFLOW ........................................................................................................................... 62
6.1 BELGIUM ............................................................................................................................................... 62
6.2 BULGARIA .............................................................................................................................................. 66
6.2.1 RECEIVING AND HANDLING ECALL ................................................................................................ 67
6.3 DENMARK .............................................................................................................................................. 67
6.3.1 TEST-SETUP ................................................................................................................................... 68
6.4 GREECE .................................................................................................................................................. 70
6.5 LUXEMBOURG ....................................................................................................................................... 73
6.6 SPAIN ..................................................................................................................................................... 75
6.7 TURKEY .................................................................................................................................................. 75
6.7.1 ECALL RECEPTION .......................................................................................................................... 75
6.7.2 ECALL VISUALIZATION AND OPERATOR ACTIVITIES ...................................................................... 76
6.7.3 CLOSING THE ECALL ....................................................................................................................... 76
7 OPERATION TIMETABLE ......................................................................................................................... 77
7.1 BELGIUM ............................................................................................................................................... 77
7.1.1 PHASING ........................................................................................................................................ 77
7.1.2 DETAILED SCHEDULE ..................................................................................................................... 79
7.2 BULGARIA .............................................................................................................................................. 80
7.3 DENMARK .............................................................................................................................................. 80
7.4 GREECE .................................................................................................................................................. 82
7.5 LUXEMBOURG ....................................................................................................................................... 82
7.6 SPAIN ..................................................................................................................................................... 83
7.7 TURKEY .................................................................................................................................................. 85
D3.1Pilot operation preparation report
02/09/2013 7 Version 1.0
Figures
FIGURE 1: FUNCTIONAL FLOW (BELGIUM) ........................................................................................................... 20
FIGURE 2: TECHNICAL SCHEMA (BELGIUM) .......................................................................................................... 21
FIGURE 3: ECALL PILOT ARCHITECTURE (BULGARIA) ............................................................................................ 24
FIGURE 4: ARCHITECTURE LAST TEST PERIOD AND WHEN IN FULL OPERATION (DENMARK) .............................. 29
FIGURE 5: ECALL PILOT ARCHITECTURE (DENMARK) ............................................................................................ 30
FIGURE 6: ECALL PILOT ARCHITECTURE (GREECE) ................................................................................................ 33
FIGURE 7 GREEK PSAP RACKING ........................................................................................................................... 34
FIGURE 8: ECALL PILOT ARCHITECTURE (LUXEMBOURG) ..................................................................................... 37
FIGURE 9: ECALL PSAP ARCHITECTURE (LUXEMBOURG) ...................................................................................... 38
FIGURE 10: THE HANDLING OF DANGEROUS GOODS IN LUXEMBURG’S ECALL ................................................... 40
FIGURE 11: THE HANDLING OF CROSS-BORDER ISSUES IN LUXEMBURG’S ECALL ................................................ 41
FIGURE 11: PILOT SITE ARCHITECTURE (SPAIN) .................................................................................................... 42
FIGURE 12: CTAG TEST AUTOMATION TOOLS (SPAIN) ......................................................................................... 48
FIGURE 13: ECALL PILOT ARCHITECTURE (TURKEY) .............................................................................................. 53
FIGURE 15: ECALL OPERATIONAL WORKFLOW (BELGIUM) .................................................................................. 64
FIGURE 16: ECALL OPERATIONAL WORKFLOW (BULGARIA) ................................................................................. 66
FIGURE 17: GENERAL ECALL OPERATIONAL WORKFLOW (DENMARK) ................................................................. 68
FIGURE 18: LONG NUMBER ECALL OPERATIONAL WORKFLOW (DENMARK) ....................................................... 69
FIGURE 19: 112 ECALL OPERATIONAL WORKFLOW (DENMARK) .......................................................................... 70
FIGURE 20: ECALL OPERATIONAL WORKFLOW (GREECE) ..................................................................................... 72
FIGURE 21: ECALL OPERATIONAL WORKFLOW (LUXEMBOURG) .......................................................................... 74
FIGURE 22: ECALL OPERATIONAL WORKFLOW (SPAIN) ........................................................................................ 75
FIGURE 23: ECALL OPERATIONAL WORKFLOW (TURKEY) ..................................................................................... 76
FIGURE 24: OPERATIONAL TIMETABLE (BELGIUM) ............................................................................................... 78
FIGURE 25: DETAILED WP3 SCHEDULE (BELGIUM) ............................................................................................... 79
FIGURE 26: OPERATIONAL TIMETABLE (BULGARIA) ............................................................................................. 80
FIGURE 27: OPERATIONAL TIMETABLE (DENMARK) ............................................................................................. 81
FIGURE 28: OPERATIONAL TIMETABLE (GREECE) ................................................................................................. 82
FIGURE 29: ECALL PILOT SCHEDULE (LUXEMBOURG) ........................................................................................... 83
FIGURE 30: ECALL PILOT SCHEDULE (SPAIN) ......................................................................................................... 83
FIGURE 31: DETAILED PILOT OPERATION SCHEDULE (SPAIN) ............................................................................... 85
FIGURE 32: OPERATIONAL TIMETABLE (TURKEY) ................................................................................................. 85
D3.1Pilot operation preparation report
02/09/2013 8 Version 1.0
Tables
TABLE 1: KPI/TEST SCENARIO TABLE ..................................................................................................................... 13
TABLE 2: PILOT SITE STATUS MAY 2013 ................................................................................................................ 15
TABLE 3: INTEROPERABILITY TESTS ....................................................................................................................... 18
TABLE 4: INVOLVED PARTIES (BELGIUM) .............................................................................................................. 23
TABLE 5: INVOLVED PARTIES (BULGARIA) ............................................................................................................. 25
TABLE 6: INVOLVED PARTIES (DENMARK)............................................................................................................. 31
TABLE 7: INVOLVED PARTIES (GREECE) ................................................................................................................. 35
TABLE 8: INVOLVED PARTIES (LUXEMBOURG) ...................................................................................................... 41
TABLE 9: INVOLVED PARTIES (SPAIN) .................................................................................................................... 52
TABLE 10: INVOLVED PARTIES (TURKEY) ............................................................................................................... 56
TABLE 11: CASE FILE DATA (BELGIUM) .................................................................................................................. 57
TABLE 12: CASE FILE DATA (BULGARIA) ................................................................................................................ 57
TABLE 13: CASE FILE DATA (DENMARK) ................................................................................................................ 58
TABLE 14: CASE FILE DATA (GREECE) .................................................................................................................... 59
TABLE 15: CASE FILE DATA (LUXEMBOURG) ......................................................................................................... 60
TABLE 16: CASE FILE DATA (SPAIN) ....................................................................................................................... 60
TABLE 17: CASE FILE DATA (TURKEY) .................................................................................................................... 62
D3.1Pilot operation preparation report
02/09/2013 9 Version 1.0
Terms and abbreviations
Abbreviation Definition
Alarmnet VC112 Danish standard for data exchange between PSAPs and ECCs
AMQP Advanced Message Queuing Protocol
AS Application Server
AVLS Automatic Volume Limiter System
CCD Call Centre Distribution
CC-PSAP CoordCom product Public Safety Answering Points
CIECA Commission Internationale des Examens de Conduite Automobile
CIP Competitiveness and Innovation Framework Programme
CIP Competitiveness and Innovation Framework Programme
CITA International Motor Vehicle Inspection Committee
CTI Computer Telephony Integration
DGPS Differential Global Positioning System
EC European Commission
ECC Emergency Control Centre
EDIFACT Electronic Data Interchange for Administration, Commerce and Transport
ENT Ericsson Nikola Tesla
ERIC European Road Information Centre
FIA Fédération Internationale de l'Automobile
GIS Geographic Information System
GLONASS Global Navigation Satellite System
GNSS Global Navigation Satellite System
GPS Global Positioning System
GSM Global System for Mobile Communications
HAK Croatian Automobile Club/Hrvatskiautoklub
HLAP High Level Application
HW Hardware
ICT PSP ICT Policy Support Programme
ISDN Integrated Services Digital Network
IVV International Association for Driver Education
KPI Key Performance Indicators
MESRE Mobile Emergency Service for Resuscitation and Extrication
MNO Mobile Network Operator
D3.1Pilot operation preparation report
02/09/2013 10 Version 1.0
MPLS Multiprotocol Label Switching
MSD Minimum Set of Data
NAD Network Access Device
NPA National Police Agency
NRN Network Routing Number
OEM Original Equipment Manufacturer
PBX Private Branch Exchange
PLMN Public Land Mobile Network
P-PSAP Primary Public Safety Answering Points
PSAP Public Safety Answering Points
RRA Romanian Railway Authority
RTP Real-time Transport Protocol
RWS Ministry of Transport, Rijkswaterstaat
SBAS Satellite-Based Augmentation System
SIP Session Initiation Protocol
S-PSAP Secondary Public Safety Answering Points
TPS Third Party Services
VIN Vehicle Identification Number
VoIP Voice over Internet Protocol
D3.1Pilot operation preparation report
02/09/2013 11 Version 1.0
1 Introduction
1.1 Purpose of Document
The purpose of this document is to highlight the operational aspects of the eCall pilots
implemented in all the member states participating in HeERO 2, in order to prepare the
operational phase of the project. The document provides a first draft of each member states
operational flowchart.
During the two operational phases of the project, the content of the document will be
modified according to the results of the tests will where necessary be revised, and will be
presented in the next deliverable. The operational workflows illustrate the different
approaches of the different Member States whilst aiming for the same goal: offering an
interoperable, pan-European eCall service based on the 112 service.
1.2 Structure of Document
The document has three main sections: 1) National pilot structure, 2) Case file data 3)
Operational Workflow.
The first section, National pilot structure, describes each member states pilot from an
operational point of view, and the different actors that are involved in the operational
activities.
The second section, Case file data, presents the data that is currently received in different
PSAPs and emergency agencies.
The last section, Operational Workflow, describes the workflow for handling an eCall from the
moment the call reaches the PSAP until the emergency agencies dispatch their resources to
the scene.
A chapter will also present the timetable of activities that will be conducted in all the national
pilots.
1.3 HeERO Contractual References
HeERO is a Pilot type A of the ICT Policy Support Programme (ICT PSP), Competitiveness
and Innovation Framework Programme (CIP). It stands for Harmonised eCall European Pilot.
D3.1Pilot operation preparation report
02/09/2013 12 Version 1.0
The Grant Agreement number is 325075 and project duration is 24 months, effective from 01
January 2013 until 31 December 2014. It is a contract with the European Commission, DG
CONNECT.
The principal EC Project Officer is:
Wolfgang Hoefs EUROPEAN COMMISSION DG CONNECT Office: BU 31 – 6/35 B - 1049 Brussels Tel: +32 296 2188 E-mail: [email protected]
One other Project Officer will follow the HeERO project:
Dimitrios AXIOTIS
Address to which all deliverables and reports have to be sent:
Wolfgang Hoefs EUROPEAN COMMISSION DG CONNECT BU 31 – 6/35 B - 1049 Brussels Tel: +32 296 2188
By mail: [email protected]
Any communication or request concerning the grant agreement shall identify the grant
agreement number, the nature and details of the request or communication and be submitted
to the following addresses:
European Commission Communications Networks, Content and Technology B-1049 Brussels Belgium
By electronic mail: [email protected]
D3.1Pilot operation preparation report
02/09/2013 13 Version 1.0
2 General issues
In the operational phase of the project, the national pilot site teams will carry out activities to
prove the viability of the adopted solution, to create confirm and update both the technical
infrastructure, and the operational procedures.
In order to do this, they will stage operational tests which relate to the project objectives
detailed in the Description of Work.
Each test sites will prepare their own test documentation containing the test scenarios
(prerequisites for each test) and the test cases. The output of this work package will be the
Result Sheets as in Annex 2, following the KPIs which were defined in WP4.
In the test documentation, each test site will declare which of the test cases corresponds with
the measured KPI in the following example table:
3 TEST SITE: Country
Test scenario /
KPI KPI 1 KPI 2 KPI 3 …… KPI n
1 YES YES - - -
2 - YES YES - YES
3 - - - YES YES
… YES YES YES - -
n - YES YES YES -
Table 1: KPI/Test Scenario Table
Accordingly, the Result Sheets will present the measured values of different KPIs, test
conditions and data from each of the test scenarios could present different issues and test-
relevant resolutions.
It is important that all test cases are correctly identified and matched to the correct KPIs
owing to the variability of each set of Pilot Site tests.
Below we present the actual status of the national pilots:
D3.1Pilot operation preparation report
02/09/2013 14 Version 1.0
Test Site/Question
Status of Test Site
No of Vehicles MNO PSAP Points of Interest Issues and Resolution
Belgium Phase 1 starting Q4 2013
15 1 MNO, eCall-flag supported
1 Test-PSAP Testing Filtering instance
Delivery IVS-es delayed
Bulgaria Implementation on-going
At least 2 NCOM, MolBG
1 (Sophia) - "eCall flag" is not going to be implemented till the end of 2013.
Denmark Implementation on-going
10-20 MNO not engaged.
Goal: All PSAP. Test phase 1: Only 1 PSAP
From car to 1st level PSAP
Retrofit IVS expected to be ready August/September 2013
Pilot-test PSAP expected to be ready November 2013
Greece Implementation on going
2 MNO not engaged
1 Test PSAP From car to 1st level PSAP
Delayed Signature of Ministerial Decision for the pilot tests
Luxembourg Installation will start End of June 2013
6 Vehicles are foreseen
EPT is partner in the project
Single (only) PSAP
End to end testing operating on a live PSAP system, cross-border testing
System not installed yet
Spain Phase 1 to start in M9 (1 month
* 12 cars (in 4 regions)
1 MNO (Telefónica)
* Intermediate PSAP (DGT)
* Value chain testing, with Intermediate PSAP (DGT) and
* eCall flag availability for phase
D3.1Pilot operation preparation report
02/09/2013 15 Version 1.0
Test Site/Question
Status of Test Site
No of Vehicles MNO PSAP Points of Interest Issues and Resolution
delay) * 10 P2Ws * 4 regional PSAPs (Galicia, Castilla y Leon, Madrid, Valencia)
regional 112 PSAPs
* Test cases for P2Ws
2 (tbc)
* Availability of regional 112 PSAPs for the tests (tbc)
* Decision on final flowchart (tbc)
Turkey Implementation Ongoing
4 Vehicles 1 MNO Single PSAP (Antalya 112 PSAP)
End to-end testing IVS purchased
Test bed installation started
Table 2: Pilot Site Status May 2013
D3.1Pilot operation preparation report
02/09/2013 16 Version 1.0
One of the major targets of this work package is to prove the viability of the concept
“interoperable pan-European eCall”. In this scope there will be interoperability tests: the
national pilots will be tested against different IVSs from other national pilots. The intention is
that those tests will demonstrate both, the viability of the implemented solutions for eCall
PSAPs and the eCall standards. Through “interoperability” we understand the capacity of
each eCall PSAP to handle standard eCalls generated by any standard IVS, proved so in
other pilot site. This means that the interoperability tests are focused on the eCall PSAP
capability not on IVS. In this scope, there will be possible to borrow or exchange IVS
between pilot sites. The initial commitment of pilot sites for such interoperability test is
presented in the following table, but during the operational phase other tests could be
possible.
D3.1Pilot operation preparation report
02/09/2013 17 Version 1.0
IVS from
Test site
Belgium Bulgaria Croatia (HeERO1)
Czech Republic (HeERO1)
Denmark1 Germany
(HeERO1) Greece Luxembourg Netherlands
(HeERO1) Romania (HeERO1)
Spain Turkey
Belgium x x x
Bulgaria x2
Croatia (HeERO1) x
Czech Republic (HeERO1)
x
Denmark1 x
Germany (HeERO1)
x x
Greece x2 x x x x x2
Luxembourg x x
Netherlands (HeERO1)
x x
Romania (HeERO1)
x x
Spain
Turkey x2
1 The Danish pilot site will use a long B-number initially, so they don’t plan any interoperability tests. 2 Greece has expressed interest in inteoperability tests with Bulgaria and Turkey, but there are currently no definite plans.
D3.1Pilot operation preparation report
02/09/2013 18 Version 1.0
Table 3: Interoperability tests
Cross border tests will be those tests between neighbour pilot sites that will test the ability of one eCall PSAP to handle eCalls generated in
the neighbour country, near the border, and wrongly routed by the mobile operators. Such test will be possible only between neighbouring
Countries,
D3.1Pilot operation preparation report
02/09/2013 19 Version 1.0
and only if the mobile operators will collaborate to handle eCalls in similar ways For example,
it will be necessary to have on the both sides of a border the eCall flag activated in the MNOs
and 112 as the eCall number used in pilot sites and in the IVSs. Assuming that all the
necessary condition will be fulfilled, the receiving eCall PSAP will either handle the eCall and
command the rescue intervention to the appropriate agencies according with the existing 112
collaboration procedures, or it will receive the eCall and forward it to the eCall PSAP of the
neighbour country. For example, in the first phase of the pilot Denmark will use a long
number, so it will not be able to participate in cross border tests.
The tests that will be made during the operation will focus on one or both of the two general
aspects: the technical viability of the solutions and the way of working of the operators in
PSAP and intervention agencies. Such tests can also be performed with the countries
participating in the HeERO 1 project.
D3.1Pilot operation preparation report
02/09/2013 20 Version 1.0
4 National pilot structure
4.1 Belgium
4.1.1 Short description
There are 21 PSAPs: 11 PSAPs for police calls (101) and 10 for medical and fire calls (100)
and 112 calls.
112 calls are directed to the provinces PSAPs, responsible for medical and fire interventions
(also treating the traditional 100-calls). Calls to 112 requiring police assistance are then
transferred to the call-centres of the integrated police (the CIC or Centre for Information and
Communication, treating the traditional 101-calls in Belgium).
4.1.2 Functional description
The Belgian implementation of eCall will be using an additional call centre, which will filter the
eCall calls. The functional flow looks like this:
Figure 1: Functional flow (Belgium)
For transferring the information from the eCall PSAP to the 112 PSAP (actually, the central
servers which serve for all 112 PSAPs in Belgium) the protocol for third party service
providers is used (EN 16102). This has two advantages:
1) Standard is already worked out in detail
D3.1Pilot operation preparation report
02/09/2013 21 Version 1.0
2) 112 PSAPs are also ready to handle private E-Call
The technical schema is as follows:
Figure 2: Technical schema (Belgium)
GW = Gateway
DB = Database
FW = Firewall
WKS = WorkStation
CIC: Communication and Information Centre (i.e. The PSAP)
As can be seen in the diagram, the setup is fully redundant. In the pilot phase the Web
interface of the database server will be used. The XML interface is reserved for future use.
The servers will all be virtual VMware servers. The tests will be carried out using Astrid’s test
D3.1Pilot operation preparation report
02/09/2013 22 Version 1.0
centre, which is technically identical to the 112 PSAP installations. In this way, the already
overloaded 112 PSAP’s are not disturbed by test calls.
4.1.3 Focus point for Belgian Pilot-site
With the introduction of eCall, several changes can be expected compared to the as-is
situation, for instance:
When usage of GSM was increasing, the PSAPs also detected quite an increase in
calls. When an accident happened, many drivers in the area were calling all in
parallel to the 112. With the introduction of eCall, one can expect that the amount of
calls to the 112 centre will again increase.
A built-in eCall device or on-board unit will be easier than a mobile phone to make a
call to the PSAP. It is expected that drivers will more easily push the button (e.g. In
case of car breakdown).
It is also expected that, since the button will be easily accessible, children will push
the button, even when no accident happened, causing an increase of false calls.
With introduction of automatic eCall, e.g. the eCall is initiated when the car crashes, it
is expected to have a large increase of calls for which intervention of an emergency
service is not needed, but where a TPSP could handle the call. Imagine the amount
of eCalls during chain collisions.
For these reasons, the Belgian consortium is proposing to introduce a filtering eCall PSAP.
A filtering eCall PSAP is an organization, separate from a 112 PSAP, which will receive the
eCalls at first instance. When the incident is serious or unclear, the call is handed over from
the eCall PSAP to the 112 PSAP.
The eCall PSAP is expected to be operated by a TPSP like Touring, ADAC, ACAFA, RACE,
ACI, etc. The TPSP should become certified to intervene as a filtering eCall PSAP for the
public authorities. There is a direct connection from the filtering eCall PSAP to the 112 PSAP
to properly hand over eCalls (both voice and data).
The focus of the Belgian pilot-site is to answer several questions which are raised because of
the filtering concept:
Based on which criteria are the routing tables in the network created?
Will there be one or more filtering eCall PSAPs and how is this decided?
How will a company get certified to become a filtering eCall PSAP?
D3.1Pilot operation preparation report
02/09/2013 23 Version 1.0
How does the interface between eCall PSAP and the 112 PSAP work? (e.g. how to
transfer both voice and (enriched) MSD between operator at eCall PSAP and
operator at 112 PSAP?)
How to ensure fast handover? A call which is identified as an emergency call should
be forwarded to the 112 PSAP within 30 seconds. Is this a reasonable figure?
How does the interfacing between the eCall PSAP and the Traffic Management
Centres work?
To solve these, and many more questions, the Belgian pilot-site is assigned as test-site to
focus on filtering eCall PSAP concept.
4.1.4 Involved parties
Name Role HeERO Consortium
ITS.be Overall coordination and support, including transfer of data to TMC
Yes
Mobistar MNO: eCall data and voice end-to-end transmission
Yes
Federal Public Service Home Affairs
Represents PSAPs: VIN decoder, Standard Operating Procedures (SOPs)
Yes
Touring eCall PSAP Yes
NXP In-Vehicle System Yes
TestronicLab Testing and certification Yes
IBSR/BIVV Testing and certification Yes
Astrid nv 112 PSAP service provider: Adaptation of the installed systems in the 112 PSAP to support eCall and MSD
Yes
BIPT Belgian Institute for Post and Telecommunication
No
Table 4: Involved Parties (Belgium)
4.2 Bulgaria
4.2.1 Short description
The organization structure of 112 Bulgarian consists of a centralized PSAP system, located
in Sofia. There is a redundant site in Ruse. All Emergency agencies are interconnected and
D3.1Pilot operation preparation report
02/09/2013 24 Version 1.0
working on the PSAP’ software platform. Voice and data communication are integrated in the
current process of handling an emergency call. It consists of the following subsystems:
o PBX
o Call Centre
o PSAP’ software, incl. GIS data and localization
o Voice Recording System
Figure 3: eCall pilot architecture (Bulgaria)
4.2.1.1 eCall project architectural overview
For the eCall solution, Bulgaria is going to implement the pilot in a centralized manner; all
eCalls (data and voice) are forwarded to a central PSAP located in Sofia, whose operators
will process the call, contacting directly the Emergency Agencies.
The eCall solution is going to be integrated in the existing platforms, modifying existing
functionalities with additional functions.
eC
all
en
viro
nm
en
t
eCall Test
Environment
PSAP SystemPBX
eCall
Test
Environment
EU CariseCall Test
module to
decode VIN
Receiver
Call
Center
System module for
integration with
existing CC system
D3.1Pilot operation preparation report
02/09/2013 25 Version 1.0
4.2.1.2 Operational environment for supporting eCall
eCall environment – IVS generates an eCall and the MNO transfers it to the PSAP’
PBX. Tests will be performed with several SIM cards from the Mtel. As the eCall flag
will be implemented at the end of 2013, the routing will be achieved via the dedicated
number, used by MNO for routing eCalls to 112 system.
PSAP system – responsible for receiving eCall from IVS and processing them as
others 112 calls, incl. presentation and visualization of MSD, incident location, etc.
eCall test environment – responsible for processing MSD
4.2.2 Involved parties
Name Role HeERO Consortium
ITS Bulgaria (Bulgarian
Association Intelligent
Transport Systems)
Project co-ordinator YES
MoI Bulgaria, via Directorate “National 112 system” and International Project Directorate
Public Authority and PSAP administration YES
NCOM (Enterprise Communications Group Ltd.)
Coordinate and contribute Implementation (WP2), Operations (WP3) and Evaluation (WP4) activities related to PSAP.
YES
ICOM Ltd. IVS YES
Technical University of Sofia
IVS YES
Mtel (Mobiltel EAD) MNO YES
Table 5: Involved Parties (Bulgaria)
D3.1Pilot operation preparation report
02/09/2013 26 Version 1.0
4.3 Denmark
4.3.1 Short description
4.3.1.1 112 today
Denmark has three PSAPs’. The Danish Police operates two PSAPs’ located in Aarhus and
Slagelse, while the Copenhagen Fire Brigade operates the PSAP in Copenhagen.
All three PSAPs can push data to ECCs, add relevant ECC to the emergency call and
handover the emergency call to the relevant ECC. But the scope of functionality, the
architecture and the telephone integration are not the same.
PSAPs operated by the National Police
The two PSAP operated by the National Police are identical and added with a test PSAP
centre for testing and education. The centres run as call centres, where the 112 call is
pushed to the longest waiting available operator. When cause for emergency call is
identified, the PSAP add the correct ECC to the call and push relevant data to the ECC, with
an EDIFACT like message standard called Alarmnet VC112.
PSAP operated by the Copenhagen Fire Brigade
The PSAP operated by the Copenhagen Fire Brigade have multiple functions. They are the
ECC for the Copenhagen Fire Brigade and a number of fire brigades from the municipalities
around Copenhagen. In addition, the Copenhagen Fire Brigade handles a number of other
than 112 emergency calls. The Copenhagen Fire Brigade PSAP does not run as a call
centre. Instead the operators pick the calls from a list. When cause for emergency call is
identified, the PSAP add the correct ECC to the call and push relevant data to the ECC, with
a XML-like message standard called MayDayML.
Cooperation
The three PSAPs, the ECCs and the telephone network operators, are all connected to the
same MPLS-network. Among other things, the PSAP receive mobile caller’s cell id through
this MPLS-network.
If there is no available operator at the Copenhagen Fire Brigade, the 112 call is automatically
redirected to the PSAPs operated by the National Police.
D3.1Pilot operation preparation report
02/09/2013 27 Version 1.0
4.3.1.2 eCall readiness
None of the PSAPs are today ready to receive E112, but all PSAPs and ECC are equipped
with GIS-functionality and have access to multiple registers that can help identify the caller’s
location.
The PSAPs receive mobile caller’s cell id (based on LIF), which is represented for the
operator as a circle on the GIS-client.
In addition, a national 112-app was introduced spring 2013. The app sends satellite-based
position information through mobile internet and initiates a normal 112-call. (e112)
4.3.1.3 eCall implementation principles
As little change as possible.
Technical solutions based on existing systems and infrastructures, especially those
made for 112-app.
Operators routines when handling eCall based on existing routines, especially the
routines related to handling calls from 112-app.
Security for existing 112-call first. Solution must not add fault-points at PSAP.
MNOs to route eCalls after same principles as for 112-call, but to special number.
4.3.1.4 The Danish Pilot Architecture comprises the following components:
Retrofit IVS from three vendors
Upgrade of three 1st level PSAPs and two PSAP test environments
Installation of a national eCall-server to service MSD from any one PSAP to all
PSAPs
Amendment of one test environment to function as primary pilot test site for data
capture and data analysis
In addition, MNO’s have been asked to participate in the last part of the pilot, if they have
installed the eCall flag in their network before June 2014.
Retrofit IVS
The retrofit IVS will be installed in 10-20 vehicles. By default, they will not be attached to the
CAN-bus of the vehicles, and have to simulate MSD for test purpose. In addition they need
logging facilities in order to gather data for later analysis and comparison with PSAP logging,
as some of the test scenarios involve uncoordinated live testing.
D3.1Pilot operation preparation report
02/09/2013 28 Version 1.0
Upgrade of 1st level PSAP
There are two different types of PSAPs which have to be upgraded.
Both have a test environment.
The upgrade will consist of eCall-MSD stripping capabilities and changes to the PSAP
application used by the operators. The changes to the PSAP application will be minimal, as
both cell information and satellite position representations already are used in Danish
PSAPs.
National eCall server
If the capacity at a given PSAP is stretched when a new 112-call arrives, the call will be
routed to another PSAP. In order for the MSD stripped at first receiving PSAP to be available
for operator at another PSAP, the MSD have to be shared among all PSAPs instantaneously.
The infrastructure for this sharing is in place and running, sharing cell information from MNOs
and satellite position from Danish 112-app for Smartphone’s.
The National eCall server to be developed will be based on the same principles as the
existing servers.
One test environment as primary test site
One of the test environments will be amended in order to function as primary test site,
receiving all test calls (dialled in with long number) in the first 10 months of the pilot test
period. The amendment involves reconfiguration of Voice Response and added logging
functionality.
Architecture first test period
The figure below illustrates the total installation for the first 10 months of the pilot test
D3.1Pilot operation preparation report
02/09/2013 29 Version 1.0
Figure 4: Architecture last test period and when in full operation (Denmark)
The figure below illustrates the total installation for the last period of the pilot test. It also
illustrates the full implementation of eCall in Denmark excluding routing tables within the
MNOs.
D3.1Pilot operation preparation report
02/09/2013 30 Version 1.0
Figure 5: eCall Pilot Architecture (Denmark)
4.3.2 Involved parties
Name Role HeERO
Consortium
Copenhagen Fire Brigade
Prepare and operate primary test node.
Procure national eCall server and operate while in pilot-test
Upgrade PSAP
Operate PSAP when go-live with 112 decided
No
Danish Police – 112 office
Upgrade PSAP with help of sub-contractor
Operate PSAPs when go-live with 112 decided
Yes
Danish Police – It-department
Operate national eCall server after pilot-test No
Danish Transport Authority Project owner
Provides vehicles and drivers for testing Yes
D3.1Pilot operation preparation report
02/09/2013 31 Version 1.0
Name Role HeERO
Consortium
Devoteam A/S Project managers hired by Danish Transport Authority
No
Danish Business Authority Regulating body for MNOs No
Ficosa Deliver retrofit IVS suitable for Danish Pilot Yes
Fujitsu Ten Deliver retrofit IVS suitable for Danish Pilot No
GMV Deliver retrofit IVS suitable for Danish Pilot Yes
DENSO Partner on interoperability testing Yes
Danish MNOs Implement eCall flag and update routing tables
No
Table 6: Involved Parties (Denmark)
4.4 Greece
4.4.1 Short description
The organization structure of 112 in Greece consists of a centralized PSAP system, located
in Athens. The General Secretariat of Civil Protection (GSCP) is the responsible authority for
the implementation of the pan European emergency number 112 in the country, according to
the ministerial resolution 1881/3-08-1999. It has also the responsibility of informing the
citizens about the existence and the usage of the 112 number, as well as to inform about the
ability of the caller location estimation.
The 112 PSAP uses 20 terminal stations, which are manned depending on the workload of
calls. The terminal stations are computers directly connected to the telephone network. The
computers include headsets for the call operators and special keyboards that facilitate and
accelerate the use of the call management application. The 112 PSAP is operated by the
Hellenic Telecommunication Organization SA (OTE SA), who is also responsible for the
technical support of the hardware and the software of the call centre, under the mandate and
supervision of the GSCP.
D3.1Pilot operation preparation report
02/09/2013 32 Version 1.0
The management application of the call centre is connected to a geographic database that is
maintained by the contractor company. This database allows the routing of calls to the
suitable service/agency, depending on their origin. The information system that currently
supports the PSAP is called ADMOSS (Advanced Multifunctional Operator Service System)
and is provided by SIEMENS. The ADMOSS is a high specification and flexible platform for
support of manned call centres, used in centres for road help, centres of information and
communication centres of co-ordination of organisations. It also supports connectivity with
alternative means and operations like SMS dispatching. All ‘112’ calls are routed to the ‘112’
PSAP which dispatches them to the Fire Brigade, Police etc. according to each case specific
requirements.
4.4.1.1 Focus point for Greek Pilot-site
Given the architecture of the Greek ‘112’, the eCalls during the pilot phase will be handled by
a new eCall PSAP for processing and handling, that is presently installed in the premises of
the Ministry of Infrastructure, Transports and Networks. All eCalls (data and voice) will be
received by the eCall PSAP using a B-number and will be dispatched directly to the
emergency services through web service. After the completion of the pilot project, the eCall
PSAP will be transferred to a location that will be indicated by the Ministry of Public Order
and Citizen Protection, who is the beneficiary of the public tender for the procurement of a
new PSAP, that is presently under evaluation process of the financial proposals. The
designation of this project, co-funded by the European Union under the National Strategic
Reference Framework, is “Modernization and upgrade of services relating to the 112
European Emergency Number using the latest information and communications technologies
with the aim of optimal management of emergency incidents - crises and the early warning of
citizens”.
4.4.1.2 PSAP support of eCall
The envisaged architecture for the Greek pilot site is shown below. Two vehicles will be
equipped with an IVS. The IVS will be able to initiate an eCall to a dedicated long number.
The eCall will be routed to a dedicated Call Centre, for eCalls only. The eCall Call Centre
(PSAP) for the test period will be located at the main premises of the Hellenic Ministry of
Infrastructure, Transport and Networks.
All the hardware and software has been acquired through a public tender procedure. For the
scope of HeERO there are two working places for two operators of the eCall PSAP. The
D3.1Pilot operation preparation report
02/09/2013 33 Version 1.0
PSAP software is able to query the Greek VIN database and retrieve data relevant to the
vehicle involved in the incident.
Figure 6: eCall Pilot Architecture (Greece)
The PSAP equipment consists of a call centre (PBX) where all incoming eCalls are
forwarded from the Public Land Mobile Network (PLMN) and the Public Switched Telephone
Network (PSTN). The inband modem terminates the data part of the call and the relevant
data (MSD) are processed from the main PSAP server. Coordinates visualization, event
handling, VIN decoding and car data extraction from the external database of the Ministry are
presented though a web interface to the operators. The main PSAP server incorporates a
web server that presents as web pages all the information to the operator while it interprets
his actions to appropriate commands for the PSAP. The voice part of the call is converted to
VoIP and it is transmitted to the operators inside the PSAP through the local area network.
The PBX, the main PSAP server and the modem are installed inside a 19” rack which is
shown below:
D3.1Pilot operation preparation report
02/09/2013 34 Version 1.0
Figure 7 Greek PSAP racking
The In Vehicle System (IVS) incorporates the components for the successful communication
with the eCall PSAP, the sampling, packaging and transmission of the data and the GSM
phone functionality for the voice communication of the driver with the PSAP operator. The
IVS is controlled, configured and managed through and external device. It saves log files
where information required for the calculation of the KPIs is stored. The IVS unit is presented
below:
4.4.2
D3.1Pilot operation preparation report
02/09/2013 35 Version 1.0
4.4.3 Involved parties
Name Role HeERO Consortium
Hellenic Ministry of Infrastructure, Transport and Networks
Project Management Yes
Institute of Communication and Computer Systems
Consultant, Technical Specifications for the tender procedures, Will overview the field trials
No
General Secretariat of Civil Protection
Responsible for PSAP and emergency services operation
No
Hellenic MNOs They may support routing the eCalls to the appropriate destination point
No
Hellenic Telecommunications Organisation (fixed line operator)
It may support routing the eCalls within the PSTN to the appropriate destination point (Call Centre)
No
Hellenic Police Will participate in the field trial No
Hellenic Fire Brigade Will participate in the field trial No
Hellenic Emergency Medical Help Services (EKAB)
Will participate in the field trial No
Table 7: Involved Parties (Greece)
4.5 Luxembourg
4.5.1 Short description
Luxembourg operates one 112 Centre (PSAP) located in the city of Luxembourg. The PSAP
is inside the building of the Rescue Service Agency (Administration des Services de Secours
– ASS), previously known as the Civil Protection Agency. The PSAP coordinates the
following types of interventions:
Ambulance / Rescue
Fire Brigade
SAMU (Service d'Aide Médicale Urgente or Urgent Medical Aid Service)
Special Units
D3.1Pilot operation preparation report
02/09/2013 36 Version 1.0
The 112 centre covers the national territory of Luxembourg. In addition to the above
emergency services the 112 Centre also takes handles calls for information as to which
hospital, doctor or pharmacy is on-call after normal hours.
The PSAP solution also provides a simple data communication with the police (who have a
separate 113 Call Centre) and the road traffic management centre. The PSAP call centre
notifies these operational centres about emergency situations. In the case of highways’
accidents, the location and the affected lane are communicated. This solution uses a
proprietary protocol.
PSAP call takers are capable of handling emergency calls not only in the Luxembourgish
language but also in French, German, and English. Some call takers also speak Portuguese,
Italian and Dutch.
The 112 centre is equipped with a geographic information system that contains data from the
whole territory of Luxembourg, including detailed information about the motorway and road
networks (stops, bridges, exits, objects).
The IT solutions used in the PSAP are outdated and are no longer maintained.
A completely new PSAP will be realised, in 2016 that will integrate the ASS PSAP and the
police in one centre and which will use state of the art PSAP solutions. This new PSAP is still
in its planning phase and the results of the HeERO2 project will be included into the
specification of the solution. For this reason no complete integration of the eCall solution into
the existing PSAP solution is foreseen.
The eCall solution will be implemented on a separate desk in the 112 PSAP allowing the
testing of the complete functionality of the eCall solutions. The integration into the PSAP
solution will be executed at the same time as the implementation of the new Luxembourg
PSAP in 2016.
The Luxembourg eCall Solution is composed of three distributed main subsystems.
D3.1Pilot operation preparation report
02/09/2013 37 Version 1.0
Figure 8: eCall Pilot Architecture (Luxembourg)
An in-vehicle system (IVS) is provided by the car equipment manufacturers FICOSA,
NxP and Fujitsu Ten.
The Mobile Network is provided by the Luxembourg Enterprise de Postes et
Télécommunications (EPT).
The Luxembourg PSAP is located in Luxembourg City and is handled by the
Administration des Services de Secours (ASS).
In addition there are interfaces to other services such as
o EUCARIS for decoding the VIN
o CITA (Luxembourg Traffic Management Centre)
o 113 Centre (Luxembourg Police Call-Centre)
o Dangerous goods tracking centre
o Interface to German and Belgium PSAPs for handling cross border eCalls
4.5.1.1 PSAP support of eCall
The eCall infrastructure will be implemented into the Luxembourg PSAP as shown in the
following figure.
D3.1Pilot operation preparation report
02/09/2013 38 Version 1.0
Figure 9: eCall PSAP architecture (Luxembourg)
The main components are:
PBX
Server hosting virtual machines with ISDN modems
eCall router
eCall server
4.5.1.2 Networks functions
In Luxembourg, 3 mobile network operators provide their services for mobile phones and
data access:
LuxGSM, a 100% owned subsidiary of EPT Luxemburg
Tango owned by Belgacom
Orange owned by France Télécom
Currently, the situation regarding eCall is still unclear. LuxGSM plans to implement the eCall
flag in 2014. The other operators will follow after LuxGSM supports eCall.
4.5.1.3 In-Vehicle System functions
The IVS from FICOSA, NxP and Fujitsu Ten contain the following main function components:
Network access device (NAD), GSM/GPRS
GNSS: GPS receiver (positioning)
Host CPU (host for telematic services including the eCall application)
D3.1Pilot operation preparation report
02/09/2013 39 Version 1.0
Antenna system interfaces (MN and GPS)
Vehicle interfaces (CAN, eCall trigger, push buttons etc.)
Audio interface (microphone and speaker)
HITEC Luxembourg and EPT will install the systems into the cars. In total six cars will be
equipped.
4.5.1.4 Handling of dangerous goods transport
Special attention will be given to the handling of dangerous goods’ transports and the
integration into the eCall solution. The Luxembourg partners and ESA are working together
on a project with the goal of establishing a tracking and tracing service for dangerous goods’
transports (DG-Trac service). Initially this service is focused on medical goods but is
foreseen to be extended to all kinds of dangerous goods, specifically those with a UN
categorisation. The server is planned to be available as prototype mid of 2014.
The eCall server of the PSAP will send the vehicle plate number as determined by EUCARIS
to the dangerous goods tracking service centre. The service centre checks if the vehicle has
loaded dangerous goods and returns information about the type and volume of dangerous
goods loaded in the vehicle to the eCall Server. The eCall server displays this information on
a map.
The interface between the eCall server and the DG-Trac service will be based on standards
developed together with CEN TC 278 WG 15. It is the intention of the Luxembourg partners
to implement the standards in the DG-Trac service as well as in the eCall server and test the
functionality and practicability of these standards. Feedback to the standardisation bodies will
be provided if necessary.
This concept was originally developed in the Dutch pilot site in HeERO1 and is being
developed with the active support of CEN TC 278 WG15.
D3.1Pilot operation preparation report
02/09/2013 40 Version 1.0
Figure 10: The handling of dangerous goods in Luxemburg’s eCall
4.5.1.5 Handling of cross-border issues
Another aspect that is important to the Luxembourg pilot site is the testing of cross-border
eCalls.
Many vehicles driving close to the borders, but still inside Luxembourg, will be connected to
German, French or Belgian mobile operators. It must be ensured that the Luxembourg 112
centre is called in case of an incident and not the respective German, French or Belgium
one.
The same applies for vehicles connected to the Luxembourg operator but driving outside the
Luxembourg border. In this case the Luxembourg eCall server has to check in which country
the calling vehicle is located. This check will be made based on the location provided in the
MSD. If the vehicle is located outside Luxembourg the eCall and the MSD provided by the
IVS will be rerouted to the correct designated 112 centre.
D3.1Pilot operation preparation report
02/09/2013 41 Version 1.0
Figure 11: The handling of cross-border issues in Luxemburg’s eCall
4.5.2 Involved parties
Name Role HeERO
Consortium
HITEC Luxembourg S.A. Pilot Site coordinator, implementation and test
yes
Entreprise des Postes et Télécommunications Luxembourg
Mobile Operator yes
Administration des Services de Secours
eCall operator, representative of the Luxembourg Ministry of Interieur
yes
FICOSA IVS provider, test support yes
NxP IVS provider, test support yes
Fujitsu Ten IVS provider, test support yes
ISMB Localisation optimisation yes
Table 8: Involved Parties (Luxembourg)
D3.1Pilot operation preparation report
02/09/2013 42 Version 1.0
4.6 Spain
4.6.1 Short description
Spain will implement Pan European eCall service into the already existing regional E112
system using an intermediate PSAP which will allow filtering and discrimination of eCalls.
The Spanish pilot architecture is based on a several layer approach. It has been agreed with
the Spanish Commission on Civil Protection. The first level will be an intermediate PSAP
deployed by the DGT in Madrid which will be in charge of filtering the received eCalls,
decoding the received MSD and sending the information to the appropriate regional 112
PSAP. This is represented in the following picture
Figure 12: Pilot Site Architecture (Spain)
At the DGT intermediate PSAP, after MSD decoding, the information received will be
provided to three parties:
Regional 112 PSAP where previous upgrading and system integration of the eCall system and the E112 already running system will be done
TCC/TIC in own DGT intermediate PSAP where the information will be related with the following own DGT databases:
o Spanish database of the Vehicle Identification Number (VIN)
o Spanish database of traffic accidents (ARENA)
And additionally, other databases providing necessary information such as
o RACC-owned database of Rescue Sheets by VIN
D3.1Pilot operation preparation report
02/09/2013 43 Version 1.0
o Traffic Police
Information received at the intermediate PSAP will be related to M1 and N1 category
equipped vehicles but some activities will also be dealing with a quick attention to
motorcycles collisions (Powered Two Wheels vehicles, P2W). For P2W, sensing assessment
in helmets and other equipment (GPS, accelerometer, gyroscope, odometer, inclinometer,
fall detection) together with solutions linked to the P2W vehicle itself will be carried out. Tests
of incidents in motorcycle races will be taken into account for this purpose. In addition to in-
laboratory tests to fine-tune the systems used in the P2W pilot, tests will be carried out in
real-life scenarios, in particular in “Cuna de Campeones de Bankia” races, in the following
Spanish circuits: Motorland, Alcalá del Río, Villena, Albaida, Cotarca, Alcarras, Albacete,
Castalla and Cheste.
Spain has 19 regional 112 emergency centres belonging to Civil Protection. 4 of them will
participate in the Spanish pilot (Galicia, Castilla y León, Madrid and Comunidad Valenciana).
All of them have different hardware and software equipment for E112 calls emergency
management. Giving coverage to 4 pilot areas will ensure both enough sampling of current
existing 112 emergency handling centres and assessment and experience (operating
procedures and discrimination of eCalls) on what happens in the border area between
different 112 emergency centres (Galicia-Castilla y León or Madrid-Castilla y León).
Madrid Pilot
Introduction
The Spanish HeERO2 pilot envisages tests and trials in four different regions. One of these
regions is Madrid.
The architecture and workflow to be applied is the same as in the rest of Spanish sites
involved in the pilot, involving
the IVS segment where eCalls will be initiated
the MNO, which will appropriately route the eCalls
An intermediate PSAP at DGT, to manage the reception of eCalls and appropriately
reroute them to the corresponding regional 112 PSAP
A regional 112 PSAP, which will receive the eCalls generated within the region of
Madrid from the DGT PSAP
D3.1Pilot operation preparation report
02/09/2013 44 Version 1.0
Pilot objectives
The Madrid pilot aims at carrying out the different tests as defined in WP4.1 with the final
purpose to register information which will allow to assess the KPIs which have been fixed for
the Spanish pilot sites. The KPIs and tests to be performed in Madrid are reflected in the
following table
Pilot architecture (technological units)
The following elements will be involved in the Madrid pilot architecture
1) Intermediate PSAP at DGT
2) 112 Regional PSAP in Madrid
3) MNO, whose behaviour will be according to the workaround proposed in D2.3 and
detailed in the Spanish pilot workflow
4) IVS provided by the company GMV (U10A unit), whose features have been detailed
in D2.3
Procedure
The pilot will be carried out in a two-fold period:
Phase 1: It will extend from September 2013 to December 2013. It will be followed by
a two-month period for data collection and consolidation, which will provide feedback
for phase 2 of the pilot; in particular, the preliminary assessment of registered data
and following of procedures to be carried out during Phase 1 will allow to incorporate
necessary adjustments for the following phase of the pilot
Phase 2: It will extend from May 2014 to December 2014, and will test the system
with possibly implemented modifications. During this phase, the collected and
consolidated data will be used for intensive processing and analysis, allowing to get
conclusions and results at the end of the project.
The initial procedure to be followed involves tests and trials one day per week, during a
period of 5 hours (precise day to be agreed by the involved partners in order to provide
necessary resources to follow the test). During this time slot, both manual and automatic
eCalls will be generated and appropriately managed. Automatic eCalls will be configured to
be triggered every 60 minutes (which involves 5 automatic eCalls per testing day). Drivers
will be requested to trigger manual eCalls once per hour, which involves 5 manual eCalls per
testing day.
D3.1Pilot operation preparation report
02/09/2013 45 Version 1.0
15 testing days are contemplated in Period 1 (75 manual eCalls and 75 automatic eCalls)
and 28 testing days are contemplated in Period 2 (140 manual eCalls and 140 automatic
eCalls)
The geographical areas to be covered will include the following scenarios:
Rural
Urban
Metropolitan
Areas with reduced cellular coverage
Cross-border areas with Castilla y León (specific locations to be defined according to specific driver needs)
The locations selected for the Madrid pilot will cover a variety of scenarios from the point of view of GNSS (visibility, multipath etc.), communications (coverage), vehicle speeds and traffic situations, in order to be able to cover as many situations as possible. The following table summarizes the Madrid pilot protocol
Type of test
Site No. Vehicle
IVS MNO PSAP Manual eCalls
Automatic eCalls
Plan Scene Cross border
Field trials
Madrid 4 U10A
TSOL No eCall flag. Long number
DGT (intermediate) Madrid 112 (regional)
Y (75 + 140), once per hour
Y (75 +140), every 60 minutes
1 day / week, 5 hours / day
-Urban -Rural -Metropolitan -Reduced coverage
Y (with Castilla y Leon)
(NOTE: Laboratory trials will be part of WP2, and therefore, only field tests are considered as part of the pilot description)
Galicia Pilot
Galicia is other of the Spanish regions in which the eCall pilot will be carried out. In this case,
the architecture and workflow to be implemented will be the same defined in the rest of
Spanish areas, including the same elements already described in the previous paragraphs
and the involvement of the regional 112 PSAP as the final eCall receiver.
Key partners
The key partners in the Galicia pilot site are:
CTAG: IVS provider and pilot coordinator
Telefónica: MNO and technological partner of 112 in Galicia
112 Galicia: official PSAP for the Galicia region
DGT: intermediate PSAP (located in Madrid)
D3.1Pilot operation preparation report
02/09/2013 46 Version 1.0
Pilot objectives
The detailed description of the tests to be carried out in the Galicia pilot will be included in
the WP4.1. The pilot operation will be focused in the execution of the different tests
according to the methodology defined, being the final purpose to register the measurements
needed for the calculation of the KPIs (defined in D4.2) in order to evaluate the performance
of the implementation in the region.
In order to analyse and ensure the interoperability of different solutions two different types of
In addition to the tests performed only in the Galicia area, other of the main aim of the pilot
will be test the interoperability. With this aim two different IVS types will be tested in the
Galicia pilot site (in order to ensure interoperability of different in-vehicle solutions) and
different interoperability tests will be carried out with other Spanish regions and with other
countries in Europe.
Pilot architecture (technological units)
The Galicia pilot architecture will include the following elements included in the general
architecture and flowchart:
1. Intermediate PSAP at DGT
2. 112 Regional PSAP in Galicia (see figure below)
3. Mobile Network Operator
4. Two different types of IVS will be tested in order to ensure interoperability of different
solutions. Those units will be integrated in 4 vehicles in order to perform the tests.
Procedure
Following the Spanish approach, the pilot will be carried out in a two-fold period:
D3.1Pilot operation preparation report
02/09/2013 47 Version 1.0
Phase 1: It will extend from September 2013 to December 2013. This first phase will
be focused in the data collection in order to provide feedback to the phase 2 of the
pilot. In this case, after the data collection period, the assessment of the KPIs and the
procedure establish for this first phase will be done. The results obtained will
contribute to refine the methodology and the implementation before the second
phase.
Phase 2: It will extend from May 2014 to December 2014. During this second period
the system will be tested, taking into account the possible modifications implemented
at this stage. The set of data collected during this period will be used for the final
analyses and generation of final conclusions of the project.
The procedure defined for the first phase takes into account the following:
Execution of periodic tests weekly from September 2013 until December 2013, using
four vehicles and two different kinds of IVSs (the exact dates for executing the tests
will depend on the on the availability of the partners and a detailed planned per day
will be agreed before starting the testing).
The test vehicles will send eCalls in different scenarios in order to test the system in
different environmental conditions that could affect its performance:
o Areas with weak signal (coverage) behaviours (e.g. tunnels)
o Areas with overload of data traffic in the network
o Bad weather conditions
o Cross border areas (Castilla Leon, Portugal and international)
o Urban/interurban areas (including different vehicle speeds and traffic
conditions for manual calls).
Automatic and manual calls will be launched during this first operational period, both
of them, in all the scenarios defined. The automatic calls will be launched remotely
from CTAG using specific equipment installed in the vehicles with the adequate
frequency to test the features of the system.
D3.1Pilot operation preparation report
02/09/2013 48 Version 1.0
Figure 13: CTAG test automation tools (Spain)
All calls will go the local Galician Emergency Centre 112 as a real emergency eCall.
For the first period, a total of at least 1000 calls will be performed taking into account
the scenario variability and the automatic/manual calls.
Laboratory trials will be part of WP2, and therefore, only field tests are considered as part of the pilot description. Nevertheless during the real trials the lab tests will continue in order to solve and to tests different issues that can appear during the real environment tests. These laboratory tests will be carried out in the eCall certification and testing laboratory that CTAG has in its premises.
Valencia pilot
Finally, the pilot to be carried out in Valencia will follow a similar procedure, given the
common architecture of the system for all Spanish regions.
Key partners
The key partners in the Valencia pilot site are:
ITS España: coordinator
Telefónica: MNO
D3.1Pilot operation preparation report
02/09/2013 49 Version 1.0
112 Valencia: official PSAP for the Galicia region
DGT: intermediate PSAP
Ericson: Technology partner
IVS will be provided by FICOSA.
Procedure
Following the Spanish approach, the pilot will be carried out in 2 phases.
P2W
To prepare the Spanish P2W pilot operation, two types of tests will be performed: a first stage should be carried out in laboratory conditions in order to perform partial validations, and the second stage should be carried out in “real” conditions. We understand as real conditions, a real motorbike with a pilot in crash condition. For being able to do this real test in the safest conditions, we will prepare 10 helmets with the necessary hardware to carry out the tests. The tests will be carried out in the Spanish Motorbike Championship “Cuna de Campeones de Bankia”, this will permit realistic testing in a semi-controlled environment. For both cases Spanish partners will define a methodology for the tests. In the case of laboratory conditions a partial experiments (like validation of subcomponents, characterization of working conditions, etc) will be designed. Also measurement equipment will be defined for this stage. For the in-race experiments we will define a methodology including the list of variables to be measured, the rate, the communication system, etc, in order to get the most accurate and complete data for the next phase: Evaluation of data. Before the in-race tests, we will perform preliminary tests in field conditions. The objective of these tests is to adjust and to verify all the equipment for the in-race environment. To complete the results obtained in tests an analysis of ISO configurations of motorbike-car and motorbike-motorbike crash will be carried out to obtain more information; this will be carried out in conjunction with WP 4.
D3.1Pilot operation preparation report
02/09/2013 50 Version 1.0
4.6.2 Involved parties
Name Role HeERO
Consortium
DGT
The Directorate-General for Traffic (DGT) that belongs to the Spanish Internal Affairs Ministry is the Spanish agency that centralises most of the competences on road safety. The core competences of the DGT are at national level on all interurban roads, except for the competences transferred to some regions:
issuing and renewing driving licences and vehicle authorisations, registering of vehicles, drivers and traffic offences;
traffic control and traffic law enforcement on all interurban roads;
a key competence of the DGT is the inspectorate of the Traffic Police, the police body in charge of traffic control and law enforcement;
centralisation of statistics of road traffic, coordination of traffic incident investigations, developing of road safety plans and policies, in coordination with other relevant ministries or public bodies;
supervision of driving information as well as road safety education campaigns.
During the pilots, DGT will be in charge of the Spanish intermediate PSAP management and operation.
Yes
Telefónica
Telefónica is one of the world leader integrated operator in the telecommunication sector, providing communication, information and entertainment solutions, with presence in Europe, Africa and Latin America.
Some of the Products and Services provided related with HeERO2 include:
Movistar Spanish Mobile Network. Movistar is the largest carrier in Spain with 24 million customers (cell phone services only);
112 Emergency Centres. Telefónica leads the Spanish Market as 112 platforms and services supplier, providing services to 64 % of Spanish population.
In particular, during Madrid pilot, Telefónica will be responsible for providing support and management of all the network-related issues (as an MNO) as well as support during the operation and management of the solution implemented in DGT as an intermediate PSAP and in Madrid, Galicia and Castilla y Leon 112 regional PSAPs, solving any incident which might occur or providing the necessary adaptations / fine tuning which deems necessary as far as the pilot is developing.
Yes
Ericsson ERICSSON is a leading ICT company with worldwide presence having more than 3.200 employees in Spain. It is partner of ERTICO and
Yes
D3.1Pilot operation preparation report
02/09/2013 51 Version 1.0
Name Role HeERO
Consortium
ITS-Spain, in the Transport sector, Member of EENA in the Emergencies 112 and plays a relevant role in the telecom standardization bodies like ETSI and 3GPP.
In particular, for all pilots Ericsson will be responsible for providing support during the operation and management of the solution implemented in DGT as an intermediate PSAP, solving any incident which might occur or providing the necessary adaptations / fine tuning which deems necessary as far as the pilot is developing. Additionally, Ericsson will give support in Valencia 112 regional PSAP.
Madrid
112 regional PSAP
Madrid 112 is the organization belonging to the Madrid regional government in charge of receiving and handling 112 calls in the regions of Madrid. Madrid 112 covers an area of 8028 km
2 and a population of more than 6 million
inhabitants. When a citizen makes an emergency call to the 112, the Madrid 112 Emergency Coordination Centre operator collects all the data on his computer and forwards it in electronic form to the relevant Services (Health, Security, and Rescue), depending on the place and nature of the reported incident.
Once the information has been received by the relevant Services, the emergency services working on the same data can interact in real time and in a bi-directional way with the 112 operator who reported the incident, and can request additional information if needed
Madrid 112 will be in charge of receiving and handling emergency calls occurring in the region of Madrid during the pilot. Information from eCalls will be sent by the intermediate PSAP at DGT, the Spanish intermediate eCall PSAP.
No
Galicia 112 regional PSAP Galicia 112 will participate in the tests that will be performed in Galicia area, in collaboration with the intermediate PSAP from DGT
No
Valencia 112 regional PSAP Valencia 112 will participate in the tests that will be performed in Valencia area, in collaboration with the intermediate PSAP from DGT
No
Castilla y Leon 112 regional PSAP
Castilla y Leon 112 will participate in the tests that will be performed to validate internal cross-border operation between Galicia-Castilla-León and Madrid-Castilla-León, in collaboration with the intermediate PSAP from DGT
No
ITS España Responsible for the tests in Valencia
Yes
GMV
GMV is a privately owned technological business group with an international presence which offers its solutions, services and products in very diverse sectors including space, Security, Transportation, Telecommunications,
Yes
D3.1Pilot operation preparation report
02/09/2013 52 Version 1.0
Name Role HeERO
Consortium
and ICTs for Public Administration and large corporations. GMV is pioneer in the development and implantation of turn-key systems based on GNSS, mobile communications and GIS with a broad portfolio of solutions for transport telematics systems and security & emergencies management. GMV has signed the MoU for eCall, and has been actively participating in the Spanish eCall working group.
GMV will be responsible for the overall coordination of the Madrid pilot site, with management responsibility. Particularly, GMV will provide support related to the IVS (carrying out any reconfiguration or fine-tuning which might be necessary as the pilot is developing). Additionally, GMV will provide support during the operation and management of the solution implemented in DGT as an intermediate PSAP in relation with those modules developed by GMV, solving any incident which might occur or providing the necessary adaptations / fine tuning which deems necessary as far as the pilot is developing
ALD Automotive
ALD Automotive is a Renting and Integral Fleet Management company belonging to Société Genérale Group that offers comprehensive Renting services for all types of vehicles brands and models to large and small companies alike.
ALD Automotive, one of the leading companies in the sector in Europe and Spain, currently operates a fleet of over 900,000 vehicles at an international level, and is present in 37 countries in the world.
During the Madrid Pilot, ALD Automotive will provide 4 vehicles, where the IVS will be installed, and the drivers, which will perform according to the pilot protocol defined for this pilot site.
No
CTAG CTAG is a non profit technological centre located in Galicia, working mainly in the automotive industry.
CTAG is responsible of the coordination and management of the Galicia pilot. In addition, CTAG will provide the two different IVS equipments to be tested and the four vehicles in which they will be installed. The tests will be carried out by CTAG in collaboration with 112 of Galicia, Telefónica and DGT. In addition, after the data collection, CTAG will be working actively in the evaluation of the results as WP4 manager.
Yes
CARTIF Technical support to the tests in Castilla y Leon
Yes
Table 9: Involved Parties (Spain)
D3.1Pilot operation preparation report
02/09/2013 53 Version 1.0
4.7 Turkey
4.7.1 Short description
eCall PSAP will be implemented under the same roof with Antalya 112 PSAP. In
Antalya, 112 is the single emergency call number and in the 112 PSAP fire, health
service, police, gendarmerie, forest fire and coast guard operators are in the same
room. In eCall pilot project, The 112 PSAP and eCall PSAP will operate without
affecting each other. eCalls from vehicles travelling through the Antalya, will be
routed to PSAP Centre via new ISDN-PRI connections in order to not to affect the
ordinary 112 Emergency Service. After the evaluation of the pilot results, system
architecture, interfaces and general eCall deployment rules will be decided by
Ministry of Interior.
Turkish eCall Pilot Architecture is composed of the following components: IVS units, Mobile
network, fixed network and PSAP. The components of the Turkish eCall Pilot Architecture
are presented on Figure 13 below.
Figure 14: eCall Pilot Architecture (Turkey)
In our system, the IVS modules which are found in the vehicles trigger the eCall
communication. The eCall call that is generated by the IVS is forwarded to the GSM network.
D3.1Pilot operation preparation report
02/09/2013 54 Version 1.0
MNOs route this call through GSM network and pass it to the PSTN network. Here, the call is
routed through PSTN lines and delivered to the Call Manager in the PSAP. Here, the call is
transferred to IP domain in the PSAP. Call Manager demodulates the MSD data. This MSD
data contains information about the vehicle, location of the vehicle and the status of the
vehicle. The Call Manager forwards the incoming voice call to the Call Taker Application in
the operator PC in SIP format and writes the MSD data to the database. The Call Taker
Application in the operator PC requests the MSD data from the Call Manager. In the operator
PC, MSD is displayed and the vehicle location is shown on the map. Also, the location of the
vehicle can be queried from the MNO’s location services.
4.7.2 Involved parties
4.7.2.1 Aselsan
Aselsan is Turkey’s leading defence electronics company. In this project, Aselsan will
develop the PSAP service. The tasks that will be realized during the pilot project
implementation can be summarized as:
A) Call centre part
Integration of PSAP in-band modem into the ASELSAN’s PSAP solution
Checking and handover of MSD information into the operator’s call taker
application
Checking voice connection with the vehicle
B) Application part
MSD handling
Presentation and visualization of MSD in call taker application
Visualization of incident location in GIS
Voice connection with the vehicle
Statistics and testing related developments in call taker application
4.7.2.2 Turkcell
There are three mobile network operators in Turkey: Turkcell, Vodafone and Avea. In the
Turkish pilot, eCall flag will be implemented and tested only on Turkcell network in Antalya.
D3.1Pilot operation preparation report
02/09/2013 55 Version 1.0
There is no need for additional HW but a new SW must be implemented on the Turkcell side.
Turkcell’s current test system in Istanbul will also be used for eCall flag related IVS-MNO-
PSAP integration tests, before field tests take place in Antalya.
4.7.2.3 Turk Telekom
Turk Telekom is Turkey’s main PSTN operator and largest Internet provider through ADSL
and fibre optical lines. In this project, Turk Telekom will act as Fixed Network Operator. The
FNO related tasks that will be realized during the pilot project implementation are
A) Interconnection of ASELSAN and TURKCELL test systems
a) Related hardware (ISDN PRI) installation
b) Routings and related network configuration
c) Routing of 154 calls ( 154 will be used in pilot project)
B) Interconnection of eCall PSAP with FNO network
a) Related hardware (ISDN PRI) installation
b) Routings and related network configuration
c) Routing of eCalls to the eCall PSAP
4.7.2.4 Tofaş and OYAK Renault
Tofaş and OYAK Renault are among the largest car manufacturers in Turkey. In this project,
they will provide the IVS. Two types of eCall IVS equipment will be used, in the Turkish pilot;
one from Civitronic (Renault) and another one from Magneti Marelli (Tofaş).
Installations will be done in four vehicles. Two vehicles will be equipped with Civitronic
devices; the other two will be equipped with Magneti Marelli devices. Renault and Tofaş will
be responsible for the installation. Both Renault and Tofaş will test manual eCalls.
Name Role HeERO
Consortium
PSAP Service Provider – Technology Provider
ASELSAN
D3.1Pilot operation preparation report
02/09/2013 56 Version 1.0
Name Role HeERO
Consortium
Mobile Network Operator (MNO)
TURKCELL
Fixed Network Operator (FNO)
TURK TELEKOM
IVS Provider- Automotive Technology Provider
TOFAŞ and OYAK RENAULT
Table 10: Involved Parties (Turkey)
5 Case file data
The scope of this is section is to give an overview of the data that is currently available in the
PSAP for every 112 call. Based on this information and where it’s gathered and processed,
every country will design the operational workflow by identifying the mandatory actions that
must be taken by the operator.
5.1 Belgium
The table below shows the case data that is currently being collected in the Belgian
emergency PSAPs. The eCall PSAP is not yet installed, so this column indicates N/A for all
data. It is part of the goals of the Belgian pilot-site to fill in the relevance for the eCall PSAP
during the project, so this table will get updated during the project.
Data eCall PSAP
Police Fire brigade / Ambulance
Name N/A X X
Telephone number N/A X X
Description N/A X X
Accident location N/A X X
Vehicle orientation N/A X X
Number of people injured N/A X X
D3.1Pilot operation preparation report
02/09/2013 57 Version 1.0
Data eCall PSAP
Police Fire brigade / Ambulance
Fire N/A X X
Are injured people trapped in vehicle
N/A X X
Dangerous goods N/A X X
Number of vehicles involved N/A X X
Table 11: Case File Data (Belgium)
5.2 Bulgaria
Data 112 PSAP Police Fire brigade Ambulance
Caller information - name, telephone number, address
X X X X
Short description of incident
X X X X
Incident location : address – city, municipality, Street, street no; descriptive information for more accurate localisation
X X X X
Agencies responsibility area
X X X X
Victim information –name, age, sex
X X X X
Telephone location - cell id, sector id position
X X X X
Incident Classification X X X X
Table 12: Case File Data (Bulgaria)
D3.1Pilot operation preparation report
02/09/2013 58 Version 1.0
5.3 Denmark
Data which is currently being collected by the 112 PSAP call taker and by the Emergency
Agencies in case of traffic accident is listed in following table:
Data 112 PSAP Police Fire brigade Ambulance
Name X
Telephone number X
Description X X X X
Accident location X
Vehicle orientation X
Number of people injured
X
How many are severely injured? And how many of the injured are still conscious?
X
Fire X
Are injured people trapped in vehicle
X
Dangerous goods X
Number of vehicles involved
X
Table 13: Case File Data (Denmark)
D3.1Pilot operation preparation report
02/09/2013 59 Version 1.0
5.4 Greece
Data 112 PSAP Police Fire brigade
Emergency Medical Help
Voice communication X X X X
Telephone number X X X X
Emergency Agency called X X X X
Location of the telephone (antenna coordinates, azimuth, estimated distance from antenna)
X X X X
Names and IDs of involved persons
X X X X
Complete vehicle data (number of plates, model, colour, number of licence)
X X X X
Accident location and date X X X X
Accident type and description X X X X
Injuries per involved person X X X X
Damages X X X X
Data for accident reconstruction (liability, diagram with cars, braking distance, testimonies from drivers and from witnesses if needed, alcohol test in minor injuries, drugs test at a hospital in severe injury or death)
X X X X
Transfer point of involved persons
X X X X
Table 14: Case File Data (Greece)
5.5 Luxembourg
The data that is currently collected by the 112 centre in Luxembourg and provided to police,
fire brigade or ambulance.
Data 112 PSAP Police Fire brigade Ambulance
Short description of incident
X X X X
Name X X X X
Telephone number X X X X
D3.1Pilot operation preparation report
02/09/2013 60 Version 1.0
Data 112 PSAP Police Fire brigade Ambulance
Description X X X X
Accident location X X X X
Vehicle orientation X X X X
Number of people injured
X X X X
Fire X X X X
Are injured people trapped in vehicle
X X X X
Dangerous goods X X X X
Number of vehicles involved
X X X X
Table 15: Case File Data (Luxembourg)
5.6 Spain
Data Intermediate PSAP (DGT)
112 PSAP Police Fire
brigade Ambulance
Name A/M S S S
Telephone number A A S S S
Description M M S S S
Accident location A A/M S S S
Vehicle orientation A M S S S
Number of people injured MT S S S
Fire MT S S S
Are injured people trapped in vehicle
MT S S S
Dangerous goods MT S S S
Number of vehicles involved MT S S S
Table 16: Case File Data (Spain)
A = Automatic information based on systems (network information, mainly, or MSD)
D3.1Pilot operation preparation report
02/09/2013 61 Version 1.0
M =Manual information registered in the PSAP system by the call taker and based on the
conversation between passenger and call taker
MT = A particular kind of manual information that is linked, generally, to the emergency
identification and classification process and the information related to the questions linked to each
particular emergency type.
A/M = Automatic information that can be modified / improved by the call taker.
S = Information sent from 112 PSAP to Agencies involved in the emergency resolution.
The amount of information will depend on the integration capabilities of each particular
agency (there are different “police” agencies, “fire brigade” agencies, etc).
5.7 Turkey
The e-call PSAP in Turkey is used only to receive eCall calls. Only the tests that are related
with the pilot project will be carried out in the eCall centre that will be developed in the
context of this project. The final decision about receiving real eCall calls in the current eCall
PSAP will be given in the future by the Ministry of Interior according to the results of the
project. In this case, it will be decided whether the eCall specific PSAP will communicate with
the PSAPs which are receiving real 112 call centres. If the decision is that there will be
communication then, which part of the information presented in the below table will be
collected by the eCall PSAP and which part will be collected by the 112 PSAP will be
decided by the Ministry of Interior.
Data Role 112 PSAP
Police Fire brigade
Ambulance
Description of Event
Short description of incident
X X X X
Description of Location
Locality, municipality, Street, street no.
X X X X
Description of Incident
Detailed Description of Incident
X X X X
Caller Location Information
Location i.e. Generated By MNO
X X X X
Caller information
(Generated by MNO)
Name Surname, Telephone Number, Location Parameters
X X X X
D3.1Pilot operation preparation report
02/09/2013 62 Version 1.0
Data Role 112 PSAP
Police Fire brigade
Ambulance
Type of Incident (Index)
Incident Classification X X X X
Index Related Questions
Help operator to understand the incident type
X X X X
MSD All fields according to standards
X X X X
Table 17: Case File Data (Turkey)
6 General workflow
6.1 Belgium
This section will explain the workflow in a setup where a filtering eCall PSAP is involved, like
the Belgian pilot-site:
6.1.1.1 Step1: Call reception
The user pushes the button, or, in case of automated eCall, the eCall is generated
because of a car crash. 112 are called by the eCall-IVS.
Based on routing tables, the call will be routed from 112 to an assigned certified
filtering eCall PSAP.
The operator at the filtering eCall PSAP is receiving the call (both voice and MSD)
and has means to enrich the MSD during interrogation of the caller.
Based on the information received from the call (both data and voice), the operator at
the filtering eCall PSAP can decide one of the following steps:
6.1.1.2 Step2: no transfer to the PSAP
The Operator at the Filtering eCall PSAP decides that there is no need to transfer to the 112
PSAP. (simple breakdown or real false call).
D3.1Pilot operation preparation report
02/09/2013 63 Version 1.0
The filtering eCall PSAP has the possibility to send breakdown services (tow-away).
In case of no-filtering-instance, these calls would typically be stamped as false calls at a 112
PSAP.
OR
6.1.1.3 Step 2: eCall is transferred to the PSAP
Based on the information received during interrogation of the driver (or maybe lack of
information) the filtering eCall PSAP Operator can decide to transfer the call to the 112
PSAP.
The operator at the filtering eCall PSAP contacts the PSAP. The PSAP-operator and
Filtering Instance operator will be in a short hand-over call and the PSAP-operator will
then continue the call. The (enriched) MSD is transferred from the Filtering Instance
to the PSAP. From this point onwards, the PSAP is taking over the eCall.
With this concept, a lot of so-called false-calls will never arrive at the PSAP but be filtered by
the eCall PSAP. This will help 112 PSAPs to concentrate on real emergency calls.
D3.1Pilot operation preparation report
02/09/2013 64 Version 1.0
Note that this is not private eCall, as private eCall does not involve the short number 112 in
the network.
The picture below shows the flowchart for the above workflow.
Figure 15: eCall Operational Workflow (Belgium)
D3.1Pilot operation preparation report
02/09/2013 65 Version 1.0
D3.1Pilot operation preparation report
02/09/2013 66 Version 1.0
6.2 Bulgaria
Figure 16: eCall Operational Workflow (Bulgaria)
D3.1Pilot operation preparation report
02/09/2013 67 Version 1.0
6.2.1 Receiving and handling eCall
1. When MNOs recognize eCall forwards it to PSAP PBX using dedicated number. 2. eCall reaches PSAP PBX which routes it to eCall Server. The in-band modem
receives and decodes MSD. External VIN database is queried (optional). When MSD is extracted, voice call is routed back to the PBX.
3. The call is transferred to the PSAP operator. CTI data, MSD data and VIN decoded data are transferred to the existing PSAP’ software and presented to the operator.
4. PSAP operator inquires the caller and gathers additional information. The operator determines the type of required emergency services, and the system forwards the event automatically to the respective ECCs, on the base of the localization information.
5. Emergency Agency dispatcher begins handling the case. Dispatcher sends and manages first responder’s teams. Resources are being sent to the incident. Dispatcher sends feedback to PSAP.
6.3 Denmark
eCall will be geographically routed among the three national PSAPs as with normal 112-call.
The figure below describes the new processes which will follow the eCall implementation in
Denmark. Please note, that the process regarding TMC-involvement will not be changed.
D3.1Pilot operation preparation report
02/09/2013 68 Version 1.0
Figure 17: General eCall Operational Workflow (Denmark)
6.3.1 Test-setup
Before going live, the setup will be tested. First with a long number to one eCall-installation
with a Voice Response mechanism (IVR). Later, when MNOs in Denmark have implemented
the eCall flag, the test will be with 112-call to live operators.
There will be basically three different tests performed for both long-number call and 112-call:
1. A fleet of 11 vehicles will drive around all Denmark for other businesses. While driving
or while stopping, the driver will periodically initiate manual or manual-automatic
eCalls. This is the main test scenario, and it will be performed with some variations in
order to test for:
a. Various combination of SIM-cards:
D3.1Pilot operation preparation report
02/09/2013 69 Version 1.0
i. Dormant or normal SIM-card
ii. Roaming or national SIM-card
b. Call Back (in long number test-period, these will be scheduled, in 112-test
period, it will be the 112-operator who decides, if there is time for Call Back
testing)
c. Resend MSD (in long number test-period, these will be scheduled, in 112-test
period, it will be the 112-operator who decides, if there is time for Resend
MSD testing)
d. If possible, interoperability with retrofit-IVS switching with other HeERO2-
pilots. Arrangements will have to be made
2. One or two vehicles will be equipped with satellite positioning measurement
equipment, and will for a short period perform a number of planned test-call
3. If possible, a special test will be performed for cross-border eCall testing with
Germany and/or Sweden. Arrangements will have to be made.
The figure below describes the processes involved in long number test-period
Figure 18: Long Number eCall Operational Workflow (Denmark)
D3.1Pilot operation preparation report
02/09/2013 70 Version 1.0
The figure below describes the processes involved in 112-test period
Figure 19: 112 eCall Operational Workflow (Denmark)
6.4 Greece
The eCalls will be processed by the dedicated eCall PSAP. The MNOs and fixed line
operator may route the eCalls to this Call Centre.
The following steps will be performed during an eCall reception:
1. The eCall PSAP receives an incoming eCall
D3.1Pilot operation preparation report
02/09/2013 71 Version 1.0
2. The eCall PSAP software decodes the MSD and queries the VIN database.
3. The voice call is transferred to a PSAP operator and the decoded MSD data and
relevant vehicle data are displayed at the screen.
4. If communication with a vehicle passenger is feasible, the eCall PSAP operator
evaluates which Emergency Services are needed and notifies them.
5. If communication with a vehicle passenger is not feasible, the eCall PSAP operator
notifies all emergency services. If there is communication established until the time of
arrival of the first rescuer at the incident location, the eCall PSAP operator evaluates
which Emergency Services are actually needed and notifies the other ones to return.
6. After the first rescuer arrives at the incident location, he/she estimates the severity
and informs the Emergency Service Centre.
7. The rescue operation is performed and the Emergency Service Centre is notified
about the result.
8. Emergency forces return to their Operation Centres.
D3.1Pilot operation preparation report
02/09/2013 72 Version 1.0
Figure 20: eCall Operational Workflow (Greece)
D3.1Pilot operation preparation report
02/09/2013 73 Version 1.0
6.5 Luxembourg
In Luxembourg the eCalls will be processed by the 112 PSAP in Luxembourg. For the test a
special phone number in the PSAP will be used to route eCalls to the eCall router. When the
eCall flag is available, this routing will be done automatically by the MNO. This makes the
technical handling of incoming eCalls much easier.
The following steps will be performed during an eCall reception
1. The PSAP receives an incoming Call at the eCall phone line
2. The PSAP eCall switch hardware receives the MSD and sends it to the eCall Server
3. The eCall Server decodes the MSD and adds EUCARIS and VIN information
4. In the PSAP, the voice call is transmitted to the internal PBX
5. The PSAP Operator accepts the call on the phone
6. The operator’s PSAP software retrieves the MSD information from the eCall Server and
displays it on the screen
7. The operator talks to the caller to find out additional information about injuries (how badly,
is it possible to reach the injured, can they be taken out of the vehicle), situation ((short
description of the accident, who is involved?), environment (Is any vehicle on fire and how
many), passengers (preconditions, pregnancy)
8. The 112 Centre immediately notifies of the accident the following:
o Emergency Medical Dispatcher of the Emergency Medical Service,
o Operational Communications Centre of the Police Administration,
o Operational centre of the legal entity in charge of maintenance and
management of the highway section on which the accident happened,
o The next fire fighting unit.
9. When the forces in the field cannot cope with the situation, they may require additional
teams either through their internal communications or through the 112 Centre.
11. Emergency services notify the PSAP of the course and end of the operation, as well as
consequences of the accident. The PSAP creates a comprehensive report.
D3.1Pilot operation preparation report
02/09/2013 74 Version 1.0
Figure 21: eCall Operational Workflow (Luxembourg)
D3.1Pilot operation preparation report
02/09/2013 75 Version 1.0
6.6 Spain
Figure 22: eCall Operational Workflow (Spain)
6.7 Turkey
6.7.1 eCall Reception
In our system, the IVS modules which are found in the vehicles trigger the eCall
communication. The eCall call that is generated by the IVS is forwarded to the GSM network.
MNOs route this call through GSM network and pass it to the PSTN network. Here, the call is
routed through PSTN lines and delivered to the Call Manager in the PSAP.
Here, the call is transferred to IP domain. Call Manager demodulates the MSD data. This
MSD data contains information about the vehicle, location of the vehicle and the status of the
vehicle. The Call Manager forwards the incoming voice call to the Call Taker Application in
the operator PC in SIP format. In this way, a voice communication channel is established
with the Call Taker Application.
eCall Iniciation
eCall Initiation
MNO forwards
the eCall to the
fixed line
operator
eCall Iniciation eCall handling in PSAP eCall emergency management
IVS
Reg
ion
al
PS
AP
(112)
Inte
rmed
iate
PS
AP
(D
GT
)M
NO
Em
erg
en
cy
ag
en
cie
sT
raff
icM
an
ag
em
en
t
Cen
tre
Fixed line operator
forwards the
eCall to the eCall
PSAP
Call reaches the
eCall
Intermediate
PSAP
Manual call?
Is
communication
with driver
feasible?
Error call? End
MSD DataAdditional
data
(ATEX)
The PSAP
operator
interviews the caller
The PSAP
operator
indexes the incident
The PSAP
operator
forwards the
case to the emergency
agencies
Dispatch
emergency services
TMC
Yes
Yes Yes
No No
Operator interviews
the caller
D3.1Pilot operation preparation report
02/09/2013 76 Version 1.0
After this point, the Call Manager sends the MSD data to the Call Taker Application. In
addition to this, the Call Manager writes the MSD data to the database.
6.7.2 eCall Visualization and Operator Activities
In the operator PC, MSD is displayed and the vehicle location is shown on the map. When
more information is required about the location of the vehicle (or if the location information
cannot be provided from MSD), the operator can query the location of the vehicle from the
MNO’s location services. The connection between the PSAP and the MNO’s database is
provided through the Internet. In this way, the location information which is gathered from the
MNO can also be displayed on the operator PC.
Additionally, the operator is able to talk with the passengers in the vehicle. The established
voice communication channel allows two way communications between the operator and the
vehicle occupants.
6.7.3 Closing the eCall
After enough information is collected about the incident, the rescue teams such as fire, police
and health emergency units are sent to the vehicle location.
The flow of the eCall call is summarized in the figure below.
Figure 23: eCall Operational Workflow (Turkey)
D3.1Pilot operation preparation report
02/09/2013 77 Version 1.0
7 Operation timetable
7.1 Belgium
7.1.1 Phasing
In the Belgian pilot site, testing will be executed in 2 phases. The implementation-phase is
preceding these test phases.
Implementation-phase: In this phase, both the technical system and the testing
procedures are brought up. In Heero2, this is mostly covered by WP2. This phase
should result in:
o IVS-es driving around, capable of initiating an eCall, Filtering instance
operational with eCall-server (Oecon), test-PSAP operational with eCall-server
and Mobile network supporting the eCall-flag and capable of adapting routing
tables.
o Test scenarios and procedures that represent typical emergency cases to test
and try out work flows and experiment on typical timings and criteria for testing
and certification.
Test driving phase 1: During this phase we will try out and test the new procedures
and workflow. This phase should result in:
o Proposal-criteria and procedures that we can use to certify filtering eCall
PSAPs,
o updated workflows for 112 PSAPs,
o algorithms for routing tables in the Mobile Network,
o improvement points for technical interoperations between the IVS, the filtering
eCall PSAP, the 112 PSAP and the mobile network.
Test driving phase 2: During this phase the updated workflows and certification
criteria from phase 1 will be verified by executing the certification tests on the
selected filtering eCall PSAP (Touring). The outputs of this phase are final
procedures for certification of filtering eCall PSAPs.
D3.1Pilot operation preparation report
02/09/2013 78 Version 1.0
Figure 24: Operational Timetable (Belgium)
BE: Implementation
BE: Test driving 1
BE: Test driving 2
D3.1Pilot operation preparation report
02/09/2013 79 Version 1.0
7.1.2 Detailed schedule
The picture below shows a detailed schedule of the tasks in the Belgian Pilot site and the relation to the WP3 tasks and milestones.
Figure 25: Detailed WP3 Schedule (Belgium)
D3.1Pilot operation preparation report
02/09/2013 80 Version 1.0
7.2 Bulgaria
Figure 26: Operational Timetable (Bulgaria)
7.3 Denmark
Long number testing will start November 2013 with a fleet of 11 vehicles being equipped with
retrofit IVS.
Spring 2014 a satellite precision testing will be performed.
H2 2014, if MNOs are ready, there will be a shift to 112-testing. In 112-testing period cross-
border and interoperability tests will be performed
When What How
November 2013 Start of pilot-testing
National coverage testing
All tests not involving
satellite-position precision,
interoperability and 112-call.
A fleet of 11 vehicles will be
equipped with retrofitted IVS-
units.
The units are not connected
to CAN-BUS, and will call a
pre-designated long number.
The vehicles have other
business all over Denmark,
and the testing will be
performed over a long period
(several months) with
manual initiated calls to the
test-facility.
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12
Phase 0Organisational assessment and live
operating preparations1.5.2013 31.10.2013
eCall test and development server pilot 31.7.2013 31.12.2013
Data colellecting and consolidation 1.1.2014 28.2.2014
Adapted PSAP software pilot 30.4.2014 31.12.2014
Data collecting and consolidation 31.5.2014 31.10.2014
Phase 1
Phase 2
Phase Operational Tasks2013 2014
Start Finish
D3.1Pilot operation preparation report
02/09/2013 81 Version 1.0
Spring 2014 Satellite-position testing One car equipped with
special satellite-position
calibration equipment, will
conduct testing on pre-
spotted locations for a few
days.
Summer 2014 If possible: Test with 112
(please note, that 112-test is
not part of the original
contract between HeERO2
and Denmark).
IVS’s in test-fleet will shift to
112 call.
Operators at all PSAP’s will
be instructed for test-
purpose. Test-drivers will be
instructed for test-purpose.
In this period, any eCall that
is not clearly a test-call will
be handled as a real
emergency call.
Summer 2014 Interoperability testing Exchange of retrofitted IVS’s.
Inserting roaming SIM-cards
in IVS’s
Cross border testing with
Germany and/or Sweden (to
be arranged)
Figure 27: Operational Timetable (Denmark)
D3.1Pilot operation preparation report
02/09/2013 82 Version 1.0
7.4 Greece
Figure 28: Operational Timetable (Greece)
7.5 Luxembourg
The Luxembourg pilot site testing will be executed in three phases (see figure below):
Phase 1: General tests of the eCall implementation.
This includes following tests:
o automatic tests with six vehicles driving in Luxembourg issuing an eCall in
defined intervals and manual tests
o manual tests during special test events where well defined test cases are
tested
Phase 2: Specific tests:
Based on the results of Phase 1 additional specific tests will be executed especially
cross border tests and interoperability tests
Phase 3: Pre-operational phase
In this phase the complete procedures of the PSAP handling eCalls will be tested.
When the eCall Flag is available after July 2014, special tests with the eCall-Flag will
be executed.
ID Task Name
1 Public procurement for the support in the pilot tests
2 Organisational arrangements
3 Installation and intiial functional testing of the equipment
4 Training of PSAP operators
5 Operations
6
7
8
9
10
Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar
2013 2014
D3.1Pilot operation preparation report
02/09/2013 83 Version 1.0
Figure 29: eCall Pilot Schedule (Luxembourg)
7.6 Spain
In general, the Spanish pilot will follow the overall timing defined in HeERO2:
- Pilot phase 1: M9 – M12
During this pilot phase the first proposal of the testing methodology and the first
implementation of the system will be tested. The results of these tests will be used to
optimize the system and the methodology before the pilot phase 2.
- Pilot phase 2: M17-M24
The data collected during this phase will be used for the final evaluation of the
implementation in Spain, being the final results and conclusions generated from the
KPIs collected during the period.
Previously, a period of laboratory testing is also considered in the framework of WP2.4
System Verification, between months M5-M9 (in order to perform verifications before pilot
phase 1) and in M16 (in order to perform verifications before pilot phase 2).
Figure 30: eCall Pilot Schedule (Spain)
D3.1Pilot operation preparation report
02/09/2013 84 Version 1.0
P2W tests
P2W operations will be performed in two different phases, laboratory testing and field testing.
Laboratory testing will validate the performance of each part of the P2W devices and each
main part will be tested separately. Nevertheless, the communication between all parts will
be also tested. Field testing will consist in two different stages. At the beginning the whole
development will be tested in real conditions and with real vehicles. Once the device and the
data collection mechanism are ready we will perform the real crash conditions in motorbike
races. Specifically, we will analyse the performance of the system in the Spanish Motorbike
Championship “Cuna de Campeones de Bankia”. This environment will permit realistic
testing in a semi-controlled environment.
In case of P2W two type of validations are important: on the one hand, the accident detection
system and on the other hand, the performance of the eCall inside the whole Spanish pilot.
The verification of these two parts will be made from the first stage of the pilot operations.
In conjunction with the WP4, we will analyse the ISO configuration for crashes. This
theoretical analysis will contribute to complete the information obtained from test.
Regarding temporal phases, the pilot operations will divide in two parts. First phase will be
executed on 2013 and then the results of this phase will be analysed. Then, from May-
December of 2014 the second phase will be performed. The detail of the planning of pilot
operation is the next table.
D3.1Pilot operation preparation report
02/09/2013 85 Version 1.0
Figure 31: Detailed Pilot Operation Schedule (Spain)
7.7 Turkey
Figure 32: Operational Timetable (Turkey)