eCall - EENA · Bergonzi, Luca Beta80 Group Bishop, Cathy OnStar Lumbreras, Cristina EENA Maher,...

34
EENA Operations Document eCall EENA asbl [email protected] - www.eena.org is a non-for-profit association 1 EENA Operations Document eCall Title: eCall EENA Operations Document Version: 2.0 Code: 3_1_5_eCall_v2.0.doc Revision Date: 13/08/2014 Status of the document: Draft For comments Approved

Transcript of eCall - EENA · Bergonzi, Luca Beta80 Group Bishop, Cathy OnStar Lumbreras, Cristina EENA Maher,...

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

1

EENA Operations Document

eCall

Title: eCall EENA Operations Document

Version: 2.0

Code: 3_1_5_eCall_v2.0.doc

Revision Date: 13/08/2014

Status of the document: Draft For comments Approved

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

2

This document was updated with contributions of the following EENA members:

Name Organisation

Bergonzi, Luca Beta80 Group

Bishop, Cathy OnStar

Lumbreras, Cristina EENA

Maher, Ann OnStar

Moseley, Russell Voltdelta

Novak, Gorazd Iskratel

Öörni , Risto VTT Finland

Rooke, Andy Ertico

Verlinden, Thom National Police, NL

Legal Disclaimer This document is authored by EENA staff members with contributions from individual members of EENA and represents the views of EENA. This document does not represent the views of individual members of EENA, or any other parties.

This document is published for information purposes only and it does not declare to be a statement or interpretation of EU law or the national law of EU Member States. This document is entirely without prejudice

to the views of relevant national statutory authorities and their legal functions and powers, whether under EU law or the national law of their Member State. Accordingly, under no circumstances may reliance be placed upon this document by any parties in compliance or otherwise with any applicable laws. Neither may reliance be placed upon this document in relation to the suitability or functionality of any technical specifications, or any other matters discussed in it. Legal advice, technical advice and other advice as relevant, may be sought

as necessary.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

3

Table of contents

1 Introduction .................................................................................................................................. 4 2 Legislation .................................................................................................................................... 5

2.1 Background ......................................................................................................................... 5 2.2 EU Recommendation on eCall ................................................................................................ 5 2.3 eCall Legislation ................................................................................................................... 6 2.4 Chronology .......................................................................................................................... 7

3 Approaches to provide eCall ............................................................................................................ 7 4 Means to initiate an eCall ............................................................................................................... 8 5 eCall service stakeholders ............................................................................................................... 8 6 Minimum set of Data ...................................................................................................................... 9 7 Table of relevant applicable standards ............................................................................................ 10 8 Pan European eCall ...................................................................................................................... 11

8.1 Overview ........................................................................................................................... 11 8.2 eCall Flag .......................................................................................................................... 12 8.3 Models .............................................................................................................................. 13 8.4 PSAP Procedures ................................................................................................................ 14 8.5 Training ............................................................................................................................ 14 8.6 Technical overview ............................................................................................................. 14

8.6.1 Telecommunication aspects ............................................................................................. 14 8.6.2 PSAP technical equipment ................................................................................................ 15

8.7 PSAPs Conformance Testing ................................................................................................ 16 9 Third party services supported eCall .............................................................................................. 17

9.1 Overview ........................................................................................................................... 17 9.2 Operational procedures and agreements for communication between PSAP and TPSP ................. 19 9.3 Technical communication with PSAPs .................................................................................... 20

10 The Harmonised eCall European Pilot Project (HeERO) ................................................................... 21 10.1 Description ........................................................................................................................ 21 10.2 National implementations .................................................................................................... 22

10.2.1 Belgium ......................................................................................................................... 22 10.2.2 Bulgaria ........................................................................................................................ 22 10.2.3 Croatia .......................................................................................................................... 22 10.2.4 Czech Republic ............................................................................................................... 23 10.2.5 Denmark ....................................................................................................................... 23 10.2.6 Finland .......................................................................................................................... 23 10.2.7 Germany ....................................................................................................................... 23 10.2.8 Greece .......................................................................................................................... 23 10.2.9 Italy.............................................................................................................................. 23 10.2.10 Luxembourg ................................................................................................................... 24 10.2.11 The Netherlands ............................................................................................................. 24 10.2.12 Romania ........................................................................................................................ 24 10.2.13 Slovenia ........................................................................................................................ 24 10.2.14 Spain ............................................................................................................................ 25 10.2.15 Sweden ......................................................................................................................... 26 10.2.16 Turkey........................................................................................................................... 26 10.2.17 Hungary ........................................................................................................................ 26 10.2.18 Cyprus, Iceland and Israel ............................................................................................... 27

10.3 HeERO Recommendations ................................................................................................... 28 11 NG eCall .................................................................................................................................. 31 12 Recommendation to stakeholders ............................................................................................... 33

12.1 Pan European eCall............................................................................................................. 33 12.2 Third Party Services supported eCall ..................................................................................... 33

13 EENA Requirements .................................................................................................................. 34

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

4

1 Introduction

Traffic incidents are one of the major causes of deaths and injuries in Europe. A timely and efficient

intervention of emergency services is crucial to save lives and reduce human suffering.

In many situations, the passengers of a vehicle involved in an incident may not be in a position to

call using a mobile phone, because either they have been injured or trapped or do not know the

local emergency number to be called. Additionally, they may be unable to provide emergency

services with a precise location, not only because they have suffered an incident but also because

they may only have a very approximate idea of their location, especially if travelling on rural roads

or whilst travelling abroad. Furthermore, travellers driving abroad may have language problems

trying to communicate with emergency services. It is worth mentioning that there are studies

which demonstrate that someone speaking to them and caring about what happened has a positive

impact on the stress levels of the people involved in an incident.

Moreover, there are many situations where there may be no witnesses because of the location or

time of the incident.

These are the main reasons why there is a need for an automated method to alert about incidents.

eCall is an in-vehicle emergency call system which:

automates the notification of certain traffic incidents. It transmits data from the vehicle and

establishes a voice channel between the vehicle passengers and the emergency services.

allows vehicle occupants to manually (potentially through a button) alert emergency

services of other emergencies in or around the vehicles such as traffic incidents that do not

meet the threshold of the automated notification such as a vehicle occupant with a medical

emergency or reporting the need for emergency services on behalf of another person.

The objective of this Operations document is to assemble all currently available information about

the issue. As in all EENA Operations document, recommendations and requirements are detailed.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

5

2 Legislation

2.1 Background

Road safety is one of the major elements of the European Union’s transport policy. In 2011 around

30 000 people were killed and more than 1.5 million injured in about 1.1 million traffic accidents on

EU roads. In this context, eCall can significantly contribute to the reduction of road fatalities and

alleviation of severity of road injuries.

Therefore, the harmonised implementation of an interoperable EU-wide eCall service in the EU has

been in the agenda of the Commission since 2005.

Given the absence of any significant progress in the voluntary deployment of eCall by the end of

2009, the Commission decided to conduct an Impact Assessment in order to assess the most

appropriate policy option to implement the EU-wide eCall service in Europe.

2.2 EU Recommendation on eCall

The Commission unveiled on 8 September 2011 its strategy on regulatory measures for eCall,

together with the adoption of the first part of this strategy, which consisted of a Commission

Recommendation on support for an EU-wide eCall service in electronic communication networks for

the transmission of in-vehicle emergency calls based on 112 (eCall) 1.

In its non-legislative resolution report on eCall: a new 112 service for citizens adopted on 3 July

2012, the European Parliament stated that eCall should be a public EU-wide emergency call

system, embedded in the vehicle and based on 112 and on common pan-European standards. It

urged the Commission to submit a proposal within the framework of Directive 2007/46/EC2 in

order to ensure the mandatory deployment of a public, 112-based eCall system by 2015 in all new

type-approved cars and in all Member States.

On 26 November 2012, the Commission adopted the Delegated Regulation (EU) No 305/2013

supplementing Directive 2010/40/EU of the European Parliament and of the Council with regard to

the harmonised provision for an interoperable EU-wide eCall.

1 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:303:0046:0048:EN:PDF 2 Full title: "Establishing a framework for the approval of motor vehicles and their trailers, and of

systems, components and separate technical units intended for such vehicles (Framework

Directive)".

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

6

2.3 eCall Legislation

Owing to the lack of progress for the voluntary deployment of eCall, the European Commission

recommended that the deployment should be mandated. As a result the European Commission has

been working with the European Parliament and the Council of Ministers to define the necessary

legislative instruments to make eCall work.

Of the three technical elements necessary to make eCall work 1) Vehicle 2) Mobile Network 3)

Public Safety Answering Point, items 1 and 3 will be mandated. All of the necessary measures for

legislation have now been completed; the current requirements can be found below.

On 13 June 2013, the Commission adopted two proposals that complete the Commission strategy

on eCall:

1) Public Safety Answering Points:

the deployment, at least 6 months before the date of application of the Regulation concerning

the mandatory fitting of the eCall device in vehicles (personal cars and commercial light

vehicles), of the eCall infrastructure required for the handling of all eCall on the EU territory,

with a final deadline for the deployment set at October 1, 2017.

the right of each Member State to organise its emergency services in the way which is most

cost effective and appropriate to its needs, including the right to let private organisations

recognised by the Member State deal with the receipt and handling of eCall, in accordance with

the specifications laid down by Delegated Regulation (EU) No 305/20133.

112 eCall handling free of charge for the users.

2) In-vehicle equipment:

The legislation for the in vehicle equipment will be dealt with by an amendment to the Type

Approval Regulations. In short this means that if a vehicle manufacturer wishes to sell a vehicle

in Europe then that vehicle MUST comply with Type Approval from a date to be determined.

eCall will form part of the type approval regulation for all new types of M1 and N1 vehicles

(passenger cars and light duty vehicles).

- Proposal for a Regulation of the European Parliament and of the Council concerning type-

approval requirements for the deployment of the eCall in-vehicle system and amending

Directive 2007/46/EC4

- European Parliament / Legislative Observatory (2013/0165(COD))5

3 eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32013R0305:EN:NOT 4 eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52013PC0316:EN:NOT 5 www.europarl.europa.eu/oeil/popups/ficheprocedure.do?lang=en&reference=2013/0165(COD)

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

7

2.4 Chronology

Recommendations

2009 Impact Assessment EU Commission

8 September

2011

strategy on regulatory measures for eCall

Commission Recommendation

EU Commission

3 July 2012 non-legislative resolution report on eCall:

urged the Commission to submit a proposal

within the framework of Directive 2007/46/EC

in order to ensure the mandatory deployment

of a public, 112-based eCall system by 2015 in

all new type-approved cars and in all Member

States

EU Parliament

26 November

2012

Delegated Regulation (EU) No 305/2013

supplementing Directive 2010/40/EU of the

European Parliament and of the Council with

regard to the harmonised provision for an

interoperable EU-wide eCall.

EU Commission

Legislation

13 June 2013 a proposal for a Decision of the EP and Council

on the deployment of the interoperable EU-

wide eCall in the PSAPs, in accordance with the

specifications laid down by Delegated

Regulation (EU) No 305/2013

EU Commission

14 April2014 European Council adopt the deployment of

eCall

EU Council

3 June 2014 Amendment to type approval discussed EU Parliament

and Council

3 Approaches to provide eCall

In case of a severe crash or after manual activation (see section 4), the in-vehicle equipment (IVE)

installed in the vehicle will trigger an emergency call. A minimum set of data (see section 6) with

relevant information about the incident is sent automatically and a voice channel with the vehicle is

set up.

The Pan European eCall (see section 8) uses the 112 number to send data and to establish the

voice channel between the passengers of the vehicle and emergency services.

Drivers can also decide to contract a private eCall service supported by Third Party Service

Providers (TPSP) (see section 9). In this case, the automatic or manually activated eCall arrives

first to the Third Party Service Provider’s call centre and then, in case of real emergency, data and

voice are forwarded to the most appropriate Public Safety Answering Point (PSAP) using the ‘long’

number of each PSAP. To establish an agreement with each TPSP or not is a decision to be taken

by the emergency services authorities.

Pan-European and TPS eCall are services that will potentially coexist. TPS is not replacing public

112 pan-European eCall based on the 112 emergency number. Therefore emergency services have

to be prepared to handle these pan-European eCalls.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

8

4 Means to initiate an eCall

Manual eCall: an eCall can be manually activated by vehicle passengers. The design and

implementation of the mechanism to trigger a manual eCall (e.g. SOS button) has yet to be

determined by vehicle manufacturers. In doing so, they have to make best efforts to

minimise the accidental activation of eCall.

Automatic eCall: In case of an incident, the deployment of one or more sensors generates

an automatic eCall with the immediate transfer of the crash data. The generation of this

type of eCall is dependant on the sensors system in the car.

5 eCall service stakeholders

eCall involves a number of different stakeholders all with separate responsibilities and tasks. The

main actors are:

In-vehicle equipment provider(s)

Mobile network operators (MNO)

Telecommunication National Regulators

Authorities (European / national / regional)

Public safety answering points (PSAP)

Emergency response organisations

Third party service providers, in case of TPS eCall

Citizens

Road operators

Data and voice

112 Most appropriate PSAP

Pan European eCall

Data and voice

Most appropriate PSAP

Third Party Service

Incident information + voice

PSAP Database

Automatic eCall

eCall automatically generated by activation of the sensors

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

9

6 Minimum set of Data

The Minimum set of Data (MSD) has been standardised by the European Committee for

Standardisation (CEN) (see the list of eCall standards in section 7).

In case of incident the public safety answering point (PSAP) receives a standardised set of data

(Minimum set of data – MSD) including the following information (this list is not exhaustive):

Message identifier: MSD format version (later versions to be backwards compatible with

existing versions).

Activation: whether the eCall has been manually or automatically generated

Call type: whether the eCall is real emergency or test call

Vehicle type: passenger Vehicle, buses and coaches, light commercial vehicles, heavy duty

vehicles, motorcycles

Vehicle identification number (VIN)

Vehicle propulsion storage type: This is important particularly relating to fire risk and

electrical power source issues (e.g. Gasoline tank, Diesel tank, Compressed natural gas

(CNG), etc.)

Time stamp: Timestamp of incident event

Vehicle location: determined by the on-board system at the time of message generation. It

is the last known vehicle’s position (latitude and longitude)

Confidence in position: this bit is to be set to “Low confidence in position” if the position is

not within the limits of +/-150m with 95% confidence

Direction: helpful to determine the carriageway vehicle was using at the moment of the

incident

Recent vehicle location n (Optional): vehicle’s position in (n-1) and (n-2)

Number of passengers (Optional): number of fastened seatbelts

Optional additional data (Optional): in some cases, optional data may be available in the

MSD (at the vehicle manufacturer discretion). This data incorporate a tag for the

identification in the beginning of the optional data (type and structure identification). This

data will be registered and maintained. PSAP will have free access such data registry data.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

10

7 Table of relevant applicable standards6

In this paragraph the relevant applicable standards are listed. Updated versions of the documents

are available through the standards bodies in each Member State. The communications standards

can be obtained through ETSI using the following link7

Pan-European eCall Operating Requirements – (PEOR) CEN EN 16072

eCall High Level Application Protocols (HLAP) CEN EN 16062

Third party services supported eCall –Operating requirements CEN EN 16102

eCall Minimum Set of Data CEN EN 15722

eCall requirements for data transmission 3GPP TS 22.101

ETSI TS 122 101

eCall Discriminator Table 10.5.135d 3GPP TS 24.008

ETSI TS 124 008

eCall Data Transfer – General Description 3GPP TS 26.267

ETSI TS 126 267

eCall Data Transfer – ANSI-C Reference Code 3GPP TS 26.268

ETSI TS 126 268

eCall Data Transfer – Conformance Testing

3GPP TS 26.269

ETSI TS 126 269

eCall Data Transfer – Characterisation Report

3GPP TS 26.969

ETSI TS 126 969

eCall Data Transfer – Technical Report - Characterisation Report 3GPP TR 26.969

ETSI TR 126 969

Data registry procedures ISO/EN

24978:2009

6 HeERO 112: List of Standards related to pan-European eCall

http://www.heero-pilot.eu/ressource/static/files/ecall_table_of_standards.pdf 7 www.etsi.org/standards-

search?page=1&search=eCall&matchall=true&matchany=false&matchexact=true&title=true&keywords=true&ed=true&versions=false

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

11

8 Pan European eCall

8.1 Overview

The 112 number is used to send data and to establish the voice channel between the passengers of

the vehicle and emergency services. It is based on a quasi-simultaneous data and voice link over

the same channel. The data link is realised by an in-band modem which has been specifically

designed and standardised for eCall. This approach guarantees an EU-wide availability of prioritised

and free eCall data transmission through established 112 voice call mechanisms. In the case

where the data is not sent or received for any reason, the eCall continues as a normal 112

emergency call.

The eCall is received directly by a public (or under public mandate) safety answering point (PSAP).

The PSAP in charge of handling eCalls may not be the same as the PSAP receiving and managing

normal 112 calls (see section 8.3). This has to be defined by the responsible authorities. The

service will be free of charge for the citizen.

M1 and N1 vehicles, i.e passenger cars and light duty vehicles (in the future, other types of

vehicles may be equipped with eCall but on a voluntary basis), will be equipped with the necessary

technology with the same technical standards and the same quality of services objectives.

The eCall in-vehicle system is powered-up and initialised when the vehicle is started.

After the triggering of the eCall (either manually or automatically), other communications that are

in progress are suspended, if needed. Microphone and loudspeakers are fully dedicated to the

emergency call. The in-vehicle system alerts the occupants that an eCall message is being sent.

At the same time the in-vehicle equipment connects to the network and the emergency call to 112

is established and routed to the most appropriate PSAP.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

12

After the eCall is picked-up by the PSAP telephone system it is routed to the PSAP in-band modem

and the MSD is transferred. At that moment, the PSAP has the automatic information given by the

vehicle available. After this, audio link is established and the PSAP operator is able to hear the

ambient noise and speak with the vehicle occupants, if possible. The PSAP operator may at any

time request that a new MSD is sent (e.g. data appears corrupted or inconsistent, or the PSAP

operator believes that the data may have changed). Once the communication with the vehicle is

finished, only the PSAP is allowed to clear down the call. At all times, the in-vehicle equipment

remains registered to the network to make call back possible.

The Pan-European eCall concept benefits from its direct prioritised emergency link to the

appropriate PSAP through the existing 112 mechanisms. The 112 call over the mobile network is

required to work in all European countries for free, even if no roaming agreement between the

vehicle’s home network and the guest network is in place. For the pan-European eCall, the priority

given to normal 112 calls in the mobile network also applies to the eCall data transmission. This

maximises the coverage and availability of the eCall service. The changes required in the mobile

networks are minor (eCall flag – section 8.2 - and PSAP routing tables).

Compared to the TPS eCall, the fact that a direct link to the PSAP is established reduces the

potential sources of failure in the emergency call provision. However, filtering of false emergency

calls (primarily for manual eCalls) will have to be done directly at the PSAP.

8.2 eCall Flag

Some emergency services have required a system to seperate eCalls from 112 calls in order to

route the calls differently. This is the main reason of the eCall flag implementation. The eCall flag

also makes it possible to differentiate automatically and manually initiated eCalls.

The flag is included in the data set travelling with the call triggered by the IVE. The flag enables

the telecommunication mobile network operator to route to a different long number (E.164

number) depending of the nature of the call, i.e. eCalls (also manual and automatically initiated

eCalls) and 112 calls.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

13

8.3 Models

In the event of an incident, the vehicle dials 112 and establishes a quasi simultaneous data and

voice communication with the PSAP. The PSAP can be public or under public mandate.

Pan European eCall can be implemented using different models. The main differences between the

models are:

All eCalls and 112 calls are routed (or not) to the same PSAP

Manual and automatic eCalls are routed (or not) to the same PSAP

Model I: eCalls routed as 112 calls. The

most appropriate PSAP receives 112 calls

and eCalls.

Model II: all types of eCalls are routed to

a dedicated PSAP only for eCalls. 112

calls continue to be routed to the 112

PSAP.

Model III: manually triggered eCalls and

automatically triggered eCalls are routed

to a different PSAP (it can be the same

PSAP for 112 calls, e.g. dedicated

manual eCall PSAP can be the same as

112 PSAP)

automatic eCall PSAP

manual eCall PSAP

Voice+MSD

Voice+MSD

112 PSAP

SOS

MSD+voice

112 PSAP

Most appropriate eCall PSAP

MSD+voice

112 PSAP

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

14

8.4 PSAP Procedures

PSAPs have to develop new procedures to handle eCalls. eCalls have to receive the same treatment

as other 112 calls (priority, language, privacy, etc.). The call-handling is to be achieved in line with

national procedures and regulation.

Nevertheless, there are special situations which PSAPs have to take into account, e.g. when data

arrives at the PSAP but there is no voice connection or when data arrives at the PSAP and voice

connection is established but nobody speaks.

Issues to take into account:

Silent calls when MSD is available (procedures could be different if it is a manual or an

automatic call)

Silent calls when MSD is not available (procedures could be different if it is a manual or an

automatic call)

Call back

Multiple generation of manual or automatic eCalls: prioritisation of automatic eCall

Request a new MSD

VIN decoding

Management of the “No confidence in position” flag

eCall routed to the wrong PSAP

Forwarding the call to another PSAP

Multilinguism

If the calls are not handled in the same PSAP as 112 calls, protocols to transfer the data to the 112

PSAP need to be established.

8.5 Training

The PSAP operator needs to be trained in the eCalls procedures and software.

8.6 Technical overview

8.6.1 Telecommunication aspects

Network operators:

eCall is supported via wireless communications networks commonly implemented by European

network operators. This ensures the availability of a real time secure transport mechanism that

makes quasi simultaneous data transfer and voice call feasible.

SIM Card:

The in-vehicle system has a valid SIM that enables the provision of the eCall service. It is to be

configured only for the purpose of making an eCall, or it could also be used, in addition and as

optional, for commercial service provision. In the first case, the IVE will be in a dormant mode (not

traceable and active only in case of eCall triggering).

Priority of the call:

eCall has the same priority as a 112 call.

Routing of the 112 call by the network:

Competent authorities have to decide where and how eCalls have to be routed. As already

mentioned, the eCall flag makes possible that eCalls are received by a different PSAP than 112

calls.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

15

Even if eCalls and 112 calls are routed to the same PSAP, it can be decided to route them to a

different group of telephone lines.

Provision of the location:

The caller (vehicle) location is provided by the MSD through GNSS coordinates. In the event that

the MSD does not reach the PSAP, the caller location is provided by the network operators like for

112 calls.

Roaming:

The in-vehicle equipment has a Pan-European roaming capability as for 112.

8.6.2 PSAP technical equipment

PSAPs have to adapt their equipment to be able to receive eCalls. They need to communicate with

the in-vehicle equipment (IVE) using an in-band modem and they have also to ensure their

software to make the MSD information available for PSAP operators. The PSAP in-band modem has

relatively low complexity. It can be implemented as software running on standard computing

equipment. Before updating the technological equipment of the PSAP, the amount of eCalls that

will be handled has to be estimated.

Currently, the technical equipment of 112 PSAPs may be very different. Some European 112 PSAPs

are equipped with very advanced technology and others only have very basic communication tools.

It is highly recommended that PSAPs are equipped to be able to handle the location of the 112

calls automatically.

PSAPs receiving eCalls will have to be equipped with a server with an in-band modem and have it

connected to the public switched telephone network via a digital interface.

Additionally, a PSAP receiving eCalls is required to be equipped with a software application that

could either be a special eCall application or integrated within the PSAP's interface software. It

should provide at least these functionalities:

warn the operator about a new eCall

display the minimum set of data

decode VIN (vehicle identification number)

warn the operator about the availability of the voice call

provide a call-back capability

request a new MSD

hung up an eCall

provide a geographical information system: display the location of the vehicle, direction and

the last positions (if available)

etc.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

16

8.7 PSAPs Conformance Testing

Conformance testing of PSAPs is considered as an important part of the eCall deployment in

Europe. The delegated regulation 305/2012 of the European Commission8 states that the member

states have an obligation to designate the competent authorities for assessing the conformance of

PSAPs to the specifications of eCall:

“Conformity assessment Member States shall designate the authorities that are competent for

assessing the conformity of the operations of the eCall PSAPs with the requirements listed in Article

3 and shall notify them to the Commission. Conformity assessment shall be based on the part of

the standard ‘Intelligent transport systems — eSafety — eCall end to end conformance testing’ (EN

16454) that relates to PSAPs conformance to pan-European eCall.” (European Commission 2013,

Article 4)

The same regulation also states that the PSAPs must be able to demonstrate conformity with the

European standards. The first part of article 7 of the regulation states that the conformity

assessment must be based on the tests included in the related European standards EN16454 (see

section 7):

“Rules on liability

The eCall PSAPs must be able to demonstrate to the competent authorities that they meet all

specified conformance requirements of the eCall standards listed in Article 3(1) [EN16062 and

EN16072, author’s own note] in respect of the part(s) of the system under their design and/or

control. They shall be liable only for that part of the eCalls for which they are responsible, which

starts at the time the eCalls reach the eCall PSAP, in accordance with national procedures”.

At present, specifications of conformance tests for eCall are available as a CEN technical

specification (CEN TS16454) but not as a full EN standard. The EN standard on conformance

testing is currently under approval (CEN 2014), and it is expected to be available within a few

months.

It should be noted that also other testing than conformance assessment may be necessary to

achieve a functional and high-quality eCall service. For example, it may be necessary to test the

performance of the PSAP solution, its reliability and its correct operation in exceptional but possible

situations (e.g. a situation with a large number of simultaneous eCalls being received, support for

all defined MSD versions, presentation of MSDs with optional additional data, etc.).

8 European Commission. 2012. Commission delegated regulation (EU) No 305/2013 of 26 November 2012 supplementing Directive 2010/40/EU of the European Parliament and of the Council with regard to the harmonised provision for an interoperable EU-wide eCall. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:091:0001:0004:EN:PDF

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

17

9 Third party services supported eCall

9.1 Overview

The term TPS eCall is used to describe an eCall service supplied by a Third Party Service Provider

(TPSP) under the responsibility of that supplier.

A member state can decide to outsource the reception of Pan European eCall to a third party, but

then the responsibility still lies with the member state. This situation is not meant by TPS eCall.

The proposed European regulation leaves room for the existence of TPS-eCall next to the Pan

European eCall under the following conditions:

Every new car must be equipped with the pan European eCall IVE

A TPS provider may offer the owner of the car TPS eCall

The owner should be informed by the TPS provider of all the consequences of the use of

TPS eCall

The owner may decide to discontinue the TPS eCall service. In that case Pan European eCall

will be activated again

Member States will choose how to structure emergency services call handling. This may or

may not include private organisations/TPSP. If private organisations/TPSP are not included,

Pan European eCall must be active.

In Private solutions Third Party Service for eCall (TPS-eCall) case data is transmitted to a private

company, known as the third party service provider (TPSP), and voice channel is established

between the vehicle passengers and this TPSP. In case of a real emergency, the TPSP operator

contacts the most appropriate PSAP and forwards all relevant information concerning the event,

including the information specified by the minimum set of data (MSD). If required by the PSAP

operator, PSAP and vehicle passenger can communicate via voice.

In TPS eCall, the emergency data transmission can be realised via the dedicated in-band modem

technology or via other solutions like SMS.

It should be noted that at the PSAP level, pan-European eCall has to be also implemented even if

the majority of vehicles in a specific region are equipped with TPS eCall: roaming vehicles from

other regions might use the pan-European eCall which will then use the direct 112 connection to

the PSAP for eCalls. In addition, it is possible for vehicles that are serviced by a TPS to revert to

pan-European eCall if the vehicle owner no longer wishes to use the services of a TPS or in the

event that the TPS connection cannot be initiated.

Third-Party Service (TPS) eCall is based on using a third party to filter and route the calls prior to

the PSAP routing. Voice call and MSD (or similar) is transmitted to the TPSP Call Center using two

channel communication methodology usually leveraging SMS technology and in-vehicle satellite

positioning technology. The calls are received by call center agents (TPSP operators) and handled

accordingly of the type of the call (emergency call, assistance call, etc.). In case of emergency, the

TPSP operator will transmit both voice and data (an IP address can be also transmitted) to the

appropriate PSAP with jurisdiction at the site of the emergency (if long numbers of this PSAP is

available to the TPSP operator).

TPS eCall will usually be based on the subscription of the customer (vehicle owner) with the third

party service provider, also offering additional services such as assistance calls, breakdown

assistance and/or other telematics services.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

18

In case of emergency:

The vehicle calls the TPS centre, making a normal call (not treated as an emergency call by the

mobile network operator) and sends the MSD or similar information (GNSS position, vehicle

identification and sensor information if available).

The data is analysed, treated and, if possible, enhanced by the Telematic service provider

The responsible PSAP will be identified and called via the long-numbers; the incident

information is then exchanged through a voice conversation or other means if available;

Conference Bridge with the driver will be activated if requested by the PSAP operator or the

vehicle occupant(s). Procedures and interfaces for the transmission of the enhanced incident

data (if different from the pure MSD) will have to be agreed between the third party service

providers and the PSAPs in each EU Member States.

The following table shows in brief the main differences between Pan European and TPS- eCall

Pan European eCall TPS eCall

Purpose/service Only emergency calls Combined with other value-added services (ie

track and trace, B-call)

Mandatory Yes (automatic and

manual)

MS has to accept

No, optional

MS may require Pan European eCall only

Type of

communication

Voice + MSD, in band Voice + MSD, serviceprovider specific

Destination PSAP, fixed in national

routing schemes MNOs

must implement (national

law)

Private answering point; TPS specific

Data Only MSD according to

standards

MSD and additional data (not yet standardised);

TPS specific

Priority Handled as normal 112

emergency call with priority

in the networks

Call has no priority in the networks

Traceability Only when eCall-message is

triggered

Dependent on agreement customer/TPSP

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

19

The European eCall Implementation Platform (EEIP) decided in its meeting 25th April 2013 to

establish a task force looking into the issue of how Third Party Service Providers (TPSPs) could

forward their calls to Public Safety Answering Points (PSAPs) when there is a need for emergency

services in relation to an incident reported via TPS eCall. Whereas it is compulsory for Member

States (MS) to establish systems for Pan-European eCall, the implementation of TPS eCall is

voluntary. For a system to be labelled eCall it has to meet the requirements as laid out in the CEN-

standard DIN EN 16102:2012-03 (EN 16102), intelligent transport systems – Ecall – Operating

requirements for third party support. This standard does not specify how and in what format the

call, including the data transmitted, is to be put forward to the PSAP.

The results of this taskforce are described in the following paragraphs.

9.2 Operational procedures and agreements for communication between PSAP and

TPSP

TPSPs need to reach an agreement with each MS where they want to provide their services. It is

worth mentioning that MS do not have any obligation to accept TPS eCall.

This agreement has to be clear on what are the responsibilities of each partner. This clarification

needs to be available for the customers.

The general principle will be that the actors are responsible for the part of the action chain for

which they provide the service.

It will be for the TPSP to ensure that data from the vehicle is received and dealt with in

a proper way, and that the audio link is functioning properly. They will also be

responsible that the handling of the incident, including the decision on whether or not

the handling of the incident is transferred to the PSAP, is in line with the agreement

between TPSP and the MS.

It is the responsibility of the national authorities to decide to where TPS calls are to be

routed, what the communication links are, how the links are activated etc.

The PSAP will be responsible for being able to take over the handling of the incident, in

line with pre-set procedures. Once the data and voice channel has reached the PSAP, it’s

up to them to handle the incident in line with their general procedures.

In addition to the service meeting the requirements of EN 16102, MSs may set their own

requirements. It is however expected that most MSs will use the same or similar requirements. It

is strongly recommended to set up a common list of requirements with the possibility for each MS

to add a few specific requirements

It has also to be established:

The conditions under which a member state is willing to accept TPS eCall

How the communication between PSAP and TPSP should take place

The boundaries of the jurisdiction of the PSAPs in each EU member states, and how to

contact them.

Areas of responsibility in case of lost of communication between the PSAP and the TPSP

A private company that provides non-emergency telematics services to their customers may

receive emergency calls if the customer uses the non-emergency connection. Private companies

that do not provide Third party services supported eCall, may still need boundaries and long

numbers to contact a PSAP in this instance.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

20

9.3 Technical communication with PSAPs

Today there are different alternatives:

Voice

Web service data push interface described in CEN EN 16102

Integrated interface in the PSAP software

A web based interface which works independently from the PSAP infrastructure and which

required a minimum equipment at PSAP (Pc, internet access); such an interface is today

implemented by some TPSPs.

Whereas the organisational and administrative needs are clear and ready to be dealt with, more

work is needed on the technical side. Standardisation on how to present and forward the MSD and

additional information is required.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

21

10 The Harmonised eCall European Pilot Project (HeERO)9

10.1 Description

HeERO pre-deployment pilot, co-funded by the European Commission, addresses the pan-European

in-vehicle emergency call service "eCall" based on 112.

It is being conducted in 2 phases

HeERO 1 - During three years (January 2011 to December 2013), the nine European

countries forming the HeERO consortium carried out the start-up of an interoperable and

harmonised 112 based in-vehicle emergency call system. Croatia, Czech Republic,

Finland, Germany, Greece, Italy, The Netherlands, Romania and Sweden shared all the

same high-level objective: prepare the local e112 eCall infrastructure necessary for the

provision of a sustainable eCall service for the European citizens and share their

experiences with the other EU Members and Associated States.

HeERO 2 - started on 1st January 2013 and will last 2 years. 6 countries (namely

Belgium, Bulgaria, Denmark, Luxembourg, Spain and Turkey) have joined the other 9

pilot sites of HeERO 1.

The eCall system will help to achieve the EU's objective to decrease the number of severe road

injuries and fatalities to 50%.

The introduction of eCall is expected to save 2,500 lives troughout Europe each year. Although the

obligation for the introduction only refers to making emergency calls to 112, more benefits can be

achieved by linking eCall to trafic management systems (in order to support the flow of traffic and

to prevent secundary accidents), and to add data on hazardous cargo. The HeERO project also

deals with these functionalities.

9 HeERO project website: http://www.heero-pilot.eu/view/en/index.html

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

22

10.2 National implementations

In this section national implementations of eCall are described. Figures of the eCall model have

been included in the countries where the eCall model differs from the 112 model10,

10.2.1 Belgium

Belgium is a HeERO 2 Pilot Site and benefits from the experience of HeERO 1. One of the major

concerns expressed by the Belgian Government concerning the deployment of eCall based on 112

was the ability of the national PSAP structure to cope with the predicted influx of eCall which prove

to either be false or inappropriate. In response to this, the Belgium pilot site has defined an

architecture which will permit a screening instance to be placed in front of all eCall received, being

either TPS or 112 eCall. This is to ensure that the PSAP only receive genuine calls. The organisation

chosen to operate this pilot is the Touring Club of Belgium, who are a commercial concern, and as

such licenced by the Belgian Government for this purpose. This is one of a number of different

solutions trialed in HeERO in direct response to concerns expressed by member states to the issue

of false or inappropriate eCall.

Filtering instance private Belgium

10.2.2 Bulgaria

Bulgaria is another HeERO 2 pilot site again benefiting from the experience of HeERO 1. The pilot

site is set up to receive eCall direct to the PSAP. The additional area of focus in Bulgaria concerns

the development of after-market in vehicle equipment that can be fitted to older vehicles. This is in

direct response to the needs of the member state where the age of the vehicle fleet is older and

the turnover of new vehicles less.

10.2.3 Croatia

Croatia is a HeERO 1 partner; they are one of 3 HeERO 1 pilot sites that declared themselves eCall

ready at the conclusion of the HeERO 1 project in December 2013. A significant level of work which

10 112 models: 112 Service Chain description: www.eena.org/uploads/gallery/files/operations_documents/2011_06_10_112_service_chain_description.pdf Technical implementation of 112 : http://www.eena.org/pages/112-implementation

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

23

benefitted all pilot sites took place in Croatia. Croatia also undertook a series of live crash tests to

examine the effectiveness of eCall in a variety of scenarios.

10.2.4 Czech Republic

The Czech Republic is a HeERO 1 partner; they have also declared themselves ready to receive

eCall. The Czech Republic has carried out extensive research in the management of eCall in the

PSAP, and still maintains a remote station to handle eCall.

10.2.5 Denmark

Denmark is a HeERO 2 partner; it has chosen to upgrade all PSAPs’ in Denmark to make Denmark

eCall ready. Initially the chosen approach was to not deploy the eCall flag using the natural call

management software to deal with eCall sending the call to the next available position, as opposed

to a dedicated position. This has now been revised, and whilst all PSAP will be upgraded the eCall

flag will be utilised.

10.2.6 Finland

Finland is a HeERO 1 partner. Finland has a unique role in being required to handle both eCall

based on 112 and the potential to be able to handle ERA GLONASS calls (This is the Russian eCall

System). Throughout the project Finland utilised a PSAP emulator as Finland is due to commission

a new PSAP system in 2015. The HeERO project has proved the necessary specifications to all the

new PSAP system to be developed to ensure eCall compliance.

In addition Finland have undertaken early work on eCall for Powered 2 Wheeled Vehicles.

10.2.7 Germany

Germany is a HeERO 1 partner. Germany is one of a number of MS who are federated; the result

of this is that there is no uniform approach to the deployment of eCall in Germany. The pilot site

chosen for Germany is located in Niedersachsen. The solution developed for the German pilot site

is innovative and in direct response to the needs of Germany (There are 263 PSAP). The solution

places a server solution in front of the existing PSAP infrastructure, providing a highly cost effective

solution. The solution has now also been deployed in Luxembourg Denmark United Emirates and

Japan.

10.2.8 Greece

Greece is a HeERO 1 partner. Greece encountered severe difficulties in the early stages of HeERO 1

and as a result received an extension into 2014. The solution deployed in Greece utilises the PSAP

system installed for the 2004 Olympics. The tests in Greece have shown that Greece is now

another MS to be very close to eCall ready with 1 mobile network operator installing the eCall flag

and the remaining network committed to be upgrade early in 2015.

10.2.9 Italy

Italy is a HeERO 1 partner. The eCall solution developed is one of a number of possible eCall

solutions for Italy. This solution located in Varese in the Piedmont Region of Lombardy also offers a

screening function. A unique circumstance in Italy is that 112 is allocated to the Carabinieri

(National Police) clearly across the rest of Europe 112 is the universal emergency number. The

solution deployed in Varese ensures that the eCall (and all other 112 calls) are directed to the

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

24

correct emergency service. The decision over which model Italy will follow is yet to be taken.

However the system deployed in Varese is capable of handling both eCall, TPS eCall, bCall and the

existing 112 calls.

10.3 Luxembourg

Luxembourg is a HeERO 2 Pilot Site. Luxembourg has the responsibility of advancing the

knowledge of eCall Trucks and Dangerous Goods, following the work carried out by the HeERO 1

Pilot Site in the Netherlands.

Luxembourg will have a new PSAP in 2015. As a result the existing PSAP architecture as shown

below is being utilised for the HeERO 2 project, with the addition of the HeERO 1 Oecon server

installed to allow the existing system to deal with eCall.

10.3.1 The Netherlands

The Netherland is a HeERO 1 Pilot Site, there has been extensive work carried out by PSAP in

defining how eCall should be handled in the Netherlands. Much of the experience can be

transferred to other PSAPs. The Netherlands have opted to discriminate between manual and

automatic eCall. Where an automated eCall is received, this will be transferred directly to the PSAP

level 2 for dispatch as it is felt that on the balance of probabilities an event has occurred, which will

require the mobilisation of a rescue resource.

10.3.2 Romania

Romania is a HeERO 1 Pilot Site and one of the three HeERO 1 sites that declared themselves

ready to receive eCall at the end of the HeERO 1 project. In addition Romania has carried out a

great deal of work in defining how eCall based on 112 should be processed by the call handlers. In

addition Romania has continued with developmental work to developed eCall in-vehicle equipment

that can be fitted to older vehicles.

10.3.3 Slovenia

Slovenia is a HeERO 2 associated partner and is technically ready to receive eCall on the whole its

territory as soon as remaining mobile operators deploy eCall flag in their networks. Slovenia is

divided into 13 PSAP regions and each of the existing PSAPs is enabled to receive eCall.

The solution for the Slovenian pilot site is extremely cost effective. An essential part of the solution

is the server for eCall handling, which is situated at national telecom operator. The server receives

eCall, decodes MSD, and reroutes voice calls and decoded MSD information to the most

appropriate of 13 regional PSAPs. Routing is done either by exploiting geo-coordinates from MSD

or called party number, predefined by mobile operator. In the future, following eCall traffic

demand, the existing server will be extended with additional capacity, as well as another server will

be deployed for geographic redundancy.

Further studies will be focused to TPS and using of the eCall infrastructure for commercial services.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

25

Slovenian eCall pilot site architecture

10.3.4 Spain

Spain is a HeERO 2 Pilot site; this is the largest site across both HeERO 1 and HeERO 2. Spain has

chosen to be another member state to employ a filtering instance in front of PSAP level 1. This is

not primarily due to the PSAP receiving high levels of false call, but owing to the PSAP structure in

Spain to ensure that the call is directed to the correct stage one PSAP. Spain is also leading work

on the development of eCall for Powered 2 Wheeled Vehicles (P2W).

Due to the complex nature of 112 in Spain a complete architecture has been developed to deal

with eCall in Spain which is shown below. The screening instance for Spain is maintained by the

Spanish Road authority (DGT). Whilst the function achieved by both Spain and Belgium are the

same in the screening of all eCall, Belgium is a commercial enterprise licensed by the Government

to carry out the function whilst in Spain the filtering instance is maintained by a Government

Agency.

IX Ljubljana IX Maribor

13 PSAP RegionsMobile Network

MSD

VOICE

MSD

VOICE

Mobile Switching

CenterBase

Station

IVE

NATIONAL TELECOM OPERATORADMINISTRATION FOR CIVIL PROTECTION AND DISASTER

RELEIF

PSAP

PSAP

PSAP

National Telephone Network

NATIONAL AUTOMOBILE ASSOCIATION

eCall Node

MSD

VOICE

VOICEDATA (MSD)

VOICE

DATA (MSD)

VOICE

DATA (MSD)

DA

TA (filtered

MSD

)

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

26

Spain eCall PSAP filtering instance

10.3.5 Sweden

Sweden is a HeERO 1 Pilot Site. The part of the HeERO 1 program carried out in Sweden did not

involve the PSAP which is privately operated in a licence from the Government. This was due to

potential conflict with 112 operations. The PSAP providers were in consultation throughout the

project, but were not project partners. Much of the understanding of the behaviour of the mobile

network and PSAP architecture was original either detected or formulated in Sweden along with

many of the optimisations for the eCall standards. Sweden has completed the HeERO project, but

as yet are not eCall ready as there is still a number of political considerations to be resolved before

Sweden will commit. It should be noted that Sweden is a MS where the presence of TPS eCall is

very strong.

10.3.6 Turkey

Turkey is a HeERO 2 Pilot Site. Whilst not in the EU, they are an approved Country, and as such

able to take part in funded work. Turkey has a highly progressive program for the conversion of all

of Turkeys regions to 112. The region of Antalya has been chosen to act as the pilot site for the

development of a 112 architecture which is capable of being rolled out throughout Turkey, as well

as being able to deal with eCall based on 112. The architecture selected by Turkey has also allowed

the Antalya PSAP to have a screening instance within the PSAP room itself. All PSAP received are

screened at one position before being handed off to the call takes and then the dispatchers. The

solution is scalable and also has redundancy built in. the system will be capable of passing eCall to

be answered to another region, as more come on line.

10.3.7 Hungary

Hungary is a HeERO Associate pilot site, for the last 2 years through both HeERO 1 and HeERO 2

Hungary have received both technical and practical assistance from the project coordination team,

and from the Finnish HeERO 1 pilot site. Hungary have continued with a program of upgrade and

testing. This was presented to the rest of Europe in December 2013. Hungary has also concluded

nex studies on the efficacy of eCall, which is available through the ERTICO website. Hungary is

currently in the process of commissioning a new PSAP system.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

27

Hungarian PSAP Architecture for eCall

10.3.8 Cyprus, Iceland and Israel

The above Countries are all HeERO Associate Countries. There are now a total of 9 across the

globe. The activity for these is varied.

Cyprus has carried out a study of the necessary work required, which could be considerable.

Iceland whilst not an EU member has actively joined the HeERO project. Iceland is currently

purchasing IVE to test with the PSAP in Iceland.

Israel has carried out a study of the needs for eCall in the State of Israel with the assistance of the

HeERO Coordination Team. The conclusion is that in effect the vehicle usage is closed in Israel.

Owing to the political and religious needs of the Country, there are 3 paid for eCall services that

will be provided for Israel.

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

28

10.4 HeERO Recommendations

The experience gathered in the member states participating in HeERO was used to identify the

challenges and enablers for eCall deployment and to prepare recommendations for eCall

deployment in Europe.11 The way the recommendations were developed is presented in the

following figure. The recommendations were developed taking into account the barriers and

enablers for eCall identified in HeERO D6.2 (Öörni and Brizzolara 2014), the solutions to eCall

deployment barriers identified in HeERO D6.4 (Öörni et al. 2014) and the results of other work

packages of HeERO.

Development of recommendations for EC, member states and other stakeholders (Öörni et al.

2014).

The recommendations given by the HeERO project are aimed at EU member states, European

Commission, standardisation organisations and other stakeholders. The recommendations are

presented in the following tables.

The recommendations for member states intending to implement eCall are summarised in the first

table (Öörni 2014).

Recommendation

Id Description

MS1 Increase the awareness of stakeholders on member state level on impacts, benefits and costs of eCall and the implementation options available. Utilise the results of HeERO and HeERO2 projects, literature available on the subject and other

11 Öörni, R. 2014. Recommendations on implementation and operation of eCall. Deliverable D6.5 of HeERO project (Harmonized eCall

European pilot). http://www.heero-pilot.eu/ressource/static/files/heero_wp6_del_d6-5-recommendations-on-implementation-and-operation-

of-ecall_v0-5.pdf [accessed 7th July 2014]

Öörni, R. and Brizzolara, D. 2014. eCall Deployment enablers and opportunities and challenges: final report, Deliverable D6.2 of HeERO

project. http://www.heero-pilot.eu/ressource/static/files/heero_d6.2_deployment_enablers_and_opportunities_and_challenges_v.0.8.pdf

[accessed 7th July 2014]

Öörni, R., Vilkman, A., Pritvic, P., Lumbreras, C., Grzebellus, M., Coldeway, B., Roine, M., Brizzolara, D., Zulkarnain, Z. 2014.

Implementation roadmap and guidelines for eCall deployment in Europe. Deliverable D6.4 of HeERO project. http://www.heero-

pilot.eu/ressource/static/files/heero_d6.4-ecall-guidelines_v1.1.pdf [accessed 7th July 2014]

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

29

Recommendation

available information sources such as iMobility effects database

MS2 Communicate the impacts and implementation options for eCall to the key stakeholders on member state level

MS3 Organise round table discussions and working groups on eCall on member state level

MS4 Identify a key stakeholder which monitors and possibly also coordinates the overall process towards eCall deployment and formally or informally takes responsibility for solving problems and for the whole process

MS5 Establish a national eCall platform

MS6 Analyse the architectural and deployment options available for eCall. Utilise the results of HeERO and HeERO2 projects, eCall standards and literature available on the topic

MS7 Develop and publish a national eCall implementation roadmap or an implementation plan. The

roadmap should describe - the actions necessary to achieve a functional eCall service chain - the roles of different stakeholders

- the schedule for eCall deployment including the various elements of the deployment process and eCall service chain (especially: eCall discriminator and PSAP upgrades)

MS8 Encourage and facilitate mutual cooperation and technical support between stakeholders within a

member state

MS9 Implement the eCall discriminator in mobile networks; cooperate with the mobile network operators and the national telecommunications regulator

MS10 Implement eCall reception and processing capabilities in PSAPs. Use the architectural solutions

defined in the national eCall implementation roadmap or implementation plan

MS11 Perform eCall end-to-end tests on member state level to ensure correct functioning and reliable operation of eCall. The tests should cover different mobile network operators, different PSAPs and different geographical areas.

MS12 Perform eCall interoperability tests. Integrate interoperability tests with the end-to-end tests.

MS13 Share and publish the results of the interoperability tests carried out after HeERO and HeERO2 – for example in the context of EeIP or in international conferences.

MS14 Monitor the status of retrofit IVE products and consider actions, if significant challenges or risks are encountered

MS15 Consider centralisation of reception and handling of eCalls to a few key PSAPs as an interim solution

if it is difficult to implement eCall reception or processing capabilities in all PSAPs at once.

MS16 Consider the use of specifications defined in EN16102 if TPS-eCall is integrated with PSAPs.

MS17 Analyse the impact of the network echo canceller disabling tone on the reliability of MSD transmission

and implement NEC disabling tone in PSAPs, if clear improvement can be observed

MS18 Analyse the reliability of eCall on member state level and the factors contributing to it. Implement necessary changes to the communication networks or to the PSAP (for example, changes to codecs used or transcoding between codecs along the call path from IVE to PSAP)

MS19 Monitor the service quality of E112 emergency calls; analyse the status of national regulations concerning the coverage of the mobile networks and handling of 112 calls, and implement changes if necessary

MS20 Provide training appropriate training for PSAP staff

MS21 Initiate a MSD retransmission when the first MSD transmission in the beginning of the connection fails.

MS22 Use the voice connection to communicate with vehicle occupants if the MSD transmission in the beginning of the connection fails.

MS23 Support development of certification scheme for eCall IVE and eCall in-band modem components.

MS24 eCall MSD transmission is not always successful. Take this into account when preparing national guidelines for operation of eCall (for example, guidelines for call handling or risk assessment in PSAPs)

MS25 Reduce the number of link layer acknowledgements (LL-ACKs) transmitted by the PSAP after a

successful MSD transmission or omit transmission of LL-ACK completely to reduce voice channel blocking time.

MS26 Take silent calls into account when developing national guidelines for operation of eCall (for example, guidelines for call handling and risk assessment)

MS27 Use the information available via voice connection such as background noise in case no one in the

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

30

Recommendation

vehicle is able to talk.

MS28 Use the information included in the MSD in handling of silent calls and calls in languages not understood by the PSAP.

MS29 Validate the location of the caller using network based positioning available for all E112 calls. Use network based positioning in case where the position included in MSD cannot be trusted.

MS30 Educate car users on the operation and correct use of eCall with information campaigns.

MS31 If necessary, implement validation of incoming calls before connecting them to a PSAP operator.

MS32 Document the erroneous operation of mobile phone models affected by the problem and contact the equipment manufacturers.

MS33 Ensure that mobile networks support E.164 numbers with the length up to 15 digits as defined in GSM and 3G specifications. The problem can likely be solved with a software update of the mobile

network affected by the problem.

MS34 Encourage participation in eCall interoperability events.

MS35 Participate in international cooperation in the context of EeIP to exchange information and best

practises and to contribute to further development of eCall

MS36 Define appropriate call handling procedures for automatic and manual eCalls (for example, handling of silent calls and calls in languages other than the official languages of the member state)

MS37 Use HeERO training manuals when providing training to PSAP operators

Recommendations for the European Commission are summarised in the Recommendations Table 2 (Öörni 2014). Recommendation

Id Description

EC1 Complete European level regulation which mandates the implementation of eCall in PSAPs, communication networks and new type-approved vehicle models

EC2 Monitor the status of retrofit and OEM IVE products and consider regulatory actions if significant risks or challenges are encountered

EC3 Support the development of certification scheme for eCall IVE and in-band modem components (this work is currently being carried out in HeERO2)

EC4 Consider the need for development guidelines for retrofit IVE products; support the development of guidelines for example by European eCall implementation platform (EeIP)

EC5 Initiate and support further research and related road-mapping work on the long-term evolution of eCall including analysis of options available to manage the lifecycles of vehicles and wireless communication networks

EC6 Facilitate the cooperation of eCall stakeholders and further development of eCall specifications (such as specifications for PTI) in the context of EeIP

EC7 Continue support to standardisation and further research on eCall taking into account - the work carried out by ETSI STF 456 and IETF working group ECRIT on the future

development of eCall - the need to optimise the acknowledgement mechanism of eCall MSD transmission to reduce

voice channel blocking time - the need to ensure reliable operation of eCall such as the reliable operation of MSD

transmission (including retransmission, analysis of the correlation between outcomes of successive MSD transmissions during the same call is recommended)

- needs for recommendations on the service quality acceptable for eCall (such as the acceptable MSD success rate)

EC8 Support dissemination of information on eCall (examples of current activities performing eCall dissemination: iMobility Challenge, HeERO, iMobility Support and EeIP)

EC9 Support dissemination of information on impacts of eCall (examples of current activities performing eCall dissemination: iMobility Challenge, HeERO, iMobility Support and EeIP)

EC10 Continue monitoring the deployment of eCall as a part of monitoring related to the European ITS

directive

EC11 Encourage sharing and publication of the results of eCall interoperability tests to be carried out after

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

31

Recommendation

HeERO and HeERO2 projects, for example in the context of EeIP or international conferences

EC12 Analyse the availability and regulatory status of dormant SIM cards and decide on actions necessary

EC13 Support the member states in their efforts to communicate the functionality and correct use of eCall to citizens – for example by providing information material

EC14 When supporting national eCall pilots, encourage participation in eCall interoperability events

EC15 Consider the need to provide guidelines for automatic and manual triggering of eCall

EC16 Funding of eCall deployment in member states by DG MOVE and the TEN-T programme (note: the funding scheme has to be aligned with the needs of member states)

Recommendations for standardisation organisations are described in the third table of

recommendations(Öörni 2014):

Recommendation

Id Description

SDO1 Include references to CEN standards in the ETSI/3GPP standards when necessary. For example, - include clear references to timers mentioned in Annex A of EN16062 in ETSI TS 126 267

SDO2 Provide specifications for support of eCall functionalities in 4G (LTE) networks taking into account the

work carried out by ETSI STF 456 and IETF working group ECRIT

SDO3 Provide a long-term roadmap for the evolution of eCall taking into account the lifecycles of vehicles and wireless communication technologies and including the means available to maintain the compatibility of IVE with wireless networks and PSAPs over extended period of time

SDO4 Develop CEN TS 16454 into European standard

SDO5 Monitor the work being carried out on periodic technical inspection of eCall IVE and implement changes to standards if necessary; participate in the work of EeIP task force PTI if necessary

SDO6 Continue support for organising eCall interoperability events

SDO7 Clarify the role and use of the LL-ACK in CEN and ETSI standards: - provide guidelines on the numbers of LL-ACKs and HL-ACK - the fact that LL-ACK is not mandatory should be made clear to developers of IVSs and PSAPs

SDO8 Update the annex A of EN15722:2011 or add an errata to the standard (some values in the example presented in Annex A are not possible according to the ASN.1 specification presented in the

standard)

Finally, two recommendations were provided for other stakeholders such as system developers -

Table 4 (Öörni 2014):

Recommendation

Identifier Description

DEV1 Continue organising eCall interoperability events

DEV2 Use dead-reckoning to support GNSS in determining the position of the vehicle. This is expected to improve IVE performance in case of short periods of unavailability of satellite signal (such as tunnels).

The recommendations presented in Tables were written in the beginning of 2014. In other words,

they are based on the results of the HeERO project and the information available at that time but

they do not take into account the results which have become available later such as the results of

HeERO2. The mapping between the challenges for eCall deployment and the recommendations

addressing the challenges is provided in (Öörni 2014).

11 NG eCall

The mobile network operators (MNOs) are shifting to Long Time Evolution (LTE) also referred to

as a 4G mobile technology. LTE networks are built on Packet Switched (PS) technologies,

where the normal modus operandi is transmitting packets of data instead of establishing a

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

32

dedicated communications channel, characteristic for Circuit Switched (CS) technologies. Early

LTE deployments are focused primarily on the mobile data connectivity services. They deliver

ultra-fast mobile internet to the users, while relying on legacy GSM (2G) and UMTS (3G) mobile

systems, using CS technology for voice services. This is primarily due to geographically limited

coverage in early deployments. The introduction of LTE will be an evolutionary step, rather

than revolutionary, as large parts of existing infrastructure is re-used providing a future-proof

technology path for flexible migration of services between GSM, UMTS and LTE mobile

technologies. Currently, major mobile network operators are in favour of a two-step packet-

voice evolution: CS fallback (CSFB) serves as an instant and low-cost temporary solution and

Internet Protocol (IP) based Voice over LTE (VoLTE) as the preferred industry choice in the long run.

Consequently, CS emergency call will be supported in mobile networks for a quite some time,

due to legacy handsets and regulatory needs. Current eCall is based on CS emergency call and

the in-band modem, which was optimised for GSM and UMTS networks. The existing

standardised solution for eCall identification procedures and protocols are determined using the

circuit switching technologies. eCall, as currently defined, establishes a voice channel and

sends data within the voice channel.

LTE has no circuit-switched technologies and therefore no CS emergency call and eCall. VoLTE

packet switched technology will be implemented instead. VoLTE is founded on IMS

specification. The IP Multimedia Subsystem (IMS) is an architectural framework for delivering

Internet Protocol (IP) multimedia services in all-IP networks. Many of the necessary features to

support eCall in the IP environment already exist in IMS standards for emergency services,

which are already implemented and deployed. Only small additions are necessary to specify IMS eCall based on existing standards.

ETSI Mobile Standard Gorup (MSG) has prepared a technical report12 on future eCall and

migration challenges as well as adders proposal for relevant LTE standards. The main idea is to

include the eCall Flag in the IMS signalling by the IVE. Routing of an eCall to a PSAP in the IMS

packet switched domain should be performed using newly specified Unified Resource Names

(URNs). Similarly, MSD is proposed to be sent by the IVE and carried in the IMS signalling to

transmit the data from the IVE to the appropriate PSAP by signalling means and not by the in-

band modem.

Since IMS eCall will not relay on in-band modem MSD transmission, it will allow faster MSD

transfer, no muting of speech path and two way data exchange providing this way “Next

Generation” eCall (NG eCall). NG eCall will enable more comprehensive data set (e.g. regional

specific data, medical data of the occupants, vehicle specific data), enhanced functionality (e.g.

PSAP ability to view video streams from onboard cameras) and also send instructions to vehicle

(e.g., sound horn, flash lights, lock/unlock doors, disable ignition).

The Internet Engeneering Task Force (IETF) has published a document describing how to

support eCall within the IP-based emergency services infrastructure.13

12 ETSI TR 103 140 Mobile Standards Group (MSG); eCall for VoIP 13 http://tools.ietf.org/pdf/draft-ietf-ecrit-ecall-00.pdf

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

33

12 Recommendation to stakeholders

12.1 Pan European eCall

Stakeholder Action

National Government Establishing the model of eCall reception and handling

National Telecommunications regulatory authority (NTRA)

Checking that all legal requirements are complied, for example , Telecoms operator to provide the eCall flag

Mobile network operators Implement the eCall flag

Treat eCalls as 112 emergency calls (free of charge, priority, national roaming, etc.) Providing the right routing based on eCall flag following the instructions of the National Authorities Providing SIM cards for the IVE (based on commercial agreements)

Competent Authorities of

Emergency Services

Make sure that emergency services have the necessary means (including

budget) to adapt their systems to eCall Solve multi-languages cases

Emergency services and their providers (e.g. Software Provider)

Infrastructure set-up (e.g. integrate eCall into the PSAP systems) Verify that eCall information is correctly received Training of operational and technical staff

Establishment of operational protocols

Car Industry and their suppliers Equip vehicles with eCall following the relevant EU Regulations Ensure the functionality of the in-vehicle system Comply with EU Regulations on data protection and free consumer choice

12.2 Third Party Services supported eCall

Stakeholder Action

National Government Regulating the co-existence of TPSP based solutions, today present on the European market [this is not mandatory for Member States]

National

Telecommunications regulatory authority (NTRA)

Not involved in the TPSP eCall

Mobile network operators Providing SIM cards for the IVE (based on commercial agreements)

TPSP Provide appropriate number of call centres and trained operators available 24/7 Creation of a PSAP database Work with PSAPs to establish protocols to communicate with PSAPs Establishment of protocols to communicate with PSAPs (if the PSAPs agree) Establishment of a Multi-language system

Filtering of false alarms (Call Center based services) Development of an interface which offers a safe way to transmit detailed crash data to PSAPs (if PSAPs agree):

Clear and structured data transmission Exact and detailed location description (address, map, coordinates)

Vehicle information (car model, color, number plate) Sensors data visualisation (by automatic eCall)

Multiple languages

Competent Authorities of Emergency Services

No specific equipment needed. TPSP will adapt its equipment to the needs of PSAPs (if PSAPs agree)

Emergency services and their providers (e.g. Software Providers)

Establishment of operational protocols Training of operational and technical staff

Car Industry and their suppliers

Ensure the functionality of the in-vehicle system Comply with EU Regulations on data protection and free consumer choice

EENA Operations Document – eCall

EENA asbl

[email protected] - www.eena.org

is a non-for-profit association

34

13 EENA Requirements

Requirements

Procedure A clear procedure is well known by call takers for handling eCalls (pan-European and TPS)

Interoperability procedure (if needed)

A procedure has been established to communicate with other PSAPs.

Agreements between TPS and PSAP (if needed)

An agreement has been established between some TPSP and the PSAP of some Member States

PSAP equipment eCalls receiving ICT system has the same availability and performance requirements as 112 calls receiving system