d3.1pilot operation preparation report - heero · d3.1pilot operation preparation report version...

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


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


02/09/2013 4 Version 1.0


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.3 DENMARK .............................................................................................................................................. 26



4.4 GREECE .................................................................................................................................................. 31


4.4.2 .............................................................................................................................................................. 34


4.5 LUXEMBOURG ....................................................................................................................................... 35



4.6 SPAIN ..................................................................................................................................................... 42



4.7 TURKEY .................................................................................................................................................. 53



02/09/2013 6 Version 1.0


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


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


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


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


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


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.


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

[email protected]

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]

mailto:[email protected]

mailto:[email protected]


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:


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


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


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.


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.


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,


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.


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


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


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?


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


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


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


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



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)


02/09/2013 26 Version 1.0

4.3 Denmark


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.


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.


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


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.


02/09/2013 30 Version 1.0

Figure 5: eCall Pilot Architecture (Denmark)


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


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


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.


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


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:


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


02/09/2013 35 Version 1.0



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


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


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.


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.


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)


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.


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.


02/09/2013 41 Version 1.0

Figure 11: The handling of cross-border issues in Luxemburg’s eCall


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)


02/09/2013 42 Version 1.0

4.6 Spain


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


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


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.


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)


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:


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.


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


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.


02/09/2013 50 Version 1.0


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


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


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)


02/09/2013 53 Version 1.0

4.7 Turkey


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.


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.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.


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


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


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)


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:


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


X

Dangerous goods X

Number of vehicles involved

X

Table 13: Case File Data (Denmark)


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.



X X X X

Name X X X X

Telephone number X X X X


02/09/2013 60 Version 1.0


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


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


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)


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


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


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).


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.


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)


02/09/2013 65 Version 1.0


02/09/2013 66 Version 1.0

6.2 Bulgaria

Figure 16: eCall Operational Workflow (Bulgaria)


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.


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:


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)


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


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.


02/09/2013 72 Version 1.0

Figure 20: eCall Operational Workflow (Greece)


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.


02/09/2013 74 Version 1.0

Figure 21: eCall Operational Workflow (Luxembourg)


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


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)


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.


02/09/2013 78 Version 1.0

Figure 24: Operational Timetable (Belgium)

BE: Implementation

BE: Test driving 1

BE: Test driving 2


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)


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


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)


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


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)


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.


02/09/2013 85 Version 1.0

Figure 31: Detailed Pilot Operation Schedule (Spain)

7.7 Turkey

Figure 32: Operational Timetable (Turkey)

d3.1pilot operation preparation report - heero · d3.1pilot operation preparation report version...

Documents