D6.1 eCall Deployment Barriers and Enablers: Preliminary ... · ECI Earth-Cantered-Inertial EDAS...

D6.1 eCall Deployment Barriers and Enablers: Preliminary Report

Version number: 1.0

Main author: ICOOR, ERTICO

Dissemination level: PU

Lead contractor: ERTICO

Due date: 30/06/2013

Delivery date: 28/10/2013

Delivery date updated document

Grant agreement no.: 325075

Pilot type A co-funded by the European Union under the Competitiveness and Innovation Programme

ICT Policy Support Programme

DG Communications Networks, Content and Technology

Page left intentionally blank


28/10/2013 3 1.0

CONTROL SHEET

Version history

Version Date Main author Summary of changes

0.1 6.06.2013 Selini Hadjidimitriou Draft of the structure

0.2 7.06.2013 Fabrizio Dominici, Asen Milanov Satellite navigation inputs,

Filtering instance

0.2 7.06.2013 Ainara Bilbao, Jerome Paris PTW inputs, PSAPs

0.3 12.06.2013 Harold Linke Luxembourg inputs

0.4 20.06.2013 Selini Hadjidimitriou Review of the deliverable and of

the structure

0.5 27.06.2013 Selini Hadjidimitriou Final review of the deliverable

0.6 15.07.2013 Davide Brizzolara Modification of the ToC

0.7 19.08.2013 Davide Brizzolara Revision of the content

0.7 02.09.2013 Davide Brizzolara, Selini Hadjidimitriou Additional contribution to Chap.

5 and Chap. 6.

0.8 04.09.2013 Davide Brizzolara Revision of Introduction and

Conclusion

0.9 05.09.2013 Davide Brizzolara, Selini Hadjidimitriou Final general review

1.0 05.09.2013 Davide Brizzolara, Selini Hadjidimitriou Submission

Name Date

Prepared Davide Brizzolara, Selini Hadjidimitriou 06.09.2013

Reviewed ICOOR 04.09.2013

Authorized Andy Rooke 10.10.2013

Circulation

Recipient Date of submission

Project partners 28/10/2013

European Commission 28/10/2013


28/10/2013 4 1.0

TABLE OF CONTENTS

Control sheet ......................................................................................... 3

Table of contents .................................................................................. 4

Figures ................................................................................................... 7

Tables .................................................................................................... 8

1 Management summary .................................................................... 9

2 Terms and abbreviations .............................................................. 11

3 Introduction ................................................................................... 14

3.1 Purpose of Document .................................................................................. 14

3.2 Intended audience of this document ............................................................ 14

3.3 HeERO Contractual References.................................................................. 14

4 HeERO2 Framework ...................................................................... 16

5 eCall activities on major emerging topics ................................... 18

5.1 eCall activities on PTW ................................................................................ 18

5.1.1 Regulatory history on PTW............................................................................. 19

5.2 eCall activities on HGV and dangerous goods ............................................ 19

5.2.1 Transport information stored in the MSD ........................................................ 20

5.2.2 Link to the transport document in MSD .......................................................... 21

5.2.3 Link to a web-service ...................................................................................... 21

5.3 eCall development activities of satellite navigation ...................................... 21

5.3.1 Availability of the Position ............................................................................... 22

5.3.2 Customisation of the eCall Requirements according to the field of application 27

6 Overview of barriers and enablers ............................................... 29

6.1 Policy layer .................................................................................................. 29

6.2 Business and economics layers .................................................................. 30

6.3 Technical/Technological layers.................................................................... 33

6.4 Standards and certification layer ................................................................. 35


28/10/2013 5 1.0

6.5 User layer .................................................................................................... 38

6.6 In-Vehicles Systems .................................................................................... 38

6.6.1 IVS design ...................................................................................................... 38

6.6.2 IVS communication ........................................................................................ 39

6.6.3 Cost of IVS ..................................................................................................... 39

6.6.4 IVS location .................................................................................................... 40

6.7 PSAP ........................................................................................................... 41

6.7.1 PSAPs organisation ....................................................................................... 41

6.7.2 PSAP false calls ............................................................................................. 41

6.8 Mobile Network Operators ........................................................................... 43

6.9 Integration with other eCall systems ............................................................ 44

6.10 Inter-operability and cross border eCall handling ..................................... 44

7 An overview of barriers and enablers at Country level .............. 45

7.1 Schematic overview of barriers and enablers .............................................. 46

7.2 Belgium ....................................................................................................... 58

7.3 Bulgaria ....................................................................................................... 62

7.4 Denmark ...................................................................................................... 63

7.5 Luxembourg ................................................................................................ 64

7.6 Spain ........................................................................................................... 65

7.7 Turkey ......................................................................................................... 66

8 Identification of Challenges for New Emerging Topics .............. 69

8.1 Power two wheelers .................................................................................... 69

8.2 Technological challenges related to PTW ................................................... 70

8.3 Legislation and regulatory aspects .............................................................. 71

8.4 Standards .................................................................................................... 72

8.5 Triggering system ........................................................................................ 72

8.6 Customer interest ........................................................................................ 73

8.7 Heavy goods vehicles and Dangerous goods ............................................. 73

8.7.1 Technological challenges related to HGV and dangerous goods .................... 74

8.7.2 IVS for HGV ................................................................................................... 75


28/10/2013 6 1.0

8.7.3 Overview on regulatory aspects and standards .............................................. 76

8.8 Retrofit devices ............................................................................................ 77

8.8.1 Design and requirements of retrofit devices ................................................... 77

8.8.2 Installation of retrofit devices and liability aspects .......................................... 78

9 Conclusion ..................................................................................... 80

10 References .................................................................................. 82

ANNEX I: Questionnaire ..................................................................... 84

ANNEX II: A Satellite Navigation Overview ....................................... 87

A.1 Radio Navigation Concept ........................................................................... 87

A.2 Fundamentals of Satellites Navigation ........................................................ 88

A.3 Geometric and Measurements Errors .......................................................... 89

A.4 Main GNSS Systems Overview ................................................................... 90

A.4.1 GPS .......................................................................................................... 90

A.4.2 GLONASS ................................................................................................ 91

A.4.3 GALILEO .................................................................................................. 91

A.4.4 COMPASS ............................................................................................... 94

A.4.5 Advantages of Multi Constellation with respect to GPS stand alone ........ 95

A.5 Augmentation System ................................................................................. 96

A.6 Local Area Differential GPS ......................................................................... 96

A.6.1 Wide Area Differential GPS Systems ....................................................... 98

A.6.2 Protection Level ....................................................................................... 99

A.7 Navigation Assistance Services................................................................. 100

A.8 Inertial Navigation System ......................................................................... 101


28/10/2013 7 1.0

FIGURES

FIGURE 1: ENHANCED STRUCTURE OF THE MSD ............................................................ 20

FIGURE 2: ECALL COMBINED STANDARDS – EC PRESENTATION ...................................... 37

FIGURE 3: TELEMATIC CONTROL UNIT INTEGRATION ....................................................... 41

FIGURE 4: ECALL RECEPTION ....................................................................................... 59

FIGURE 5: TRANSFER TO THE PSAP ............................................................................. 59

FIGURE 6: FILTERING INSTANCE OPERATORS ................................................................. 60

FIGURE 7: EFFECT OF RECEIVER CLOCK OFFSET ON TOA MEASUREMENTS ...................... 89

FIGURE 8: FIRST GPS + GALILEO POSITION PERFORMED WITHIN ISMB ........................... 94

FIGURE 9: LOCAL AREA DIFFERENTIAL GPS CONCEPT REPORTED FOR A SINGLE GNSS

SATELLITE................................................................................................................... 97

FIGURE 10: WADGPS SYSTEMS COVERAGE AREAS ...................................................... 99


28/10/2013 8 1.0

TABLES

TABLE 1: ENABLERS AT POLICY LEVEL ........................................................................... 29

TABLE 2: BARRIERS AT POLICY LEVEL ........................................................................... 30

TABLE 3: ENABLERS AT BUSINESS AND ECONOMICS LEVEL .............................................. 31

TABLE 4: BARRIERS AT BUSINESS AND ECONOMICS LEVEL .............................................. 32

TABLE 5: ENABLERS AT TECHNOLOGY / TECHNOLOGICAL LAYER ...................................... 34

TABLE 6: BARRIERS AT TECHNOLOGY / TECHNOLOGICAL LAYER ....................................... 35

TABLE 7: ENABLERS OF THE STANDARDISATION AND CERTIFICATION LAYER ...................... 36

TABLE 8: BARRIERS OF THE STANDARDISATION AND CERTIFICATION LAYER ...................... 37

TABLE 9: BARRIERS IN BELGIUM ................................................................................... 46

TABLE 10: BARRIERS IN BULGARIA ............................................................................... 47

TABLE 11: BARRIERS IN DENMARK ............................................................................... 48

TABLE 12: BARRIERS IN LUXEMBURG ............................................................................ 49

TABLE 13: BARRIERS IN SPAIN ..................................................................................... 50

TABLE 14: BARRIERS IN TURKEY .................................................................................. 51

TABLE 15: ENABLERS IN BELGIUM ................................................................................ 52

TABLE 16: ENABLERS IN BULGARIA ............................................................................... 53

TABLE 17: ENABLERS IN DENMARK ............................................................................... 54

TABLE 18: ENABLERS IN LUXEMBURG ........................................................................... 55

TABLE 19: ENABLERS IN SPAIN ..................................................................................... 56

TABLE 20: ENABLERS IN TURKEY .................................................................................. 57

TABLE 21: CHALLENGES FOR PTW .............................................................................. 69

TABLE 22: CHALLENGES RELATED TO HGV AND DANGEROUS GOODS .............................. 74

TABLE 23: CHALLENGES OF RETROFIT DEVICES ............................................................. 77


28/10/2013 9 1.0

1 Management summary

D6.1 Barriers and Enablers Preliminary Report aims to give an overview of barriers and

enablers for the implementation of the eCall focusing on the challenges related to the

emerging topics: Heavy Good Vehicles (HGV), Powered 2 Wheeled Vehicles (PTW) and

Retrofit Devices. The content of the Deliverable is based on phone interviews carried out by

ICOOR, during the months of April and May 2013. Each interview lasted about one hour and

around 20 respondents provided their answers to the questions listed in the Annex I. Most of

the respondents were HeERO2 participants. Some of them took part in the interview sending

their answers by email.

Respondents to the interview were part of the following categories: IVS, PSAP and retrofit

devices providers, emergency answering points (i.e. police), MNOs, OEMs, private

operators, research centres, associations and university.

This document is intended to highlight the different perspectives existing between

respondents and to converge to a set of aspects that might prevent or facilitate the eCall

implementation. These viewpoints reports the opinion of HeERO2 partners, dealing with the

organisation of the Pilot Sites (in this case observations are more specific to the country

peculiarities) and the vision of the different stakeholders involved in the eCall value chain

depending on their position in the European eCall development process.

The structure of this deliverable is the result of the cooperation and availability of WP6.1

participants to provide all the information needed to have an overview of the challenges and

enablers for the eCall deployment.

The provided answers have shown the need to regulate several aspects eCall. From the

point of view of some of the respondents, for instance, legislation should be introduced with

reference to the need to force the implementation of eCall Flag by MNOs, to the need to

ensure the minimum set coverage, to clarify liability aspects of eCall and procurement issues

at PSAP level.

A business model for PSAPs technology is needed especially with the objective to setup a

filtering entity and in order to ensure fair competition between eCall providers.

From the technical and technological point of views there are several aspects that need to be

clarified and solved especially in relation to the need to ensure that the eCall device is

working properly (i.e. crash tests, PTI) and that sufficient network coverage is guaranteed.

PSAPs in the vertical chain (PSAP 1 to 2) must be able to effectively manage eCalls and

exchange information between each other.


28/10/2013 10 1.0

With reference to PTW, the process of an eCall development service has several differences

comparing to the existing vehicle designations M1 and N1. This creates the need to develop

a special system and consideration should be given to appropriate regulations. The main

challenge is the triggering strategy and the voice communication because, in case of an

incident, the rider is separated from the vehicle.

With reference to HGV and the carriage of dangerous goods one challenge is the position of

the eCall device because some of the vehicle may be articulated being formed by two parts:

the tractive unit and trailer part carrying goods, although it should be recognised that smaller

vehicles with multiple loads present a greater challenge. Another aspect is the type of

information to be transmitted, that is the MSD definition. Finally, concerning retrofit devices,

there are several technical challenges that must be faced such as the need to ensure that

the device is properly installed.

An update of this document will be provided during the last months of the project when the

Pilot Sites will provide feedback on their tests and additional challenges and enablers may be

identified.


28/10/2013 11 1.0

2 Terms and abbreviations

Term Definition

ASN.1 Abstract Syntax Notation One

ADR European Agreement concerning the International Carriage of Dangerous

Goods by Road

ACEM European Motorcycle Manufactures Association

AOC Advanced Operational Capability

CEN European Committee for Standardization

CIP Competitiveness and Innovation Programme

CS Commercial Service

DOP Dilution of Precision

EC European Commission

ECEF Earth Centre Earth Fix

ECI Earth-Cantered-Inertial

EDAS EGNOS Data Access Service

EGNOS European Geostationary Navigation Overlay System

ETSI European Telecommunications Standards Institute

DIV Directie Inschrijvingen van Voertuigen – Vehicle Registration Service (Belgium)

GBAS Ground Based Augmentation System

GNSS Global Navigation Satellite System

GPS Global Positioning System


28/10/2013 12 1.0

HGV Heavy Goods Vehicle

INS Inertial Navigation System

IVS In-Vehicle System

LADGPS Local Area Differential GPS

LCV Light Commercial Vehicle

LTE Long-Term Evolution

MNO Mobile Network Operators

MSD Minimum Set Data

IVS On-Board Unit

OEM Original Equipment Manufacturer

OMA-SUPL Open Mobile Alliance-Secure User Plan Location

PER Packed Encoding Rules

PPS Precise Positioning Service

PRS Public Regulated Services

PSAP Public Safety Answering Point

PTI Periodic Test Inspection

PTW Power Two Wheeler

RSS Received Signal Strength

RTCM Radio Technical Commission for Maritime Services

RTK Real Time Kinematic


28/10/2013 13 1.0

RoHS Restriction of Hazardous Substances

SAR Search And Rescue

SBAS Satellite Based Augmentation System

SISNeT Signal in Space through the Internet

SoL Safety of Life

SPS Standard Positioning Service

TDOA Time Difference Of Arrival

TEC Total Electron Content

TTFF Time To First Fix

TOA Time Of Arrival

TPSP Third Parties service Provider

VIN Vehicle Identification Number

WADGPS Wide Area Differential GPS


28/10/2013 14 1.0

3 Introduction

3.1 Purpose of Document

The purpose of this document is to build up a reference for the barriers and enablers to eCall

implementation in HeERO2 Member States; the document is a continuation of the HeERO 1

deliverable. The aim is to provide an overview of the aspects that could facilitate or slow

down the deployment of eCall services at country and European level. Specifically, barriers

and enablers in the HeERO2 Pilot Sites are identified as well as the ones referred to the new

emerging topics of HeERO2: geo-referencing, Power Two Wheelers, retrofit devices, HGV

and vehicles carrying dangerous goods.

Pilot Sites countries may use this document for the following processes:

Defining the description of their state of the art for the PSAP and 112 system

Comparing the advances made after the execution of their Pilot Site;

Evaluating the current progress compared to one of other HeERO2 participants;

Identifying possible enablers to be transferred to their countries to overcome

existing challenges;

Being a reference for external associate partners involved in Pan-European eCall

who may take advantage of the experience gained in the context of HeERO1 and

HeERO2 projects.

3.2 Intended audience of this document

Deliverable 6.1 on “eCall Deployment Barriers and Enablers” is aimed at the following

audiences and respectively at the fulfilment of the following objectives:

European Commission: to communicate the main challenges for the implementation of the

eCall services at European level from the different stakeholders point of views.

Consortium partners: to recognise barriers existing at Pilot Site level and to identify possible

enablers for the execution of the Pilot Site in line with the timeline of the project.

HeERO2 Management Team: to provide an overview of possible challenges on Pilot Site

implementation.

3.3 HeERO Contractual References

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


28/10/2013 15 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 HeERO2 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]





28/10/2013 16 1.0

4 HeERO2 Framework

The Deliverable D6.1 “eCall Deployment, Barriers and Enablers” is a continuation from the

document of the same name delivered in HeERO1.

While D6.1 in HeERO1 described barriers and enablers of eCall deployment in the HeERO1

Countries, the present deliverable describes barriers and enablers in HeERO2 Countries.

Specifically, D6.1 is a preliminary report that will be updated at the end of the project, when

results from Pilot Sites will be available.

In continuity with D6.1 in HeERO1, an overview of the development activities on eCall

specifically focused on new topics is proposed in Chapter 5.

Then barriers and enablers for eCall deployment are presented on the basis of the answers

provided by project partners during the phone interviews made by ICOOR: focusing on the

challenges related to the emerging topics: Heavy Good Vehicles (HGV), Powered 2 Wheeled

Vehicles (PTW) and Retrofit Devices.

A version of the questionnaire proposed during the phone interview is included in Annex I of

the present deliverable. An additional document has been prepared which includes all the

answers provided by interviewed.

As shown in Annex I, the questionnaire groups questions considering the following types of

respondent:

IVS providers

OEMs

PSAPs

MNOs

In HeERO1, the questionnaire was based on the value chain components of eCall and a set

of layers to be considered for the successful implementation of eCall services:

Policy layer

Business Layer

Operational Layer

Technological Layer

User layer

Moral and ethical issues


28/10/2013 17 1.0

All the previous layers are described in HeERO1 D6.1 (Chap. 5):

The policy, business, technical/technological layers and user layers are kept in HeERO 2. No

moral and ethical issue has been considered in this deliverable because respondents did not

touch upon these aspects.

The methodology used in the formulation of a questionnaire aimed at the identification of

barriers and enablers. Successively these questions have been posed to HeERO 2 WP6

participants.

In order to identify barriers and enablers from different point of views, the questionnaire was

separated in sections based on the respondent category. For instance the first group of

questions is addressed to IVS providers, the second group to OEMS, etc.

During the phone interviews, questions were posed to respondents belonging to each

category and the different points of view on each subject are included and highlighted in

each section.

Finally, specific questions have been addressed to identify barriers and enablers on the

newly emerging topics, the deployment of PTW, Heavy and Dangerous goods and

aftermarket devices.


28/10/2013 18 1.0

5 eCall activities on major emerging topics

This chapter illustrates eCall activities on the major emerging topics, as planned in HeERO1

- Task 6.1: eCall for Heavy Goods Vehicles, Powered 2 wheeled vehicles, retrofit devices

5.1 eCall activities on PTW

Several projects have been proposed and developed with the objective to increase the safety

of PTWs and the implementation of the eCall is one of the key challenges of the sector. This

section gives an overview of the main activities developed for PTWs that are oriented to

safety systems and emergency call.

The objective of the SAFERIDER (Advanced Telematics for enhancing the safety and

comfort of motorcycle riders) FP6 project is the analysis of the ADAS and IVIS integration on

PTW and the development of an efficient and rider-friendly user interfaces for riders comfort

and safety. The project identifies the eCall as one of the four actions with highest impact for

PTW safety, along with a tele-diagnostics module, the navigation and route guidance and the

weather, traffic and a warning system for areas of hazard for bike riders.

The project 2-BE-SAFE (Two-Wheeler Behaviour and Safety) started in January 2009 and its

main objective is to target behavioural and ergonomic systems research to develop

countermeasures for enhancing PTW’s riders’ safety. The project includes research on crash

causes and human errors, and they carried out the world’s first naturalistic riding study

involving instrumented PTWs.

The aim of the PISa project is to develop and implement reliable and fail-safe integrated

safety systems for PTWs in order to improve the performance and primary safety (handling

and stability). The project is oriented towards the braking stability, traction control, intelligent

suspension, active seats and on-board protective devices.

The objective of the MOSAFIM (MOtorcyclists road SAFety IMprovement through better

behaviour of the equipment and first aid devices, October 2012 - September 2013) is aimed

at increasing road safety for European motorcyclist through the improvement of possible

protective equipment performance, making an analysis of current standards and identifying

new ones. The other objective of the project is the definition of recommendations for the

implementation of an eCall.

ACEM is the European motorcycle manufactures association and the safety is one of their

main topics. They use the MAIDS incident databases. They concluded that the developments

for eCall are at very early stage, especially those related to PTWs. They thought

manufacturers have adopted an individual approach towards finding the best solutions to


28/10/2013 19 1.0

multitude of open and complex questions and they identified the next challenges for eCall

implementation:

The sensors, their function, location and algorithms to discriminate an emergency

from a normal situation have to be developed

The robustness of the link between the helmet and the PTW needs to be operative in

all incident configurations

The eSafety Forum is a joint platform involving all the road safety stakeholders. They

consider the PTWs as vulnerable road users within the framework of the iMobility Forum.

One of its main conclusions is the solutions that exist already for the cars cannot be

introduced to the PTWs without relevant research and adaptation.

5.1.1 Regulatory history on PTW

Regarding PTW it’s highlighted the lack of specific regulation regarding on-board devices.

There is a generic directive (Directive 2010/40/EU) on the framework for the deployment of

Intelligent Transport Systems in the field of road transport and for interfaces, but it is not

oriented towards PTW. The most relevant directive to take into account is the general one

related with electromagnetic compatibility: normative 97/24 chapter 8. In any case, for

electric/electronic systems is mandatory the RoHS (Restriction of Hazardous Substances)

directive 2002/95/CE.

Type-approval requirements for new vehicles of the L-category, mopeds, motorcycles,

tricycles, quadricycles are currently set out in Directive 2002/24/EC, which repeals the

Council Directive 92/61/EC.

Along with these, the Commission Directive 2009/108/EC (amending the Directive 97/24/EC)

regulates on certain components and characteristics of two or three-wheel motor vehicles.

Then, with COM (2010) 542 the EC proposes new environment and safety technical

requirements and a legal framework for new technologies. Finally, the (EU) No 168/2013

regulates the approval and market surveillance of two- or three-wheel vehicles and quad

bikes.

In case of helmets, there is not a specific normative. The helmet required the CE marking

and must fulfil the normative related to low voltage and telecommunications electric safety:

the Directive 1999/5/EC and the normative EN60950. In case of use of Bluetooth

communications interoperability test are mandatory.

5.2 eCall activities on HGV and dangerous goods

The current eCall implementations are designed for light vehicles. But there are requests to

extend eCall to HGVs.


28/10/2013 20 1.0

The discussion about standardisation of HGV in eCall started in 2011. Draft legislation by

ADR (European Agreement concerning the International Carriage of Dangerous Goods by

Road) is expected in 2013 and by UN in 2014. The final legislation process may be executed

in 2015 and 2016 to become mandatory in 2017.

The standard is under development by CEN TC278 WG15. It was discussed if the eCall

functionality should include all HGVs’ or only those carrying dangerous goods. The

consensus is now that all HGVs’ should be included into the eCall legislation. Goods that are

not declared as dangerous goods could become so in certain case due to the aggregation of

different loads e.g. In the Mont Blanc catastrophe a truck carrying normal margarine caught

fire and the margarine became as dangerous as a gas tanker. Therefore emergency services

would like to have the information on what is loaded on a truck in case of an incident.

The main challenge is how to obtain the information on what is loaded on a truck that has

had an incident and keep the information up to date as the load changes.

There are three models under discussion:

information about the loaded goods is stored in the MSD;

a link to a transport document is stored in the MSD;

a link to a web service providing detailed transport information is stored in the MSD.

The three models are discussed in the next chapters.

5.2.1 Transport information stored in the MSD

This is the most direct way of handling the transport information. The information about the

loaded goods is stored directly in the MSD. In CEN TC278 WG15 the enhanced structure of

the MSD, described in Figure 1, is under discussion.

Figure 1: enhanced structure of the MSD


28/10/2013 21 1.0

In Block from 12g to 12l, 6 different dangerous goods type can be stored including the UN

number, the quantity. This is a simple solution that needs the least changes in the eCall

chain, though this may have limitations regarding multiple loads, multiple drop loads or loads

where the condition of the load may change en route.

5.2.2 Link to the transport document in MSD

A document in PDF format, similar to the transport documentation, is stored on a server. This

document contains all necessary information about the transported goods. It can be created

by the fleet management system or can be updated by hand. The MSD only contains a link

to this document. The link is transferred to the PSAP as part of the MSD and the operator in

the PSAP can open this document in case of an incident.

5.2.3 Link to a web-service

In this model the information about all transports is stored in one or several trusted tracking

services. These services receive the information from the logistic companies regarding their

transports that should be traced. In case of an incident, the service can provide this

information to the PSAP via a web service. The link to this web service is stored in the MSD.

The information about the transported goods is retrieved via the VIN stored in the MSD. So

no additional information is needed.

5.3 eCall development activities of satellite navigation

Satellite navigation (GNSS) represents a fundamental building block for the eCall framework

and in general for a huge number of applications belonging to the Information and

Communication Technologies (ICT) domain. Generally speaking, satellite navigation is

wrongly identified just as GPS position and the GPS receiver is conceived as simple

commodity. The goal of this chapter is to provide knowledge on the potential benefits

deriving from the correct adoption of most recent navigation technology. It has to be noted

that the following information can be assumed only as useful recommendations for the IVS

and potential suggestions for the next generation eCall service, fostering its adoption within

different field of applications. Such technologies can be considered as enabler toward new

opportunities for the eCall service.

The analysis reported in this chapter offers interesting points of discussion in the direction of

enhancing the quality of the eCall service, in line with HeERO2 perspective; however these

subjects should surely lever the synergy with other ICT projects (not only eCall based).

Furthermore, the same concepts can be easily extended towards other fields of application

generally classified as Location Based Services (LBS).


28/10/2013 22 1.0

Hereafter a short description about eCall service is reported in order to highlight the strong

link with GNSS. The eCall procedure mainly relies on the automatic transmission of pieces of

information concerning the vehicle (inside an ad hoc message that is called Minimum Set of

Data (MSD)) to a Public Safety Answering Point (PSAP), when specific events are triggered

from the In Vehicle System (IVS). Thanks to the eCall procedure, the PSAP is aware of

dangerous situations involving vehicles and can manage them, by activating and

coordinating rescue procedures in an efficient way. In this context, it is clear the key role of

the vehicle position, which represents the most valuable information within the MSD.

Today the existing IVSs embed mass-market GPS receivers that are used to retrieve the

localisation and timing information. In this sense, the state of the art eCall service should be

enhanced with the adoption in the future of advanced navigation solution in order to mitigate

the effects of some extreme conditions for the GNSS receiver may impact on the positioning

performances in terms of:

Availability;

Accuracy;

Integrity and Reliability.

5.3.1 Availability of the Position

A GPS receiver is not always able to compute the position. The non-availability of the vehicle

position represents a critical issue for the eCall service. Without automatic IVS position it’ is

difficult to ensure proper rescue interventions, especially when people inside the vehicle are

unconscious and are not able to directly interact with PSAP staff. Such conditions that

prevent receivers to compute the position can be verified in different situations reported

below:

Satellites availability issues. As explained in Annex II, it is required to see at least 4

GPS satellites in order to compute the position. In theory, the GPS constellation was

set up in order to provide such visibility conditions at every time and at every location

in the world. However, it is not possible to take into account natural or artificial

obstacles (mountains, urban canyons) that obscure the satellites from the receiver

standpoint. Therefore, the possibility to receive the satellite signal is strictly

dependent on the environment and on the elevation angle of the satellite with respect

to the horizon. It has to be noted that GPS constellations do not ensure the same

coverage level in each location. It was configured to ensure an higher coverage over

the North America, and so it offers lower coverage level, for example, in the Russian

area;


28/10/2013 23 1.0

Jamming: the satellite signal can be obscured by means of interferences. The

interferences can be unintentional (for example powerful radio transmitters already

installed over the territory) or intentional. Actually, today it is possible to purchase

specific interfering electronic devices, generally defined as “jammers” (even though

their use is not legal in many countries), that can be exploited, for example, to disable

satellite antitheft devices when stealing cars. At the same way, this problem should

be taken into account for IVS receivers, in particular for specific transportation

categories, like dangerous goods transportation or high value loads;

Long TTFF: Generally speaking, the time the receiver takes to provide the first

position, up to several minutes in harsh positioning environments. The impact of

TTFF on eCall should be taken into account during the test plan of HeERO 2 project.

5.3.1.1 Accuracy, Reliability and Integrity of the Position

The GPS receivers integrated within IVSs provide positions without any guarantee of

accuracy and reliability. Therefore, it is not possible to know the confidence threshold of the

position. It has to be noted that, the system was built for military purposes GPS positioning is

provides free of charge. GPS SPS does not have any kind of guarantee concerning the

quality of the positioning, or about the service availability. The following points depict

possible scenarios in which the error that afflict the GPS position cannot be neglected:

High DOP: the accuracy of the position depends on the geometrical distribution of

the satellites used for Position, Velocity and Time (PVT). For example, an urban

canyon limits the sky portion from which it is possible to get satellite signal;

Multi-path and other error sources: the acquisition of the satellite signal is affected

by many different error sources. Generally the most important one is represented by

the multi-path effect, that is relevant mainly in canyon scenarios (urban or mountain) ;

Spoofing: From a technical standpoint, it is possible to illegally reproduce GPS

satellite signals and transmit fake navigation messages. Such methods can be used

to counterfeit the user position. Such aspect may affect the truthfulness and the

reliability of the localisation acquired at PSAP level.

Recommendation for IVS GNSS enhancement

The previous sections provide a brief but clear overview about the potential problems that

may be encountered exploiting GPS positioning service as simple commodity. The following

sections provide a theoretical overview about the solutions proposed in order to drastically

reduce the impact of the presented issues. Such topics can be easily extended to the galaxy

of LBS. It has to be noted that the analysis reported in the following sections can be

assumed as a list of general recommendations and points of attention that may be


28/10/2013 24 1.0

consolidated with the results coming from the HeERO 2 test phase; therefore each point is

reported as is (without specific number or specific technical implementation). The authors of

this document endorse the translation of the following themes into clear technical

requirements and specification addressed toward potential follow up of the eCall service.

Enhanced Requirements for IVS GNSS resources

The selection of the GNSS receiver to be integrated within IVS plays a key role for the final

quality of the eCall service. Besides the GNSS receiver, the IVS should also embed

additional hardware\software resources for GNSS purposes. Therefore, the

recommendations reported in the following will be addressed for overall GNSS IVS resources

It should be noted that the amendment to type approval for eCall has indeed recommended a

multi-constellation approach:

Multi constellation: The GNSS receiver integrated within IVS shall be GPS, Galileo

and GLONASS enabled. Single multi constellations reduce the impact of the issues

reported above. First, the adoption of multi constellation GNSS receiver improves the

positioning service availability and accuracy, thanks to the increasing number of

satellites in view. Moreover, additional constellations exploitation enables the GNSS

receiver and the overall IVS to exploit the advantages of GLONASS and Galileo.

GLONASS improves the quality of the service in northern latitudes in Europe; Galileo,

with respect to GPS, provides additional services that can ensure benefits to eCall.

Augmentation enabled (EGNOS for Europe): such feature, very common among

mass-market receivers, can be exploited not only to improve accuracy, but also to

exploit integrity functionalities, as reported in Section 0. Note that the IVS should be

deputed to compute the Protection Level (PL) exploiting WADGPS corrections; such

data can be retrieved directly from the GNSS receiver (if provided) or extracted from

EDAS service (powered by European Space Agency (ESA). The EDAS link can be

established via Internet (GSM-GPSR-UMTS) or via DVBT;

High level of sensitivity: The sensitivity of the GNSS receiver may mitigate issues

concerning availability and accuracy explained before, because it allows improving

the acquisition capabilities of the receiver in harsh conditions. The definition of a

correct threshold requirement will be treated during the project test phase;

Secure User Plan Location (SUPL) enabled: The exploitation of the OMA-SUPL

relies on the GSM measurements usually provided by GSM modems (already

embedded in the IVS). The GNSS receiver shall accept SUPL messages for

assistance procedure;


28/10/2013 25 1.0

INS integration: The IVS should embed low cost Inertial Measurement Unit (IMU)

system (see Section 0 for details) connected to the GNSS receiver in order to allow

the dead reckoning procedure (useful when GNSS position is not available).

Galileo Services Enhancement

Galileo will provide different valuable services that may enhance the GNSS performances

within the HeERO 2 framework. Beyond the Open Service that allows to improve the

accuracy and reliability of positioning service with respect to standalone GPS, Galileo offers

other services that would provide benefit to eCall. Galileo technologies will drastically reduce

the probability of jamming and spoofing thanks to both the robustness of the signal and the

advanced cryptography technique (such as signal authentication security provided by the

Commercial Service). Due to the increase of the navigation performances, the adoption of

advanced Galileo Services (such as CS, PRS) should be taken into account for the future

evolution of the eCall technology. Therefore, the architecture definition of the IVS should be

designed to exploit Galileo services. In particular, the possibility to adopt CS for specific

fields of application (e.g.: dangerous goods transportation vehicles) should be investigated.

It has to be remarked that the future adoption of single multi constellation GNSS receiver

(GPS + Galileo or GPS + Galileo + GLONASS) at IVS side should represent a great

advantage for the eCall service; it allows relying on localisation functionalities offered by

other constellation (GPS and GLONASS), enabling the eCall to exploit Galileo services when

they will be available (according to the European Commission schedule, Galileo early

services will be ready by the end of 2014; the complete constellation will be fully deployed

from 2020, as illustrated in Annex 0).

EGNOS Accuracy and Integrity

As explained before, the adoption of EGNOS features allows improving the accuracy of the

position. In addition EGNOS messages provide the instruments to evaluate the so called

Protection Level, that can be assumed as a sort of upper bound for the position error and a

quality indicator for the position provided. It has to be remarked that the Protection Level

concept was originally created for the aeronautical applications. Customisation of the

Protection Level (PL) for the automotive field is an open point at the time of writing that can

be dealt with by the HeERO2 test bed. The PL can be exploited to define the area in which it

is possible to find the real position of the vehicle, providing advantages for rescue

interventions. For example, thanks to the PL, it should be possible to define the correct

research area from which the eCall alert was launched.

The concept of Protection Level can be matched with the Alert Limit (AL): when the PL

exceeds the AL (that can be tailored for specific fields of application), it is not possible to trust


28/10/2013 26 1.0

on the GNSS position; therefore, it is necessary to retrieve position from backup sources (if

available).

Assistance Procedure

The main goal of the assistance procedures is to reduce the TTFF that for the eCall service

could represent an issue.

The possibility to exploit the GSM network measurements as a positioning source based on

GSM cells is very interesting: the Mobile Network Operator (MNO), that knows the BTS

network location on the territory, is able to perform tri-lateration exploiting BTS signal

strength measurements. The position provided by SUPL server (that is not accurate) can be

exploited as a redundancy localisation source; moreover, it is possible to perform a cross

check with GNSS receiver position in order to detect potential spoofing action. It has to be

remarked that in order to exploit OMA-SUPL features, the eCall supervisor authorities should

stipulate an agreement with MNOs.

MSD Protocol Improvements

The GNSS overview provided within the document fosters some changes to the MSD

standard format in order to host additional pieces of information associated to the positions

provided by the GNSS IVS receiver. Such changes to the original format can be adopted

avoiding retrofit issues concerning pre-existing eCall IVSs, due to the presence of spare

fields foreseen by the current MSD standard version. Such changes (that could be formally

defined during the HeERO2 test phase) go in direction of enabling additional GNSS services

and are listed in the following:

Jamming indicator. In literature, there are techniques that detect jamming attempts.

Therefore, it could be useful to add an indicator reserved for jamming alert;

Spoofing indicator. In literature, there are techniques that detect spoofing actions.

Therefore, it could be useful to reserve an indicator for spoofing alert;

Quality indicator: PL can be assumed as a quality indicator, because it provides the

upper bound of the positioning error.

There are two different strategies to follow:

PL can be computed directly by the IVS: this strategy permits to reduce the

amount of data required to provide information, but is not flexible;

PL can be computed by the network infrastructure: this strategy requires

additional information with respect to the previous one (e.g. the satellites used to

compute position), but gives advantages in terms of flexibility and scalability.


28/10/2013 27 1.0

5.3.2 Customisation of the eCall Requirements according to the field of

application

Standard Pan-European eCall service was conceived as agnostic service with respect to the

different fields of automotive application. However, the effectiveness of the eCall technology

should be enhanced with a minimum level of complementary customisation according to the

specific sector of use without changing the nature of the original service. This subject is wide

and apparently lies out of the scope of this document. However, from GNSS standpoint, each

solution presented would be tailored according to the specific field of application. This section

is focused in particular on the dangerous and heavy goods transportation that represents a

critical application from a safety point of view, even if some considerations can be easily

extended toward other field of applications. In this case, the GNSS requirements in terms of

availability, accuracy and reliability of the positioning service should be stricter with respect to

other fields of applications.

It has to be considered that, nowadays, the vehicles used for dangerous goods

transportation are generally equipped with other electronic on board systems devoted to

other ICT services and ad-hoc service platforms. For instance, it is possible to assume that

the vehicles are usually remotely tracked from a control centre. Therefore, a point of

discussion about eCall integration concerns the coexistence of the IVS and other devices

already mounted on board. From an architectural point of view (hardware equipment), the

IVS should be exploited for additional services with respect to eCall and should communicate

with third party platforms. The same point can be argued for the PSAP and other IT platforms

for LBS; in fact, the PSAP should be able to redirect eCall information toward other back-end

systems devoted to other services, transforming the PSAP in a sort of middleware for

advanced functionalities. As a simple example, the IVS should pack encrypted information

(like for example the type of goods transported) inside spare fields of the MSD that the PSAP

may just transfer toward other platforms. This strategy enhances the added value of the

PSAP, avoiding overloading it with additional duties. The problems concerning this kind of

service are just at administrative and management levels: the eCall supervisor authorities

and other service providers should find an agreement about this subject in order to formally

regulate this interaction.

For this specific field of application, it should be useful to add some additional trigger related

to GNSS. It has to be remarked that the management of such alerts is not argument of this

document. In the following, some specific case study will be reported:

The IVS GNSS receiver is not able to provide the position for long time: such

condition must be avoided, because in case of danger, the authorities (or the


28/10/2013 28 1.0

entities demanded for this aim) would not be able to rapidly intervene. An alert

should be sent toward PSAP (or to other involved platform);

Spoofing or jamming actions: The detection of spoofing or jamming action can

be interpreted as a potential theft attempt. This case should be notified, especially

for dangerous goods transportation.

Furthermore, it would be possible to evaluate additional requirements for IVS

architecture, as depicted in the following:

GNSS-INS receiver: An Inertial Navigation System (INS) is able to bridge GNSS

outages (and improve GNSS signal tracking in tightly coupled systems); GNSS is

able to calibrate INS sensors (thus improving performance during GPS outages).

The adoption of INS would mitigate the problems concerning the satellite signal

availability due to lack of visibility or interferences (e.g. jamming);

Adoption of professional GNSS receiver for IVS: Due to very high costs, the

use of professional GNSS receiver could be taken into account only for limited

fields of application (e.g.: dangerous goods transportation), in order to ensure

better quality of positioning services (in terms of accuracy, reliability and position

availability) with respect to the integration of GNSS mass market receivers.

Exploitation of Galileo CS: The adoption of CS would enhance the accuracy

and reliability of the positioning service. Moreover, thanks to the authentication

strategy, it would drastically reduce the probability of success of spoofing actions.


28/10/2013 29 1.0

6 Overview of barriers and enablers

6.1 Policy layer

The policy level is the basis for the successful implementation of eCall services.

Respondents from Belgium point out that EU initiatives alone are not enough but national

legislation should be introduced in order to define the ITS development framework including

eCall. In addition the introduction of ad-hoc regulations should also take into account national

specificities and funding aspects.

The table below summarises, for each category, some of the aspects mentioned during the

phone interviews that should be regulated by governments in the opinion of the respondents.

IVS Regulations on vibration testing, electronic test or temperature of eCall devices

would allow eCall devices to have minimum requirements and to be more reliable.

MNOs Implementation of eCall would be faster if MNOs are forced to implement the

eCall Discriminator (eCall Flag). However MNOs such as Orange believe that an

introduction of a formal obligation on MNOs would just add another layer of

challenges and would not solve national specificities.

Regulations should be introduced to clarify liability aspects with reference to

network coverage.

Minimum network coverage (i.e. on main roads) should be introduced. This

aspect is explained in the chapter dealing with MNOs.

OEMs There should be regulations of IVS providers and OEMs responsibilities in case

the system fails: this issue can be resolved by the certification of the IVS device.

PSAPs Call for tenders would allow selecting the best PSAP technology provider.

Governments should simplify procurement procedures All the MS PSAP should

be conform to eCall specification. This could be assured by a certification process

Table 1: Enablers at policy level

There are different points of view on how governments should push the implementation of

eCall. For instance, respondents believe that there should be a regulation that forces MNOs

to implement the eCall Discriminator (eCall Flag). On the other hand MNOs believe that it

would not foster the implementation of eCall services.


28/10/2013 30 1.0

IVS EU regulations on eCall devices cover only radio communication.

MNOs There is no regulation on the implementation of eCall Discriminator (eCall

Flag).

OEMs Liability aspects related to eCall device performance should be clarified and

regulated.

PSAPs Procurement procedures are too complex.

Table 2: Barriers at policy level

Another point, reported by MNOs, is the need to introduce regulations on the minimum level

of coverage. If regulations are introduced, a clarification will be required concerning the entity

that would finance eventually required extension. It should not be forgotten that despite the

assertions from the MNO regarding cost, Pan European eCall based on 112 is a designated

TS12 call which MNOs are required to handle free of charge.

6.2 Business and economics layers

From the business and economics point of view, several aspects have being mentioned

during the interviews as crucial for a successful introduction of eCall: the need to create

appropriate business models in order to finance the infrastructure upgrade, the setup of the

filtering entity or the provision of additional services to the eCall devices in order to foster

their penetration into the market.

There is general agreement between respondents on the need to organise call for tenders in

order to improve competition and quality of solutions. There are not many companies on the

market able to provide a complete software and hardware solution for PSAP upgrade for

eCall. Obviously, companies taking part in the HeERO project will be well positioned to

upgrade PSAPs for eCall across Member States. However making this process transparent,

under call for tender, would encourage competition between different providers and will

ensure that the PSAPs are upgraded using the best possible solutions. The promotion of

public open tenders for PSAP upgrade would be helpful. Some excellent works carried out to

advise public authorities on the optimal strategies for the public procurement processes for

ITS have been mentioned by the interviewed partners. This deliverable commends the use of

this document: Pre-Commercial Public Procurement for ITS innovation and deployment

(P3ITS).


28/10/2013 31 1.0

MNOs

Need to clarify funding aspects, especially before the introduction of legislations on

network coverage.

Even if eCall is a free service, MNOs would favour an environment where PSAPs

are not allowed to push the costs of dealing with emergency calls back to

operators.

OEMs

OEMs could offer additional services together with the eCall such as vehicle

tracking, fleet management and should allow some open choice for customers.

However this will be not possible with a dormant SIM.

PSAPs All MS are covered by the necessary legislation that requires a competitive

tendering process; however there are delays on the national legislation application.

As a consequence, respondents believe that a call for tenders should be put in

practice in order to select the best PSAP technologies. Procurement procedures

would allow having better competition mechanisms. As already explained in this

document there is some highly relevant work already available regarding

procurement for ITS (e.g. Pre-Commercial Public Procurement for ITS innovation

and deployment (P3ITS))

The question regarding the use of an intermediate PSAP is an operational decision

taken by Member States. There are two HeERO 2 Pilot Sites who are operating

this architecture (Belgium and Spain). One is using a Government provided

intermediate PSAP the other is provided by a Motoring organization. It is too early

to say whether this architecture will prove effective in the processing of manual

calls, or whether this will introduce a delay in the processing of the 112 call. This

aspect will be followed up in the revision of this document taking into account

project evolution.

IVS Interfaces should be standardised and should allow open choice for customers in

order to guarantee fair competition for actors willing to offer additional services and

applications. This would favour the acceptance of eCall devices from users.

Certification has a strong role to play in this field, which would provide assurance to

Vehicle manufacturers that devices are compliant with the standards and certified

in terms of performance.

Table 3: Enablers at business and economics level

At PSAP level, Chapter 6.7.2, describes the filtering function introduced in Belgium as a

strategy to manage false calls. Interviewed authorities indicate that the cost of the filtering


28/10/2013 32 1.0

functions should be borne by the private sector. For drivers who already have private eCall or

bCall services, the coupling to a PSAP can be assumed as part of the cost for that service.

MNOs

It is not clear which entity should finance the extension of the network

improvement in case of regulation on minimum level coverage. Before

introducing legislations on network coverage, there is the need to clarify

these funding aspects.

There are considerable costs for the eCall discriminator (eCall flag)

implementation (i.e. in UK, MNOs have to pay a charge to PSAPs

operators).

OEMs

eCall is a free service but there is an extra cost for OEMs, this is no

different from the existing arrangement for all 112 calls single number

emergency calls across Europe.

3G technology is entering the market and OEMs should adapt and move

from 2G to 3G. This might embody a cost penalty for them. It should be

noted that the current specification for IVS are based on 2G network.

However the system will work equally well on a 3G network, since 3G will

deal with both voice and data. 4G or LTE is a different technology but work

is already underway to understand the implications of this new technology.

This work is led by ETSI/3GGP.

PSAPs Given that the introduction of a filtering entity may help the implementation

of eCall services by reducing the number of false calls, it is not clear which

entity should finance it.

It is also not clear which entity should finance the upgrade of existing

PSAPs (i.e. chapter 7.6 describes the need to upgrade regional PSAPs in

Spain).

IVS The process to detail technical requirement is still open. The latest 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/EC) has been

published by the EC on June 2013.

Table 4: Barriers at business and economics level

With reference to the commercialisation of eCall devices, some of the interviewed partners

believe that the standardisation of IVS would allow different actors to offer additional


28/10/2013 33 1.0

telematics services and applications, having a larger choice of products for customers. This

would foster fair competition and would encourage innovation in the European telematics

market.

From the MNOs perspective, provided answers focus on the following point: the challenge is

to identify the right entity that will finance the extension of the network in the case of the

introduction of a regulation on a minimum level of coverage. This issue of network coverage

is one which will affect all networks, and of course represents a commercial decision for the

respective network. Regarding this aspect, it has been mentioned that the eCall with the

designation of TS12 will work across ALL networks irrespective of which network the SIM is

registered to.

Additional considerations have been reported by respondents regarding costs: eCall should

provide a free service at the point of use and this represents an extra cost for vehicle

manufactures. Part of these costs could be generated by the type of contract existing

between the vehicle manufacturer and the network operator because a dedicate SIM needs

to be installed into the device. Vehicle owners cannot choose the type of contract to sign with

the MNO. Concerning these aspects, it has been noted in some answers that, as already

detailed in this report, the standard Pan European eCall will operate on a “Dormant” SIM.

This means that for the majority of the life of the vehicle the SIM will be inactive, the traffic

generated on the network will be very low and costs are anticipated to be lower than a

conventional SIM provided for voice calls. However if an enhanced service is proposed, the

situation will be different since the SIM will need to be registered to a vehicle owner and

there will be a financial arrangement required. Whilst each vehicle may be fitted with a

dormant SIM technically it is possible to remotely alter the characteristics of the SIM to

enable enhanced services if required.

An additional aspect reported, is the point of view of private operators who are aware of the

costs of providing the eCall service. These are the costs to setup the filtering instance or to

upgrade PSAPs. They report that governments should finance the eCall or, at least, the

PSAPs upgrade. However, since this is a Tele Service 12 call (112), the cost of upgrade will

form part of the universal directive on the provision of 112 services and the cost will either fall

to the PSAP provider who is licensed or the MS as the 112 operator.

6.3 Technical/Technological layers

From the technical point of view, respondents stated that one of main technical challenge is

where to position the eCall device. A complete description of this aspect can be found in

chapter 6.6.1 dealing with IVS design and integration.


28/10/2013 34 1.0

MNOs

The call routing should be tested and should be accurate. Especially at the borders

areas where there also foreign MNOs. Task 6.5 of HeERO 2 will deal with cross-

border aspects allowing continuity of service.

At European level the decision is to use 2G as this has the greater coverage in

general across Europe, but it will also work as on a 3G system, as 2G and 3G are

capable to support passage of data. GLONASS works instead on 3G.

A big challenge is LTE and ETSI 3GGP have a specific task force on this matter.

For enhanced eCall services, a multi-profile SIM could be used in order to allow

users to choose their preferred MNOs. This technology is under development.

IVS

For the positions of the IVS different solutions (on the external surface of the

vehicle or integrated in the IVS by using an ad-hoc antenna) with advantages and

disadvantages have been proposed (in chapter 6.6.1 dealing with IVS design and

describing OEMs requirements for device integration).

Task force RETRO deals specifically with aftermarket eCall and new testing

procedures on the correct functioning of the retrofit device are developed in the

context of Task 6.2 of HeERO 2 on certification and a further report on PTI has

been completed by EEIP in order to verify integrity and reliability.

In addition enabling activities regarding IVS are carried out by the HeERO

Standards task Force. Useful contributions are the CEN EN standard End to End

Conformance Test and the PTI report.

PSAPs New technological solutions should be developed in order adapt to the existing

systems.

In order to avoid replication of information, PSAPs should share updated

information (see chapter 6.7.1 dealing with PSAPs organization). However these

aspects are outside the scope of HeERO.

It should be noted that the HeERO project have developed:

A server solution that will work with any current PSAP architecture and will permit

the handling of both Pan EU eCall and TPS eCall;

Training solutions, already there are 8 dedicated training manuals linked to a

generic manual, with another 7 to be produced in HeERO 2.

Table 5: Enablers at technology / technological layer

Additional reported aspects are related to testing that has not been very effective until now.

The procedures to perform the crash tests are being defined and there should be clear


28/10/2013 35 1.0

scenario on how to react if the device is not working properly especially when there is no in-

band modem connection.

MNOs

In some areas there are challenges related to network capacity in case of an

elevated number of generated eCall, even considering that eCall receive priority

across all networks.

IVS

It is not clear which is the best position of the eCall device. It is not clear how to

test the correct functioning of the device, if it is working properly or not. There are

many devices running into the market and using different types of components. For

instance modems may have different capabilities. There should be minimum set of

requirements for IVS providers.

These challenges are faced by the activity of several groups (see Enablers).

PSAPs The challenge will be to integrate eCalls into the existing workstations.

The PSAP personnel will have to adapt to the new system that consists in the

integration of the eCall into it so that the upgraded systems should have an easy

interface.

Table 6: Barriers at technology / technological layer

Finally, it has been mentioned that in some countries there are still open technological

challenges at PSAP level due to the integration of the eCall system into the existing PSAPs

workstations, and of course the political landscape which accompanies the various PSAP

configurations, these must not be under-estimated. HeERO 1 has already successfully

demonstrated technical solutions to solve virtually all technical challenges involved with the

physical reception of a eCall at a PSAP what remains problematic are the political issues

which bolster and maintain the current PSAP systems.

6.4 Standards and certification layer

All the aspects related to standards and certification is discussed in the contest of HeERO

Standards Task Force lead by ERTICO ITS-Europe. Specific Deliverables and initiatives are

planned in the context of HeERO project. In this paragraph are listed the main topics

reported by the interviewees.


28/10/2013 36 1.0

MNOs

SMS could be a backup service but reliability is an issue because of the possibility

of transmission delays.

IVS

A centralised approach, through a third party, that is in charge of the certification

and standardisation is seen as a good option especially with regards to IVS unit’s

certification.

There should be a summary so that operators could have a clearer overview of the

existing standards.

PSAPs Need for a summary of existing standards.

Filtering instance is a new solution and it needs to be certified.

Table 7: Enablers of the standardisation and certification layer

The need of certification has already been mentioned. The eCall In-Vehicle System has to be

compatible with all eCall-ready PSAPs in Europe. Thus a centralised approach, through a

third party, that is in charge of the certification and standardisation is seen as a good option

especially with regards to IVS unit’s certification. There is no requirement to certify the bearer

network, as all Networks are subject to certification anyway. But there is a requirement to

ensure conformity for all PSAPs’ across Europe, which again a centralised approach seems

to be appropriate for the respondents.

Taking into account the feedback received by PSAP operators, the difference between CEN

and ETSI standards are not always clear and there are, in general, too many and too

extensive standards applicable to eCall. It has been noted by the respondents that there

should be a summary so that operators could have a clearer overview of the existing

standards.


28/10/2013 37 1.0

Figure 2: eCall combined Standards – EC presentation

The activities promoted in the context of the HeERO project and supported by the EC

(European Commission) are considered as an enabler for this challenge.

IVS

There should be a third party that guarantees a centralised approach to

certification of different components of the eCall device: the existence of difference

devices into the market does not allow to guarantee minimum level of performance

and to have an eCall system that is inter-operable (see 6.6.1 on IVS design)

without a clear certification process

PSAPs It has been noted that too many and too extensive standards applicable to eCall.

Even if there is already a standard (ISO 27001), discussion is still ongoing on data

security techniques that are not very clear (see chapter 6.7.2 dealing with PSAPs

acceptance of eCall).

It should be cleared how filtering instances shall be certified. Filtering instance is a

new solution as such needs to be certified.

Table 8: Barriers of the standardisation and certification layer

Difficulties in the understanding the ASN.1 PER (Packed Encoding Rules) representation of

the MSD (Minimum Set of Data) have been reported. The PER unaligned format for


28/10/2013 38 1.0

representing the MSD as explained in EN15722 appears unclear and incomplete so that it

should be clarified and integrated. It has been quoted the given example in Annex B for

encoding request is remotely related to the MSD in terms of the types of data encoded.

Instead an exhaustive bit by bit explanation of the “ASN.1 PER unaligned example MSD

message should be given in order to easily understand the structure of the message”.

In addition, the following points have been mentioned in the interviews. EU regulations on

eCall devices cover only radio communication but not vibration, electronic or temperature

testing. Electronics are in fact subjected to environmental aspect which must be taken into

account. Electrical installation is the main challenge especially in relation to the airbag. There

is in fact no certification or warranty on airbags functioning and IVS should be connected to

airbag sensors.

6.5 User layer

eCall is a mandated device so that no consideration has to be undertaken on whether

owners want the eCall device or not. Finally, whether a vehicle owner has a TPS eCall or

not, in the event of an incident, the device will call 112 only (This is according the Type

approval amendment documents June 2013).

Some of the respondents (MNOs and private operators) believe that users should be able to

choose between different types of eCall devices with diverse functionalities and should be

able to select the preferred MNO operator. For instance a multi-profile SIM that allows having

more than one type of contract with MNO could be a good solution. This technology is still

under development and it would create additional costs.

6.6 In-Vehicles Systems

6.6.1 IVS design

From the IVS design point of view, one of the main challenges mentioned by the respondents

is the position of the device in the vehicle and the possibility to test if the device is working

properly. Testing should be performed using data provided by both vehicle manufactures and

electronic devices manufactures.

The importance of ensuring a good antenna performance has been reported in several

interviews. Different alternative solutions have been proposed. A possibility for a good

antenna reception/transmission is to position the IVS on the vehicle roof or the external rear

view mirrors. The main problem of having antennas out of the IVS is that, in case of an

incident, the antenna could be damaged and the eCall is not performed. Moreover, the

antenna should not be surrounded by too many metallic parts: the external surface of the


28/10/2013 39 1.0

vehicle is not the best location for the receiver. However, having an internal device may not

allow a good GPS antenna reception (see also chapter 6.6.4 on IVS location).

Some manufacturers produce devices in which the antenna is integrated into the IVS. With

fractal antenna design technology it is possible to develop small antennas which fit inside the

IVS and to obtain good performances. This solution is the most suitable in case of crash.

However it has to be defined if the IVS must work with internal antennas only or it could have

also external antennas to add redundancy and security to the system.

It has been noted by the interviewed participants that the existence of different types of IVS

available in the market is an issue that do not allow having a defined minimum level of

performance of eCall devices. It should be noted that the IVS currently in use are pre-

production devices. However the standards for the IVS and its performance are clear and

again seek to illustrate why certification is necessary in terms of the IVS.

Differences on IVS devices can rely on the type of modem deployed, on the IVS designs or,

in general, on network adaptations. Each modem can, for instance, have a different

sensitivity and consequently different behaviour in low signal areas. For this reason it is

important to define and standardise the validation process of the IVS with reference to the

sensitivity of the antenna. For instance it should be secured that every IVS works with the

same level of performance, or at least, at a minimum level of performance. IVS

communication systems need to be tested in order to ensure the interoperability of the eCall

system. All manufactured in-vehicle system (IVS) must be able to communicate with any

other manufactured public safety answering point (PSAP).

6.6.2 IVS communication

Some challenges concerning the IVS communication have been reported by the participants:

eCalls may be affected by the prevalent radio conditions in the same way normal calls may

be affected. In rare cases, this may increase the MSD transmission time. The tests

performed in HeERO projects are assessing these aspects: the performance indicators

regarding these points will be evaluated in WP4.

The respondents mentioned the importance of testing scenarios in which, after an incident, a

driver experiences problems with in-band modem connection needed in order to evaluate the

different options on how to react when the system fails.

In conclusion, it is a shared view that the testing operations for IVS communication will

provide very useful feedback and will be a helpful for eCall efficient deployment.

6.6.3 Cost of IVS

IVS suppliers recognise, in the provided answers, that there is an inherent conflict between

cost and quality. eCalls IVS is a life-saving device, so even with low-cost solution serious


28/10/2013 40 1.0

measures should be taken to guarantee that every single standard requirement is strictly

met. So, clear certification guidelines are the key to achieving this goal.

Although eCall is a free service for the user, the introduction of an eCall IVS generates two

kinds of extra costs. On one hand, the vehicle manufacturer has to assume an extra cost for

the IVS device. As eCall is not profitable for the OEM, a possibility is to introduce some

additional service in the IVS that satisfy customer wishes like fleet management for logistics

companies, stolen vehicle tracking or real time traffic information.

On the other hand, some respondents remarks that each IVS needs a dedicate SIM to work

properly, so there is the need for a contract between the driver and the mobile network

operator. On the other hand, the following points have been noted:

1. If the SIM is dormant, and in reality only used once or maybe twice in the life of the

vehicle there is no need for the owner to have a contract with the MNO;

2. The system CAN be manipulated if necessary, at a very early stage.

6.6.4 IVS location

As regards the location, since the IVS is a safety system and one of the safest positions in

the vehicle is the dashboard, the recommended location suggested during the interviews for

the IVS integration is inside the dashboard.

In order to assure a good reception and transmission of the electromagnetic signals to and

from the IVS the following list is presented as general recommendations.

1. Metallic components can cause interference that could affect the behaviour of the

internal antennas of the IVS. It is recommended to avoid metallic objects surrounding

the IVS. However, effect on antenna performance will highly depend on the size and

location of metallic components, so a deeper analysis in final configuration should be

carried out in order to proper antenna design.

2. The TCU (Telematic Control Unit) should be placed in horizontal position from the

floor to assure good reception of the GPS antenna that must get the information from

the satellites.

3. Due to the GPS antenna directive radiation pattern, any metallic part above the

antenna (metallic elements, cables, windshield thermal layer, etc.) will affect the

radiation pattern shape directly and therefore the antenna performance.

As a summary, the Telematic Control Unit integration must follow these recommendations.

No metallic parts surrounding the

module around 200 mm.


28/10/2013 41 1.0

No metallic parts to the zenith

direction in > ± 40 degrees.

Horizontal integration as possible.

Max. tilt = 10 degrees

Figure 3: Telematic control unit integration

In addition, Respondents report that the communication between the IVS and the vehicle is

one of the points to be clarified: for the IVS installed in the vehicle during production, the

communication could be easily done by the bus CAN, but for equipping old vehicles different

approaches should be evaluated.

6.7 PSAP

6.7.1 PSAPs organisation

112 calls have been already handled and received for many years. In some countries, eCalls

will not be handled using the same infrastructure and organisation as 112 emergency calls. A

new approach of organisation and technical infrastructure will be set up. This change should

be managed in the correct way to avoid possible malfunctions.

The European Emergency Number Association (EENA) states that in some countries eCalls

will not be routed to the same PSAP as 112 calls. It may happen that information about the

same incident arrives as eCall to the eCall handling PSAP and as normal 112 calls (for

example incident witnesses) to the 112 calls handling PSAP. To avoid sending resources

twice, information between PSAPs should be shared and updated.

6.7.2 PSAP false calls

Currently PSAPs receive a large amount of false calls, owing to misuse of the 112 system.

This is a Europe wide problem, and this can emanate from both the actual 112 caller who

has insufficient information to make the right choice on the number to dial, to service centres

who receive call and are insufficiently trained to deal with the call correctly and as a result

pass the call to the 112 for resolution.

40º

10

º


28/10/2013 42 1.0

With the increase of usage of GSM, the PSAPs detected an increase of emergency calls

because when an incident happens, many drivers in the area are calling in parallel 112.

With the introduction of eCall, it is expected that the amount of calls to the 112 centre will

again rise. Several expected additional changes have been reported by the respondents

compared to the as-is situation:

A built in eCall device, or on-board unit will be more easy than a phone call. 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, also children will

push it, even when no incident happened. ISO standardisation should include

indication of the position of the eCall device considering this and other scenarios.

In case of multiple vehicles involved in one incident (for instance a chain collisions),

using automatic eCall, initiated by designated sensors that detect significant impacts

when the car crashes, PSAP operators expect to have a large increase of calls for

one single event. In these situations the emergency services will need to sort calls out

in order to have a clear view of the real emergency needs.

In addition, it has been reported that also dealing with silent eCalls can also be a real

challenge for emergency services. In many cases such calls may be genuine emergency

calls by people who have lost consciousness. In this situation the MSD transmission is still

possible and it should be carefully evaluated. Furthermore, hang-up calls may occur in very

rare cases if there is network unavailability (This should not be the case with 112 calls except

in times of national emergency) or in case of failure or damage of the device initiating. To

overcome these issues the focus should be on the MNO to ensure high quality services.

The importance of a filtering activity has been raised as an enabler for eCall deployment: for

rescue authorities this is a concept that is similar to the one provided by private TSP eCall in

some countries. A filtering instance is an organisation at PSAP, or separate from the PSAP,

that will receive, screen the call then pass it to the licensed PSAP to dispatch first

responders.

Some considerations have been reported on PSAP personnel acceptance of eCall system

and functions by PSAP personnel: they are aware of the possibility that the number of calls

could increase after the introduction of eCall and that changes to the PSAP system need to

be carried out. For instance, the integration of eCall into the workstations of the PSAPs

personnel will be a challenge since they will have to adapt to a new eCall system. New

procedures have to be set up and new technology has to be used by 112 operators in order

to handle eCalls. Even 112 operators with long experience handling 112 calls need to be

trained.


28/10/2013 43 1.0

It should be noted that the configuration of the eCall IVS and intrinsic connection to the

vehicle may result in a revision of current policy to tell the call to move away from the vehicle

on a highway, as of course the vehicle remains the point of contact between the PSAP and

those requiring assistnace.

The importance of specific training has been reported, especially in the case of cross-border

activities. It is extremely important that PSAP personnel have the capacity to communicate in

different languages. This is not only crucial in cross boarder calls but also in calls made by

foreign travellers visiting or living in the country.

PSAP operators should be able to speak as many languages as possible in order to have a

better chance to easily communicate with the people involved in an incident. In private

emergency call centres, some operators are able to speak 8 European languages.

For private eCall operators dealing with assistance calls from other countries is already in

place but it still represent a problem. Third party translation services can be helpful in these

cases. However, it has been noted that the most important information is that contained in

the MSD as it can be use independently from the voice call.

6.8 Mobile Network Operators

For the point of view of MNOs, the following points have been raised during the interviews.

Some of the operators report that there are costs for the implementation of the eCall

discriminator (eCall Flag). Regulations aimed to require them to adopt the eCall flag are not

necessarily a solution. However, recommendation C (2011) 6269 on support for an EU wide

eCall service in electronic communication networks for the transmission of in-vehicle

emergency calls based on 112 was adopted on 08/09/2011.

In general, the feedback from the questionnaire is that MNOs would favour an environment

where PSAPs for instance are not allowed to push the costs of dealing with emergency calls

back to operators. The Universal Service Directive has decreed that 112 eCall is a free

service so that the most important aspect related to MNOs is related to the effectiveness of

the eCall service.

Some of the answers report that it should be very important to have minimum network

coverage for eCall (for instance this should be ensured on the main roads). Existing

coverage will work with eCall on 2G and additional coverage is it would not be required if

there was no eCall.

Some of the answers report that regulations could be introduced in order to ensure minimum

network coverage for eCall, for instance coverage should be ensured on the main roads.

Existing coverage will work with eCall on 2G and additional coverage is desirable it would not

be required if there was no eCall.


28/10/2013 44 1.0

6.9 Integration with other eCall systems

Pan European eCall is compatible with the ERA-GLONASS, so as to guarantee good

emergency call management in case of an incident near the Russian border. There is a

working group organised by ERTICO ITS-Europe and GLONASS Union that is working to

harmonise both standards. Currently the standards are very similar except that eCall can

work on 2G or 3G and ERA-GLONASS only on 3G. In addition, in case of incident, ERA-

GLONASS sends an SMS in addition to the emergency call, in the event that the in-band

modem cannot make contact, and the SIM profile in the GLONASS unit is different.

6.10 Inter-operability and cross border eCall handling

It is part of HeERO 2 project description to define several indicators and parameters which

determine the correct functionality of the full system (IVS and eCall). The ability for eCall to

be inter-operable is of prime concern to the project. eCall must be able to function

seamlessly anywhere in Europe.

The published standards have gone a long way in ensuring that eCall is inter-operable,

however the potential for inter-operability issues has to be confirmed by Pilot Sites and

industry trial results, even when technical implementations follow the released standard.


28/10/2013 45 1.0

7 An overview of barriers and enablers at Country level

This chapter, in the first part, summarises barriers and enablers identified by respondents at

country level: two tables group and summarise the answers at Member State level.

In the second part the description of the barriers and enablers in each HeERO 2 pilot country

is detailed.

The tables are available reported in the next pages.


28/10/2013 46 1.0

7.1 Schematic overview of barriers and enablers

IVS PSAP OEMs MNOs Data transmission Interoperability

and cross border

eCall handling

Emerging topics

1 - Manual call:

Discussion on the

need

1 - Possible increase of

calls number at PSAP.

2 - How to cover the

costs for the filtering

entity?

3 - Integration of eCall

into the existing PSAPs

interfaces.

4 - Certification

procedures for PSAPs.

Not reported 1 - SIM-less phone

emergency call is

not accepted.

1 - eCalls are affected

by the prevalent radio

conditions may

increase MSD

transmission time.

1 - There is the need

for testing eCall at

cross border areas,

communication is an

issue.

Need for integration

of EU eCall and

TPSP.

1 - Issues on

whether to install

the retrofit device,

there is no

interface

standardization,

there are liability

issues and the

need to set up PTI.

2 - Authorities

should review the

PTI.

Table 9: Barriers in Belgium


28/10/2013 47 1.0


and cross border

eCall handling

Emerging topics

1 - Trade-off

between the cost

and the quality of

the device.

Standards have to

be met.

2 -Certification is

needed.

1 - Procurement issues

are causing delays on the

subcontracting

procedures

Not reported 1 - A workaround

solution developed

by MNO (Mobiltel)

will be used till the

eCall flag

implementation at

the end of 2013

1 - VIN national

database does not

exist.

2 - The PER unaligned

format for representing

the MSD is unclear.

3 - Need to test data

transmission.

No experience 1 - Clear

requirements and

procedures for

certification are

missing for retrofit

devices.

2 - Connection and

interaction of

retrofit device to

vehicle’s electronic

device and control

units is limited.

3 - Challenges in

achieving a rIVSs’t

design of retrofit

device.

Table 10: Barriers in Bulgaria


28/10/2013 48 1.0


and cross border

eCall handling

Emerging topics

No experience No experience No experience 1 - Difficulties for

MNOs to implement

eCall Flag.

2 - Guidelines and

recommendations

for MNOs are

needed.

1 - National VIN

database (DMR) is not

yet connected to

EUCARIS.

1 - Challenges

existing with

reference to eCall

cross boarder

handling. Assistance

should be improved

1 - Requirements

for retrofit devices

are missing.

Table 11: Barriers in Denmark


28/10/2013 49 1.0


and cross border

eCall handling

Emerging topics

1 - Integration of

the device into the

vehicle and testing

1 - Worries on the

increasing number

of eCalls due to

false alarms.

2 - Need to train

PSAP staff in order

to be able to handle

false eCalls.

1- Not very clear

how to eCall

service should be

provided for HGV

and dangerous

goods because

part of the vehicle

is produced by

OEMs the other

part, transporting

goods, is

produced by

different

manufacturers

1 - There should be

a regulation for

which all MNOs

have to provide

eCall service.

2 - Need to extend

network coverage

but issues on how

to finance that.

1 - Too many calls

could make the

network congested

thus causing

transmission

problems.

1 - A large portion of

the country is

covered by foreign

operators. It is

unclear how eCalls

will work once the

services will be

implemented.

1 - Need to define

a good triggering

strategy for HGV

and dangerous

goods.

2 - Need to provide

dynamic

information on the

type of goods

transported.

3 - Need to define

standards and

legislation for HGV

and dangerous

goods.

Table 12: Barriers in Luxemburg


28/10/2013 50 1.0

IVS PSAP OEMs MNOs Data

transmission

Interoperability

and cross border

eCall handling

Emerging topics

1- Antenna positioning in

the car

2 - Risks related to

possible low performance

of too many different IVS

existing in the market

(retrofit devices).

3 - Extra telematics

services can be

implemented that make

use of the IVS (enabler),

but interfaces must be

standardised to allow open

choice for customers and

competition, and OEMs

reluctant to allow third

parties gain access to the

IVS.

1 - Worries on the

possibility to have extra

work at PSAPs.

2 - Need to integrate

regional PSAPs to the

central one located in

Madrid.

3 - Lack of funds for the

technical update of the

regional systems.

4 - The 19 regional

PSAPs in Spain have

different organizational

models; emergency

protocol for handling

eCall is not harmonized

across Europe, and

having an intermediate

PSAP adds one more

level of coordination to

the eCall handling chain

1 - eCall represents

an extra cost for

OEMs. Shifting from

2G to 3G

technology could

further increase

eCall costs.

2 - OEMs do not let

an external device

to connect to IVS

interfaces

1 - Users cannot

choose the type of

contract to be

signed with the

MNO.

2 - Delay on eCall

Flag

implementation.

3 - Private number

will be used for

testing instead of

112

1 - Data

transmission

generates extra

costs in the system.

1 - Only tests between

adjacent regions will be

performed, not between

different countries (no

real interoperability will

be tested).

2 - DGT local vehicle

database will be used

(ATEX) instead of

EUCARIS, limitation to

decode vehicle VIN

number from foreign

vehicles.

1 - Difficulties to

guarantee the

performance of

retrofit devices.

Standardisation and

certification of retrofit

devices are a

challenge.

2 - PTW challenges:

incident detection, no

sensors to be used

for a triggering

strategy, rIVSs’tness

and false alarms,

integrity of the

system, detection of

the number of

occupants, lack of

regulations.

Table 13: Barriers in Spain


28/10/2013 51 1.0

IVS PSAP OEMs MNOs Data

transmission

Interoperability

and cross border

eCall handling

Emerging topics

No barriers identified by

interviewed Turkish

partners

1 - Procurement

issues already started

but delays are

expected due to the

need to comply with

national legislation.

No barriers

identified by

interviewed

Turkish partners

1 - Numbering

plans have not

been clarified.

There is a

discussion about

which number

ranges will be

used in

production.

1~Communication

of MSD is

dependent on

radio conditions.

In some rural

areas it is hard to

transfer MSD to

the PSAP

properly.

1 - Providing eCall

service to vehicles

arriving from other

countries will be an

issue.

2 - Roamers with IVS

equipped cars

cannot be used with

roaming steering.

Steering of roaming

should also be tested

with different IVS

vendors.

1 - Interconnection

between various

vehicles electronic

devices and control

units can be

barriers for the

introduction of

retrofit devices.

Table 14: Barriers in Turkey


28/10/2013 52 1.0

IVS PSAP OEM MNO Data

transmission

Interoperability

and cross

border eCall

handling

Emerging

topics

1 - eCall should be

sold in parallel with a

package of services.

1 - 4 out of 11 PSAPs are

integrated and are working

together.

2 – Activities for adaptation

and creation of a unique

legal and technical

framework to allow private

and public eCall services to

use the filtering instance.

3 - Astrid will manage and

provide all PSAP

technology.

4 - Call for tender has been

organized in order to select

private PSAP operators.

Not

reported

1 - Orange, France

Telecom is working

on eCall Flag.

2 - The involvement

of MNOs in the

discussion on eCall

is important.

3 - MNOs have the

responsibility to

process eCalls as

normal emergency

calls.

1 - Planned

tests will

include the

possibility to

extract the VIN

data provided

by the Federal

Government.

SMS are

already used

by private

operators.

Not reported 1 - An NXP

device will be

used for four

different vehicles

brand.

Table 15: Enablers in Belgium


28/10/2013 53 1.0


transmission

Interoperability

and cross border

eCall handling

Emerging topics

1 - TUS is developing

the first eCall oriented

device

Not reported Not reported 1 - eCall Flag

implementation is

scheduled in

December 2013

Not reported Not reported 1 – Planned testing

of retrofit devices:

modification of

existing IVS’s for

emergency and

crash alerting to

achieve

compliance to all

relevant auto-

motive standards.

Table 16: Enablers in Bulgaria


28/10/2013 54 1.0

IVS PSAP OEM MNO Data transmission Interoperability and

cross border eCall

handling

Emerging topics

Not reported 1 - Most of the

components are

ready at the Danish

PSAP.

2 - Operational

decisions on the

acceptance of eCall

from PSAP have

been already taken.

Not reported Not reported 1 - There is a need for

a small adjustment to

the Danish protocol on

satellite positioning of

the emergency chain.

1 - Use of EUCARIS

information in order to

improve interoperability

service.

2 - Use of existing

protocols for handling

112-cross border calls

1 - Use of plug-and-play

retrofit devices for the test.

2 - Each retrofit device

manufacturer should have

different configuration of

retrofit devices for vehicle

models.

3~Recommendations and

guidelines for the retrofit

device to survive a crash

test

Table 17: Enablers in Denmark


28/10/2013 55 1.0

IVS PSAP OEM MNO Data transmission Interoperability and

cross border eCall

handling

Emerging topics

Not reported Not reported Not reported 1 - MNOs funding

could favour the

eCall permanent

implementation.

1 - SMS could be

useful for improving

and completing data

transmission.

1 - PSAP operators

speak at least four

languages. In this way

most of 112 calls can be

handled. Train the trainer

concept is used (most

experienced people will

train the others).

1 - For HGV and

dangerous goods

customers might be

interested in having an

eCall service.

Table 18: Enablers in Luxemburg


28/10/2013 56 1.0

IVS PSAP OEM MNO Data transmission Interoperability

and cross

border eCall

handling

Emerging topics

Not reported 1 - The PSAP in Madrid will

operate as a filtering instance.

This PSAP will filter and

dispatch calls to the other

regional PSAP.

2 - Ericsson will provide all

PSAP components so that there

will be no problems with the

understanding of the standards.

3 - Traffic information and

Rescue Sheet retrieval from the

intermediate PSAP will improve

the dispatching of rescue

services, as added value

information will be provided to

them.

1 - OEMs are

already working

with IVS suppliers

for providing

devices with

several

infotainment

services that

include eCall

capabilities

Not

reported

Not reported Not reported 1 - PTW: helmet with

sensors embedded in

order to detect whether

there is an incident and

an eCall must be

deployed

Table 19: Enablers in Spain


28/10/2013 57 1.0


transmission

Interoperability

and cross

border eCall

handling

Emerging topics

Not reported 1- In Antalya where the

test will take place; all

emergency

associations use a

common call centre

infrastructure.

2 - Emergency calls are

already regulated at

country level under the

Turkish Information and

Communication

Authority.

Not reported 1 - Some of

national public

administration

organisations,

commercial

entities like GSM

operators and

electronic

companies signed

the eCall

Memorandum of

Understanding.

Not reported Not reported Not reported

Table 20: Enablers in Turkey


28/10/2013 58 1.0

7.2 Belgium

Public Safety Answering Point

As regards the PSAP, in Belgium there is a first level PSAP with a filtering function. This

PSAP routes eCalls to call medical service or to police of the Province where it is needed. In

Belgium there are 11 Provinces each with one Police officer and there are 10 PSAPs for fire

and medical emergency services. Currently 4 of 11 PSAPs are integrated and are working

together, sharing the same floor and same system. In the near future all system will be

integrated and there will be only one PSAP per Province.

In Belgium PSAPs are supported by 3 different authorities: Police, Fire and Medical. The

Police have access to the DIV (Directie Inschrijvingen van Voertuigen – Vehicle Registration

Service) databank, which can be used for searching VIN numbers. DIV also has a

connection to EUCARIS. Fire and Medical do not have access at this moment, but since they

are on the same technical platform, they can request access permission (in progress). There

are 7 PSAPs served by Astrid which only handle Police calls, 4 PSAP’s served by Astrid

handling all type of calls and 6 non-Astrid PSAPs handling fire/medical calls. The latter will

be migrated to the Astrid platform in the coming years. All Astrid PSAPs are standardised

and use a common infrastructure.

The real challenge, at PSAPs level, that working activities will increase once eCall has been

introduced. It is in fact not very clear how to handle eCall in case of a multiple collision where

the eCall systems from several vehicles may be activated. In order to overcome this

situation, the filtering instance has been introduced.

Belgium has created a unique legal and technical framework to allow public and private eCall

to be based on a filtering function. To realise this, existing law is being adapted. It needs to

be cleared out how filtering instances shall be selected and certified, how many filtering

instances can potentially operational in parallel, how the mobile network will select the

forwarding of an eCall to a specific instance, etc. These rules should be embedded in

updated laws.

The filtering instance 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 instance by the

public authorities. There is a direct connection from the Filtering instance to the PSAP to

properly hand over eCalls (both voice and data).


28/10/2013 59 1.0

This section will explain the operation:

Step 1: Call reception

Figure 4: eCall 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 assigned certified filtering

instances.

The operator at the filtering instance 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 instance can decide one of the following steps:

Step 2: no transfer to the PSAP

The Operator at the Filtering instance decides that there is no need to transfer to the PSAP.

(Simple breakdown or a false call).

Figure 5: transfer to the PSAP

The filtering instance 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 PSAP.


28/10/2013 60 1.0

OR

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 Instance Operator can decide to transfer the call to the PSAP.

Figure 6: Filtering instance operators

The operator at the Filtering Instance 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.

This will help the PSAPs to concentrate on real eCalls. Note that this is not private eCall, as

private eCall does not involve the short number 112 in the network.

The goal 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 instances and how is this decided?

How will a company get certified to become a filtering instance?

How does the interface between Filtering Instance and PSAP work? (E.g. how to

transfer both voice and (enriched) MSD between 2 operators at Filtering instance and

operator at PSAP?)

How to ensure fast handover? A call which is identified as an emergency call should

be forwarded to the PSAP within 30 seconds.


28/10/2013 61 1.0

How does the interfacing between Filtering Instance and Traffic Management Centres

work?

If needed, PSAP staff will receive training. Currently it is too early to organise it because the

staff will not remember it in one or two years. In Belgium pre-deployment will begin in 2014

and in 2015 the PSAP will be able to receive eCall coming from the filtering instance.

Mobile Network Operator

Belgium has many boarder countries. Cross Border is a key element for the successful

implementation of the eCall. Specifically, SIM-less emergency call is not accepted in

Belgium, although there are many SIM-less phones in Europe.

Orange do not anticipates any significant or widespread issues, though notes that the eCalls

may be affected by the prevalent radio conditions in the same way that normal calls may be

affected. In rare cases, this may increase the MSD transmission time, and the HeERO 2

activities will provide some assessment of this.

There are two aspects related to the regulation of MNOs duties. The first is related to the

implementation of eCall Flag which is important for eCall handling by MNOs. The routing and

data transmission should be tested and should be accurate, especially along the border

areas where there also foreign MNOs.

Orange have been in full support of the voluntary deployment of eCall, which was explicitly

expressed with GSMA signing the European Commission’s Memorandum of Understanding

to implement eCall across Europe in September 2009 on behalf of the European mobile

network operators and with the attention of then Commissioner of DG CONNECT Viviane

Reding.

Few respondents believe that an introduction of a formal obligation on MNOs would just add

another layer of challenges and would not resolve national specificities.

Currently it is important that scenarios for testing eCall are determined and that MNOs are

closely involved in these discussions. Technology changes fast within the mobile

environment so that there is the need to look forward to anticipate updates to standards. This

aspect is similar to the vehicle industry, although with a slower time-to-market, they require

considerable long-term planning.

IBSR is working together with Orange and France Telecom and the eCall flag will be

implemented here without delays.

Orange has the responsibility to process incoming eCalls in the same manner as normal

emergency calls are processed. The responsibility for processing eCalls and routing them to

the correct PSAP always lies with the network serving the vehicle at the time of activation,

which may or may not be the home network of the user placing the eCall (i.e. roaming).


28/10/2013 62 1.0

This is confirmed in the European Commission’s Communication of August 2009, in which it

is stated: “The mobile network operator (MNO) identifies that the 112 call is an eCall from the

‘eCall flag’ inserted by the vehicle’s communication module. The MNO handles the eCall like

any other 112 call and routes the call to the most appropriate emergency response centre -

Public Safety Answering Point (PSAP) - 13 as defined by the public authorities.” It is

furthermore stated that “Member States must inform mobile network operators operating in

the country of the most appropriate PSAP to route eCalls.”

The use of SMS is already foreseen as a mean for contacting the emergency service. This

service will be active in 2014. In Belgium there is an on-going national project on SMS

service for deaf or bad hearing people to contact PSAPs.

SMS could enrich the eCall system, but there could be an issue with reliability and

prioritisation of an “emergency SMS” by the MNOs. Orange believes that, at this stage,

changing the technical standards to potentially include SMS, would mean a delay to the

deadline end of 2014. Therefore, at this stage, the inclusion of SMS is not recommended.

In Belgium there are a lot foreign drivers so communication could be an issue (also for

private eCall operators). For private eCall operators cross boarder handling is already in

place but it still represent a problem. For the emergency services PSAPs these kinds of calls

will be handled the same as the 112 cross boarder eCalls.

Retrofit Devices

Belgium will test the use of retrofit devices. However the interface is not standardised and

there are some doubts on whether the interface to the CAN bus is sufficiently open to allow

easy integration of retrofit devices. HeERO 2 will test many IVS and many vehicles so that

enough inputs should be gathered by the end of the project to confirm that there is a need for

more work on that aspect.

Where to put the device is the real challenge. The same IVS will be tested with different

vehicle brands and lifetime. Thus it will be possible to assess if the eCall box emplacement

ensures functioning of the device in case of severe incidents.

Another aspect is liability. For instance Volvo equipped with retrofit device, after four year a

technical inspection is performed. Authorities should be responsible for assuring that the PTI

is performed on IVS for retrofit devices.

7.3 Bulgaria

A central PSAP, located in Sofia, will handle all eCalls at national level. In the future, it is

planned to dispatch eCalls at a regional level. Mtel will upgrade the MSC software by

December 2013.


28/10/2013 63 1.0

The eCall-flag implementation is scheduled by the last quarter of 2013.

ICOM will provide the eCall telematics devices for retrofit installation in passenger cars and

LCV’s, implementing the eCall in-band modem standardised by ETSI in IVSs’ (In vehicle

System), and prepare all necessary documentation. This will be done through modification of

existing IVS’s for emergency and crash alerting to achieve compliance to all relevant

automotive standards and still be available as retrofit devices.

The provided IVS’s will target the ultimate goal of bringing to the market a low-cost eCall

compliant retrofit IVS solution for passenger cars and LCV’s, so that mass retrofit

installations in used vehicles may be possible in the near-term, which is a key factor for

achieving tangible social benefits from eCall deployment in the 10 new EU member states

and especially in Bulgaria and Romania.

Technical University of Sofia will develop in-vehicle system. This device will have the

following components and possibilities:

GSM with integrated in-band modem - this component will utilise the data connection

over the speech channel of GSM network.

GPS - this module will provide accurate geo-location of the vehicle.

Gyroscope and inertial sensor - these sensors will provide possibility of crash

detection.

Procurement issues are currently causing delays on the subcontracting procedures.

Specifically, delayed hardware delivery is delaying the consignment of all the other products

that depend on it. In addition the largest thread from the implementation point of view will be

the integration between PSAP and eCall test and development environment. Finally, a

national VIN does not exist yet. Other issues are expected to arise during the execution of

the test.

7.4 Denmark

The main challenge of the Danish pilot is the mobile network because operators are not

willing to implement the eCall Flag. Currently there are three out of four operators that cover

all Scandinavia. The reason why MNOs do not implement the eCall Flag right away could be

that they don’t see the business in it. There should be a standardised way or should exist

recommendations for MNOs on how to implement eCall and more information accessible to

them on what are the consequences for MNOs after the implementation of the eCall.

Interoperability is already an issue in Denmark when foreign vehicles enter the country. The

assistance will be improved if EUCARIS information should be introduced.


28/10/2013 64 1.0

In Denmark call for tender procedures are efficient. A number of suppliers that are pre-

qualified to deliver the whole system are selected. A general tender is made on a short list of

six/ten suppliers and the procedure from tender is posted to vendor is selected can be as

short as 14 days.

The pilot test will use plug and play retrofit devices. Currently Pilot Sites participants are

looking for suppliers and for cooperation with them. The test on these devices will be based

on the same KPIs as the ones identified in HeERO 1. However there will be no crash test to

see the endurance of the devices.

7.5 Luxembourg

As Luxembourg is small and a transit country all PSAP operators speak 4 languages:

Luxembourgish, German, French and English as a matter of course (This is common

practice in Countries that for significant cross roads on the Trans European Road network).

Some operators speak additional languages like Portuguese. With this approach most 112

calls can be handled.

Luxembourg has only one PSAP that is operated by Administration des Services de Secours

(ASS). All 112 calls in Luxembourg arrive here. The operators in the PSAP coordinate the

emergency service, like fire brigades, ambulances, emergency doctors and civil protection

and also work closely with the Luxembourg police. A new PSAP expected to be implemented

in 2016 police and ASS will work together in one control room.

The biggest Luxembourgish MNO Enterprise de Postes et Telecommunication (EPT) is

partner in the HeERO 2 project and supports the implementation of eCall in Luxembourg.

The eCall-flag is expected to be implemented Mid 2014, to allow complete eCall tests with

eCall-Flag at the end of the HeERO 2 project.

The main issue discussed in Luxembourg in regards to eCall is how to handle the false calls.

There is no experience on how many calls will arrive after the implementation of the eCall

service and how many people are needed.

The Luxembourg 112 PSAP is a service PSAP. This means that 112 can be called for

questions like, where is the next open pharmacy, where is the next doctor etc. With the

introduction of eCall this traffic may increase as with the manual eCall button in the car it is

much easier now to call the PSAP. The PSAP staff have to gain experience how to handle

this situation.

Moreover PSAP staff will have to be able to handle the call and face all situations. Training

will be organised to train the full staff of the PSAP on handling eCalls. Probably there will be

about 12 people to be trained. The training concept will be based on the “Train the Trainer”

concept. The most experienced people will train the others.


28/10/2013 65 1.0

A big portion of the country is mainly covered by foreign MNOs. In border areas it is possible

to receive signals from the foreign operators such as the Germans ones. Currently calls that

arrive to the German operators are forwarded to Luxembourg operators. It is not decided

how this will work once eCall services will be implemented.

The solution implemented for eCall in the HeERO 2 project is an interim solution to test eCall

and gain first experience. The final solution will be integrated into the new PSAP that is

expected to come into operation in 2016.

Therefore a simple solution based on the solution used in Germany and Netherlands was

selected and will be implemented in the Luxembourg PSAP. The solution provider ensures

that the eCall standards are implemented correctly. This has already been proven in the tests

of the HeERO project.

The operational procedures have to be defined and adapted to the current procedures. Here

a standard set of procedures be very helpful.

At the moment calls that arrive to the German operators are forwarded to Luxembourg

operators. SMS support is not seen as an option in Luxembourg.

7.6 Spain

In Spain there are 19 regions each with a different PSAP solution. A central PSAP, located in

Madrid, will receive eCall from vehicles and re-route them to the corresponding 112 Centre.

There will be the need to adapt the systems of the 19 regions to receive the eCall.

From the analysis of the state of the art carried out in WP2, it was shown that in Spain each

PSAP has an internal procedure for handling emergencies.

The main challenge of the Spanish pilot is the technical differences between regional PSAPs

and the lack of funding for their upgrade. One goal of HeERO 2 is to provide experience for

the homogenisation of the PSAPs procedures specifically on how operators should handle

eCall. Similarly to Belgium and Luxembourg, one of the main barriers for the eCall

implementation in Spain is related to the concern of extra work due to the entrance of false

calls. For this reason a central PSAP in Madrid will function as filtering instance. This PSAP

will be in charge of filtering and dispatching calls to the regional PSAPs.

However there is the need to adapt and integrate the regional PSAPs to the central PSAP.

Spanish pilot partners are also considering the possibility to perform the HeERO 2 test using

a long number instead of 112 as the MNO who are supporting the project do not have

sufficient funds to achieve everything, so the focus remains on resolving the complex issues

regarding the filtering function in the central PSAP and the integration of the 19 PSAP.


28/10/2013 66 1.0

The understanding of PSAP standards is not a problem in Spain where a single provider of

PSAPs components is aware of all existing standards. However recommendations to PSAPs

from operational point of view are needed.

Ericsson is pushing toward the use of SMS and this service will be available in 2014 (Not

connected with eCall). Moreover there exists an on-going national project on SMS for deaf

or hard of hearing people in order to be able to contact with the PSAPs.

Since the in-band modem is not always reliable for sending MSD, the possibility to add SMS

as an additional service is also discussed in several meetings. The main problem is the

reliability of the technical service. Standards for in-band modem communication are already

in place and took a while before they have been approved; the same could happen to SMS

standardisation, though it must be clearly stated this does not form any part of Pan European

eCall where the direction in clear with the use of In-band modem..

Spain will test the eCall for PTW. eCall IVS that is independent from the PTW have been

designed so that there will be not the need to integrate with the PTW design.

The main issue is the crash protection which is more challenging comparing to vehicles.

Due to the lack of regulation, at first stage the PTW eCall will fulfil the existing normative (see

chapter 8.3 on legislation and regulatory aspects of PTW) and the device will be independent

from the vehicle itself.

There are no issues understanding the standards because those are mainly oriented to the

emergency transmission and the pilot test call management system is the same as in an

automobile.

The triggering strategy for the pilot consists in an on-board module and a helmet module as

described in chapter 8.5. The use of the Smartphone to analyse an alternative way to carry

out the eCall could be tested.

Concerning the voice transmission a voice channel with Bluetooth between the rider and the

helmet is implemented. Even there is not a voice connection, the MSD will be sent. A button

to deactivate the eCall if the rider detects a false positive and the possibility to activate the

eCall manually are also considered.

The main technological challenges of the Spanish pilots are the development of 4 different

Pilot Sites and the integration of the PTW vehicles which has a very different characteristics

comparing with other vehicles.

7.7 Turkey

In Turkey the PSAP located in Antalya will be tested. Two PSAPs will be under the same roof

but they will not interact with each other; they will use separate system infrastructure from


28/10/2013 67 1.0

HeERO 2. Turkey is working on a project aimed to bringing all emergency services in a 112

single emergency call number. In Antalya all emergency associations use a common call

centre infrastructure.

After the test, the Ministry of Interior will take decisions concerning the required number of

PSAPs for dispatching eCalls. However emergency calls are regulated at country level under

the Turkish Information and Communication Technologies Authority and this will support the

implementation of the eCall. Since eCall is related with mobile communications, the

regulatory of MNOs duties is fundamental for eCall deployment.

There are three mobile network operators in Turkey - Turkcell, Vodafone and Avea. In

Turkish pilot, eCall flag will be implemented and tested on Turkcell network in Antalya. There

was a working trial on TIM Italy network. Probably the same market corrections will be

implemented on Turkcell network.

Numbering plans have not been clarified and there is a discussion about which number

ranges will be used in production.

Communication of MSD is dependent on radio conditions. In some rural areas it is hard to

transfer MSD to the PSAP properly. Another issue is steering of roaming issue. Roamers

with IVS equipped cars cannot be used with roaming steering. Steering of roaming should

also be tested with different IVS vendors.

Turkish government does not give any funding for emergency communication to MNOs.

Their thought is that MNOs are obliged to supply this service on Telco Grade basis and with

high location accuracy. However, MNOs should invest on location acquisition systems. In US

for example, MNOs are collecting money from their subscribers every month for emergency

purposes.

For pilot, only one MSC-S is planned to upgrade for eCalls. Turkish Information and

Communication Technologies Authority’s will take decisions and regulations about

implementation of eCall flag in other MNO operators’ networks. This authority is the decision-

making body on this kind of emergency communication issues.

With reference to the tests, there are procurement issues. Subcontractors have been already

identified at the beginning of the project but, in order to complete public procurement

procedures, it is necessary to comply with national legal requirements.

Finally there will be a language problem especially in relation to cross boarder eCalls.

In Turkey some of national public administration organisations, commercial entities like GSM

operators and electronic companies signed the eCall Memorandum of Understanding. This

shows the willingness and the determination to implement eCall nationwide.


28/10/2013 68 1.0

A national implementation plan for eCall implementation is not defined yet. However, there is

a draft ITS Action Plan of Ministry of Transportation that includes the implementation of eCall

System at the same time with EU countries.

The pilot activity in the context of HeERO2 will bring Turkey the necessary experience for

this planning, especially for institutional and financing issues.


28/10/2013 69 1.0

8 Identification of Challenges for New Emerging Topics

8.1 Power two wheelers

The following table summarises the main challenges to the development of PTW (Power two

wheelers) eCall services. All these aspects are described in more detail in the following

chapters.

Triggering

system

PTWs do not have the sensors that in vehicles are used to trigger the

emergency call. If sensor are introduced the decision on their position is

critical. Voice communication is difficult, manual activation or deactivation

needs careful consideration- simple button on bike is not possible.

Strategies tailored to PTW need to be developed.

Voice

transmission

The establishment of a successful voice transmission is more difficult

comparing to vehicles. A possibility is to place the voice communication

system in the helmet and connect it to the IVS placed in the motorbike.

MSD One of the most important information is the number of occupants which is

in general very difficult to determine and the VIN number. GPS coordinates,

the direction of the vehicle and the time of the incident are also important.

Additional information existing for vehicles is also useful.

Standards

and

regulations

Ambitious schedule from EU bodies for eCall implementation with still

unclear topics like private call centres. There is the need to proceed step by

step. Specifically, there is the need for regulations on environmental,

electrical safety and stress tests, functional safety (ISO 26262 or ISO

61508) and on reliability of the communication protocol.

Standards for ‘front end’ on PTW need to be defined (meaning incident

detection).

Other Need for planning of eCall architecture.

The interest of customers is demonstrated with the different projects

developed in EU frame related PTW safety (SAFERIDER, PISa, MOSAFIM,

etc.) and by the increasing number of Smartphone applications existing for

PTW for emergency call.

Table 21: Challenges for PTW


28/10/2013 70 1.0

8.2 Technological challenges related to PTW

The biggest problem of eCall for PTW is the definition of the triggering strategy. Specifically,

the problem is to detect false calls and the need for a strategy that reduces the activation of

the emergency call in case of errors.

The other aspect is the need to design a system which is robust and that guarantees the

complete functionalities of the system in particular after the incident. The main difference

between the vehicles is the dynamic of the incident so that many aspects need to be taken

into account and not all aspects can be taken from the automotive sector.

Specifically, the main technological issues of eCall for PTW are:

Incident detection algorithm: integration of all sensors’ data, thresholds definition,

signals filtering, etc.;

PTWs do not have the sensors that are pre-existing an automobile and used to

trigger an emergency transmission;

Robustness and false alarms: a PTW may fall over in a number of circumstances

without the need for an eCall signal to be generated;

Integrity of the system in case of incident;

Detection of the number of occupants;

Robustness of the link between the helmet and the PTW needs to be operative in all

incident configurations;

Economical obstacle: the largest market segment (60%) is represented by urban

oriented vehicles with a cylinder capacity below 125cc and consumer costs between

1000€ and 3000€. The costs associated with a legislative approach to eCall would be

disproportionately high for the vast majority of PTW models.

The implementation of an eCall system for PTW is very different comparing to the system

designed for cars. These differences generate the technological challenges that have been

listed at the beginning of the chapter and that will be analysed below.

Due to the complexity of a PTW incident compared to car incidents, with so many different

scenarios on PTW (i.e. the deflection of the vehicle due to its small frontal area, the

separation rider and vehicle, the relative high number of single incidents) the incident

definition is the main challenge. Very few studies exist to define a “serious PTW incident”

based on vehicle or rider data. The triggering strategy will be far more complicated than car

because PTWs do not have the sensors which are used to trigger the emergency call. This

fact makes difficult the detection of the incident, converting the detection into one of the most

challenging part of the entire system. The detection process has different steps which have

to be carefully evaluated for the specific case of PTW: the selection of the sensors,


28/10/2013 71 1.0

integration of the information of all the sensors, the thresholds definition, signal filtering,

incident detection algorithm, etc. The decision on the position of the sensors is also critical

(Additional details on this topic are illustrated in Par.8.5)

The part of the emergency transmission itself is not different comparing to other kind of

vehicles. Nevertheless, the establishment a successful voice transmission is more difficult. In

case of incident, since the separation of the rider from the PTW is the most common

situation, keeping the voice communication alive is more challenging. In the Spanish pilot a

voice communication is implemented via Bluetooth between the eCall device and the helmet.

It has to be insured that the robustness of the link between the helmet and the device needs

to be operative in all incident configurations.

Another challenge is related to the integrity of the eCall device itself. The vast majority of

parts of the PTW are exposed to have an impact in case of incident, so that when its location

is selected it must be taken into account.

Regarding the MSD one of the most usable information for emergency services is the

number of occupants. In case of PTW the number is one or two, but it is very difficult to

determine the actual number of riders in each case.

One possible solution is to place the voice communication system in the helmet and connect

via Bluetooth the IVS that is placed on the motorbike. In this case standards exist for

reliability aspects but there are no regulations. There is the need for regulations on

environmental, electrical safety and stress tests, functional safety (ISO 26262 or ISO 61508)

and on reliability of the communication protocol.

8.3 Legislation and regulatory aspects

There is a lack of regulation related to this kind of devices in PTW. Specifically there is the

need for standards and regulations on environmental, electrical safety, functional safety (ISO

26262 or ISO 61508), stress tests and tests on the reliability of the communication protocol.

The most relevant normative is the next:

Directive 2010/40/EU: deployment of Intelligent Transport Systems in the field of road

transport and for interfaces.

Directive 2002/24/EC: Type-approval requirements for new vehicles of the L-

category.

Normative 97/24 (chapter 8): Electromagnetic compatibility for PTW.

And for helmet device the following normative have to be taken into account:

1999/5/CE: for radio-electric and telecommunication equipment;

EN60950: low voltage directive.


28/10/2013 72 1.0

8.4 Standards

The most part of the defined standards for Pan European eCall are related to the emergency

transmission itself, avoiding the standardisation of the incident detection.

There are no standards on how data should be collected and sent in case of an incident

involving a PTW. However it has to be noted that, in case of PTW, the transmission

management with emergency services is the same as the one used in case of other vehicles.

8.5 Triggering system

This is the most challenging issue of the eCall for PTWs. By default, a PTW does not have

an impact detection system. In case of automobiles, the airbag signal is used to trigger the

emergency call, but it is not possible to do the same. The first approach when developing a

triggering system is the combination and integration of different inertial sensors with the GPS

data.

Two different solutions are described.

1. One possible scenario might be an onboard system (eCall box) with SIM card and

detection software etc. in a crash proof place on the PTW and a small ‘sensor’ unit on

the rider. This should be a ‘flexible’ device with no hard fixation to any garment or

helmet, since it would restrict freedom of choice of helmet and garment and lead to

reduced acceptance by users.

2. The alternative strategy consists in developing the signal by dividing it divided into

two different modules. The main is the on-board module and the secondary module is

placed into the helmet. On-board module completed all the eCall chain: the detection

of the incident and the emergency transmission management. The location concrete

of this module is not decided yet, but it will be independent of the vehicle, that is to

say, the eCall system could be used with any motorbike.

The module in the helmet allows a better evaluation of the incident: this module can assess

the head injuries of the rider in case of incident. The helmet electronic is also use to provide

voice communication with the emergency call.

The use of a Smartphone can be also an alternative to this device. Its main drawbacks are

the next:

The limited sensors of conventional Smartphone: they only have a 3 axis

accelerometer.

It is impossible to predict the location of the sensors (of the Smartphone), and it is

very difficult to design a general algorithm for all cases.


28/10/2013 73 1.0

8.6 Customer interest

Customer interest will grow if:

System is simple and will not restrict rider’s freedom of choice regarding garment,

helmet, etc.;

Reasonable cost to user (no or very small subscription fee);

As all safety devices, acceptance will start in North Europe and gradually expand to

South Europe;

Personal data protection is essential – motorcyclists maybe more than other groups

are very sensitive on ‘misuse’ of their data i.e. when it comes to record driving

behaviours. eCall must avoid to be regarded as ‘black box’.

Currently, user can choose an emergency system. The intention of PTW OEM is not to

impose the purchase of clothing specifically dedicated to eCall. In general, it is necessary to

take into account customer needs and to consider the impact on the cost of the device.

Currently costs are high because development costs are high. The problem is that costs are

much higher comparing to vehicles.

8.7 Heavy goods vehicles and Dangerous goods

The following table summarises the main challenges for the development of eCall services

for HGV and dangerous goods. All these aspects are described in more detail in the following

chapters.

MSD The main issue is how to get the information what is loaded in a truck

that has an incident. Currently the type of warning is not clear. There

are three possibilities: information stored into MSD, a link to the

transportation document is stored in the MSD or link to web service

providing transport information stored in the MSD.

IVS The problem is that the truck is formed by two separate systems: the

one carrying goods and the other produced by the vehicle

manufacturers.

It is necessary to find a good position for the IVS and how to trigger the

system in case of incident.

Data transmission The exchange of dynamic information on type of goods transported and

on the type of warning that should be produced in case of fire.

Discussion on how to encrypt data inside the data string for making


28/10/2013 74 1.0

them available for the PSAP.

Standards,

legislation and

regulatory aspects

Liability aspects are not clear. There is no legislation to provide

information on the type of goods transported. There should be a flag

indicating if the vehicle can transport dangerous goods or not and the

type of HGV or dangerous goods it can transport.

There is the need to provide legislation or to let the private sector to

manage these problems.

Table 22: Challenges related to HGV and dangerous goods

8.7.1 Technological challenges related to HGV and dangerous goods

As described in chapter 5.2 on eCall development activities for HGV and dangerous goods

the standard is under development by CEN TC278 WG15. It was discussed if the eCall

functionality should include all HGV or only those carrying dangerous goods. The consensus

is now that all HGV should be included into the eCall legislation. The main issue is now, how

to get the information what is loaded in a truck that has an incident?

There are 3 models under discussion:

1. information about the loaded goods is stored in the MSD;

2. a link to a transport document is stored in the MSD;

3. a link to a web service providing detailed transport information is stored in the MSD.

The 3 models are discussed including the main barriers in the next chapters:

Transport information stored in the MSD

This is the most direct way of handling the transport information. The information about the

loaded goods is stored directly in the MSD.

This is a simple solution that needs the least changes in the eCall chain.

The main issues of this model to be discussed are:

This concept only works for transports with a limited number of different goods, e.g.

tankers.

How will the information about the transported goods be kept up to date? How will the

information be updated when material is loaded or unloaded? How to ensure that the

information is correct and not manipulated? An interface for the IVS to the fleet

management solution may be necessary to keep the data up-to-date.

Link to the transport document in MSD

A document in PDF format, similar to the transport documentation, is stored on a server. This

document contains all necessary information about the transported goods. It can be created


28/10/2013 75 1.0

by the fleet management system or can be updated by hand. The MSD only contains a link

to this document. The link is transferred to the PSAP as part of the MSD and the operator in

the PSAP can open this document in case of an incident.


How to update the link in the IVS? Can it be fixed and only changed when the owner

of the vehicle is changing?

How will the information about the transported goods be kept up to date? How will the

information be updated when material is loaded or unloaded? How to ensure that the

information is correct and not manipulated? An interface of the fleet management

solutions used in logistic companies may be necessary to keep the data up-to-date

and to generate the documents.

Link to a web service

In this model the information about all transports is stored in one or several trusted tracking

services. These services receive the information from the logistic companies regarding their

transports that should be traced. In case of an incident the service can provide this

information to the PSAP via a web service. The link to this web service is stored in the MSD.

The information about the transported goods is retrieved via the VIN stored in the MSD. So

no additional information is needed.


This kind of service is not available and accepted yet (several EU and ESA projects

work on it)

This service must be trusted by the logistic companies as it stores sensitive

information

Who pays for this service?

The web interface is not standardised

8.7.2 IVS for HGV

In case of HGV and dangerous goods, the IVS should be integrated in the design of the

vehicle (e.g. for instance between the driver and the passenger, on the dashboard). In this

position it would be difficult to destroy it.

The problem is that the truck is formed by two separate systems: the one carrying goods and

the one produced by the vehicle manufacturer. Additionally there are different sensors

comparing to the ones of the vehicles currently mandated for eCall. Another issue that is

explained below concerns the exchange of dynamic information on type of goods transported


28/10/2013 76 1.0

and on the type of warnings that should be provided in case of fire caused by transported

goods.

Additionally the trailer could have some sensors to detect, for example, fire, smoke, loss of

pressure. This information could be sent remotely to the IVS to be included on the MSD.

In the future, it should be desirable that all truck manufacturers include the IVS and the on-

board computer in the truck as series equipment. Only in this scenario, the OEM can be the

responsible for the eCall. The liability aspect is not clear in any different scenario.

Another challenge of the eCall in HGV is to detect collision on the truck and on the trailer.

Trucks do not have airbags, so one option could be to get the information from the tensor of

the safety belt (though not mandated in many trucks) there are a number of other novel

sensors that could be employed all concerning the vehicle dynamics in a critical situation.

Collisions in the trailer could be detected by several sensors or accelerometers.

Concerning HGVs is necessary to find a good position for IVS and how to trigger the eCall

system in case of an incident. There should be two devices for measuring the acceleration of

the vehicle in order to determine if there is an incident or not. If the acceleration of the device

exceed a certain threshold it is possible to determine if an incident occurred. The biggest

challenge is the test.

Concerning vehicles transporting dangerous goods, there is no indication whether the vehicle

transports dangerous goods. Dynamic information is needed because every time different

type of goods is transported. Solutions have to be explored on how to deal with IVS

connected to a central service. In this way the eCall system could check in a central

database and provide information to emergency services on which kind of goods are

transported. In this case the logistic companies should provide information to this central

database. A possibility is having a central database similar to the one of EUCARIS.

8.7.3 Overview on regulatory aspects and standards

Standards are in progress and this is an important aspect which will be handled in the

contest of HeERO 2 WP6.2.

For HGVs there should be an indication on which type of heavy goods are transported. There

should be a flag that states if the vehicle can handle dangerous goods or not. With the

classification of vehicles on whether if they can or cannot transport heavy goods vehicles it

could be easier to provide the appropriate eCall service.

MSD depends on the kind of risk that want to be avoided and on the type of load transported.

For instance there could be risk of fire for some types of goods. The type of warnings to be

provided is not clear. So that there is the need to provide legislation on these aspects or to

let the private sector to manage the problem.


28/10/2013 77 1.0

8.8 Retrofit devices

The following table summarises the challenges related to the use of retrofit devices for eCall

services. These aspects are described in more detail in the following chapters.

Retrofit device

design &

technical aspects

Need to have a rIVSs’t design.

Radio and GPS signal in retrofit devices is a problem. The correct

functionality of the IVS cannot be fully guaranteed without an

appropriate installation on the vehicle. A possible solution is to offer a

discount for vehicle insurance if the retrofit device is installed by a

certified company.

The location of the unit should be analysed in terms of vehicle impact

thus considering the construction year of the vehicle which has an

influence on the performance.

Standardisation

and certification

Clear requirements, standardisation and procedures for certification are

deployment barrier.

No recommendations or guidelines exist for crash test or for the

installation of retrofit devices by skilled people. There should be

certification or warranty on airbag functioning and clear regulation on

liability issues. There should be an independent body that certifies

retrofit devices.

Legislation and

regulations

Liability aspects should be clarified.

The retrofitting market will need a legal framework that in turn could

lead to an increased public acceptance level of eCall system.

Table 23: Challenges of retrofit devices

8.8.1 Design and requirements of retrofit devices

Clear requirements, standardisation and procedures for certification represent up to now

deployment challenges for retrofit devices. There is a difficulty to understand what a retrofit

device is, requirements in terms of robustness and technical aspects are also missing and it

is necessary to have strict regulations. A legal framework for retrofit devices could lead to an

increased public acceptance level of eCall system.

Retrofit devices are almost 100% autonomous (with exception of the power supply). Their

connection and interaction to vehicle’s electronic devices and control units is limited.

Challenges lie mainly in achieving a very robustness design capable of delivering the

required functionalities in extreme conditions, which is at the same time universal enough to


28/10/2013 78 1.0

allow fitting in all passenger car makes and models. Each car manufacture has different

communication systems. Therefore the challenge is to have a number of configuration

templates such as different combination of retrofit device and vehicle models.

The location of the unit should be analysed in terms of vehicle impact thus considering the

construction year of the vehicle which has an influence on the performance. No

recommendations or guidelines currently exist for retrofit device to survive a crash test.

In order to ensure that the device is working properly, motion sensors could be a solution.

Some kind of accelerometer set could be programmed to generate an event of crash when a

threshold of acceleration is achieved. However this solution could cause a lack or an excess

of emergency Calls generation due to the lack of communication with the vehicle.

Radio and GPS signal in retrofit devices is, in general, a problem. For the commercialisation,

it should look nice and it should be hidden in order the make the people used it.

Retrofit device providers affirm that the main challenge is the certification and standardisation

of interfaces, especially when speaking about devices which have a direct impact on safety.

For example, retrofit on-board devices need to have access or connection to specific in-

vehicle systems/interfaces (e.g. CAN bus) for specific purposes involve a barrier for the

deployment of aftermarket eCall devices. Generally, OEMs will not be open to let an external

device to connect to specific in-vehicle systems and this might have an impact on safety

aspects, for example in case of failure of the system, if the IVS is series equipment, the car

manufacture has responsibility. As explained in the following chapter, in the case of retrofit

devices, it is not clear who has the liability. Moreover the correct functionality of the IVS

cannot be fully guaranteed without an appropriate installation on the vehicle.

8.8.2 Installation of retrofit devices and liability aspects

This is a critical issue in case of retrofit devices. The installation must guarantee good

antenna reception and the IVS have to communicate with the vehicle getting somehow the

information from the airbag. The key point is to define the requirements on the retrofit IVS

installation. Its position in the vehicle is very important for good antenna reception. But the

electrical installation is the main challenge. The information on the condition of the airbag

could be used for the installation of retrofit devices. However, it has to be noted that there are

no sensors specified for eCall, it is only recommended that after market devices have internal

sensors and should not interface with the vehicle.

In general there is no relation between the vehicle manufacturer and the company installing

the IVS. The installation of retrofit device should be performed by skilled people. However

standards, requirements or guidelines are missing.


28/10/2013 79 1.0

A possibility is that insurance companies take the responsibility for the installation of the

device and guarantee the correct IVS functioning. As an exchange, the insurance company

could obtain information from its customers like mileage or vehicle use.

Another possible solution is to offer a discount for vehicle insurance if the retrofit device is

installed by a certified company. This system could ensure that retrofit devices are installed

in the correct way. In Germany there are many dealers of electronic devices. These

companies could be the certified installer of retrofit devices for eCall. They know how to

install IVS such that the system works. Discussion with the certification task force of HeERO

2 is taking place on this subject.

Finally, the introduction of an independent body that certifies retrofit devices is highly

recommended.


28/10/2013 80 1.0

9 Conclusion

This preliminary report illustrated several aspects that have been identified by respondents to

ICOOR interviews as challenges, barriers and enablers for the implementation of an inter-

operable and European eCall service.

In this conclusion some of the main identified challenges are summarised.

At national level, challenges on how to finance programmes and technology for the eCall

implementation have been highlighted. In HeERO 2 this aspect is mainly focused on the

need to finance the filtering entity that is expected to facilitate the introduction of eCall and its

acceptance from PSAP operators. There are also specific national situation such as in Spain

where the need to finance the update of regional PSAPs and their integration to the central

PSAP have been raised.

Concerning the business aspect, while in HeERO 1 is underlined the importance to integrate

private operator services to the Pan-European eCall, HeERO 2 considers also aspects

related to the need to finance the network extension for ensuring network coverage or the

need to standardised IVS devices to have the possibility of offering additional services to

customers and increasing the competition, it should not be forgotten that the mandating of

eCall will in a limited instance present Europe with it first fleet of connected cars, this is an

opportunity that should not be missed.

The provided answers have shown the relevant activity to regulate several aspects of eCall.

From the point of view of some of the respondents, for instance, legislation should be

introduced with reference to the implementation of eCall Flag by MNOs, to the need to

ensure the minimum set coverage, to clarify liability aspects of eCall and procurement issues

at PSAP level.

From the technical and technological point of views, challenges have been identified

especially in relation to the need to ensure that the eCall device is working properly (i.e.

crash tests, PTI) and that sufficient network coverage is guaranteed. The importance of

interoperability tests has been mentioned. PSAPs must be able to effectively manage eCalls

and exchange information between each other.

With reference to PTW, the process of an eCall development service has several differences

comparing to vehicles. This creates the need to develop a special system and appropriate

regulations. The main challenge is triggering strategy and the voice communication because,

in case of an incident, the driver is separated from the vehicle. With reference to HGV and

dangerous goods vehicles the main challenge is the position of the eCall device because the

vehicle is formed by two parts: the cabin and a separate part carrying goods. Another aspect


28/10/2013 81 1.0

is the type of information to be transmitted, that is the MSD definition. Finally, concerning

retrofit devices, there are several technical challenges that must be faced such as the need

to ensure that the device is properly installed.

An update of this document will be provided during the last months of the project when the

Pilot Sites will provide feedback on their tests and additional challenges and enablers may be

identified.


28/10/2013 82 1.0

10 References

http://www.saferider-eu.org/

http://www.2besafe.eu/

http://www.pisa-project.eu/

http://www.mosafim.eu/welcome

Public Consultations. Deployment of in-vehicle emergency call – eCall – in Europe.

Comments from the European Motorcycle Industry (ACEM). Brussels. 2010.

http://ec.europa.eu/information_society/activities/esafety/index_en.htm

Commission Directive 2010/40/EU of the European Parliament and the Council on the

framework for the deployment of Intelligent Transport System in the field of road transport

and for interfaces with other modes of transport. Official Journal of the European Union.

7.7.2010.

Commission Directive 2002/24/EC of the European Parliament and of the Council on the

type-approval of two or three-wheel motor vehicles. Official Journal of the European Union

18 3 2002

Commission Directive 97/24/EC of the European Parliament and of the Council of 17 June

1997 on certain components and characteristics of two or three-wheel motor vehicles.

Commission Directive 2009/108/EC of 17 August 2009 amending, for the purposes of

adapting it to technical progress, Directive 97/24/EC of the European Parliament and of the

Council on certain components and characteristics of two or three-wheel motor vehicles.

Regulation (EU) No 168/2013 of the European Parliament and of the Council of 15 January

2013 on the approval and market surveillance of two- or three-wheel vehicles and

quadricycles

Directive 1999/5/EC of the European Parliament and of the Council of 9 March 1999 on radio

equipment and telecommunications terminal equipment and the mutual recognition of their

conformity.

EN60950 Safety of Information Technology Equipment including Electrical Business

Equipment Normative

Education of 112 call takers EENA Operations Document:

http://www.eena.org/ressource/static/files/2012.010.22.3.3.3.edusupport.v1.0.pdf

Psychological support EENA Operations Document:

http://www.eena.org/ressource/static/files/2012.10.22_3.3.2_psysupport_v1.0.pdf

http://www.saferider-eu.org/

http://www.2besafe.eu/

http://www.pisa-project.eu/

http://www.mosafim.eu/welcome

http://ec.europa.eu/information_society/activities/esafety/index_en.htm

http://www.eena.org/ressource/static/files/2012.010.22.3.3.3.edusupport.v1.0.pdf

http://www.eena.org/ressource/static/files/2012.10.22_3.3.2_psysupport_v1.0.pdf


28/10/2013 83 1.0

Multilingual 112: Multilingual 112 Calls EENA Operations Document

http://www.eena.org/ressource/static/files/2012-03-02_3-1-4_mic-v-1.pdf

Navipedia website http://www.navipedia.org

Titterton, D. H. and Weston, J. L. (1997): Strapdown Inertial Navigation Technology. 2nd ed.

Paul Zarchan editor, ISBN:1-56347-693-2.

Open Mobile Alliance website:

http://technical.openmobilealliance.org/Technical/release_program/supl_v3_0.aspx

E. D. Kaplan, C. J. Hegarty, Understanding GPS: principles and applications, Second

Edition, Artech House, Norhood, MA, 2006

GSA website http://www.gsa.europa.eu

P3ITS http://www.ertico.com/pre-commercial-public-procurement-for-its-innovation-and-

deployment

http://www.eena.org/ressource/static/files/2012-03-02_3-1-4_mic-v-1.pdf

http://www.navipedia.org/index.php/main_page

http://technical.openmobilealliance.org/technical/release_program/supl_v3_0.aspx

http://www.gsa.europa.eu/

http://www.ertico.com/pre-commercial-public-procurement-for-its-innovation-and-deployment


28/10/2013 84 1.0

ANNEX I: Questionnaire

HeERO2 WP6 Barriers and Enablers

Name of the respondent:

Company:

Type of company / role in HeERO2:

List of questions

IVS/PSAP suppliers (providing all or part of IVS)

Could you please explain your experience with IVS/PSAP design?

Have you ever had any issue with understanding the standards?

Could you please explain any existing thread concerning interoperability issues?

Have you ever experienced design issues, especially in relation to the need to limit

device costs?

Have you ever experienced issues related to OEMs requirements for device

integration?

For supplier providing retrofit devices

Did you have any experience related to the design of retrofit devices?

Do you think that requirements for retrofit devices are missing? If yes, which aspects

are missing?

What are the main challenges related to the installation of retrofit devices (i.e.

interconnection and interaction between various vehicle electronic devices and

control units)?

Vehicle OEMs

Could you please summarize your experience related to IVS design / integration? For

instance, have you ever experienced difficulties in fitting IVS in the vehicle design

plans?

Could you please list any existing issue related to legislation / regulatory aspects?


Do you believe that there are enough requirements for ensuring eCall performance

(i.e. requirements for radio communication)?

What are the main factors that do not allow a reduction in device development costs?

Could you please list any existing issue related to the coexistence with other

connected devices (i.e. other applications connected to mobile IP )?

Could you please explain any issue related to liability ?


28/10/2013 85 1.0

Have you ever experienced any issue related to compliancy and quality assessment?

What are the main issues related to competition with private eCall services?

How do you evaluate customer interest in eCall service?

PTW

Could you please explain the main technological challenges related to eCall system

in PTW (i.e. incident detection, definition of the triggering strategy, hardware location,

reliability of the system)?

Could you please summarize your experience related to PTW design / eCall

integration?



Could you please indicate the best position where the trigger system should be

located in PTW (i.e. portable by the pilot for instance in the helmet, onboard,

combination of systems, etc.) ?

Since the separation of the rider from the PTW after an incident is highly expected,

could you please list the main challenges related to eCall (i.e. no voice connection

with PSAP, manual activation/deactivation of the system, etc.)

Could you please list which are, in your opinion, the most important MSD for PTWs?

How do you evaluate customer interest in eCall service for PTW?

Dangerous and Heavy goods

Could you please explain the main technological challenges related to eCall system

in HGVs and dangerous goods vehicles?


Could you please list any existing issue related to standards?

Could you please list which are, in your opinion, the most important MSD for HGVs

and dangerous goods?

How do you evaluate customer interest in eCall service for HGV and dangerous

goods?

PSAP

Could you please explain if there are any eCall system procurement issues? For

instance, do you think that there is the need for call for tenders?

Have you ever experienced any issues concerning local regulations related to

installing eCall in PSAP?

Have you ever experienced any issues related to privacy?


28/10/2013 86 1.0

Do you think are there challenges related to get access to VIN national data bases?

Could you please explain if there are difficulties to fit with eCall regulations?

PSAP staff

Could you please list the main issues related to the acceptance of the eCall systems

and functions by the PSAP personnel?

Are there enough possibilities for PSAP personnel training?

Which are the main issues related to PSAP personnel training with reference to cross

boarder handling of eCall?

In order to improve data transmission, do you think that SMS should be added as

additional service?

MNOs

Could you please explain any existing operational issue related to the deployment of

eCall?

Since eCall is free of charge, are there any cost issues?

Could you please list any existing issue related to regulatory aspects?

Could you please explain any existing issue related to liability aspects?

Do you think that the regulatory of MNOs duties is fundamental for eCall deployment?

Could you please motivate your answer?

Do funding possibilities exist for MNOs?

Do you think that MNOs funding system could favour the eCall permanent

implementation?

Which are in your opinion the main issues related to IVS communication (i.e.

deterioration of voice quality during transmission, communication of MSD)?

In order to improve data transmission, do you think that SMS should be added as

additional service?

MS

Could you please describe the main technological challenges in your pilot and how do you

plan to tackle with them?


28/10/2013 87 1.0

ANNEX II: A Satellite Navigation Overview

This chapter provides a general overview about the navigation concepts mentioned in

Chapter 5.3, in order to simplify the understanding of the main arguments related to the

GNSS.

A.1 Radio Navigation Concept

The navigation concept is defined in several Radio Navigation Plans as “To drive in a safe

and secure mode a mobile from a starting point to its final destination”. The previous

statement underlines that navigation is by definition a “real-time” process, in the sense that it

is a process that takes place on a time scale comparable to the speed of a mobile user.

Navigation is then the determination of the position of such mobile that must be obtained and

maintained on a temporal scale consistent with the mobile speed.

Considering radio-navigation, such a position (and possibly speed) is obtained on the basis

of the observation of an electromagnetic signal, by estimating or measuring some

parameters of the signal itself. Such parameters can be for example, the propagation time

from the transmitter to the receiver, the phase of the received signal, or the Received Signal

Strength (RSS), i.e. the received power level. In many cases such parameters are converted

to estimated distances between the receiver and a reference point (i.e. the transmitter) the

position of which is known in a pre-defined reference frame. The position is obtained by the

intersection of geometrical loci, name Line of Positions. Such a procedure is given the name

of Trilateration.

The location detecting problem may be approached with several different positioning

methods, also called location techniques; they consist of an algorithm for the estimation of

geographical location. From a geometric point of view, the location solution is typically

provided by the intersection of a certain number of geometrical entities such as circles and

hyperbolas (in a two-dimensional scenario) or spheres, hyperboloids and cones (in a three-

dimensional scenario). They are defined by particular available measurements between the

terminal being located and some reference points placed at known sites. In literature, it is

possible to find out different possible reference systems:

Conical system: the user receives signals from sources placed at known

locations. The user position is obtained by the intersection of straight lines or

cones. The receiver measures the Angle of Arrival (AOA) of the incoming signals

from all the available transmitters.

Hyperbolic system: the receiver typically determines the Time-Difference-Of-

Arrival (TDOA). The TDOA is the difference in the propagation delay between two


28/10/2013 88 1.0

transmitters and a unique receiver. All transmitters need to be accurately

synchronized with the same time reference, whereas the receiver does not need

to be synchronous.

Spherical system: the receiver evaluates a parameter of the signal incoming

from the sources whose value is proportional to the absolute distance from a set

of transmitters placed at known locations. These kinds of systems are usually

based on the received signal strength, or a measurement of a Time of Arrival

(TOA).

A.2 Fundamentals of Satellites Navigation

A proper use of the signals broadcast by navigation satellite allows the users to estimate

instantaneously and in real time its Position, Velocity and Time (PVT) on the Earth surface

(or in flight). GPS utilizes the Time-of-Arrival (TOA) concept in order to determine the user

position: it consists of the measure of the time for a signal transmitted by a satellite at a

known location to reach a user receiver. This time is then multiplied by the speed of light to

obtain the distance between the receiver and the satellite. By measuring the propagation

time of signals broadcast from multiple satellites at known locations, it is possible to

determine the receiver position

Assuming that the receiver clock is perfectly synchronized with the satellite transmitter, the

distance R between the satellite and the user can be calculated measuring the transit time of

the signal. In fact, if the i-th satellite transmit a pulse at t0, and it is received at time t0+ the

distance between the transmitter (i-th satellite) and the receiver can be estimated as the

product of speed of light and the :

In the three-dimensional space, every Ri defines a spherical surface having centred the

position of the i-th satellite. Through the intersection of at least three of these spheres, it is

possible to compute one point that represents a precise user position (see Figure 7a). The

other point of intersection can easily be rejected due to fact that it is in the deep space.


28/10/2013 89 1.0

Figure 7: Effect of receiver clock offset on TOA measurements

In a real situation, the receiver clock is not synchronized with the transmitter. In fact while the

satellite payloads host synchronous satellites, it is not possible to have user clocks aligned

with the satellite time scale at low cost and complexity. Therefore, the measure of the

distance suffers of a bias as shown in Figure 7b by the term that is common for each

satellite. Such a bias represents the shift of the receiver time scale with respect to the GPS

time scale. The measurement performed by the receiver is then called pseudo range and it is

defined as the sum of the true distance Ri and a term due to the time scale misalignment.

It has to be remarked that in order to estimate its position a receiver must have at least four

satellites in view, and such satellites must be in Line-of-sight, or the relationship between the

propagation time and the geometric distance is lost. If a larger number of satellites are in

view a better estimation is possible. This aspect should be taken into account for the IVS

GNSS receiver in order to improve the quality of the positioning, as mentioned in Section

5.3.1.

A.3 Geometric and Measurements Errors

The definition of an error budget for GNSS can be found in literature. Each error source has

been duly investigated during the years and many papers and publications addressed

physical aspects, modelling, and mitigation of the effects. In the following sections the error

sources for GPS will be reviewed, since the studies related to this system are much more

consolidated, with respect to Galileo at the time of writing.

The accuracy of the computed position depends on the following factors:

Number of satellites in view and Geometrical Dilution of Precision;

Satellite clock error;

Ionospheric error;

Tropospheric error;

Local error sources (e.g. receiver noise, multipath, interferences).


28/10/2013 90 1.0

The quality of the position provided can be damaged also for the intervention of interferences

(unintentional or intentional). It is possible to classify two different classes of interferences:

Jamming: intentional or unintentional interferences may disrupt the signal to noise ratio of the

satellite signal, limiting the probability of providing localization functionalities;

Spoofing: Emulation of the satellites constellation signals used in order to counterfeit the

position computed by the receiver.

A.4 Main GNSS Systems Overview

This Section provides an overview about the most important GNSS systems, reporting

historical information and some technical details.

Generally speaking, a Global Navigation Satellites System is composed by three segments:

The space segment: it is made by the constellation of the satellites that transmit

a ranging signal;

The control segment: tracks each satellite and uploads to the space segment its

predictions of future satellite positions and clock corrections;

The user segment: the devices that exploit the navigation services.

A.4.1 GPS

GPS was set up by several U.S. government organizations for military purposes, with the

goal of realizing an “optimum” satellite navigation system with the following attributes:

global coverage;

continuous operability;

high accuracy.

Nowadays the GPS is fully operative both for military purpose or civilian aims; in fact it

provides two services:

Standard Positioning Service (SPS), for the civil community (free of direct user

fees);

Precise Positioning Service (PPS), for authorized military and selected

government agency users (U.S. and allied military).

The GPS constellation is composed by 31 healthy satellites positioned in 6 Earth-Cantered

orbital planes and it has been modified several times in order to obtain an optimal coverage

of the Earth surface.

Initially, it was composed by 24 satellites subdivided on three distinct orbits, inclined of 63

degree relatively to the equatorial plane; subsequently, the satellites number was reduced to

18 for economic reasons, and then increased to 21: 18 positioned in six orbit planes and 3


28/10/2013 91 1.0

used in case of out of service. Recently the number of active satellites has been increased

up to the current 31 satellites, in order to improve system capabilities and performances in

the GPS modernization framework.

The Operational Control Segment (OCS) is composed of all the terrestrial reference stations

that have the following tasks: to coordinate the activities between satellites, to monitor the

orbits, to synchronize the atomic clocks and to exchange information for the construction of

the navigation message. It is constituted by one main control station (in Colorado Springs),

five monitor stations and four ground control stations.

A.4.2 GLONASS

GLONASS is a space-based global navigation satellite system (GNSS) that provides reliable

positioning, navigation, and timing services to users on a continuous worldwide basis freely

available to all. GLONASS receivers compute their position in the GLONASS Reference

System using satellite technology and based on triangulation principles. GLONASS Space

Segment is composed of 24 satellites in three orbital planes whose ascending nodes are 120

deg apart. 18 satellites are required in order to cover the Ex USSR area.

GLONASS Ground Segment includes the System Control Centre and the network of the

Command and Tracking Stations that are located throughout the territory of Russia. The

control segment provides monitoring of GLONASS constellation status, correction to the

orbital parameters and navigation data uploading.

Finally, GLONASS User Segment consists in the user receivers which compute coordinates,

velocity and time from the GLONASS navigation signals.

Such system guarantees a high level of coverage at high latitude, where GPS encounters

some problems. Therefore, GLONASS allows to widespread the global service of positioning.

There are two different signals transmitted from GLONASS satellites:

Standard Precision (SP) for civilian use;

High Precision (HP) obfuscated, for military purposes;

Military Signal Access to India.

It has to be remarked that GLONASS constellation was set up in order to improve the service

coverage in the Russian area and consequently in the north Europe.

A.4.3 GALILEO

Galileo is the European navigation satellite system will try to improve the performances with

respect to the GPS, overcoming some of the present limitations of GPS. Galileo will be an

open, global system, fully compatible with GPS but independent from it. Interoperability

features with GPS, GLONASS (the Russian satellite navigation system) and other external


28/10/2013 92 1.0

systems is a primary requirement to enable the provision of services based on the combined

use of Galileo, GPS and GLONASS signals. This means that a user will be able to locate

himself with the same receiver from any of the satellites in any system. This aspect will be

taken into account in the definition of the navigation signals and in the selection of common

references.

Its baseline design is composed by a fully deployed constellation of 30 satellites (27

operational + 3 spares), positioned in three circular Medium Earth Orbit (MEO) planes at a

nominal average orbit semi-major axis of 29601.297 Km, in order to ensure the entire

coverage of the Earth’s surface.

Four navigation services and one service to support Search and Rescue operations have

been identified to cover the widest range of user’s needs, including professional users,

scientists, mass-market users, safety of life and public regulated domains. The following

Galileo satellite-only services will be provided worldwide and independently from other

systems by combining Galileo's Signals in Space:

The Open Service (OS) provides positioning, velocity and timing information that can be

accessed free of direct user charge. This service is suitable for mass-market applications.

The Open Service is accessible to any user equipped with a receiver, with no authorisation

required. While up to three separate signal frequencies are offered within the Open Service,

cheap single-frequency receivers will be used for applications requiring only reduced

accuracy. In general, Open Service applications will use a combination of Galileo and GPS

signals, which will improve performance in severe environments such as urban areas. The

Open Service could also be used by professionals who require high precision but not

integrity, complementing this service with GNSS Augmentation techniques. It has to be

remarked that the Open Service does not offer integrity information, and the determination of

the quality of the signals will be left entirely to the users. There will be no service guarantee

or liability from the Galileo Operating Company on the Open Service.

The Safety of Life Service (SoL) improves the open service performances providing timely

warnings to the user when it fails to meet certain margins of accuracy (integrity). It is

envisaged that a service guarantee will be provided for this service.

The Commercial Service (CS) is aimed at market applications requiring higher performance

than offered by the Open Service. It provides added value services on payment of a fee.

Galileo CS uses combination of two encrypted signals for higher data throughput rate and

higher accuracy authenticated data. The foreseen applications will be based on:

Dissemination of data with a rate of 500 bps, for added value services;


28/10/2013 93 1.0

Broadcasting of two signals separated in frequency from the Open Services signals in

differential applications to facilitate advanced applications such as integration of Galileo

positioning applications with wireless communications networks, high accuracy positioning

and indoor navigation.

These will be developed by service providers, which will buy the right to use the two

commercial signals from the Galileo operator. Developing commercial applications either by

using the commercial signals alone, or by combining them with other Galileo signals or

external communications systems, opens a wide range of possibilities. The worldwide

coverage brings a strong advantage for applications requiring global data broadcast.

Moreover, CS will offers the authentication signal “security critical” available for commercial

uses.

The Public Regulated Service (PRS) will be used by groups such as police, coast-guards

and customs. Civil institutions will control the access to the encrypted PRS. Access by region

or user group will follow the security policy rules applicable in Europe. The PRS is

operational at all times and in all circumstances, including during periods of crisis. A major

PRS driver is the robustness of its signal, which protects it against jamming and spoofing.

The PRS will provide a higher level of protection against the threats to Galileo Signals in

Space than is available for the Open Services (OS, CS and SoL) through the use of

appropriate interference mitigation technologies. The need for the Public Regulated Service

(PRS) results from the analysis of threats to the Galileo system and the identification of

infrastructure applications where disruption to the Signal in Space (SiS) by economic

terrorists, malcontents, subversives or hostile agencies could result in damaging reductions

in national security, law enforcement, safety or economic activity within a significant

geographic area.

The Search and Rescue Service (SAR) broadcast globally the alert messages received

from distress emitting beacons. It will contribute to enhance the performances of the

international COSPAS-SARSAT (Search and Rescue Satellite Aided Tracking) system based

on the detection of emergency beacons.

It is important to highlight that Galileo will constitute the first satellite positioning and

navigation system provided specifically for civil purposes. Galileo will offer an extremely wide

number of applications, which will interest transportation, aviation and maritime sectors. The

combination of navigation data with additional information makes possible to devise many

uses of the system across many activities (e.g. transportation, engineering, science,

environment), and in many sectors (e.g. oil and gas, banking, insurance,

telecommunications). From eCall standpoint, Galileo will offer interesting improvements in


28/10/2013 94 1.0

terms of accuracy and integrity. Furthermore, Galileo advanced services will provide

additional instruments to face jamming and spoofing actions.

At the time of writing, there are 4 Galileo positioning satellites in orbit:

Galileo-IOV PFM (Thijs);

Galileo-IOV FM2 (Natalia);

Galileo-IOV FM3 (David);

Galileo-IOV FM4 (Sif).

The Navigation Lab inside the ISMB computed one of the first Galileo positions using a

proprietary software receiver that is shown in Figure 8.

Figure 8: First GPS + Galileo position performed within ISMB

A.4.4 COMPASS

The Compass Navigation Satellite System (CNSS), also named BeiDou-2, is China’s

second-generation satellite navigation system that will be capable of providing positioning,

navigation, and timing services to users on a continuous worldwide basis.

Although the upgrade of its regional navigation system towards a global solution started in

1997, the formal approval by the Government of the development and deployment of

BeiDou-2/CNSS was done in 2004 and it is expected to provide global navigation services by

2020, similarly to the GPS, GLONASS or Galileo systems.

As of December 2011, the COMPASS system was officially announced to provide Initial

Operational Service providing initial passive positioning navigation and timing services for the

whole Asia-Pacific region with a constellation of 10 satellites (5 GEO satellites and 5 IGSO


28/10/2013 95 1.0

satellites). During 2012, 5 additional satellites (1 GEO satellites and 4 MEO satellites) were

launched increasing to 14 the number of satellites of the constellation. Until 2020, the system

is going to launch the remaining satellites and evolve towards global navigation capability.

A.4.5 Advantages of Multi Constellation with respect to GPS stand alone

Nowadays GPS system is the main timing and positioning system fully operative and

available. Most of Location Based Services (LBS) relies on GPS positioning service.

However, it has to be remarked the most important limitation:

Precision: poor and variable in accordance with user positions;

Reliability: in some areas situated to extreme values of latitude, the cover is

uncertain as well as the signal penetration into urban areas;

Military control and management: this involves the risk of civil services

interruptions without notice.

The precision and the reliability of the GPS can be slightly enhanced thanks to the adoption

of the navigation augmentation systems; the problem concerning the military control cannot

be solved.

Designed as a civil system, Galileo will offer high quality services oriented to several

typologies of final users, with particular attention in terms of reliability, precision and

availability. Moreover, Galileo will provide specific services with integrity message, in order to

inform in real-time the users of possible degradation of the signal. Furthermore, Galileo

signals and encryptions are more robust and permit to reduce the effect of jamming and

spoofing attempts, which can be identified as issue for eCall service provision.

The use of multi constellation GNSS receivers offers great advantages in terms of satellites’

availability, due to the increasing number of satellites for positioning. For this reason, the

multi constellation receiver with respect to single constellation receivers would improve:

Positioning availability: each GNSS system was conceived in order to mainly

concentrate the positioning service coverage over the interesting area (GPS for

North America, GLONASS for Russian Areas, Compass for China, Galileo for

Europe); however, the increasing number of satellites improves the probability of

positioning even in harsh environment;

Accuracy: The increasing of the satellites number for positioning enhances the

accuracy of the position computed by GNSS receiver.


28/10/2013 96 1.0

A.5 Augmentation System

Augmentation system provides additional data that can be used in order to enhance position

service. The main goals of the augmentation system are to improve the accuracy, trying to

reduce the effect of the error sources.

From general standpoint, an augmentation system relies on monitoring stations in well-

known and fixed positions equipped with professional GNSS receiver. Thanks to the

knowledge of the monitoring station position and the GNSS satellites position with high

accuracy, the monitoring station is able to compute a real distance between the receiver

antenna and the satellites. Such information can be analytically elaborated in order to

provide corrections (called differential) that can be broadcasted though a communication

channel and applied at user level according to a pre-defined mathematical model.

The problem concerning such corrections is their own validity:

Time validity: the corrections validity continuously decreases after a period of

time;

Space correlation: the corrections validity decrease with the increasing of the

distance between the monitoring stations and the user.

For this reason, there are two different strategies followed in order to provide augmentation

systems:

Local Area Differential GPS Systems: Lots of monitoring stations (real or

“virtual”) installed on the area with very high accuracy provided over a limited

geographic area;

Wide Area Differential GPS System: A sophisticated mathematical model and

the possibility to exploit wide broadcast channel (normally GPS satellites signal)

permits to provide a good level of accuracy over a continental area with limited

number of monitoring stations (and ground infrastructure).

A.6 Local Area Differential GPS

Figure 9 sketches the LADGPS concept with a single GNSS satellite. Thanks to the

knowledge of the reference station position and, with a certain level of approximation, also

the satellite position, it is possible to get the real distance from the satellites to the reference

station antenna. The difference between the estimated pseudo range (P) and the effective

range (R) is the pseudo range error.


28/10/2013 97 1.0

Figure 9: Local Area Differential GPS Concept reported for a single GNSS satellite

Thanks to the knowledge of the correct position of the reference station and the satellite

position, it is possible to compute the real distance between them. The distance between the

pseudo range estimated and the effective distance can be assumed as differential correction

to be transmitted to the GNSS receivers within limited geographic area.

LADGPS system provides such errors to the GNSS receivers that can use them in order to

compensate error above pseudo ranges estimation and consequently strongly reduce the

error in the computed position. The corrections are provided using RTCM format.

There are limitations on the LADGPS applicability.

Limited Geographic area: the validity of the corrections decreases with the

increasing of the distance between the reference station and the GNSS receiver.

It can be assumed that it is not possible to use them when the distance

overcomes 100 km;

Limited time interval: the validity of the corrections decays with the elapsing

time; therefore, it is necessary to continuously receive the corrections in order to

have the possibility to apply them.

Technical limitation: The GNSS receiver should be enabled to exploit RTCM

messages from an external source. Among the mass market GNSS receivers, it is

not common the integration of this feature.

For the reasons mentioned above, from eCall standpoint, the LADGPS services, despite the

high level of accuracy reachable with their corrections, can be adopted in very limited

number of cases, because of the poor LADGPS coverage on the European countries.


28/10/2013 98 1.0

A.6.1 Wide Area Differential GPS Systems

WADGPS corrections are based on a complex mathematical model that permits to split the

corrections for each error sources. The main idea is that of providing a good level of

accuracy (lower than LADGPS system) over continental areas with reduced infrastructure.

The corrections are broadcasted by geostationary satellites over the interested continental

land using the same frequencies of GNSS positioning systems. Such strategies permits to

overcome the intrinsic limitation within the LADGPS system, providing a good quality service

in terms of both accuracy and integrity; therefore its exploitation should be taken into account

within eCall framework.

The differential corrections are enveloped with Minimum Operational Performance Standard

(MOPS). From architectural standpoint, it is possible to divide the WADGPS systems in four

different segments:

the Ground Segment: it consists of GNSS (GLONASS, GPS, GEO) Ranging and

Integrity Monitoring Stations (RIMS), which are linked to a set of redundant control

and processing facilities called Mission Control Centre (MCC). Every satellite is

monitored by the MCC in order to determine the integrity parameters, pseudo

range differential corrections and Ionospheric delays. This piece of information

are sent to the Navigation Land Earth Station (NLES) through a message and

then up-linked with the GEO Ranging Signal to GEO satellites.

the Space Segment: it is composed of transponders on board of geostationary

(GEO) satellites;

the User Segment: it is represented by the WADGPS receiver category. Its goal

is to verify the SIS performances and a set of prototype user equipment for civil

aviation, land and maritime applications;

the Support Facilities: it includes the Development Verification Platform (DVP),

the Application Specific Qualification Facility (ASQF) and the Performance

Assessment and System Checkout Facility (PACF).

The mathematical model adopted by WADGPS is more complex with respect to that

exploited from LADGPS systems. Such models provide specific differential correction for

each kind of error source; the corrections are transmitted through a protocol called Minimum

Operational Performance Standard (MOPS). Figure below shows the WADGPS coverage

areas on the Earth currently available.


28/10/2013 99 1.0

Figure 10: WADGPS Systems coverage areas

In Europe the WADGPS system available is EGNOS. It was built by ESA, European

Commission and Euro control and represents the first European step towards the satellite

navigation. EGNOS ensures the augmentation service over the European countries thanks to

the SIS broadcasted by 3 geostationary satellites and via Internet thanks to EDAS service,

that constitute the main interface point for multimodal Service Providers supplying the

EGNOS products in real-time.

A.6.2 Protection Level

From general standpoint, Protection Level can be assumed as an upper bound for the error

that afflicts the positioning computation. Therefore it provides a sort of confidence interval

around GNSS position that include the real position with a probability closed to 100%. The

algorithm for the computation of the protection levels that contains also the requirements for

the SBASs implementation.

It is important to highlight that the PL estimation is possible thanks to the fact that the

WADGPS systems provide parametric corrections for satellites and also estimates for the

modelling of theirs variances. For that reason the PL calculation is effective only if the

receiver positioning engine uses exclusively the satellites for which EGNOS data are

available, for the effect of the uncorrected satellites on the error cannot be predicted.

All the variances derived from post processing of the raw data provided by WADGPS

messages. The procedure that allows computing all the variances lies out of the goals of this

documents and can be found in literature.


28/10/2013 100 1.0

The PL computation is dependent on the application sector. For transportation it has to take

into account precise requirements by respective authority. For aviation and maritime they are

respectively ICAO and IMO. In the case of the automotive application, currently there aren’t

constraints by any authority, therefore the computation of the weight applied in the PL

computation process can be done in order to satisfy different requirements. It has to be

remarked that the definition of specific requirements for PL tailored for automotive is

challenging due to the difficult to characterize correctly the huge number of potential

environment (urban canyon, highway and so on).

At the time of writing, there are not any authorities that regulate and standardize the PL for

automotive applications. In the last few years, it has been created an interest around this

argument. HeERO2 project should endorse this process, creating synergy with other reality

involved in this field of application. Such strategy will enhance the PL exploitation that can

represent an important added value for eCall service.

A.7 Navigation Assistance Services

Assisted GNSS techniques have been designed for two main purposes: to reduce the TTFF

and to increase the sensitivity of the receiver in harsh environments (e.g. indoor). The core

idea is to provide aiding to the terminal via a wireless network. Such aiding includes (but is

not limited to): precise ephemeris, reference position, reference time, Ionospheric corrections

and acquisition parameters (estimate of the Doppler shift). A positioning server at the

network level is in charge of generating the assistances, but also it can compute the user

position on the basis of the observables (sent by the user to the server) improving the

accuracy thanks to local differential corrections and or EGNOS/EDAS (wide area GNSS

augmentation system). The communication between the terminal and the positioning server

can be set up using two approaches:

Control-Plane in which the assistances are sent via pre-defined cellular network signal

structures, like GSM and WCDMA;

User-Plane in which the assistances are sent via a general TCP/IP data connection and so

not requiring any wireless standard specific messages.

Cellular system agnostic solutions for the user-plane A-GNSS approaches have been

developed and standardized by the Open Mobile Alliance. Note that user-plane approach

allows in principle to create a local assistance infrastructure using for example a wireless ad-

hoc/sensor network having a positioning server available at the network management level.

The most resent architecture for the interchange of GPS assistance data is the so called

Open Mobile Alliance – Secure User Plane Location (OMASUPL). This specifies the


28/10/2013 101 1.0

architecture for the localization service in mobile terminals defining the transport protocol for

the assistance localization information, in the User Plain (UP) and in the Control Plain (CP).

The architecture defined in specification v1.0 is based on the interactions between a client

terminal and a network server. As said, the communication is “over the user plane” using the

ULP protocol on a data bearer TCP/IP of GPRS or UMTS. The architecture does not require

HW or SW changes in the Base Transceiver Station (BTS) of the cellular network allowing a

low-cost deployment at the communication provider level.

It has to be remarked that the SUPL procedure can provide a position based on GSM cells,

by means of trilateration of the BTS signals information (only the MNO knows the correct

dislocation of the GSM network infrastructure, including the BTS positions). SUPL server

position can be used as a sort of comparison\backup\redundancy localization source, for

example when the GNSS receiver is not able to compute it.

A.8 Inertial Navigation System

Inertial Measurement Unit (IMU) is a self-contained unit constituted by a set of inertial

sensors, namely, gyroscopes and accelerometers, whose outputs give the inputs required for

the computation of the navigation solution. A gyroscope is a device for measuring or

maintaining orientation, traditionally based on the principle of conservation of angular

momentum. The other types of inertial sensors that form an IMU are the accelerometers,

which are devices based on Newton’s second law and capable to determine the three-

dimensional acceleration vector. Inertial navigation systems use their gyros and

accelerometers to compute current position and velocity from a given starting position.

However, any Inertial Sensor suffers from different kind of noises that can affect the accuracy

of the computed navigation solution. In fact, gyroscope errors will result in errors in the

attitude computation, whereas accelerometer errors will lead to errors in the integrated

velocity and position. Therefore the integration of INS with some other sensor is required.

One of the best known sensor-fusion is the one between INS and GPS. The benefit of such

integration is to compensate for the limit of each single sensor. For instance, although GPS

provides a deterministic solution for both position and velocity, it has its own shortcomings.

Among them are: low data rate (typically 1 Hz), susceptibility to jamming (even unintentional

interference), and lack of precision attitude information. GPS and inertial measurements are

complementary for two reasons. Their error characteristics are different and they are

measures of different quantities. GPS provides measures of position and velocity.

GPS position measurement accuracy is limited due to a combination of low signal strength,

the length of the pseudo-random code, which is about 300 m, and errors in the code tracking

loop. Multipath, the phenomenon whereby several delayed copies of the signal arrive at the


28/10/2013 102 1.0

antenna after being reflected from nearby surfaces, is a source of correlated noise,

especially for a moving vehicle. GPS position measurements also have constant or slowly

changing biases due to satellite ephemeris and clock errors.

In contrast, the accelerometers in an inertial navigation system measure specific force. They

have relatively low-noise characteristics when compared with GPS measurements.

The goal of INS/GPS integration, besides providing the redundancy of two systems, is to

take advantage of the synergy outlined as follows:

The conventional approach to aiding the receiver’s carrier and code tracking loops with

inertial sensor information allows the effective bandwidth of these loops to be reduced, even

in the presence of severe vehicle manoeuvres, thereby improving the ability of the receiver to

track signals in a noisy environment such as caused by a jammer.

The inertial system provides the only navigation information when the GPS signal is not

available.

Low-noise inertial sensors can have their bias errors calibrated during the mission by using

GPS measurements in an integrated navigation filter that combines inertial system and GPS

measurements to further improve the performance. The accuracy achieved by the combined

INS/GPS system should exceed the specified accuracy of GPS alone.

Having inertial instruments at the core of the navigation system allows any number of

satellites to play a role in the solution.

The data rate of the solution can be much higher with respect to the GPS stand-alone (1-

10Hz) and ranges from (10-100Hz) typically.

The most common techniques that are presented in the scientific literature to achieve an

integration between the GPS and INS systems are the following ones:

loosely-coupled,

tightly-coupled,

ultra tightly-coupled INS/GPS hybridization.

D6.1 eCall Deployment Barriers and Enablers: Preliminary ... · ECI Earth-Cantered-Inertial EDAS...

Documents

Transcript of D6.1 eCall Deployment Barriers and Enablers: Preliminary ... · ECI Earth-Cantered-Inertial EDAS...