D2.1 State of the art analysis, operational and functional ... · 31/10/2013 Grant agreement no.:...

31/10/2013

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

D2.1 State of the art analysis, operational and functional requirements

Version number: Version 1.1 Main author: Frank Brennecke Dissemination level: PU Lead contractor: ERTICO – ITS Europe Due date: 31st March 2013 Delivery date: 15th April 2013 Revision date 31st October 2013

D2.1 State of the art analysis, Operational and functional requirements

3 Version 1.1

Control sheet

Version history

Version Date Main author Summary of changes

0.1 17.01.2013 Frank Brennecke Draft of the structure

0.2 03.02.2013 Frank Brennecke Combining input

0.3 14.03.2013 Nora Brodersen Comments and Corrections in Language and Spelling

0.4 15.03.2013 Frank Brennecke Reformatting, Comments and adding Questionnaires

0.5 18.03.2013 Frank Brennecke Reformatting to new document standard, adding Management summary

0.6 26.03.2013 Frank Brennecke Adding Danish Input, adding reviews from MS

0.7 11.04.2013 Andy Rooke Review

1.0 15.04.2013 Ana Blanco Response to review

1.1 31.10.2013 Frank Brennecke Adjustments according to GSMA Comments

Name Date

Prepared Frank Brennecke 18.03.2013

Reviewed Andy Rooke 11.04.2013

Reviewed Andy Rooke 15.04.2013

Authorized Andy Rooke 15.04.2013 - 31.10.2013

Circulation

Recipient Date of submission

Project partners 15.04.2013

European Commission 15.04.2013 – 03.12.2013


4 Version 1.1


5 Version 1.1

TABLE OF CONTENTS

CONTROL SHEET ............................................................................................................................................... 3

FIGURES ......................................................................................................................................................... 11

TABLES ........................................................................................................................................................... 11

1 MANAGEMENT SUMMARY .................................................................................................................... 13

2 TERMS AND ABBREVIATIONS ................................................................................................................. 15

2.1 TERMS ................................................................................................................................................... 15

2.2 ABBREVIATIONS .................................................................................................................................... 17

3 INTRODUCTION ..................................................................................................................................... 20

3.1 PURPOSE OF DOCUMENT...................................................................................................................... 20

3.2 STRUCTURE OF DOCUMENT .................................................................................................................. 20

3.3 HEERO CONTRACTUAL REFERENCES ..................................................................................................... 20

EUROPEAN COMMISSION .............................................................................................................................. 21

COMMUNICATIONS NETWORKS, CONTENT AND TECHNOLOGY ..................................................................... 21

B-1049 BRUSSELS ........................................................................................................................................... 21

BELGIUM ........................................................................................................................................................ 21

BY ELECTRONIC MAIL: [email protected] .................................................................... 21

4 STATE OF THE ART ................................................................................................................................. 22

4.1 BASIC DESCRIPTION OF ECALL SERVICE ................................................................................................. 22

4.2 PUBLIC SAFETY ANSWERING POINT (PSAP) .......................................................................................... 22

4.2.1 BELGIUM ....................................................................................................................................... 22

NB: SAMU IS THE MOBILE EMERGENCY SERVICE FOR RESUSCITATION. .......................................................... 23

TYPE OF CALLER LOCATION INFORMATION: CELL ID ....................................................................................... 24

4.2.2 BULGARIA ...................................................................................................................................... 25

FIGURE 2: BULGARIA PSAP NETWORK ARCHITECTURE ................................................................................... 25

4.2.2.2 WORKFLOW AND EMERGENCY DATA EXCHANGE ........................................................................... 27

FIGURE 3: COORDINATORS - DISPATCHER’S WORKFLOW ............................................................................... 27

4.2.2.3 CALLER LOCALIZATION .................................................................................................................... 27

4.2.3 DENMARK ...................................................................................................................................... 27

PSAPS OPERATED BY THE NATIONAL POLICE .................................................................................................. 28

PSAP OPERATED BY THE COPENHAGEN FIRE BRIGADE ................................................................................... 28

COOPERATION ............................................................................................................................................... 28

4.2.4 LUXEMBOURG ............................................................................................................................... 29

FIGURE 4: LUXEMBOURG PSAP MODEL .......................................................................................................... 29


6 Version 1.1

4.2.5 SPAIN ............................................................................................................................................. 30

FIGURE 5: SPAIN PSAPS GEOGRAPHICAL AREAS ............................................................................................. 31

4.2.6 TURKEY .......................................................................................................................................... 32

FIGURE 6: NETWORK TOPOLOGY OF ANTALYA CALL CENTRE ......................................................................... 33

FIGURE 7: OPERATION PRINCIPLE OF ANTALYA CALL CENTRE ........................................................................ 33

FIGURE 8: LOCALIZATION OF MOBILE CALLERS IN 2G AND 3G MOBILE NETWORKS ....................................... 36

4.2.7 GREECE .......................................................................................................................................... 36

FIGURE 9: FLOWCHART OF PROCESSING EMERGENCY 112 CALLS ................................................................... 38

4.3 MOBILE NETWORK OPERATOR (MNO) ................................................................................................. 39

4.3.1 BELGIUM ....................................................................................................................................... 39

4.3.2 BULGARIA ...................................................................................................................................... 39

4.3.3 DENMARK ...................................................................................................................................... 40

4.3.4 LUXEMBOURG ............................................................................................................................... 40

4.3.5 SPAIN ............................................................................................................................................. 40

4.3.6 TURKEY .......................................................................................................................................... 41

4.3.7 GREECE .......................................................................................................................................... 41

4.4 IN-VEHICLE SYSTEM (IVS) ...................................................................................................................... 41

FIGURE 10: ECALL IVS DATA MODEM OVERVIEW ........................................................................................... 42

4.4.1 ICOM (BULGARIA) .......................................................................................................................... 43

FIGURE 11 ICOM ECALL UNIT .......................................................................................................................... 45

4.4.2 TUS (BULGARIA) ............................................................................................................................ 47

FIGURE 12 IVS OVERVIEW .............................................................................................................................. 48

4.4.3 CTAG IVS (SPAIN) ........................................................................................................................... 49

FIGURE 13: CTAG IVS OVERVIEW .................................................................................................................... 49

4.4.4 FICOSA’S TELEMATIC CONTROL UNIT (TCU) (SPAIN, LUXEMBOURG, DENMARK) ......................... 50

FIGURE 14: FICOSA’S TCU OVERVIEW ............................................................................................................. 52

4.4.5 GMV U-10A OBU (SPAIN AND DENMARK) .................................................................................... 53

FIGURE 15: GMV’S U-10A OBU OVERVIEW ..................................................................................................... 53

4.4.6 CIVITRONIC UBIQ ECALL (GREECE) ................................................................................................ 54

4.4.7 RENAULT SAS TELEMATICS CONTROL UNIT (TURKEY)................................................................... 55

4.4.8 MAGNETI MARELLI UNIT (TURKEY) ............................................................................................... 55

FIGURE 16: CONNECTION DIAGRAM OF THE UNIT.......................................................................................... 56

4.4.9 CIVITRONIC’S X700 PLATFORM (TURKEY) ..................................................................................... 56

FIGURE 17: CIVITRONIC IVS UNIT OVERVIEW ................................................................................................. 57

FIGURE 18: CIVITRONIC UNIT SYSTEM ARCHITECTURE ................................................................................... 58

4.4.10 FUJITSU TEN PLATFORM (DENMARK, LUXEMBOURG) .................................................................. 58


7 Version 1.1

FIGURE 19 FJ10 IVS ......................................................................................................................................... 59

EQUIPMENT SPECIFICS: .................................................................................................................................. 59

IVS DIMENSIONS ............................................................................................................................................ 59

SPECIFICATIONS ............................................................................................................................................. 59

4.5 ADDITIONAL SERVICES (ROAD OPERATORS, HIGH CONSEQUENCES DANGEROUS GOODS) ................ 60

4.5.1 DENMARK ...................................................................................................................................... 60

4.5.2 LUXEMBOURG ............................................................................................................................... 60

4.5.3 GREECE .......................................................................................................................................... 61

5 OPERATIONAL AND FUNCTIONAL REQUIREMENTS ................................................................................ 62

5.1 STANDARDS ........................................................................................................................................... 62

5.2 GENERAL OVERVIEW OF THE ECALL TRANSACTION FOR PAN-EUROPEAN ECALL ................................ 62

FIGURE 20: RELATIONSHIP OF ECALL TRANSACTION TO STANDARDS ............................................................. 63

5.2.1 DETAILED EXPLANATION OF THE ECALL TRANSACTION ................................................................ 64

STEP 7 – CLARIFICATION OF THE OVERALL EMERGENCY SITUATION AND LOCATION ..................................... 64

STEP 9 – CALL CLEAR-DOWN .......................................................................................................................... 64

5.2.2 OTHER TECHNICAL RECOMMENDATIONS ..................................................................................... 65

5.3 FUNCTIONAL REQUIREMENTS - IVS ...................................................................................................... 65

5.3.1 HIGH LEVEL FUNCTIONAL REQUIREMENTS ................................................................................... 66

5.3.2 PROCEDURES FOLLOWING POWER-UP OF THE IN-VEHICLE SYSTEM ............................................ 66

5.3.3 ACTIVATION ................................................................................................................................... 66

5.3.4 CALL SET-UP .................................................................................................................................. 67

5.3.5 MSD TRANSFER ............................................................................................................................. 68

FIGURE 21: DATA FLOW DESCRIPTION ........................................................................................................... 68

SEQUENCE OF STEPS: ...................................................................................................................................... 68

5.3.6 APPLICATION LAYER ACKNOWLEDGEMENT (AL- ACK) (CALLED “HL-ACK” IN TS 26.267) .............. 69

FIGURE 22: AL – ACK DIAGRAM ...................................................................................................................... 69

5.3.7 REQUEST "SEND MSD" (CALLED “START” IN TS 26.267) ................................................................ 69

FIGURE 23: SEND MSD DIAGRAM ................................................................................................................... 70

5.3.8 LIST OF TIMERS .............................................................................................................................. 70

5.3.9 HEERO2 INTEROPERABILITY CONDITIONS FOR IVS ....................................................................... 73


VIN DECODER ................................................................................................................................................. 73

MSD DATA ..................................................................................................................................................... 73

5.4 FUNCTIONAL REQUIREMENTS - MOBILE NETWORK OPERATOR (MNO) .............................................. 74

5.4.1 ECALL ESTABLISHMENT ................................................................................................................. 74

5.4.2 PRIORITISATION OF AN ECALL ....................................................................................................... 74


8 Version 1.1

5.4.3 ECALL 'FLAG' .................................................................................................................................. 74

5.4.4 ECALL ROUTING TO PSAP .............................................................................................................. 75

5.4.5 PROVISION OF POSITIONING INFORMATION ................................................................................ 75

5.4.6 HEERO2 INTEROPERABILITY CONDITIONS FOR MNO .................................................................... 76

5.5 FUNCTIONAL REQUIREMENTS - PSAP ................................................................................................... 76

5.5.1 GENERAL REQUIREMENTS ............................................................................................................. 76

5.5.2 MSD DISPLAY TO THE PSAP OPERATOR ........................................................................................ 76

5.5.3 PSAP OPERATOR USER INTERFACE ................................................................................................ 76

5.5.4 AUDIO LINK TO VEHICLE OCCUPANTS ........................................................................................... 77

5.5.5 ECALL CLEAR-DOWN ...................................................................................................................... 77

5.5.6 PSAP CALL BACK ............................................................................................................................ 77

5.5.7 REROUTING TO ANOTHER PSAP/EMERGENCY CONTROL CENTRE ................................................ 78

5.5.8 RECORDING OF EVENT DATA TO PSAP INFORMATION SYSTEM ................................................... 78

5.5.9 PROVISION OF INFORMATION TO TMC AND OTHER PUBLIC AUTHORITIES .................................. 78

5.5.10 REQUEST FOR AND RECEPTION OF SUPPLEMENTARY INFORMATION .......................................... 78

5.5.11 HEERO2 INTEROPERABILITY CONDITIONS FOR PSAP .................................................................... 79


5.6 HEERO2 OPERATIONAL REQUIREMENTS .............................................................................................. 79

5.6.1 ROUTING OF AN ECALL .................................................................................................................. 79

5.6.2 LOCATION AND DIRECTION ........................................................................................................... 79

5.6.3 MINIMUM SET OF DATA (MSD) ..................................................................................................... 80

5.6.4 ECALL TRIGGERING ........................................................................................................................ 80

5.6.5 ESTABLISH VOICE CHANNEL .......................................................................................................... 80

5.6.6 ECALL TERMINATION ..................................................................................................................... 80

5.6.7 PSAP CALL-BACK ............................................................................................................................ 80

5.6.8 PSAP CLEARDOWN ........................................................................................................................ 81

6 QUESTIONNAIRES .................................................................................................................................. 82

6.1 PUBLIC SAFETY ANSWERING POINT PSAP ............................................................................................. 82

6.1.1 EXAMPLE OF QUESTIONNAIRE ...................................................................................................... 82

YES – NO ........................................................................................................................................................ 83

YES – NO ........................................................................................................................................................ 84

YES – NO ........................................................................................................................................................ 84

YES – NO ........................................................................................................................................................ 85

6.1.2 BELGIUM PSAP REPORT ................................................................................................................. 87

6.1.3 BULGARIA PSAP REPORT ............................................................................................................... 89

6.1.4 DENMARK PSAP REPORT ............................................................................................................... 92


9 Version 1.1

6.1.5 LUXEMBOURG PSAP REPORT ........................................................................................................ 94

6.1.6 SPAIN PSAP REPORTS .................................................................................................................... 96

6.1.7 TURKEY PSAP REPORT ................................................................................................................. 114

6.1.8 GREECE PSAP REPORT ................................................................................................................. 117

6.2 MOBILE NETWORK OPERATORS MNO ................................................................................................ 118

6.2.1 EXAMPLE OF QUESTIONNAIRE .................................................................................................... 118

PART 1. GENERAL INFORMATION ON MOBILE NETWORK OPERATOR .......................................................... 118

PART 2. ANALYSIS OF EXISTING TELECOMMUNICATION INFRASTRUCTURE ................................................. 118

GENERAL INFORMATION ON MOBILE NETWORK ......................................................................................... 118

PART 3. IDENTIFICATION OF HARDWARE AND SOFTWARE NEEDS* ............................................................. 119

PLEASE ANSWER IF THE INFORMATION IS AVAILABLE .................................................................................. 119

PART 4. IDENTIFICATION OF REQUIRED MODIFICATION ON EXISTING INFRASTRUCTURE* .......................... 119

PART 5. IMPLEMENTATION PLAN ................................................................................................................. 120

PART 7. PREREQUISITES AND ASSUMPTIONS ............................................................................................... 120

6.2.2 BELGIUM MNO REPORT .............................................................................................................. 120

6.2.3 BULGARIA MNO REPORT ............................................................................................................. 122

6.2.4 DENMARK MNO REPORT ............................................................................................................. 125

6.2.5 LUXEMBOURG MNO REPORT ...................................................................................................... 125

6.2.6 SPAIN MNO REPORT .................................................................................................................... 125

6.2.7 TURKEY MNO REPORT ................................................................................................................. 130

6.2.8 GREECE MNO REPORT ................................................................................................................. 133

6.3 IN-VEHICLE SYSTEM (IVS) .................................................................................................................... 135

6.3.1 EXAMPLE OF QUESTIONNAIRE .................................................................................................... 135

PART 1 - GENERAL INFORMATION IN VEHICLE SYSTEM ................................................................................ 135

PART 2 - ANALYSIS OF EXISTING IVS ............................................................................................................. 136

PART 3 - IDENTIFICATION OF HW AND SW NEEDS ........................................................................................ 136

PART 4 - IDENTIFICATION OF REQUIRED MODIFICATION ON EXISTING IVS .................................................. 136

PART 5 - IMPLEMENTATION PLAN ................................................................................................................ 136

IDENTIFICATION OF IMPLEMENTATION STEPS FOR ENABLING THE HEERO2 IVS FUNCTIONALITY ................ 136

PART 6 - PREREQUISITES AND ASSUMPTIONS .............................................................................................. 136

6.3.2 BELGIUM IVS REPORT .................................................................................................................. 137

6.3.3 BULGARIA IVS REPORT ................................................................................................................ 138

6.3.4 DENMARK IVS REPORT ................................................................................................................ 143

6.3.5 LUXEMBOURG IVS REPORT ......................................................................................................... 150

6.3.6 SPAIN IVS REPORT ....................................................................................................................... 159

6.3.7 TURKEY IVS REPORT .................................................................................................................... 169


10 Version 1.1

6.3.8 GREECE IVS REPORT .................................................................................................................... 174


11 Version 1.1

Figures

FIGURE 1: COMPARISON OF FUTURE AND CURRENT ORGANISATION OF EMERGENCY CALL HANDLING IN

BELGIUM 23

FIGURE 2: BULGARIA PSAP NETWORK ARCHITECTURE 25

FIGURE 3: COORDINATORS - DISPATCHER’S WORKFLOW 27

FIGURE 4: LUXEMBOURG PSAP MODEL 29

FIGURE 5: SPAIN PSAPS GEOGRAPHICAL AREAS 31

FIGURE 6: NETWORK TOPOLOGY OF ANTALYA CALL CENTRE 33

FIGURE 7: OPERATION PRINCIPLE OF ANTALYA CALL CENTRE 33

FIGURE 8: LOCALIZATION OF MOBILE CALLERS IN 2G AND 3G MOBILE NETWORKS 36

FIGURE 9: FLOWCHART OF PROCESSING EMERGENCY 112 CALLS 38

FIGURE 10: ECALL IVS DATA MODEM OVERVIEW 42

FIGURE 11 ICOM ECALL UNIT 45

FIGURE 12 IVS OVERVIEW 48

FIGURE 13: CTAG IVS OVERVIEW 49

FIGURE 14: FICOSA’S TCU OVERVIEW 52

FIGURE 15: GMV’S U-10A OBU OVERVIEW 53

FIGURE 16: CONNECTION DIAGRAM OF THE UNIT 56

FIGURE 17: CIVITRONIC IVS UNIT OVERVIEW 57

FIGURE 18: CIVITRONIC UNIT SYSTEM ARCHITECTURE 58

FIGURE 19 FJ10 IVS 59

FIGURE 20: RELATIONSHIP OF ECALL TRANSACTION TO STANDARDS 63

FIGURE 21: DATA FLOW DESCRIPTION 68

FIGURE 22: AL – ACK DIAGRAM 69

FIGURE 23: SEND MSD DIAGRAM 70

FIGURE 24: ECALL FLAG 75

Tables

TABLE 1: TIMINGS 72

TABLE 2: PSAP – BELGIUM 89

TABLE 3: PSAP – BULGARIA 92

TABLE 4: PSAP – DENMARK 94

TABLE 5: PSAP – LUXEMBOURG 96

TABLE 6: PSAP – SPAIN INTERMEDIATE ECALL PSAP- DGT 98

TABLE 7: PSAP – SPAIN CAT 112 CATALUNYA 102


12 Version 1.1

TABLE 8: PSAP – SPAIN CASTILLA Y LEÓN 105

TABLE 9: PSAP – SPAIN COMUNITAT VALENCIANA 109

TABLE 10: PSAP – SPAIN GALICIA 111

TABLE 11: PSAP – SPAIN MADRID 114

TABLE 12: PSAP – TURKEY 116

TABLE 13: PSAP – GREECE 118

TABLE 14: MNO – BELGIUM 122

TABLE 15: MNO – BULGARIA 125

TABLE 16: MNO – DENMARK 125

TABLE 17: MNO – LUXEMBOURG 125

TABLE 18: MNO – SPAIN 130

TABLE 19: MNO – TURKEY 133

TABLE 20: MNO – GREECE 135

TABLE 21: IVS – BELGIUM NXP 138

TABLE 22: IVS – BULGARIA ICOM 142

TABLE 23: IVS – BULGARIA TECHNICAL UNIVERSITY OF SOFIA 143

TABLE 24: IVS – DENMARK FICOSA 147

TABLE 25: IVS – DENMARK FUJITSU TEN 150

TABLE 25: IVS – LUXEMBOURG NXP 152

TABLE 26: IVS – LUXEMBOURG FICOSA 156

TABLE 27: IVS – LUXEMBOURG FUJITSU TEN 159

TABLE 28: IVS – SPAIN FICOSA 164

TABLE 29: IVS – SPAIN GMV 167

TABLE 30: IVS – SPAIN CTAG 169

TABLE 31: IVS – TURKEY CIVITRONIC 172

TABLE 32: IVS – TURKEY TOFAS 174

TABLE 33: IVS – GREECE CIVITRONIC 179


13 Version 1.1

1 Management Summary

Road fatalities in the EU-27 have fallen by 43% between 2001 and 2010, when the European

Commission published its White Paper on European Transport Policy. The European Road

Safety Action Programme and the Intelligent Car Initiative have had a significant impact on

this positive development, and are expected to continue in the medium term to produce

further benefits towards the vision of zero road fatalities.

However, with around 1.15 million serious traffic collisions causing around 31 000 deaths

and more than 1.5 million injured in 2010 on European roads, for an estimated cost to the

society of about EUR 160 billion, further action is required.

The pan-European in-vehicle emergency call, ‘eCall’, is estimated to have the potential to

save up to 2 500 fatalities annually in EU-27 when fully deployed, to reduce the severity of

injuries, bring significant savings to society in healthcare and other costs and reduce human

suffering.

The HeERO2 project will prepare, carry-out and coordinate eCall pre-deployment pilots at

European level taking into account the published standards.

The overall project objective is to prepare for the deployment of the necessary infrastructure

in Europe with the aim of making the Pan-European in-vehicle emergency call service eCall

a reality.

The implementation of the in-vehicle emergency call service eCall at European level should

take into account two major conditions on which its successful operations will depend:

a) Interoperability and cross border continuity: the possibility for any vehicle from

any European country travelling across Europe to use the eCall service in case of a

serious collision should be a service key driver. The interoperability issue covers not

only the technical solution but also operational aspect.

b) Harmonisation: the eCall service can work effectively across Europe only if

developed in a harmonised way in the different countries, still respecting the different

national implementations. The use of 112/E112 represents the first steps of this

harmonised approach.

HeERO2 has issued an exhaustive state-of-the-art analysis in the area of 112 resp. E112

calls identifying all necessary system implementation steps with a focus on:

in-vehicle system equipment interface


14 Version 1.1

telecommunication infrastructure (specifically 112/E112 related parts)

PSAP infrastructure

This analysis issued the Hardware (HW) and Software (SW) set-ups required at the different

HeERO pilot sites and gathered the initial background information for the definition of steps

leading towards the eCall standards implementation. On this basis, the In Vehicle System,

112/E112 and PSAPs needed upgrades will be defined for HeERO member states.

As far as the PSAPs infrastructure is concerned, this analysis also helped understanding the

technology upgrades needed in the different participating Member States in order to

accommodate the eCall service within national/local specificities in terms of PSAPs and

Emergency Operations organisations.


15 Version 1.1

2 Terms and abbreviations

2.1 Terms

TERM DEFINITION

112 single European emergency call number supporting Teleservice 12 (ETSI

TS 122 003)

Call clear-down termination of call and freeing up of line (usually achieved by hanging up

the receiver or pressing ‘end call’ or similar on screen)

cellular network

wireless communications network consisting of multiple adjacent access

points (cells) with the capability of homogeneous transfer of a

communications session instance to an adjacent cell without significant

interruption to the session

E112 emergency communications service using the single European

emergency call number, 112, which is enhanced with location information

of the calling user TS12

eCall Emergency call generated either automatically via activation of in-vehicle

sensors or manually by the vehicle occupants; when activated it provides

notification and relevant location information to the most appropriate

Public Safety Answering Point, by means of mobile wireless

communications networks, carries a defined standardised minimum set of

data (MSD) notifying that there has been an incident that requires

response from the emergency services, and establishes an audio channel

between the occupants of the vehicle and the most appropriate Public

Safety Answering Point

eCall generator

occupant of a vehicle or equipment within a vehicle that has cause to

trigger an eCall transaction by automatic or manual means

eCall discriminator or

identifier

one of two information element bits (flags) included in the emergency call

set-up message that may be used by the mobile network to filter and

route automatically and manually initiated eCalls to a designated PSAP

eCall service

end-to-end emergency service to connect occupants of an affected

vehicle to the most appropriate PSAP via an audio link across a PLMN

together with the transfer of a minimum set of data to the PSAP


16 Version 1.1

eCall transaction

Establishment of a mobile wireless communications session across a

public wireless communications network and the transmission of a

minimum set of data from a vehicle to a public safety answering point and

the establishment of an audio channel between the vehicle and the PSAP

eCall trigger

Signal emanating from within the vehicle to the eCall in-vehicle equipment

which requests to start an eCall transaction

emergency control

centre

Unit which deals with emergency calls and which has the capacity to

consider professionally the need for response, and which has the

provision to mobilise the needed resources to deal with the emergency in

question

in-vehicle equipment

Equipment within the vehicle that provides or has access to in-vehicle

data required for the minimum set of data and any other data that is to be

sent as part of or complementary to the minimum set of data to effect the

eCall transaction via a public mobile wireless communications network

providing a link between the vehicle and a means of enacting the eCall

service via a public mobile wireless communications network

in-vehicle system in-vehicle equipment together with the means to trigger, manage and

effect the eCall transaction

Minimum Set of Data

Standardised data concept comprising data elements of relevant vehicle

generated data essential for the performance of the eCall service

[EN 15722:2011]

most appropriate

PSAP

PSAP defined beforehand by responsible authorities to cover emergency

calls from a certain area or for emergency calls of a certain type

network access device

(NAD)

device providing communications to a mobile wireless communications

network with homogeneous handover between network access points

Process The method of operation in any particular stage of development of the

material part, component or assembly involved.

Public Safety

Answering Point

(PSAP)

physical location working on behalf of the national authorities where

emergency calls are first received under the responsibility of a public

authority or a private organisation recognised by the national government

service provider

physical and functional component responsible for providing telematics

based services to its subscribers

Teleservice 12 emergency service supported by PLMNs


17 Version 1.1

vehicle manufacturer

entity which first assembles the vehicle and provides eCall equipment as

part of its specification and subsequently sells the vehicle directly or via

an agent

vehicle occupant(s) person(s) inside the vehicle

2.2 Abbreviations

TERM DEFINITION

3G Third generation mobile telecommunication system

3GPP Third generation partnership protocol

ACK Acknowledgement

AieC Automatic Initiated eCall

ASB Samaritan association

ARQ Automatic Repeat Request

AT Attention (part of modem instruction to dial as specified in ETSI TS

127 007)

BCD binary coded decimal

BER Basic encoding rules (ASN.1)

BS Bearer Services

BSC Base Station Controller

CAN Controller-Area Network

CIP Competitiveness and Innovation Framework Programme

CLI Calling Line Identity

CRC Cyclic Redundancy Check

DRK German red cross

DTMF Dual-tone multi-frequency (signalling)

EC European Commission

ECC Emergency Control Centres

ELS Emergency Rescue Centre Administration’s operating system

ETSI European Telecommunications Standards Institute


18 Version 1.1

FIFO First in first out

GIS Geographic Information System

GNSS Global Navigation Satellite System

GSCP General Secretariat of Civil Protection

GSM Global System for Mobile communications

GMS Integrated Emergency Room Processing System

GMV Grupo Mecánica del Vuelo Sistemas

GW Gateway

HGV Heavy Goods Vehicle

HLR Home Location Registry

HMI Human Machine Interface

HPLMN Home Public Land Mobile Network

IAM Immediate Alert Message

IMEI International Mobile Equipment Identity

IMSI International Mobile Subscriber Identity

IND Indication

IP Internet protocol

ISDN Integrated Services Digital Network

IRLS Integrated regional control centres

IVS In-Vehicle System

KRLS Cooperative Regional Control Centres

LAN Local Area Network

LTE Long Term Evolution (of 3G UMTS access network)

MieC Manually Initiated eCall

MLP Meridian Lossless Packing

MSC Mobile Switching Centre

MNO Mobile Network Operator

MSISDN Mobile Subscriber ISDN (integrated services digital network)


19 Version 1.1

MSD Minimum Set of Data (EN 15722)

NACK Negative Acknowledgement

NAD Network Access Device (e.g. a GSM or UMTS module)

NRN Network Routing Number

OBU On-board Unit

OTA Over the Air

PAN Personal Area Network

PER Packed encoding rules (ASN.1)

PEZ Police operation centre

PLMN Public Land Mobile Network

PSAP Public Safety Answering Point

REQ Request

RFID Radio Frequency Identification

RNC Radio Network Controller

RPM Rounds per Minute

SIM Subscriber Identity Module (GSM/3GPP)

SS7 Signalling System No. 7

SUT System Under Test

TPS Third Party Service

TS12 Teleservice 12 ETSI TS 122 003 (112)

TCTV Emergency calls centre

UML Unified Modelling Language (ISO 15901)

UMTS Universal Mobile Telecommunication System

USIM User Service Identity Module

VLR Visited Location Register

WGS World Geodetic System

WGS 84 World Geodetic System; issue 1984 (last revised 2004]


20 Version 1.1

3 Introduction

3.1 Purpose of Document

The purpose of this document is to build up the reference document for identification of the

functional and operational requirements, HW installation and SW implementation needs in

each HeERO2 project member state. This analytical task is focusing on all parts of the future

eCall service chain which means the readiness of the in-vehicle system equipment,

telecommunication infrastructure (specifically 112/E112 related parts) and PSAP

infrastructure.

3.2 Structure of Document

The first part of this document is describing the current situation of eCall implementation in

each member state. The second part of this document is focused on operational and

functional requirements, all in three areas: -

Mobile network operators,

Public safety answer points

In vehicle systems.

There are set basic standards and versions for all three areas and based on workshop

results there are clarifications for some technical features.

HeERO2 has recognised that this particular issue requires individual attention, and as a

result HeERO2 has now formed a group with a specific remit to look at these issues.

Chapter 6 contains questionnaires with a description of the current situation of PSAPs, IVS

and MNOs in each member state.

3.3 HeERO Contractual References

HeERO is a Pilot type A of the ICT Policy Support Programme (ICT PSP), Competitiveness

and Innovation Framework Programme (CIP). It stands for Harmonised eCall European Pilot.

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:


21 Version 1.1

Wolfgang Hoefs EUROPEAN COMMISSION DG CONNECT Office: BU 31 – 6/35 B - 1049 Brussels Tel: +32 296 2188 E-mail: [email protected]

One other Project Officer will follow the HeERO project: Dimitrios AXIOTIS [email protected]

Address to which all deliverables and reports have to be sent: Wolfgang Hoefs EUROPEAN COMMISSION DG CONNECT BU 31 – 6/35 B - 1049 Brussels Tel: +32 296 2188 By mail: [email protected]

Any communication or request concerning the grant agreement shall identify the grant

agreement number, the nature and details of the request or communication and be submitted

to the following addresses:

European Commission Communications Networks, Content and Technology B-1049 Brussels Belgium

By electronic mail: [email protected]

mailto:[email protected]




22 Version 1.1

4 State of the art

4.1 Basic description of eCall service

eCall is the pan-European emergency call service for vehicles intended to operate

seamlessly in Europe and supported by the EU Member States in order to reduce the

consequence of accidents and improve safety on the roads. This telecommunication service

is intended to be made available on new vehicles class M1 (Passenger carrying vehicles up

to 8 seats) and N1 (Goods vehicles with a gross vehicle weight not exceeding 3500kg),

independent of the brand, in any EU country and independent of the geographical location of

the equipped vehicle within the EU.

Once fully deployed, this interoperable eCall public service will become available to any

equipped vehicle travelling in Europe, without need of any additional device or service

agreement.

The eCall service can be activated manually or automatically when a serious incident occurs,

the on-board sensors trigger the start of an automatic eCall. Once triggered, the on-board

vehicular system (IVS) establishes an automatic emergency communication (E112) over a

mobile network with the Public Safety Answering Point (PSAP).1 The emergency

communication consists of a voice communication together with the transmission of the

incident data (Minimum Set of Data) to the PSAPs operator answering the emergency call.

4.2 Public Safety Answering Point (PSAP)

The following chapters describe the situation of PSAPs in each country. It is based on

information received by completed questionnaires from each member state. The

questionnaire responses can be found in Chapter 6.

4.2.1 Belgium

4.2.1.1 112-call Model

There are three geographical regions in Belgium:

the Flemish Region, subdivided into five provinces

the Walloon Region, subdivided into five provinces

1 PSAP: the physical place where eCall terminates and that first receive the emergency call. We assume that it is managed by a

Public Authority or by a private organization recognized by Government. The most appropriate PSAP is the one identified on a territorial base by right authorities to serve the emergency calls starting from a specific geographic area or to manage emergency calls of a certain type (e.g. eCall).


23 Version 1.1

the Brussels-Capital Region

112 calls are directed to the provinces call-centres, responsible for medical and fire

interventions (also dealing with the traditional 100-calls). Calls to 112 requiring police

assistance are transferred to the call-centres of the integrated police (the CIC or Centre for

Information and Communication, treating the traditional 101-calls in Belgium).

Province by province, these two types of call-centres are gathered and physically moved to

the same location. Three provinces have already made this step.

It is planned to further integrate the two call-centres in each province by introducing neutral

call takers who will answer all calls to 112, 100 and 101, thus putting an end to transferring

some calls from a call-centre of the integrated police to the call-centre responsible for

medical and fire interventions (or vice versa) within the same province.

Future organisation

Current organisation

Figure 1: Comparison of future and current organisation of emergency call handling in Belgium

NB: SAMU is the Mobile Emergency Service for Resuscitation.

4.2.1.2 Number of PSAPs

There are 21 call-centres altogether: 11 call-centres for police calls (101) and 10 for medical

and fire calls (100 and 112).

4.2.1.3 Technology

Province per province, these two types of call-centres are gathered and physically moved to

the same location. Medical and fire interventions will use the same technology as the call-

centres of the integrated police (the CAD-platforms of ASTRID). Three provinces have

already made this step.


24 Version 1.1

Calls to 112 are now being treated in the 100/112 call-centre. However, in the future, all calls

will be treated by call takers in one joint emergency call-centre per province, gathering

information for either police dispatchers or fire and medical dispatchers.

4.2.1.4 Data centres

Central applications are hosted in two central data centres. There are point to point data

connections from the two data centres to each PSAP. Traffic is encrypted. Most of the

servers used by the PSAPs are still hosted inside the PSAPs. It is possible to transfer events

and units to another PSAP.

There are several external connections (mostly XML) towards police, fire departments and

the medical disciplines.

4.2.1.5 Languages

There are three official languages in Belgium (Dutch, French and German). German is only

spoken in one PSAP. French and Dutch are usually spoken in all PSAPs (though not

guaranteed).

4.2.1.6 Monitoring

ASTRID monitors all the systems using HP “Openview”. Monitoring is done in its own 24x7

Network operation Centre.

4.2.1.7 Caller Location in support of emergency services

Method of providing mobile caller location and the time needed to provide it on

request (Pull): Mobile caller location is available for the PSAPs working with ASTRID CAD-

platforms. A circle, in which the caller is likely to be, appears automatically on the map of the

call handlers. This circle is based on the radius of the receiving mobile phone mast. In

densely populated areas, the information is quite accurate and allows location the caller

within several hundred meters. In rural areas, it may be within several kilometres. Information

is not provided upon specific request of the 112 call handler.

The system (LBS or Location Based Services) will automatically request and receive the

information from the mobile telephone operators.

Type of caller location information: Cell ID

4.2.1.8 eCall

In Belgium eCall is not supported at the moment. In HeERO2, Belgium will install an

infrastructure to handle both public and private eCalls. Public eCalls will be treated by an

external call centre where only valid eCalls will be transmitted to the PSAPs. The way of


25 Version 1.1

connecting the external call centre will technically be the same as for private eCall call

centres (EN-16102).

4.2.2 Bulgaria

The E112 system in Bulgaria is a centralized nationwide Emergency Services Network

consisting of 6 PSAPs. There are 2 main and 4 regional call taking points, which are mutually

interconnected and are operating in redundant configuration.

PSAPs structure is based on economic regions. According to Bulgarian legislation the

country is divided into six economic regions, and there is one PSAP per economic region.

Each centre is intended to serve the corresponding economic region. The system is 100%

homogeneous across the country though any centre can accept calls from any geographical

point of the country (including geographical areas outside the corresponding economic

regions). The incidents are always served by the same way and that is transparent for the

calling citizens. That functionality makes the 112 system very flexible in two cases. First if

there is no available call taker in one centre the calls are automatically redirected to free call

takers in another centre. Second if one of the call centres is not accessible due to failure,

then the calls to that centre are automatically redirected to the other ones.

Figure 2: Bulgaria PSAP network architecture


26 Version 1.1

All the PSAPs are equipped with the same technology and are able to receive 112-calls both

from mobile and fixed telecommunication operators in Bulgaria. Beside the 112 service, the

PSAP centres are able to handle all other legacy (but still operational) national emergency

numbers: 150, 160 and 166. The technical architecture is based on a centrally hosted

communication and information infrastructure, which is able to deliver high reliability and

flexibility. The technologies and systems used are complex and innovative, allowing fixed

and mobile telecommunications operator identification, caller localization and ability to

support the 112 service in different languages.

Redundant interconnections between all centres ensure that each 112-call is delivered on

time to an available call taker, regardless of the caller’s location. This way it is guaranteed

that citizens will always get timely assistance in case of emergency with key performance

indicators are: average answer time 3.5 sec., % of calls answered within 10 seconds =

99.3%, call set-up time 0.75 sec, call response 4, .2 sec).

The dispatchers within the emergency services (fire brigade, police and medical rescue) are

connected remotely to the E112 system. They use the same CAD (computer aided dispatch)

software client as the call takers in the PSAPs and they are part of the 112 PSAP information

and communications infrastructure.

PSAP call takers are capable of handling emergency calls in Bulgarian and EU official

languages: English, German, French, Spanish, Italian, Greek, Rumanian and Non EU

languages Turkish and Russian. Emergency calls from citizens speaking other languages

than Bulgarian are automatically (whenever possible, based on country codes) or manually

(by the call taker) re-routed to an available call taker who speaks the language required.

Bulgaria does not have a commercial eCall service in operation. For the HeERO2 pilot

implementation, a testing eCall platform will be established.

4.2.2.1 Data communication

There are secure and redundant network connectivity between PSAPs and ECCs

(Emergency Control Centres: fire brigade, police, medical services, mountain rescue brigade,

maritime administration, etc.). Within each ECC, one or several dedicated 112 dispatcher

workstations are located. These workstations are installed in ECCs in all of the 28 regional

centres of Bulgaria.

There is a defined uniform format of data communication messages established on a

national level.


27 Version 1.1

4.2.2.2 Workflow and emergency data exchange

Създаване на

събитие за пътен

инцидент

СПЕШНО ПОВИКВАНЕ

Телефон/SMS/факс /ел. поща

ДИ

СП

ЕЧЕ

РКО

ОРД

ИН

АТО

РО

ПЕ

РАТ

ОРПопълване на

формуляра на

събитията

Поемане на

събитие

Създаване

на случай

Пътен инцидент

Създаване на

събитие за

обработка

Събитие за пътен

инцидент

Поемане на

събитието за обработка

Обновяване на статуса

Завършване на събитието

Насочване на

ресурси

Назначаване на

отговорност

Наблюдение

на случаяЗатваряне

на случая

Маркиране

за

архивиране

Emergency callEvent

creation

Fill data in

the el. form

Case creationSend to

emergency

services

Acceptance of the case and first

responders management

Case

feedback

Case monitoring CO

OR

DIN

ATO

RDI

SPAT

CHER

OPER

ATOR

Incident

Incident

case

Direction of first

responders

Figure 3: Coordinators - dispatcher’s workflow

The data exchange between call takers, coordinators and dispatchers is unified and bi-

directional:

Call takers fill initial event data in the CAD system and update the event template

during the process of handling the emergency case;

Dispatchers within ECCs receive timely the new event, update the status of the event

and send feedback to the call takers.

For auditing and other purposed all voice calls are recorded and attached to the event.

These recordings can be played by the call takers even during handling the event.

4.2.2.3 Caller Localization

Caller location identification is based on mobile cell ID position and its segment of coverage

(for mobile calls), thus the location information is as precise as the size of the area covered

by the segment. Such information is then decoded and displayed on the CAD application by

an integrated GIS module.

4.2.3 Denmark

Denmark has three PSAP. The Danish Police operates two PSAP located in Aarhus and

Slagelse, while the Copenhagen Fire Brigade operates the PSAP in Copenhagen.


28 Version 1.1

All three PSAP use MX-ONE (IP-PBX) and Solidus eCare (call centre software) both from

Aastra. And all PSAPs can push data to ECCs, add relevant ECC to the emergency call and

handover the emergency call to the relevant ECC. But the scope of functionality, the

architecture and the telephone integration are not the same.

PSAPs operated by the National Police

The two PSAP operated by the National Police are identical and added with a test PSAP

centre for testing and education. The centres run as call centres, where the 112 call is

pushed to the longest waiting available operator. When cause for emergency call is

identified, the PSAP add the correct ECC to the call and push relevant data to the ECC, with

an EDIFACT like message standard called Alarmnet VC112.

PSAP operated by the Copenhagen Fire Brigade

The PSAP operated by the Copenhagen Fire Brigade have multiple functions. They are the

ECC for the Copenhagen Fire Brigade and a number of fire brigades from the municipalities

around Copenhagen. In addition, the Copenhagen Fire Brigade handles a number of other

calls than 112 emergencies. The Copenhagen Fire Brigade PSAP does not run as a call

centre. Instead the operators pick the calls from a list. When cause for emergency call is

identified, the PSAP add the correct ECC to the call and push relevant data to the ECC, with

a XML-like message standard called MayDayML.

Cooperation

The three PSAPs, the ECCs and the telephone network operators, are all connected to the

same MPLS-network. Among other things, the PSAP receive mobile caller’s cell id through

this MPLS-network.

If there is no available operator at the Copenhagen Fire Brigade, the 112 call is automatically

redirected to the PSAPs operated by the National Police.

eCall readiness

None of the PSAPs are today ready to receive E112, but all PSAPs and ECC are equipped

with GIS-functionality and have access to multiple registers that can help identify the caller’s

location. In addition, the PSAPs receive mobile caller’s cell id (based on LIP), which is

represented for the operator as a circle on the GIS client.


29 Version 1.1

4.2.4 Luxembourg

Luxembourg operates one 112 Centre (PSAP) located in the city of Luxembourg. The PSAP

is inside the building of the Rescue service agency (Administration des Services de Secours

– ASS). The PSAP coordinates the interventions of the following emergency services:

Ambulance / Rescue

Fire brigade

SAMU (Service d'Aide Médicale Urgente or Urgent Medical Aid Service)

Special Units

The 112 centre covers the national territory of Luxembourg.

The Luxembourg 112 system is closest to the “Civilian Call-taking & Dispatching” model. This

means that the 112 centre acts as a single point of entry and dispatches the calls to other

agencies like police if necessary. The 112 centre even provides support services to the

Luxembourg citizens like providing the address of the nearest doctor or pharmacy.

Figure 4: Luxembourg PSAP model

The technology integrates functionalities, including fixed telephone terminal identification

(number and address), mobile operator identification and cellular phone localization.

The PSAP solution also provides a simple data communication with police and the road

traffic management centre. The PSAP call centre notifies these operational centres about


30 Version 1.1

emergency situations. In case of highway accidents the location and the affected lane is

transmitted. The solution uses a proprietary protocol.

PSAP call takers are capable of handling emergency calls not only in Luxembourgian but

also in French, German and English. Some call takers also speak Portuguese and Dutch.

The 112 centre is equipped with a geographic information system that contains data from the

whole territory of Luxembourg, which includes detailed data on the motorway and road

network (stops, bridges, exits, objects).

In Luxembourg no commercial eCall service is in operation.


PSAP can send information about events to

police

road traffic management centre (CITA)

Communication with these centres is carried out via a proprietary protocol.

The transferred messages contain information about the event (for highway accidents:

location, direction).

4.2.4.2 Caller Localisation

For landline callers the phone number is provided. The operator retrieves the information to

which address, name and location the phone number belongs. For mobile callers the phone

number, name (if available) and the cell ID of the base station used for the call is provided.

From the cell ID the operator can retrieve the location of the base station.

4.2.5 Spain

Spain operates 19 PSAPs’ that receive 112 calls from both mobile and fixed telephone lines.

Most PSAPs utilize the Telefónica “Séneca” platform to handle emergency events, with not

all PSAPs across Spain using the same version of this platform. Some PSAPs even have a

proprietary system for handling emergency events. If required, PSAPs can communicate and

exchange information with each other through a manual telephone call (no automatic

exchange of information between the respective PSAP’s systems / software applications).

Only TPS eCall is operated in Spain at the moment, mainly provided by insurance

companies.


31 Version 1.1

Figure 5: Spain PSAPs geographical areas

General Directorate of Traffic (DGT) will host an intermediate PSAP in its Traffic

Management Centre placed in Madrid, which will filter eCalls (in order to discard false

alarms) and forward them to the most appropriate 112 PSAP. 19 PSAPs depending on the

regional governments of the Autonomous Communities and Autonomous Cities which are

currently responsible for the handling of the 112 emergency calls, will receive the eCall

information from the intermediate PSAP (MSD will be decoded in the intermediate PSAP

only, and the relevant information will be forwarded to the appropriate PSAP, together with

the voice call).

DGT currently manages the traffic information and roadside assistance telephone number

‘011’. It also is responsible for implementing the basic technical standards in terms of traffic

and road safety, is competent in the regulation, management and traffic control on interurban

roads and urban crossings, and also in the development and maintenance of the Register of

Traffic Accident Victims. The traffic police are in charge of the surveillance, regulation and

control of traffic, road safety and roadside assistance. The DGT is the owner of the vehicle

database.

Most of the Emergency Control Centres (ECC) of fire brigades, the police and emergency

medical services are equipped with software applications for processing emergency events,

but not all of them use the same system. PSAPs are equipped with a GIS system, which

contains data at regional level only (GIS to be installed at the intermediate PSAP will be the

only one with data from the whole territory). Most PSAPs utilize the ArcGIS software by

ESRI, with cartographic information in the Shapefile SHP format. Some PSAP works with the


32 Version 1.1

GeoMedia software by Intergraph, with the cartographic information in SmartStore format.

Most ECCs use a GIS system of the previous providers, with information at regional level

only.


In general, PSAPs have data connections with the different ECCs in their region, and

communication is, in most cases, under a two-way scheme (PSAP ECC). From a

technical perspective, interfaces are built on different technologies, such as custom web

services (with XML-based messages) or Oracle Service BUS technology (communication

protocol based on the EDXL – ESAP standard of Oasis). In all cases, messages are

encoded, and security and privacy mechanisms are implemented.

4.2.5.2 Caller localization

PSAPs automatically receive Push information on the position of the caller whenever a 112

call is involved, meaning that the Mobile Network Operator provides the geographical

coordinates (X, Y) of the antenna that handles the call, and an area that delimits the actual

position of the caller.

In some cases, location of the caller can be obtained under a Pull scheme, as well. With

telephone calls received from the landline, location is obtained through ANI/ALI tables from

the CMT (Comisión del Mercado de las Telecomunicaciones).

Location information is obtained during the first 15 seconds from the reception of the call,

with some PSAPs receiving this information in 1.5 seconds, in average.

The accuracy of the localisation within the mobile phone network is, in urban areas, between

100 m and 300 m; in rural areas, it is from 500 m to 10 km. For calls originated from mobile

networks, the POSIC112 v2 protocol is used, that is utilized to send, from the MNO to the

PSAPs, information on the position of the mobile terminal that is making the 112 call. It is

applied to all calls, including those of international or national roaming services.

4.2.6 Turkey

Except for the provinces Antalya and Isparta, all the emergency centres in Turkey have their

own call centres. In this respect, there is no integration among the emergency associations.

In Antalya, where eCall test system will be established, all the emergency call centres give

service in the same location. All the associations use a common call centre infrastructure.


33 Version 1.1

Figure 6: Network topology of Antalya call centre

Figure 7: Operation principle of Antalya call centre

The main actors in the Antalya call centre and their corresponding duties are as follows:

1. Call taker: Group of operators that initially receive the calls from the users. 90% of the

emergency calls that take place in Antalya are classified as useless calls. Call takers

differentiate the real calls from the fake calls and forward the real calls to the related

associations. If needed, the call taker can receive personnel support from related


34 Version 1.1

associations. In this case, the system sets up a conference call among the calling

user, the call taker and the association’s expert personnel.

Call takers can monitor ongoing (active) events and can provide the latest information

about each event, to recurring callers about the same event.

The call taker can both forward the voice call to the Dispatcher and publish the call in

the system as an event. The call taker can select the associations that will be

involved in the event by marking the related associations when publishing the event.

When all call takers are occupied, the user can be forwarded to a voice robot (IVR)

where he can leave a message or can be queued in the emergency call queue. Since

Antalya is a tourist destination, the operators who can also speak German, Russian

and English.

2. Call dispatcher

Related organisations that provide emergency services.

For health, emergency health technicians and doctors; for police, police officers and

policemen; for fire brigade, officers and firemen; for military police, soldiers from

several ranks are serving as Dispatchers. Their main job is to dispatch events which

are forwarded by the call takers to the mobile units and agency terminals. They also

monitor the jobs that are being carried out by the agency terminals and mobile units.

When all the operations related to an event are completed, the event is finalized

(terminated) by the dispatchers. Call takers and Dispatchers are working on the same

LAN.

3. Agency terminal user

They work on events that are assigned to them by the Dispatchers and can assign

duties to the mobile units. They are able to insert and edit information about the

events.

Agency computers are connected to the PSAPs via secure DSL connections.

4. Mobile Units

They execute the operations that are assigned to them by the Dispatchers and the

Agency Terminals.

They can establish voice and data connection to the PSAP over the radio network.


35 Version 1.1

4.2.6.1 Software in the Antalya call centre and its Properties

The definition and establishment of the Antalya PSAP is carried out by Aselsan. The operator

software in the call centre and the related infrastructure services are also provided by

Aselsan in accordance to the needs and the requirements of the Ministry of the Interior.

1. Call taker software: All the voice and data communication of the call taker is provided

by the Aselsan software. It contains modules for connecting to telephone and radio

networks as well as entering event information. It also is possible to generate voice

recordings with this software.

2. Dispatcher software: All the voice and data communication of the Dispatcher is

provided by the Aselsan software. It contains modules for connecting to telephone

and radio networks as well as entering event information. It is possible to generate

voice recordings with this software. This software is also used for communicating with

the mobile units and the agency terminals.

3. Agency terminal software: It manages the events that are assigned to Agency

Terminals by the dispatchers. Both voice and data communication is provided over

this software.

4. Mobile unit software: It manages events that are forwarded to it by the dispatchers

and the agency terminals. It is possible to make data communication with PSAP and

Agency Terminals by the software.

5. Automatic Vehicle Location / Tracking (AVL) Software: It can be accessed by the call

taker, forwarder and the agency terminal user. The operators can monitor the

vehicles over the digital maps. The location of the user that made the emergency call

is also monitored on this application.

6. System Management Software: All the definitions and authorizations in the system

are carried on this software.

4.2.6.2 Caller Localization of Mobile Callers (2G and 3G mobile networks)

GSM operators provide information about: Latitude, longitude, inner Radius, outer Radius,

start angle, stop angle. In the sample drawing below, the coordinates of point O are the

latitude and the longitude of the MNO’s base station location. [OA] = inner Radius, [OB] =

outer Radius, COB angle: start angle, COD angle: stop angle. These parameters tell that the

exact position of the caller is in the shaded region.


36 Version 1.1

Figure 8: Localization of Mobile Callers In 2g And 3g Mobile Networks

4.2.6.3 Caller Localization of Fixed Network Callers

Just like the mobile case, pull method is used. If the calling user’s location data is available in

the database, this data is used. If not, text based address information is used instead.

4.2.6.4 Special Phonebook

Special phonebooks are created which contain users with disabilities and users that need

special emergency services. When a user who is in these phonebooks calls the 112 PSAP,

the call takers are warned by a message and provided detailed information about the caller.

The Republic of Turkey does not have a commercial eCall service in operation.

4.2.7 Greece

In Greece there is only one PSAP for 112 voice calls that uses 20 terminal stations, which

are manned depending on the workload of calls. The terminal stations are computers directly

connected to the telephone network. The computers include headsets for the call operators

and special keyboards that facilitate and accelerate the use of the call management

application. The Hellenic Telecommunication Organization SA (OTE SA) is responsible for

the technical support of the hardware and the software of the call centre. In addition there is

a central terminal that supervises the operation of the computers and the total workload of

the call centre.

The management application of the call centre is connected to a geographic database that is

maintained by a contractor company. This database allows the routing of calls to the suitable


37 Version 1.1

service/agency, depending on their origin. The information system that currently supports

the PSAP is called ADMOSS (Advanced Multifunctional Operator Service System) and is

provided by SIEMENS.


The ADMOSS is a high specification and flexible platform to support manned call centres,

used in centres for road help, centres of information and communication and centres for

coordination of organisations. It also supports connectivity with alternative means and

operations like SMS dispatching.

Beyond the basic telephone centre services, ADMOSS offers additional functionality, with

which the possibilities of a telephone centre can be adapted for additional use, as:

Direct diversion of calls to any number

Possibility of videoconference

Notices via SMS

ADMOSS is supported by the EWSD network infrastructure (Electronic Worldwide Switch

Digital), which allows high level functionality. It supports 10.000 terminal stations, from which

4.000 can be simultaneously active - all on one switch EWSD.

ADMOSS has the possibility of distributing call operators in the all breadth of network. With

the use of Voice over IP, call operators could be stationed at any point in the world.

The EWSD system operates on a modular architecture, which allows the redevelopment of

the network at any moment, depending on the PSAP needs. With the use of multiple

processors, the possibility for management of calls is practically unlimited, allowing

simultaneously the import of new services whenever it is required.

Moreover, ADMOSS, exploits the ACD (Automatic Call Distribution) function, incorporated in

the EWSD system that can apply “intelligent” distribution of calls. It monitors on a continuous

basis the situation of call operators and categorizes the incoming calls. Using routing

mechanisms, it limits the average waiting time while simultaneously transmitting informative

statements depending on the type of call pending.

In combination with the HiPath ProCenter, it can carry out routing depending on the type of

incoming calls. Using the characteristics of incoming calls, the system can dynamically select

the suitable subgroup of terminals or even specific terminal to service them.

4.2.7.2 Caller Localization

This can be done either on the basis of call location or after the caller makes specific choices

answering in questions of system via his telephone appliance (System Interactive Voice


38 Version 1.1

Response - IVR). ADMOSS supports both the internal IVR functionality of EWSD and hiR

Resource Server for statements and interactive dialogues.

With the IVR technology it is possible to service all different types of calls from a single

number - which is also easier to be remembered by the users of service. Third party

telephone centre connectivity is also supported, via CTI models (Computer Telephony

Integration).

Finally, ADMOSS supports a variety of system controls, like wall screens for operational

centres and statistical functionality that allows a level of control for the offered service.

Currently, all emergency 112 calls are dispatched to the appropriate Emergency Control

Centres (i.e. police, ambulance, and fire brigade) after executing a series of processes

described in the flowchart shown below.

Figure 9: Flowchart of processing emergency 112 calls


39 Version 1.1

4.3 Mobile Network Operator (MNO)

Mobile network operators (MNO) have basically the task to handle eCalls as any other

112/E112 emergency call, including the caller line identification and caller location

information if provided and giving eCall the same priority and reliability as any other

emergency call through their core network. Their new role is now supporting the “eCall flag” -

signalling parameter inserted by the IVS when establishing the call. This eCall Service

Category Identifier is specified in 3GPP TS24.008 and will be used by MSCs of at least one

Mobile Network Operator Responsibility for processing eCall and routing it to the right PSAP

as mandated by the national authorities always lies with the network serving the vehicle at

the time of activation.

The following passage describes the situation for MNOs in each country. It is based

especially on information received in completed questionnaires. Responses from

questionnaires can be found in Annex 1.

The overall situation in all countries shows that currently no MNO has integrated any eCall

related structures, but they all operate distribution tables to locate the responsible PSAP

when an emergency call is executed by a mobile phone.

4.3.1 Belgium

For the Belgian site, the MNO will be Mobistar, part of the Orange Group. The eCall flag will

be implemented and an in-band modem will be supported by the mobile network operator

Right now Mobistar foresees the full support of the eCall flag in a software release which is

assumed to be available in Q1 2014.

In the meantime a release including the eCall support will only be installed on a test platform

based on an extra implementation and validation service provided by its suppliers.

This, at present, limits the pilot to a demo in lab environment during 2013 together with the

involved consortium members (IVS supplier and PSAP).

The implementation of an intermediate release that would allow a real eCall pilot in the

Brussels region during 2013 is under investigation.

4.3.2 Bulgaria

Currently Mobiltel implements reception and handling of 112 calls in all its network coverage

in Bulgaria, according to rules and regulations applicable to all MNOs in the country.

Emergency voice calls to 112 are routed to the PSAP (there are 2 such – main and


40 Version 1.1

redundant) via E1 connectivity (a pair of such lines exists for each of the 2 PSAP) with

information about calling number, cell ID, telecom operator code, etc.

Existing MSC hardware is compatible, but currently in its software eCall standard

requirements and functionality are not implemented. The major technical activity for the

national pilot tests is the respective upgrade that would bring the MSC up-to-date for eCall

full-featured implementation from MNO point-of-view.

4.3.3 Denmark

Denmark does not have a MNO directly involved in the national project, but there are

discussions with all four MNO’s in Denmark regarding the implementation of the eCall flag in

the networks.

4.3.4 Luxembourg

The main mobile network operator of Luxembourg the Entreprise des Postes et

Télécommunications (EPT) is project partner in the HeERO2 project. EPT provides a

GSM/UMTS mobile network with 95% coverage of Luxembourg. 112 calls are routed by the

network automatically to the 112 centre. EPT plans to implement the eCall Flag in 2014.

4.3.5 Spain

Although in Spain there are several MNOs operating, Telefónica is the Spanish MNO directly involved in the HeERO2 pilot. 2G and 3G mobile network generation will be utilized in the pilot. Moreover, only the MSCs operating on the geographical area involved in the pilot (Galicia, Castilla y León, Madrid and Comunidad Valenciana) will be used. These areas represent about 30 % of the total Spanish territory and about 36 % of total Spanish population. Telefónica network actually supports the 112 emergency calls (both from national and international roamers) and the routing of 112 emergency calls from the caller to the geographical PSAP that must respond to the call (detailed information on the PSAPs can be found in section 4.2.5 above). Currently, there is no support for eCall in the network. Telefónica does not have a formal test network, but uses a test laboratory where every new hardware or software version, adaptation, etc. is proved before its deployment in the live network. Telefónica labs support the live network hardware and software specifications. The actual hardware and software network infrastructure could support the managing and routing of emergency eCalls, but it will need some modifications to work properly. Unfortunately, these modifications cannot be carried out within the actual project and, therefore, eCall pilot cannot use the 112 number to test the behaviour of the entire solution. So a common number will be used by IVS to send an eCall and this eCall will be routed directly to the intermediate PSAP, where MSD demodulation and eCall management will be carried out. Whilst the pilot site recognizes that this is far from ideal, it was felt necessary to follow this path that the


41 Version 1.1

architecture that has been defined for Spain is of considerable interest to other member states with similar 112/eCall architecture.

4.3.6 Turkey

In Turkey, Turkcell is the MNO involved in the HeERO2 pilot project. It will distinguish eCalls

by the use of the eCall flag and route the eCalls to the PSAP via Turk Telekom. Other

emergency calls will be routed as before. In addition a test MSC-Server and Media Gateway

will be used for eCall tests.

Although existing Hardware is capable of handling eCalls, currently test MSC-S’s Software is

not supported to distinguish such kind of eCalls. In order to support eCalls new market patch

will be applied onto the switch. After SW upgrade eCalls can be routed according to the eCall

flag.

4.3.7 Greece

In Greece there is only one PSAP for 112-calls, operated by the General Secretariat of Civil

Protection (GSCP).

The ‘112’ PSAP operator manually dispatches the emergency calls to the fire brigade, police

etc. according to the specific requirements of each case.

Greece does not have an MNO directly involved in the national consortium. Additionally,

there is no MNO that officially supports the eCall flag functionality. There are discussions

with all MNOs, requesting the implementation of the eCall flag before the pilot tests start and

their official response is expected. One of the MNOs has declared the availability of

prototype software that supports the eCall flag and their willingness to make it available for

the pilot tests.

4.4 In-Vehicle System (IVS)

Contrary to the previous chapters, In-Vehicle systems (IVS) are an integrated part of the pan-

European eCall. There are a few TPS IVS available; there is a special section for these

systems at the end of this chapter.

The main components of the IVS data modem are illustrated in the next figure. The MSD

information input into the IVS transmitter is first appended with CRC information. These bits

are then encoded in the hybrid ARQ (HARQ) encoder using FEC coding to reduce the

susceptibility to transmission errors. The HARQ encoder employs a powerful state-of-the-art

turbo encoding scheme with incremental redundancy added for each retransmission. The

signal modulator converts the encoded data into waveform symbols which are especially


42 Version 1.1

suitable for transmission through speech codec employed in present mobile systems,

including the GSM Full-Rate and the various modes of AMR codec.

The IVS receiver continues to monitor the feedback messages from the PSAP data modem.

As long as the received feedback messages are NACK messages, retransmissions of the

MSD with incremental redundancy are automatically continued until an ACK message set

(containing a link-layer ACK message and a compressed higher-layer ACK message from

the application layer) is received by the IVS, or operation is terminated by the PSAP. After

the transmission of the MSD information and the higher-layer ACK message is completed,

the eCall modem transmitters in both the IVS and PSAP return to idle state and the signal

paths from the transmitters are switched off to avoid interference with the normal voice call.

In push mode, the IVS reuses the downlink message format for requesting the PSAP to pull

the MSD. Request messages are transmitted until the IVS receiver detects START

messages from the PSAP or a timeout occurs. Upon detection of the START messages the

IVS continues as if it was in pull mode.

Figure 10: eCall IVS data modem overview

The following sections describe the situation about IVS in each country. The information is

based on the questionnaires received. Responses to questionnaires can be found in Annex

2.

Unlike the previous chapters, the structure of this chapter follows the idea that IVS systems

are not country-related. In fact, OVS 1st tier suppliers operate all over Europe and we will find

the same components within many IVS systems within the project. If there are national

exceptions to this rule, they will be emphasized in the appropriate context.

CRCH-ARQ

EncodereCall MSD

Signal

Modulator

Speech

Encoder

ACK/NACK

feedback

from PSAP

Signal

Demodulator

Speech

Decoder

FEC

Decoder

Speech in

Speech out

IVS Data Modem


43 Version 1.1

The different IVS systems are described system by system, not country by country. This

follows the experience that 1st tier suppliers sell their systems to different car vendors in

different member states. Thus a differentiation by country is not necessary. However, the

different descriptions contain information about the countries in which the IVS are used

during HeERO2.

An overview of more existing and available IVS systems can be found in the D2.1 Final

Document of the HeERO1 project.

4.4.1 Icom (Bulgaria)

Icom’s own emergency and crash alerting service is operational throughout Bulgaria since

February 2012. The system called “EuroGPS CrashAlert” is based on Icom’s on-board units

EuroGPS SmartTracker ALM-3A, equipped with crash sensors, gyro- and accelerometers-

based inertial system, speaker, microphone, and an emergency button for manual

emergency call initiation. The service is available as a managed value-added service to all

users of Icom’s fleet management systems (about 20,000 units installed in Bulgaria) for

passenger cars and LCV’s and is operated by our own proprietary Control Centre via instant

alerting with vehicle and crash-related data and automatic or manual initiation of regular

cellular voice calls with the control centre personnel.

The IVS to be used in HeERO2 is an adjusted version of our main fleet management module

EuroGPS SmartTracker ALM-3A, with modifications to comply with the eCall requirements.

EuroGPS SmartTracker ALM-3A, which is the basis for the eCall ISV unit, supports several

GPS chip models from different manufacturers with 50 to 65 satellite channels and both GPS

and GLONASS compatibility. Several different GSM data modems are available in different

modification (dual- and quad-band) and a functional prototype with in-band data modem is

available.

EuroGPS SmartTracker ALM-3A is a highly customizable GPS OBU with OTA setup, remote

diagnostics and firmware updates remote service additions, service activation/deactivation,

remote operational parameter control and settings and allows connection to external devices,

touch screen LCD displays, for two-way communication with the driver, navigation,

multimedia applications, etc.

It works with Icom’s own telematics service platform – EuroGPS eVehicle – enabling a

number of specific commercial fleet management solutions as well as UBI, B-Call and road

user charging scenarios.


44 Version 1.1

The IVS collects PVT data (position, velocity, time) in real time (every 1 second) as well as

data for direction on road, engine status, fuel level, and other readings from optionally

connected sensors (like doors, gates, engine speed in RPM’s, temperature in refrigerated

cargo sections or the cabin, panic buttons, RFID readers, low battery when disconnected

from vehicle, actual fuel quantity (when appropriate fuel sensor is installed, or a connection

to a non-defective standard vehicle fuel sensor is made), number of passengers in vehicle

(when appropriate sensor installed), and allows the connection of multiple additional sensors

or devices like flow-meters, fuel sensors, temperature and pressure sensors, security

devices, etc.)

Further the device has built-in CAN bus interface controller and features a proprietary CAN

expansion network, allowing both functional and interface expansion and multiplication and

multiple CAN connections.

4.4.1.1 In-vehicle system functions

A prototype of eCall IVS provided by ICOM will be used.

The IVS from ICOM contains the following main function blocks:

Network Access Device NAD, GSM/GPRS

GNSS: GPS receiver (positioning)

Host CPU (host for Telematics Services including eCall application)

Antenna system interfaces (MN and GPS)

Vehicle interfaces (CAN, eCall trigger, push buttons etc.)

Audio interface (microphone and speaker)


45 Version 1.1

Figure 11 ICOM eCall Unit

Special measures are taken to ensure the best possible performance when retrofitting in

used vehicles, as follows:

Backup power and internal antenna for autonomous work, which ensures functionality

even in severe crashes

Gyro- and accelerometers-based inertial system with advanced crash detection to

ensure a reliable automatic triggering of an eCall with retrofit installation on any kind

of passenger car (including very old models).

The eCall IVS prototype, which is going to be used in HeERO2, is based on ICOM’s existing

OBU for commercial telematics and proprietary emergency and crash-alerting service, to

which the following features for eCall will be added:

a) In-band modem implementation in the IVS will be completed in accordance with

following specifications:


46 Version 1.1

In-band modem solution; General description (Release 10) 3GPP TS 26.267

V10.0.0 (2011-03)

In-band modem solution; Conformance testing (Release 10) 3GPP TS 26.269

V10.0.0 (2011-03)

In-band modem solution; ANSI-C reference code (Release 10) 3GPP TS

26.268 V10.0.0 (2011-03) + 26268-a00_ANSI-C_Source_Code.zip

Intelligent transport systems – eSafety – eCall minimum set of data (MSD) EN

15722, June 2011

Intelligent transport systems – eSafety – ECall high level application

requirements (HLAP) prEN 16062, Date: 2010-09

Intelligent transport systems – eSafety – Pan European eCall - Operating

requirements EN 16072, Date: 2011 -07

b) Implementation of eCall activation - Functional requirements concerning eCall: prEN

16072

c) Implementation of MSD transfer - Intelligent transport systems - eSafety - eCall

minimum set of data (MSD) EN 15722, June 2011

The system will be installed into 10 vehicles from 10 different commercial fleets currently

using ICOM’s OBU’s in passenger cars and light commercial vehicles. The selected vehicles

will be from different makes and models to help testing the feasibility and functional

compliance of low-cost retrofit IVS for mass equipping of used vehicles.

Inertial data can be collected and processed at 1ms intervals to ensure proper incident

detection.

As Bulgaria does not have a strong OEM auto manufacturing industry and the current

passenger car park is one of the oldest in Europe, the IVS unit is targeted at the retrofit

market with a focus to lows-cost yet fully functional and eCall compliant IVS.

A functional prototype implementing an in-band modem is available. Compliance to finalized

certification guidelines is going to be achieved by minor modifications.

The existing firmware of EuroGPS SmartTracker ALM-3A will be largely used. Certain

modifications will be required to achieve compliance to certification guidelines.

Currently more than 20,000 active system units are in the field in Bulgaria. All new hardware

produced for commercial fleet management and other consumer telematics scenarios are

going to include eCall functionality after the eCall ISV (which is available as prototype at this

stage) is fully productized, tested, and ready for certification.


47 Version 1.1

Minor modifications are going to be done iteratively following the implementation plan of

HeERO2, and based on actual results in different test scenarios.

No major new HW development is envisaged as most of the hardware components in the

prototype ISV are compatible with European eCall. The GPS module with in-band modem is

already implemented as a prototype version, minor changes might be necessary before

readiness for start of mass production. The unit casing and the voice subsystem will be

modified to meet all the eCall requirements for reliability of triggering and following through

eCalls in different scenarios (automatic and manual).

The unit firmware is very flexible, extendable, with more than 2000 settable parameters and

with full integration of Icoms telematic platform, which supports apart from basic eCall

functionality a number of telematics scenarios for both consumer and corporate

environments and services for the public and private sectors (commercial fleet management

in a number of specialized industries, UBI, road user charging, mass transit management

and control, etc.)

No major SW changes are envisaged, just minor modifications to achieve full compliance to

finalized standards requirements.

Extensive testing is planned within the pilot. It will involve the equipping of 10 vehicles and

testing many different scenarios in various GSM coverage conditions and different ways of

triggering the eCall (manual, simulated, automatic, etc.)

4.4.2 TUS (Bulgaria)

The TUS’ IVS module is an eCall solution in progress for Bulgaria.

The unit will be able to perform the following functions:

Establishing eCalls

Manual eCall button

Automatic crash detection and analysis

Additional functions

Existing HW will be used and is compatible with available eCall requirements. Due to current

lack of a working PSAP server in Bulgaria final tests are postponed until the installation of

such a server or the purchase of a PSAP simulator.


48 Version 1.1

Figure 12 IVS overview

The TUS eCall IVS module contains the following main function blocks:

Network Access Device NAD, GSM/GPRS


uController control unit

External GSM/GPS antenna

SIM card interface (common SIM cards will be used)

Human interface (Push buttons, etc.)

Car interface (CAN bus, Power supply)

Audio interface (microphone and speaker)

Sensors for crash detection (Inertial, Gyro, Compass, etc.)

Existing third party eCall modem is used. It is assumed to be fully eCall compliant

according to manufacturer’s reference.

The TUS eCall IVS module is still under development and undergoing tests. It will be

able to perform automatic crash detection and analysis, as well as manual

establishing of eCalls. All functions comply with ETSI and CEN eCall standards.


49 Version 1.1

4.4.3 CTAG IVS (Spain)

The CTAG IVS system is composed by 2 subsystems:

eCall Human Machine Interface (eCall HMI). Composed by all the components

related to a correct user interaction with the eCall service:

o eCall peripheral board with button and LED indicator for eCall manual

activation

o Microphone and speakers

CTAG eCall and Telematics IVS Control Unit. The main functions of this electronic

control unit related to eCall service are:

o Collect all information related to eCall service messages, in order to compose

the required data messages (MSD)

o Establish and maintain the voice channel with PSAP

.

Figure 13: CTAG IVS overview

The described system has the following capabilities related to eCall:

Collect car and GPS data and compose eCall messages

Establish and maintain the eCall service manually or automatically when a crash is

detected.

CAN

GPS

Airbag

VIN

sp

eake

r

mic

rop

ho

ne

IVS

GSM

3G In-Band Modem112 eCall

In-Vehicle System

ready for eCall

eCall HMI


50 Version 1.1

Keep online including disconnection from car battery condition

In addition it contains other telematic related functions.

Main features of the system are:

3G modem eCall compliance

CAN interface

GPS receiver

Audio interface

Auxiliary battery

Interface for eCall HMI

Antenna

Host CPU for telematics services including eCall application

Existing HW and SW will be used for eCall purposes, being compatible with available eCall

requirements. In particular, described hardware and its related software/firmware are

compliant with ETSI and 3GPP pan-European in-band technology standards.

4 CTAG’s IVS units will be integrated in 4 vehicles foreseen in Galicia. No modifications are

required on existing IVS.

The envisaged implementation steps for enabling the HeERO2 IVS functionality are:

In-vehicle integration: M5

Integration tests and verification: M6

4.4.4 Ficosa’s Telematic Control Unit (TCU) (Spain, Luxembourg, Denmark)

Ficosa has developed a smart and compact communication platform to satisfy the increasing

demand of telematic services in the vehicle, whether the issue is connecting vehicles to each

other (Car2Car / C2C) or to the infrastructure (Car2Infrastructure / C2I) . The TCU –

Telematic Control Unit – platform comprises compact and cost effective solutions to enable

safety and infotainment applications in the vehicle. Furthermore, the TCU product family is

designed to minimize the installation costs and maximize system robustness in case of

accident and external manipulation. The TCU is a state-of-the-art OBU (on board unit).


51 Version 1.1

Ficosa’s Telematic Control Unit system includes integrated antennas based on fractal

technology. Telematic modules allow internal and external communications within the vehicle

integrating various telecommunication technologies, such as mobile telephony, CAN bus and

positioning systems, in a single unit.

Main characteristics and benefits:

Enabled by current technology and capable to integrate new ones to support future

telematic services

Cost effective and compact electronic design

Optimal design and performance of integrated antennas

Easy installation, only one connector to the vehicle

System robustness in case of accident and external manipulation thanks to integrated

antennas in the same module

Automotive conformance

Functions supported:

TCU eCall for Emergency Services - eCall 112

TCU for Anti-Theft Services (Stolen vehicle tracking)

Roadside Assistance / Breakdown-CALL (B-CALL)

Remote Diagnosis

Remote setting

Fleet Management

Pay As You Drive

Car Sharing

Equipment specifics:


52 Version 1.1

Figure 14: Ficosa’s TCU overview

Detailed information on equipment specifics can be found in Section 6 (Questionnaires).

The TCU eCall HW has been specifically designed to support driving assistance and

emergency services. Additionally, the TCU eCall complies with the European Commission

directives on eCall. Ficosa participates in several European initiatives in the field of vehicular

safety and communications and has signed the Memorandum of Understanding of

eCall. Moreover, the TCU eCall SW ought to be customized in order to be able to execute

eCall functionality in HeERO2 Scenarios. eCall should be available in a non-CAN scenario;

in order to make this possible some SW change ought to be considered. 5 units will be

provided for the HeERO2 Spain consortium.

The modification process includes analysis of HeERO2 Application Scenarios and the

detection of SW requirements in order to make possible eCall execution with Ficosa’s TCU

HW; implementation of SW modifications (eCall in non-CAN vehicle); HW/SW integration and

testing. TCU HeERO2 customized SW will be test in Ficosa’s premises as well as in

HeERO2 actual scenarios. (Detailed information and the necessary customization and

implementation can be found in Chapter 6).

As a prerequisite, specific Test modes should be discussed in order to foresee SW

implementation, for instance, during test fields may be necessary to allow to perform eCall

not only on 112, but also standard phone number due to PSAP initial unavailability, and also


53 Version 1.1

autonomous and periodic eCall communication feature to allow intensive testing for

performance analysis. Furthermore, handling assumptions must be observed, IVS units will

be shipped completely closed and their manipulation must be restricted to Ficosa authorized

personnel only.

4.4.5 GMV U-10A OBU (Spain and Denmark)

GMV’s IVS U-10A is a mobile location unit that implements GNSS location and eCall

(automatic and manual) features according to applicable standards (in addition to other

value-added services). Based on GPS signals, it also incorporates GPRS/GSM

communication and in-band modem technology and a complete set of peripheral interfaces

for different sensors to be used in customized applications to meet specific applications’

needs and requirements (including microphone, audio and panic button for eCall purposes).

GMV’s U-10A OBU is intended to be compatible for both After Market and OEM in-vehicle

installation (with necessary adaptations).

Figure 15: GMV’s U-10A OBU overview

Main functionalities of the IVS are:

Communication management

eCall management (automatic and manual)

Fleet tracking and monitoring

Highly Accurate Distance calculation

Firmware remotely uploading

Self-diagnosis

Supports one OBU-multiples services architecture

Additional functionalities are shown in Chapter 6.

Existing HW will be used with necessary modifications for eCall purposes. In particular,

integration of microphone, audio and panic button peripheral unit will be carried out.


54 Version 1.1

Moreover, existing SW will be used with necessary customization and configuration for eCall

purposes, including firmware modifications, development of procedures for eCall triggering

(automatic and manual), MSD implementation and transmission, adoption of latest

developments from Standardization Task Force on eCall IVSs and development of platform

to monitor test vehicles for detailed information registering (detailed information about the

necessary customization and implementation plan can be found in Chapter 6).

4 GMV’s U-10A units will be used for eCall tests in Madrid’s demonstration site and for cross-

bordering eCall tests between Madrid and Castilla y León. They will be installed in 4 vehicles

from one of GMV’s customers.

Tests need to include IVS SW configuration, IVS integration on preliminary test vehicle,

verification of IVS correct operations (eCall triggering, IVS-PSAP communication, MSD

transmission etc.), registering of IVS information on the developed platform for analysis.

As a prerequisite it is anticipated that the IVS will be temporarily installed in (GMV’s) vehicles

for testing. Test calls can be selected to be triggered manually, or in pre-defined intervals (of

e.g. 5 minutes) after a GPS position fix has been made. Additionally, having a built-in

accelerometer, IVS can be configured to trigger automatic eCall under predefined status of

accelerometer. 112 and PSAP might be used at a later date; in the beginning a normal, pre-

defined landline number will be called for preliminary tests. Identification of the IVS will be

based on the IMEI or the VIN number, coded according a scheme defined in the HeERO2

team within the given boundaries (e.g. a virtual HeERO2 manufacturer identification). The

SIM is assumed to be an exchangeable standard SIM card.

4.4.6 Civitronic ubiq eCall (Greece)

Two IVS units will be supplied by the contractor of the PSAP equipment, as described in the

tender for the supply of HW and SW of PSAP and IVS. The IVS unit proposed is the ubiq

eCall from Civitronic, which uses the ARM9 core TC65i, a high performance open platform

Java module from Cinterion. The IVS unit uses GSM module AH3 from Cinterion, as in-band

modem with integrated eCall functionality. The unit requires an external antenna and offers

manual and automatic eCall trigger option. It supports three use cases:

automatic emergency call triggered manually via the automatic eCall button

manual emergency call triggered manually via the manual eCall button

test call set up on an ordinary voice call triggered manually via the test eCall button


55 Version 1.1

At call start the eCall In band Modem goes into push Mode, meaning that the IVS triggers

MSD transmission by asking the PSAP to request an MSD transmission. The voice channel

will be muted for the duration of MSD transmission.

4.4.7 Renault SAS Telematics Control Unit (Turkey)

Renault SAS offers a system that contains the following main ECUs (Electronic Control

Units):

Airbag Control Unit “ACU”: It detects if a crash has occurred and sends a trigger

signal to the Telematic Control Unit.

Telematic Control Unit “TCU”: It is responsible for composing the data message

(MSD), transmitting of the data to the PSAP and establishing a voice connection with

the PSAP.

eCall human-machine interface “EMU”: It has a switch, 2 LEDs, a microphone and a

speaker in order to allow manual eCall launch and voice connection to PSAP.

The TCU contains the following main function blocks:

Network Access Device “NAD”, GSM/GPRS


Host CPU (host for Telematics Services including eCall application)

Antenna system interfaces (NAD and GPS)

Vehicle interfaces (CAN, eCall trigger)

Audio interface (for EMU microphone and speaker)

4.4.8 Magneti Marelli Unit (Turkey)

TOFAS is planning to use an eCall solution by Magneti Marelli. Starting from the eCall box

oriented to manage automatic and manual emergency call (ATB Telematic Box), Magneti

Marelli has customized the IVS in order to manage the Pan-European eCall and the

breakdown call service (bCall).

The eCall solution is based on two components:

Telematic Control Unit (Autonomous Telematics Box, ATB) providing

o GPS Functionality

o Cellular Network connectivity


56 Version 1.1

o Speaker

Emergency Media Unit “EMU”

o Microphone

o eCall Button

o Breakdown Call Button

IVS main functions are:

Radio interface used: 2G, GSM module including in band modem made by Sierra

Wireless

Version of standard for MSD

eCall flag management

The devices will be installed in After Market (power supply from the cigarette lighter).

Figure 16: Connection diagram of the unit

4.4.9 Civitronic’s X700 platform (Turkey)

The Civitronic’s platform is the base for the IVS in Romania, a proven base for both After

Market and OEM telecommunication boxes. It is an IVS device designed for fleet

management systems, combining state-of-art processing ARM9 core and GSM/GPRS

modem with integrated GPS receiver, in-band GSM modem for eCall functionality,

automotive power supply and GSM antenna. System core is TC65i, a high performance open


57 Version 1.1

platform Java module from Cinterion. A second GSM module, AH3 from Cinterion, is used as

in-band modem with integrated eCall functionality. The integrated GPS receiver delivers

precise location, speed and heading information, while external buttons allow for manual

control of eCall scenarios.

Figure 17: Civitronic IVS Unit Overview

The unit is able to perform the following functions:

Tracking Mode and Fleet Monitoring

Alarm Status

Private and Business Modes

Panic Button

Driving Style Monitoring

Theft Detection and Stolen vehicle tracking

Over the Air Configuration and Firmware Download

Accelerometer Auto Calibration and Crash Detection

Driver identification based on unique DallasKey

Geo-fence alarms and notifications

Existing HW will be used and it is compatible with available eCall requirements. Currently the

system is able to perform private and public eCall. Tests have been made with a server

provided by Cinterion.


58 Version 1.1

Figure 18: Civitronic Unit System Architecture

4.4.10 Fujitsu Ten Platform (Denmark, Luxembourg)

FUJITSU TEN’s IVS consists of a main unit, controller-indicator, external antennas,

microphone and loudspeaker. This IVS supports pan-European eCall service that is activated

by a signal from vehicle, manual button on controller or the acceleration sensor in main unit.

The main unit has CAN bus interface so that it is able to collect the valuable data from a

vehicle.


59 Version 1.1

Figure 19 FJ10 IVS

Supported functions:

a. Pan-European eCall

b. ERA-GLONASS

Equipment specifics:

IVS dimensions

IVS main unit: approx W130 x D75 x H35 [mm]

Indicator : approx W140 x D65 x H26 [mm]

Wire harness between IVS main unit and Indicator: 1.5 m

External mobile network antenna (film type) : W170 x D70 [mm]

External mobile network antenna cable length : 3.5 m

External GPS antenna (film type) : W70 x D70 [mm]

External GPS antenna cable length : 3.5 m

Specifications

item specifications

eCall trigger Automatic / Manual switch

Mobile network GSM, UMTS

Mobile antenna external / internal


60 Version 1.1

MSD transmission In-band-modem

GNSS receiver GPS / GLONASS

GNSS antenna external / internal

SIM card SIM / eSIM

Backup battery yes

Power supply Backup, IG from vehicle

Microphone external

Loudspeaker external

Status indicator LED

Software update yes

Communication log

Device Memory in SD card/USB Serial Port

DATA

RTC, MSD, GNSS position,

Mobile/GPS Signal condition,

Mobile signal freq/ID,

sequence of MSD sending,

PSAP message, conversation,

System diagnostics, etc.

4.5 Additional services (Road Operators, High Consequences Dangerous

Goods)

4.5.1 Denmark

If there is a road traffic incident, the PSAP push the relevant data to The Danish Road

Directorate.

4.5.2 Luxembourg

This means that the 112 centre acts as a single point of entry and dispatches the calls to

other agencies like police if necessary. The 112 centre even provides support services to the

Luxembourg citizens like providing the address of the nearest doctor or pharmacy.


61 Version 1.1

4.5.3 Greece

4.5.3.1 Road Operators

In Greece, the Incident Management (IM) is structured into different operating services,

depending on the governmental agreement. Usually there is a private organisation that is

responsible for a road traffic incident on main highways like Attiki Odos, Egnatia Odos and

Olympia Odos, that may also be contractor for the construction of the highway. Road traffic

incidents require the cooperation of the private organisation and the police, while (depending

on the agreement) a private organisation may breakdown assistance services, like the case

of Express Service supporting Attiki Odos and others. Road Management is also operated by

the private organisations, including road service and safety, road congestion, etc.

4.5.3.2 Dangerous Goods

In Greece, currently there are no automated alert procedures for incidents involving

hazardous materials. Relevant information can be accessed either by road cameras, on-site

police officers, or the driver’s declaration of the UN number as described in the ADR.


62 Version 1.1

5 Operational and functional requirements

5.1 Standards

List of standards is available at:2

http://ec.europa.eu/information_society/activities/esafety/eCallstandards/index_en.htm

http://ec.europa.eu/information_society/activities/esafety/doc/eCall/annex_standard.pdf

5.2 General overview of the eCall transaction for pan-European eCall

In the introduction to European Standard, eCall was described as "an emergency call

generated either automatically via activation of in-vehicle sensors or manually by the vehicle

occupants (the eCall generator); when activated, it provides notification and relevant location

information to the most appropriate Public Safety Answering Point, by means of mobile

wireless communications networks and carries a defined standardised minimum set of data,

notifying that there has been an incident that requires response from the emergency services

and establishes an audio channel between the occupants of the vehicle and the most

appropriate Public Safety Answering Point.

Pan-European eCall effects this service using a Circuit Teleservice supported by a Public

Land Mobile Network (PLMN) (Teleservice 12/TS12) ETSI TS 122 003.

After the establishment of an emergency voice call (112/E112) between a vehicle and a

Public Safety Answering Point (PSAP) the audio equipment comprising the microphone and

loudspeaker in the vehicle is disconnected from the line whilst the MSD is transmitted, within

the voice band, to the PSAP data processing equipment. An indication shall be given to the

occupants of the vehicle that an eCall is in progress. On completion of the MSD transfer the

in-vehicle audio system is reconnected to the line and a voice communication is established

between the vehicle occupants and a PSAP operator.

The incident related information associated with the 112/E112 voice call, contained within the

MSD, is made available to the PSAP operator in the manner decided locally.

2 All standards will be placed on HeERO2 PROJECT PLACE in unique directory

http://ec.europa.eu/information_society/activities/esafety/ecallstandards/index_en.htm

http://ec.europa.eu/information_society/activities/esafety/doc/ecall/annex_standard.pdf


63 Version 1.1

Figure 20: Relationship of eCall transaction to standards

Following the initial resolution of the incident by the PSAP operator, the PSAP operator may

clear down the call, however, the in-vehicle system (IVS) remains registered on the mobile

network, for the period specified in EN 16072 to enable the PSAP or rescue services to recall

the vehicle occupants.

The eCall service technical requirements, as they apply to the establishment of the TS12

emergency call and the transfer of the in-band data, are as specified in ETSI TS 122 101 and

ETSI TS 124 008. These specifications also describe the use, by the mobile network, of the

eCall flag identifier, needed to ensure the correct filtering and routing of eCalls to a

designated eCall capable PSAP.). The eCall in-band modem, used to transfer the MSD, is

specified in ETSI TS 126 267 and ETSI TS 126 268.


64 Version 1.1

5.2.1 Detailed explanation of the eCall transaction

Under normal circumstances, the stages of the pan-European eCall transaction that provide

the service can be described as comprising 9 steps:

Step 1 – Procedures following power-up and initialization of the in-vehicle system

Step 2 – Activation (of system); a) the eCall generator initiates the eCall by sensors triggered

and/or manually, sends the in-vehicle triggered eCall to a PSAP. The eCall consists of two

elements:

the Minimum Set of Data (MSD), and

a voice (audio) telephone call based on TS12;

Step 3 – Call set-up (including identifying call type, make call, network selection and

registration, authentication (home location registry), cell localisation (by network), establish

audio connection to PSAP modem server). The wireless communications network operator

(MNO) system shall establish the TS12 call and route the voice call, including the MSD, to

the most appropriate PSAP, according to national arrangements; An eCall compliant MNO

system shall make use of an eCall flag, as specified in ETSI TS 124 008 [Release 8 or later],

received in the emergency call set-up message, to differentiate eCalls from other TS12

emergency calls. eCall flags may be used to filter and route eCalls to a dedicated destination

if required;

Step 4 – MSD transfer (including disconnect microphone and loudspeaker in vehicle from the

line, send call tone, synchronise, request MSD, send MSD, error check), and link layer ACK

(including stop MSD transmissions)

Step 5 – Application layer ACK; the PSAP transmits an acknowledgement to the eCall IVS

specifying that the MSD has been properly received

Step 6 – Establish audio link (including check audio link to vehicle occupants, MSD

visualization, rerouting to another PSAP)

Step 7 – Clarification of the overall emergency situation and location

Step 8 – Initiate incident resolution and inform vehicle occupants verbally that help is coming

Step 9 – Call clear-down

Procedures also need to be defined by local or national authorities for failure exceptional

causes such as:

PSAP or rescue service call back (voice only) or 'SEND MSD’;

MSD not transmitted correctly;

false generation of eCalls;


65 Version 1.1

network registration fails;

call failure;

network not capable to support eCall flag;

eCall routed to a non-equipped PSAP;

PSAP modem failure;

PSAP network/ICT failure;

PSAP application failure;

PSAP operator does not respond;

MSD not sent;

MSD not received;

audio link not established;

audio link established but subsequently fails;

re-attempt in case of interrupted call;

automatic repeat attempts;

IVS NAD does not receive clear-down;

Procedures/protocols for other process features need also to be specified, such as:

termination of manual eCall trigger before it has been confirmed by vehicle

occupants;

activation/deactivation of eCall equipment in the vehicle.

5.2.2 Other technical recommendations

eCall flag will not be mandatory for PSAP and Mobile network during HeERO2 as in

HeERO 1 long number dialling has shown to be capable of demonstrating eCall

functionality, but it must be recognised that for full deployment the necessary

upgrades will be required. Experience in HeERO 1 has shown that this is not always

straight forward. The GSMA have given an undertaking to ensure that all networks

will be upgraded ready for full deployment. Current information indicates that this

should be achieved by the end 2014.

all IVS should have functionality to generate eCall flag (Service Category in

Emergency Set Up) also for HeERO2 testing

all IVS can also use a “long number” at least for HeERO2 project

5.3 Functional requirements - IVS

Pan-European eCall system should involve a few basic modules and procedures described

below. These parts are in different stages of standardization; related standards are included.


66 Version 1.1

5.3.1 High level functional requirements

the In-Vehicle System shall include a Network Access Device (NAD, e.g. PLMN (such

as GSM AND 3G), module);

the In-Vehicle System shall detect when an eCall trigger has been initiated;

in the event of an incident the eCall system shall automatically determine whether or

not to trigger an eCall and where appropriate make such an eCall automatically;

an eCall shall also be able to be triggered manually;

upon triggering an eCall the eCall system shall attempt to send a Minimum Set of

Data (MSD) to any system operated by a given Mobile Network Operator (MNO) with

the European pre-assigned TS12 destination address (112);

the eCall system shall also try to establish a voice connection between the vehicle

and that pre-assigned destination address (preferably a Public Safety Answering

Point (PSAP) with TS12)

5.3.2 Procedures following power-up of the in-vehicle system

The IVS network access device (NAD) shall conform in all respects to the applicable ETSI

specifications and in particular to the requirements specified in ETSI TS 122 101 and ETSI

TS 124 008 with regard to this initial power - up procedure.

As specified in ETSI TS 122 101, an eCall IVS NAD shall have a valid SIM/USIM. The

SIM/USIM enables the provision of the eCall service, The SIM/USIM can be configured only

for eCall (in this European Standard referred to as "eCall only"), or a combination of eCall

and commercial service provision.

5.3.3 Activation

Once the in-vehicle system is made aware by the eCall generator of a triggering event that

fulfils the requirement described in EN 16072, and provided that there is no ongoing eCall in

progress, the activation sequence shall start. In order to meet the objectives of the provision

of the service defined in EN 16072, additional application protocols are required to

successfully affect an activation sequence.

The in-vehicle system shall:

if necessary immediately interrupt any ongoing communication using the

communication channel


67 Version 1.1

required for eCall;

disconnect the in-vehicle microphone from the line;

disconnect the in-vehicle loudspeaker from the line;

start the eCall transaction at the IVS level;

except for retrofit eCall systems, installed in-vehicle equipment shall ensure that the

in-vehicle

audio equipment is muted for the duration of the eCall (as defined in EN 16072); alert

the vehicle occupants of an initiated eCall as described in EN 16072.

References to standards:

Information content of MSD: CEN/TS 15722 (EN 15722)

Functional requirements concerning eCall: prEN 16072

5.3.4 Call set-up

Emergency call set-up is initiated by the IVS "Activation Function" executed by IVS network

access device (NAD).

Timer T2 - IVS Call clear-down Fall-back Timer (CCFT)


68 Version 1.1

5.3.5 MSD transfer

Figure 21: Data flow description

Sequence of steps:

Send initiation signal (5 * “SEND” bursts) from IVS eCall modem to PSAP

eCall modem synchronisation in PSAP

Request MSD by PSAP eCall modem to IVS eCall modem (n * “START” bursts)

eCall modem synchronization in IVS

IVS eCall modem: MSD transmission to PSAP eCall modem (“MSD tx”),

potentially in several repetitions, until link layer “ACK” is received from PSAP or

“HL-ACK” is received from PSAP (“ACK” may be omitted completely).

PSAP eCall Modem: Send link layer “NACK”, until CRC successful

PSAP: Link layer error check

PSAP: Link layer ACK from PSAP eCall modem to IVS eCall modem

PSAP: Sends “HL-ACK” immediately after “NACK” and “ACK” (“ACK” may be

omitted), if format check is successful.

SEND

START

ACK (may be

HL-ACK (immediately)

NACK


69 Version 1.1

5.3.6 Application layer acknowledgement (AL- ACK) (called “HL-ACK” in TS 26.267)

After successful MSD transfer, the PSAP shall check the MSD content automatically. If the

format check succeeded, the PSAP shall subsequently automatically send the positive AL-

ACK to the IVS so it can be received within 5 s from reception of the LL-ACK (T6 – IVS wait

for AL-ACK period).

Figure 22: Al – ACK diagram

Proposal: If the CRC was found OK, but the format check detects an invalid MSD, then the

PSAP shall ignore the MSD. In most cases it does not make sense to repeat an invalid MSD.

5.3.7 Request "SEND MSD" (called “START” in TS 26.267)

The PSAP application shall have the capability to instruct the PSAP modem to request the

IVS to send the latest version of the MSD at any time a voice connection is active to the IVS.


70 Version 1.1

Figure 23: Send MSD diagram

Note: The PSAP may only send the CLEARDOWN at the end of a successful MSD (re-)

transmission. In case of marginal radio link coverage or other obstacles in the voice path the

MSD transmission may be unsuccessful, in which case the CLEARDOWN cannot be sent to

the IVS.

5.3.8 List of timers

T1

Manually initiated eCall (MIeC)

false triggering cancellation

period

Vehicle occupants may cancel a false

triggering of a manually initiated eCall

before call set-up.

Specified by

manufacturer.

May be zero.

T2

IVS Call Clear-down Fall-back

Timer (CCFT)

If the IVS NAD does not receive a call

clear-down indication from the mobile

network, or an application layer call clear-

down message from the PSAP and the call

60 min

START

NACK

ACK (may be omitted)

HL-ACK or CLEARDOWN


71 Version 1.1

clear down timer has reached 60 min, the

call shall be cleared down.

T3

IVS INITIATION signal duration

The IVS INITIATION signal stall not persist

for longer than 2 s from when the UE

receives notification that the call is first

answered.

2s

T4

PSAP wait for INITIATION signal

period

If a valid INITIATION message is not

received by the PSAP modem within 2 s

from when the NAD knows that the call has

been answered then the call shall be routed

to a PSAP operator.

5s3

T5

IVS wait for SEND MSD period

If the IVS eCall modem, whist sending the

INITIATION message, does not receive or

recognise a valid "SEND MSD" message

from the PSAP eCall modem within 2 s,

from the time that the IVS receives an

indication that the PSAP has answered the

call, it shall reconnect the IVS loudspeaker

and microphone in the vehicle.

5s4

T6

IVS wait for AL-ACK period

If an AL-ACK is not received within 5 s from

receipt of the link layer ACK, the

loudspeaker and microphone in the vehicle

shall be reconnected to the line in order to

enable the call to revert to an E112 voice

call.

5s

T7

IVS MSD maximum transmission

time

If the IVS does not receive a link layer ACK

(LL-ACK) within 20 s from the start of MSD

transmission, it shall cease transmission

20s

3 Currently under discussion with CEN (proposal by HeERO standardization task force) 4 Currently under discussion with CEN (proposal by HeERO standardization task force)


72 Version 1.1

and the IVS audio system shall be re-

connected.

T8

PSAP MSD maximum reception

time

If the PSAP eCall modem does not send a

link layer ACK (LL-ACK) within 20 s after

having sent the "SEND MSD" message to

the IVS eCall modem, it shall route the

voice call to a PSAP operator.

20s

T9

IVS NAD (eCall only

configuration) minimum network

registration period

Following call clear-down by the PSAP the

IVS NAD shall remain registered on the

serving network and available to receive

calls from the PSAP and rescue workers for

a minimum period of one hour as defined in

EN 16072.

1h

T10

IVS NAD (eCall only

configuration) network De-

registration Fall-back Timer

(DFT)

An IVS NAD configured to make eCalls and

test calls only shall, following call clear-

down and maximum expiration period of

the De-registration Fall-back Timer (DFT)

12 h period, de-register from the serving

network.

12h

Table 1: Timings


Contents and structure of MSD: CEN/TS 15722 (EN 15722)


High-level application protocol for eCall: prEN16062

Requirements for the transmission of MSD: ETSI TR 22.967, TS 22.101

Method used to transmit MSD (modem): ETSI TS 26.267, TS 26.268

eCall flag: ETSI TS 24.008, table 10.5.135d


73 Version 1.1

The HeERO standardization task force made some proposals for changes in the standards

15722 and 16062. These changes are not approved at this time (Jan 2013) but are

recommended to be implemented in future eCall systems.

5.3.9 HeERO2 interoperability conditions for IVS

SIM/USIM with roaming capability

In band modem according to ETSI TS 26.267, TS 26.268, rel. 10.0.0 recommended

MSD according to EN 15722 (June 2011)

Request Send MSD - every IVS shall implement the functionality to re-transmit the

MSD on PSAP-Request (START) and then re-open the voice communication, but

PSAPs are free to use this feature.

Table of timings implementation


IVS basic features

There is suggested to test (during HeERO2 project) only “common SIM card” (not

special eCall SIM CARD) according to HeERO2 scope of work. This of course does

not mean that someone on national level could not test it on his own way during the

HeERO2 project.

3G networks for IVS is not required by the scope of the HeERO2 project, there is just

necessary to have voice communication. Support for the mobile networks (2G or 3G)

by IVS is optional.

In case of Resend MSD IVS should provide PSAP with the actual position of the car.

VIN Decoder

Conclusion: EUCARIS is the preferred solution, HeERO2 admits also proprietary VIN

decoder at least with the same functionality of VIN decoding, and these are currently

available commercially.

MSD data

The main structure of MSD in accordance with EN 15722 is valid and usable for

HeERO2 project testing. “Optional additional data” (as part of MSD) will be “tolerated”

(=not to be evaluated as “error” by the system) but could be recognize on national

level.


74 Version 1.1

Optional “Vehicle location” (as a part of MSD) – it’s suitable to explain exact meaning

how the data will be used (for example in special situation as “loss of GPS signal and

following car incident)

5.4 Functional requirements - Mobile Network Operator (MNO)

5.4.1 eCall establishment

To initiate an eCall the IVS eCall activation function shall request the NAD to initiate a call

set-up to the network with a request for a Teleservice 12.

5.4.2 Prioritisation of an eCall

An eCall, whether generated automatically or manually, shall normally be given the highest

priority on the use of whatever wireless networks are used by the In-Vehicle System for an

eCall transaction, except where these are required for time-critical active safety messages.

5.4.3 eCall 'flag'

In the call set-up message the IVS NAD shall set the "Service Category " information

element (IE) in accordance to ETSI TS 122 101 (Release 8 or later). The purpose of this

eCall 'flag' is to enable a serving 'Mobile Switching Centre' (MSC) that supports this

functionality, to differentiate between speech only Teleservice 12 emergency calls (112 or

E112) and eCalls. Additionally the MSC may also be able to discriminate between Manually

Initiated eCalls and Automatically Initiated eCalls. The eCall flag may be used to route eCalls

to a dedicated PSAP operator. ETSI TS 122 101 provides a description of the "eCall flag"

and specifies the mandatory inclusion of the MIeC or AieC identifiers in the call set-up

message.


75 Version 1.1

Figure 24: eCall flag

5.4.4 eCall routing to PSAP

On receipt of the TS12 emergency call request, the mobile switching centre (MSC) in the

network shall route the call to the most appropriate PSAP. The MSC shall make use of the

"eCall flag" in the call setup message to route the eCall to a designated eCall capable PSAP.

The network provider shall route eCalls to separate PSAP connections (telephone lines)

compared to normal 112 calls, if this is required by individual PSAPs.

In case a single PSAP handles both eCalls and 112 calls and if the PSAP uses the Euro

ISDN primary rate interface (E1) for 112, network provider shall ensure, that the eCalls are

always routed to selected E1 channels, if this is required by individual PSAPs.

NOTE It may be noted that although an indication of manual or automatic eCall initiation is

included in the MSD, this information is not used by the mobile network for routing eCalls to a

particular PSAP, but may be used by the receiving PSAP.

5.4.5 Provision of positioning information

MNO (mobile network operator) provides the results of the network positioning of the IVS

which made the E112 call.

References to standards - functional requirements concerning eCall: prEN 16072


76 Version 1.1

5.4.6 HeERO2 interoperability conditions for MNO

Dialled number 112, this is important to get the correct priority, but only with the

Service Category IE present and set to manual or automatic eCall, otherwise the

regular PSAP-services would be disturbed by the HeERO2-test-IVSes.

Usage of eCall Flag as follows :

o AIeC : Emergency Service Category Value (octet 3) Bit 7 = 1

o MIeC : Emergency Service Category Value (octet 3) Bit 6 = 1

5.5 Functional requirements - PSAP

5.5.1 General requirements

ECall capable PSAP is required to be equipped with a software application that can receive,

validate and display the MSD contents to its operator(s). This could either be a special eCall

application or integrated in the PSAP's interface software.

Each PSAP should be able to decide which data it will display to its operators. However, this

software/system should at least:

warn the operator about a new eCall arrival;

show the data included in the MSD in an understandable way

warn the operator about the availability of the voice call;

provide a call-back capability;

provide a new MSD requirement application user interface;

provide an ability to clear-down the eCall.

5.5.2 MSD display to the PSAP operator

A PSAP can decide in which graphical way the MSD will be displayed to its operators but the

eCall case page shall show the data included in the MSD in a clear and understandable way.

In respect of interpreting the VIN content of the MSD, the PSAP needs to be equipped with a

VIN decoder.

5.5.3 PSAP operator user interface

In order to allow the PSAP operator to establish the audio link as soon as possible ensuring

this way the shortest possible processing time, the IVS shall never attempt to re-send the

MSD unless it has been requested to do so via a "SEND MSD" request.

The user interface shall be displayed in the eCall case page to allow the PSAP operator

interaction with IVS while observing the eCall handling process flow. This interface can be

designed at the convenience of the PSAP but shall allow at minimum for the event that the


77 Version 1.1

MSD is successfully received, the system acknowledges the MSD, and moves directly to

voice contact with the occupants of the vehicle.

5.5.4 Audio link to vehicle occupants

If the caller is able to speak, the call is handled as a normal 112 call.

5.5.5 eCall clear-down

On receipt of the MSD and/or completion of the telephone conversation with the vehicle

occupants, the PSAP operator shall clear-down the eCall. Depending on the context (see

below), the call may be cleared down by either hanging up in the normal way or by sending a

clear-down instruction to the IVS.

After the IVS has received the LL-ACK or T5 – IVS wait for SEND MSD period or T7

– IVS MSD maximum transmission time ends, the IVS shall recognise a normal hang-

up from the network. Furthermore the IVS shall clear-down the call.

After the PSAP has sent the LL-ACK or T4 – PSAP wait for INITIATION signal period

or T8 - PSAP MSD maximum reception time ends and the IVS receives a AL-ACK

with status = “clear down”, it shall clear-down the call.

The IVS shall not attempt an automatic redial following a call clear-down by either of the

above two methods.

Following call clear-down by the PSAP the IVS NAD shall remain registered on the serving

network and available to receive calls from the PSAP and rescue workers for a minimum

period as defined in EN 16072.

The eCall only IVS network de-registration fall-back timer (DFT) shall be reset following call

clear-down to control the maximum time that the IVS stays registered on the network (T10 -

IVS NAD (eCall only configuration) network De-registration Fall-back Timer (DFT)).

Following acceptance of an eCall by the PSAP systems, but for which the eCall could not be

processed (e.g. call was dropped), then the PSAP operator may attempt to call back into the

vehicle, but if this is done shall first allow the IVS sufficient time for automatic retries) as

described in EN 16072.

Following network de-registration the IVS shall go to standby mode and adopt the eCall

"Inactive State" in accordance with the eCall terminal state machine procedures specified in

ETSI TS 124 008.

5.5.6 PSAP call back

The PSAP operator shall be able to initiate a call back using the PSAP application system

(e.g. call back application user interface) or directly dialling the number using a conventional

phone as defined in EN 16072.

The sequence shall be that:

operator activates the call back application user interface/dials the number;


78 Version 1.1

telephone system processes the call;

IVS automatically shall answer the call (as described in EN 16072. The IVS shall

provide audio and/or visual feedback to the occupants that a call has been

successfully established;

operator handles the case;

operator clears down the call

5.5.7 Rerouting to another PSAP/emergency control centre

Different eCall architectures are foreseen and, in some architecture, rerouting to another

PSAP or emergency control centre may be necessary. The PSAP who initially receives the

eCall shall process the data included in the MSD, establish the audio communication and

handle the call; if appropriate, the receiving PSAP may reroute the call and MSD data to

another PSAP or emergency control centre according to procedures determined by the

responsible authority. This can be done via data or audio connection, or, preferably, both.

The eCalls present the same routing difficulties across borders as any other 112 emergency

calls. It can occur that the MSD and the voice call are received by a PSAP which is not

responsible for handling this emergency. Effective rerouting of the emergency data and voice

is the responsibility of PSAPs, as determined by the national authority.

5.5.8 Recording of event data to PSAP information system

Recording of data related to the emergency call to the PSAP information system. This data

set includes information on the E112 call itself, results of the risk assessment and actions

taken by police, rescue and ambulance services.

5.5.9 Provision of information to TMC and other public authorities

The PSAP which received the emergency call informs TMC (traffic management centre) and

other public authorities about the incident.

5.5.10 Request for and reception of supplementary information

PSAP may retrieve supplementary information related to a vehicle or user of the vehicle from

a service provider mentioned in the MSD received. The information received from the service

provider is stored in the PSAP information system and presented in a form understandable to

a human user.

This feature may be standardised in future but it is not included in current specifications of

pan-European eCall


Contents and structure of the MSD: CEN/TS 15722 (EN 15722)


High-level application protocol for eCall: prEN16062


79 Version 1.1

Requirements for the transmission of MSD: ETSI TR 22.967, TS 22.101

Methods used to transmit MSD (modem): ETSI TS 26.267, TS 26.268

5.5.11 HeERO2 interoperability conditions for PSAP

PSAP data modem according to ETSI TS 26.267, TS 26.268, rel. 10.0.0

recommended

MSD according to EN 15722 (June 2011)

Request Send MSD

Table of timings implementation


eCall re-send MSD should be tested as mandatory feature

eCall call-back should be tested as mandatory feature

Clear Down – it is necessary to distinguish between clear-down message and clear

down as termination of a call

5.6 HeERO2 Operational requirements

The main aim of the whole consortium during HeERO2 project is to follow and prove concept

of existing standards, therefore the main normative document for operational requirements is

EN 16072 - Pan European eCall- Operating requirements.

Operational requirements are generally described in this document, but beside this it is

reasonable to mention requirements dedicated to HeERO2 project, which has been chosen

during preparing this part of document.

5.6.1 Routing of an eCall

The in-vehicle eCall equipment shall support at least one wireless medium to be

suitable for transmission of an eCall (the prime medium) that is able to sustain both

data transfer and voice communication

The IVS shall identify the eCall communications with the eCall flag, eCall flag does

not have to be supported by all PSAP operators within HeERO2 project

5.6.2 Location and direction

The format of the location data in the MSD will comply with EN 15722.

Vehicle location will based on GPS data, map matching is not required

MNO calculated location is not required


80 Version 1.1

5.6.3 Minimum set of data (MSD)

The format of the MSD and contents of the eCall message will be as determined in

EN 15722

For VIN reaching there will be used Eucaris system

5.6.4 eCall triggering

Vehicles will be equipped with manual activation "TS12/SOS". The design and

positioning of these activation button depends on IVS providers

IVS will alert the vehicle occupants that an eCall message has been sent and that the

system shall attempt to make a direct voice connection with the PSAP.

The IVS may allow vehicle occupants to abandon a manually initiated eCall (in order

to cancel an unwanted triggering) before the eCall has been activated, but once the

eCall trigger has been confirmed within the IVS and therefore the eCall has been

activated, the eCall transaction shall not be terminated by the vehicle occupants.

5.6.5 Establish voice channel

The IVS system shall attempt to establish a 'hands-free' audio connection between

the occupants of the vehicle and the PSAP.

5.6.6 eCall termination

The eCall comprises both the sending the MSD and the establishment of a direct

voice channel between the PSAP and the occupancy of the vehicle. The PSAP will

determine when the eCall is terminated and shall notify the in-vehicle system.

IVS redial

Once the IVS is registered on the network, it will remain registered for a minimum

period of one hour after the eCall is terminated or until ignition is turned off or

available power is exhausted, whichever is sooner. (in case the PSAP wishes to

reconnect to the vehicle)

If an eCall voice connection between the IVS and the PSAP is dropped unexpectedly

and the IVS has not previously received confirmation from the PSAP that the eCall

can be terminated, then the IVS may automatically attempt to re-establish a voice call

to the PSAP. If an eCall has been successfully terminated by the PSAP, then the IVS

shall not attempt to reconnect to the PSAP unless a new trigger is received.

5.6.7 PSAP call-back

If an eCall has been successfully terminated by the PSAP, then the IVS shall allow a

call-back into the vehicle. Such a call-back after a successfully terminated eCall may

be treated with lower priority and it is therefore not necessary to block other vehicle

functions to allow this


81 Version 1.1

5.6.8 PSAP CLEARDOWN

If the PSAP decides to end an eCall instantly or not to accept any more incoming

calls from the same incident, it can send a CLEARDOWN message to terminate the

connection and prevent the IVS from re-dialling.


82 Version 1.1

6 Questionnaires

6.1 Public safety answering point PSAP

6.1.1 Example of Questionnaire

1) The operation of commercial eCall service:

a. is provided

b. is not provided

by the state or emergency services.

i. if operated, please describe system being operated

_____________________________________________

_____________________________________________

2) The number of call receiving points:

a. Number of PSAPs receiving the 112 eCall on the Member State’s territory

__________

b. Number of PSAPs receiving the eCall messages after the Europe-wide eCall

(2014) system is launched

__________

c. Provided 2b < 2a, please describe the principle for selecting the PSAPs

designed for receiving the eCall

_________________________________________

3) Software application for the processing of information on events

a. Are the PSAPs designed for receiving the eCall messages (see 2b) equipped

with software application for processing the events and with information

support?

YES – NO

i. If YES, please describe system (technical characteristic and data)

_____________________________________________

_____________________________________________

b. Are the Emergency Control Centres (ECC) of Fire Brigades equipped with

software application for processing the events and with information support?

YES – NO



83 Version 1.1

_____________________________________________

_____________________________________________

c. Are the ECC of the Police equipped with software application for processing

the events and with information support?

YES – NO


_____________________________________________

_____________________________________________

d. Are the ECC of Emergency Medical Service equipped with software

application for processing the events and with information support?

YES – NO


_____________________________________________

_____________________________________________

4) Geographical Information Systems

a. Are the PSAPs designed for receiving the eCall messages (see 2b) equipped

with a geographical information system (GIS)?

YES – NO

If YES:

i. Is the GIS containing data from the whole territory of the Member

State? YES – NO

ii. Is the GIS containing detailed data on the motorway and road network

(stops, bridges, exits, objects)?

YES – NO

If YES, please describe data structure and format

_____________________________________________

_____________________________________________

iii. Is the GIS enabling the identification of line topographic elements?

YES – NO


84 Version 1.1

If YES, please describe system (technical characteristic and data)

_____________________________________________

_____________________________________________

b. Are the ECCs of Fire Brigades equipped with geographic information system?

YES – NO

If YES:


State? YES – NO



YES – NO


_____________________________________________

_____________________________________________


YES – NO


_____________________________________________

_____________________________________________

c. Are the ECCs of the Police equipped with geographic information system?

YES – NO

If YES:


State? YES – NO



YES – NO


_____________________________________________

_____________________________________________


YES – NO


_____________________________________________

_____________________________________________


85 Version 1.1

d. Are the ECCs of Emergency Medical Service equipped with geographic

information systems? YES – NO

If YES:


State? YES – NO



YES – NO


_____________________________________________

_____________________________________________


YES – NO


_____________________________________________

_____________________________________________

5) Data communication

a. Is there a data connection between PSAPs and ECCs of individual emergency

units (Fire Brigade, Police, and Emergency Medical Service)?

YES – NO

If YES:

i. to Fire Brigade YES – NO

ii. to Policy YES – NO

iii. to Emergency Medical Service YES – NO

iv. other – please specify: _______________________________


_____________________________________________

_____________________________________________

b. Is there a definition of a uniform format of data communication messages?

YES – NO

If YES:

i. At what level is the uniform format established?

1. regional


86 Version 1.1

2. national

Please describe data structure and format

_____________________________________________

_____________________________________________

ii. Which units of the emergency system are using the format referred to?

1. Fire Brigade YES – NO

2. Police YES – NO

3. Emergency Medical Service YES – NO

c. Data communication is operated as:

i. One-way system (PSAP -> ECC)

ii. Two-way system (PSAP <-> ECC)

Multi-way system (PSAP <-> ECC <-> ECC)

Please describe system (technical characteristic and data)

_____________________________________________

_____________________________________________

Caller Localisation

d. Is the PSAP receiving information within the GSM network on the position of

the caller whenever a 112 call is involved?

YES – NO

e. Information on the position of the caller is transmitted through a technology of:

i. Push

ii. Pull

f. Does the PSAP dispose of information on the position of the caller during the

first 15 seconds from the reception of the call?

YES – NO

g. What is the accuracy of the localisation within mobile phone network?

__________________

Please describe technical characteristic

_____________________________________________

_____________________________________________


87 Version 1.1

6.1.2 Belgium PSAP report

Q Report

1 The operation of commercial eCall service is not provided by the state or emergency

services

2 The number of call receiving points:

Number of PSAPs receiving the 112 eCall on the Member State’s territory

10 logical Fire/Medical PSAP’s and 11 logical Police PSAP’s

Number of PSAPs receiving the eCall messages after the Europe-wide eCall

(2014) system is launched

11 logical Fire/Medical PSAP’s and 11 logical Police PSAP’s

Provided 2b < 2a, please describe the principle for selecting the PSAPs

designed for receiving the eCall

Filter Contact centre will determine if police or fire/medical is needed, based on

geographical region, call will be transferred to PSAP in that region

3 Software application for the processing of information on events

a. PSAPs currently are not designed for receiving the eCall messages but

will be after HeERO 2 project.

b. Emergency Control Centres (ECC) of Fire Brigades are equipped with

software application for processing the events and with information

support? Some Fire brigades use an automatic XML feed from the

PSAP, where responding teams are automatically notified.

c. The ECC of the Police are equipped with software application for

processing the events and with information support. The police use their

own system ISLP. Police events are automatically transferred via

CAD2ISLP from the PSAP to the police systems.

d. The ECC of Emergency Medical Service are equipped with software

application for processing the events and with information support. Some

use the same system as the fire departments use. For billing reasons

there are separated XML feeds.

4 Geographical Information Systems

a. PSAPs designed for receiving the eCall messages (see 2b) are


88 Version 1.1

equipped with a geographical information system (GIS)

i. The GIS contains data from the whole territory of the Member

State?

ii. The GIS contains detailed data on the motorway and road

network (stops, bridges, exits, objects). That is an internal

Intergraph format; there are tools to convert to this format

available. Detailed maps are only provided for the geographical

region of the PSAP.

iii. The GIS enables the identification of line topographic elements.

Intergraph can create event based on latitude/longitude

information

b. The ECCs of Fire Brigades are not equipped with geographic information

system

c. The ECCs of the Police are not equipped with geographic information

system

d. The ECCs of Emergency Medical Service are not equipped with

geographic information systems

5 Data communication

a. There is a data connection between PSAPs and ECCs of individual

emergency units (Fire Brigade, Police, Emergency Medical Service)

i. to Fire Brigade YES

ii. to Policy YES

iii. to Emergency Medical Service NO

b. There is a definition of a uniform format of data communication

messages at national level (XML for Fire and proprietary for Police)

i. Which units of the emergency system are using the format

referred to?

1. Fire Brigade YES

2. Police YES

3. Emergency Medical Service NO


89 Version 1.1

c. Data communication is operated as:

i. One-way system (PAP -> ECC). The PSAP is only pushing info

to external systems

6 Caller Localisation

a. The PSAP is receiving information within the GSM network on the

position of the caller whenever a 112 call is involved

b. Information on the position of the caller is transmitted through a

technology of:

i. Pull

c. The PSAP disposes of information on the position of the caller during the


d. The accuracy of the localisation within mobile phone network is variable.

Location is based on Cell-ID, accuracy depends on size of GSM cell

where the call comes from

Table 2: PSAP – Belgium

6.1.3 Bulgaria PSAP report

Q Report


services

2 The number of call receiving points:

a. Number of PSAPs receiving the 112 eCall on the Member State’s

territory is not applicable

b. Number of PSAPs receiving the eCall messages after the Europe-wide

eCall (2015) system is launched is planned to be the same as for current

calls


c. PSAPs are designed for receiving the eCall messages (see 2b)

equipped with software application for processing the events and with

information support. Description: Main data centre in Sofia and Disaster

data centre in Rousse. The CAD application is called ELS (from


90 Version 1.1

Siemens) with CTI Integration to the PBX over Contact Centre Software

(Siemens HiPath ProCenter)

Presentation - Client Application - Java frontend applet

Middleware - Tomcat servlet Engine; Apache2

Application - VIRuntime Servers

Data - 3-node Oracle RAC DB

Incoming calls are routed to the most appropriate free call taker based

on the location and language of the caller.

The CAD application permits the call takers to:

Answer the call, transfer the call etc.

See the location of the caller (area)

Manually fill in additional data for the event

Get feedback from the ECCs

Close the event

d. Emergency Control Centres (ECC) of Fire Brigades are equipped with

software application for processing the events and with information

support. The software application used for processing the 112 events is

the same as the one used in the PSAPs.

e. The ECC of the Police are equipped with software application for

processing the events and with information support. The software

application used for processing the 112 events is the same as the one

used in the PSAPs.

f. The ECC of Emergency Medical Service are equipped with software

application for processing the events and with information support. The

software application used for processing the 112 events is the same as

the one used in the PSAPs


a. PSAPs are designed for receiving the eCall messages (see 2b)

equipped with a geographical information system (GIS). The GIS

contains data from the whole territory of the Member State. The GIS


91 Version 1.1

does not contain detailed data on the motorway and road network

(stops, bridges, exits, objects) The GIS does not enable the identification

of line topographic elements

b. The ECCs of Fire Brigades are not equipped with a geographic

information system

c. The ECCs of the Police are not equipped with a geographic information

system

d. The ECCs of Emergency Medical Service are not equipped with a




emergency units (Fire Brigade, Police, and Emergency Medical Service:


ii. to Policy YES

iii. to Emergency Medical Service YES

iv. Mountain Rescue Brigade YES

v. Maritime Administration YES

Technical characteristic and data: Through working places which are

part of PSAPs application


messages at national level

c. data structure and format: According to the current communications at

112


referred to?

1. Fire Brigade YES

2. Police YES

3. Emergency Medical Service YES


92 Version 1.1

ii. Data communication is operated as Two-way system (PSAP <->

ECC). Software client of the same application as in PSAP




b. Information on the position of the caller is transmitted

i. within ISDN frame


first 15 seconds from the reception of the call

d. The accuracy of the localisation within mobile phone network is

“Area”. Information is transmitted as a 6 digit number. Query to data

Base renders the geographical coordinates of the mobile mast with the

segment of the covered area.

Table 3: PSAP – Bulgaria

6.1.4 Denmark PSAP report

Q Report


services

2 Number of call receiving points:


territory: 3


eCall (2014) system is launched: 3


a. The PSAPs are not designed for receiving the eCall messages (see 2b)


information support

b. The Emergency Control Centres (ECC) of Fire Brigades are not



93 Version 1.1

information support

c. The ECC of the Police is not equipped with software application for

processing the events and with information support?

d. The ECC of Emergency Medical Service is not equipped with software

application for processing the events and with information support


a. The PSAP designed for receiving the eCall messages (see 2b) is not


b. The ECCs of Fire Brigades are equipped with geographic information

system. The GIS contains detailed data on the motorway and road

network (stops, bridges, exits, objects): Vector data with few attribute

information, and without network topology (for more info:

http://www.fotdanmark.dk/Menu/data/fot-specifikationen)


system. The GIS contains detailed data on the motorway and road

network (stops, bridges, exits, objects): Vector data with few attribute

information, and without network topology (for more info:

http://www.fotdanmark.dk/Menu/data/fot-specifikationen)


geographic information systems. The GIS contains detailed data on the

motorway and road network (stops, bridges, exits, objects): Vector data

with few attribute information, and without network topology (for more

info: http://www.fotdanmark.dk/Menu/data/fot-specifikationen)



emergency units (Fire Brigade, Police, and Emergency Medical Service:


ii. to Policy YES


iv. Mountain Rescue Brigade YES

http://www.fotdanmark.dk/Menu/data/fot-specifikationen




94 Version 1.1

v. Maritime Administration YES

Technical characteristic and data: Based on two different protocol types


messages at regional level based on two different protocol types. The

format is used by Fire Brigade, Police and Emergency Medical Service

c. data structure and format: According to the current communications at

112


referred to?

1. Fire Brigade YES

2. Police YES


ii. Data communication is operated as One-way system (PSAP ->

ECC) and Multi-way-System (PSAP <-> ECC <-> ECC) based on

two prototypes. Each PSAP only uses one of the two protocols


a. The PSAP receives information within the GSM network on the position

of the caller whenever a 112 call is involved


technology of Push

c. The PSAP disposes information on the position of the caller during the


The accuracy of the localisation within mobile phone network is “cell” (Cell ID, LIP) and

about 70-75%.

Table 4: PSAP – Denmark

6.1.5 Luxembourg PSAP report

Q Report


services


95 Version 1.1


c. Number of PSAPs receiving the 112 eCall on the Member State’s

territory: 1

d. Number of PSAPs receiving the eCall messages after the Europe-wide



e. The PSAPs are not designed for receiving the eCall messages (see 2b)


information support

f. The Emergency Control Centres (ECC) of Fire Brigades are not


information support

g. The ECC of the Police is not equipped with software application for


h. The ECC of Emergency Medical Service is not equipped with software



e. The PSAP designed for receiving the eCall messages (see 2b) is not


f. The ECCs of Fire Brigades are not equipped with geographic information

system

g. The ECCs of the Police are not equipped with geographic information

system

h. The ECCs of Emergency Medical Service are not equipped with



a. There is no data connection between PSAPs and ECCs of individual


b. There is no definition of a uniform format of data communication

messages


96 Version 1.1

c. Data communication is operated as: Two-way system (PSAP <->

ECC) by a simple proprietary solution exchanging text messages.


d. The PSAP receives information within the GSM network on the position


e. Information on the position of the caller is transmitted through a

technology of Push

f. The PSAP disposes information on the position of the caller during the


g. The accuracy of the localisation within mobile phone network is “low”.

The location of the base station is providing only imprecise information

about the position of the caller

Table 5: PSAP – Luxembourg

6.1.6 Spain PSAP reports

6.1.6.1 Intermediate eCall PSAP- DGT

Q Report


services

2 The number of call receiving points


territory: 0


eCall (2014) system is launched:

In the frame of HeERO2 project Traffic General Directorate (DGT) will

host an intermediate PSAP in the Traffic Management Centre which will

filter the calls and redirect the call to the most appropriate 112 PSAP.

If this architecture is adopted, 19 centres depending on the regional

governments of the Autonomous Communities and Autonomous Cities

which are responsible for the answering of the 112 emergency calls, will

receive the eCall information from the intermediate PSAP.


97 Version 1.1

Note: DGT Manages the traffic information telephone 011 and roadside assistance.

Responsible in determining the basic technical standards in terms of traffic and road

safety. Competent in the regulation, management, and traffic control on interurban

roads and urban crossings. Competent in the development and operation of the

Register of Traffic Accident Victim. The traffic police functionally depend on the General

Directorate in surveillance, regulating and controlling traffic and road safety and for the

protection and roadside assistance. The DGT is the owner of the vehicle database.


a. The PSAPs designed for receiving the eCall messages (see 2b) is


information support. In the frame of HeERO2 project it will be

implemented the intermediate PSAP in the Traffic Management Centre,

this information is not available at this moment.


a. The PSAPs designed for receiving the eCall messages (see 2b) are

equipped with a geographical information system (GISIf YES:

i. The GIS contains data from the whole territory of the Member

State


network (stops, bridges, exits, objects

We have considered two options. The first one is to use our

organization’s GIS which is built on the ESRI products. The

structure and format of the data is the standard one defined by

ESRI plus the features our organization is interested in. The

second option does not include a full featured GIS.

iii. The GIS does not enable the identification of line topographic

elements




i. from eCall Intermediate PSAP to 112 PSAP. This has to be


98 Version 1.1

defined in the frame of HeERO2 project

b. Currently there is no definition of a uniform format of data

communication messages. It has to be defined in the frame of HeERO2

project.


referred to?

1. Fire Brigade YES – NO

2. Police YES – NO

3. Emergency Medical Service YES – NO

c. Data communication operation method has to be defined in the frame of

HeERO2 project

6 1) Caller Localisation

a. For the eCall Intermediate PSAP a decision about the PSAP receiving

information within the GSM network on the position of the caller

whenever a 112 call is involved has to be defined in the frame of

HeERO2 project

Table 6: PSAP – Spain Intermediate eCall PSAP- DGT

6.1.6.2 CAT 112 Catalunya

Q Report

1 CAT112 currently does not provide commercial eCall service.

2 Number of call receiving points

(answer missing)


Note: CAT112 does not coordinate actuation of the emergency bodies (fire brigade,

police, and emergency service) in the field.

a. Are the PSAPs designed for receiving the eCall messages (see 2b)


information support?

CAT112 utilizes the Telefónica “Séneca” platform to handle emergency


99 Version 1.1

events. Other PSAPs across Spain use the same system, but not

necessarily the same version, in some cases. Some other PSAPs have

a proprietary system. In case needed, PSAPs communicate with each

other through a telephone call (no automatic exchange of information

between the respective software applications; interesting for the tests in

areas between two adjacent regions, each managed by a different

PSAP).

b. Are the Emergency Control Centres (ECC) of Fire Brigades equipped


support? Not all the ECC of Fire Brigades across Spain use the same

software application.

c. Are the ECC of the Police equipped with software application for


Not all the ECC of the different Police bodies across Spain (e.g. Mossos

d’Esquadra, in Catalonia; Guardia Civil, etc.) use the same software

application.

d. Are the ECC of Emergency Medical Service equipped with software


Not all the ECC of Emergency Medical Services across Spain use the

same software application.


a. The PSAPs designed for receiving the eCall messages (see 2b) is

equipped with a geographical information system (GIS)? CAT112 uses

ArcGis.

i. The GIS contains data from Catalonia only


network (stops, bridges, exits, objects in Shape format.

iii. The GIS enables the identification of line topographic elements


system

i. The GIS does not contain data from the whole territory of the


100 Version 1.1

Member State



iii. The GIS enables the identification of line topographic elements

c. The ECCs of the Police are equipped with geographic information

system

i. The GIS contains detailed data on the motorway and road


d. The ECCs of Emergency Medical Service are equipped with geographic

information systems


Member State



iii. Is the GIS enabling the identification of line topographic

elements?



emergency units (Fire Brigade, Police, Emergency Medical Service


ii. to Policy YES


The system called “Passarel·la de Comunicacions de Seguretat i

Emergències” (PCSE), translated from Catalan as “Gateway for Security

and Emergencies Communication”, is in charge of managing the

exchange of information between all the emergency units. It is based on

Oracle Service BUS technology.

Additionally, there is a DB-link for the communication between the 112

and the Catalan Government Fire Brigade dispatching applications (in

the midterm, this interface will be migrated into the PCSE, as well)


101 Version 1.1

h. There is a definition of a uniform format of data communication

messages at regional level. Communications protocol based on the

EDXL – ESAP standard of Oasis

i. Units of the emergency system that are using the format referred

to?

1. Fire Brigade NO

Integration scheduled for Q4 2013

2. Police YES


ii. Data communication is operated as Multi-way system (PSAP <->

ECC <-> ECC)

The 112 operator receives the telephone call and registers the

incident data (location, typology) in the software application for

emergencies handling. Depending on the emergencies action

plan, he/she forwards voice and data (or data only), to the

applicable unit/units in charge of the emergency handling. The

operative emergency unit replies the 112 with the status of the

incident (received, acknowledged, managed, ended) so that the

112 can close the event.

Dataset to be sent by the 112 to the emergency units that are

registered in the software application for emergencies handling is

encapsulated in an EDXL-ESAP format message, and are

forwarded to the PCSE, that is in charge of handling it to the

receiving emergency unit. The PCSE has security and privacy

mechanisms integrated in the communication protocol.





technology of


102 Version 1.1

i. Push: Telephone calls from the mobile network – PUSH: the

mobile network operator provides the geographical coordinates

(X, Y) of the antenna that handles the call, and an area that

delimits the actual position of the caller.

ii. Pull: Telephone calls from the PSTN – PULL: Location is

obtained through ANI/ALI tables from the CMT (Comisión del

Mercado de las Telecomunicaciones).

c. The PSAP disposes information on the position of the caller during the

first 15 seconds from the reception of the call. Location information is

available in 1.5 seconds, in average.

d. Accuracy of the localisation within mobile phone network is some

hundred meter in urban environments to some kilometres in rural

environments.

Table 7: PSAP – Spain CAT 112 Catalunya

6.1.6.3 PSAP Systems Castilla y León

Q Report


services



territory is currently 0

Number of PSAPs receiving the eCall messages after the Europe-wide

eCall (2014) system is launched: If it is agreed to extend the architecture

within HeERO2 framework, it will consist of an intermediate PSAP and

19 centres 112 to which eCall (previously filtered) will be forwarded

(1+19)


a. The PSAPs are designed for receiving the eCall messages (see 2b)


information support. The system used to handle emergency events is the

Telefónica Séneca platform. Other PSAPs across Spain use the same


103 Version 1.1

system, but not necessarily the same version, in some cases.



information support

c. Some of the ECC of the Police are equipped with software application

for processing the events and with information support


application for processing the events and with information support. It is a

similar system to Séneca platform, but for health emergencies.




i. The GIS contains data just from a regional level?


network (stops, bridges, exits, objects) - ESRI Shapefile SHP

iii. The GIS enables the identification of line topographic elements. It

consists of different layers on streets, roads, routes, rivers etc.

b. Some of the ECCs of Fire Brigades are equipped with geographic

information systems. The ECCs of Fire Brigades of Burgos and

Salamanca are equipped with a geographic information system,

integrated through the Bus system. Bus is an integration system based

on web services to communicate different entities involved in

emergencies handling. In the call letter, just coordinate’s data are

communicated, although the system is prepared to transmit images (it

could be a fixed photo of the incident localization plane).


Member State

c. Some of the ECCs of the Police are equipped with geographic

information system? Just the ECCs of the Police of Valladolid and some

other isolated cases are equipped with a geographic information system.

In general, Local Police does not count with GIS, apart from the Local

Police of Valladolid, since it shares its Control Centre with the National


104 Version 1.1

Police.


information systems

i. The GIS contains only data from a regional level


network (stops, bridges, exits, objects) - ESRI Shapefile SHP

iii. The GIS enables the identification of line topographic elements. It

consists of different layers on streets, roads, routes, rivers etc.





ii. to Policy YES


iv. Emergency Military Unit (UME) - It makes use of a Warnings

Terminal, as an integrated part of Séneca system, where all

information related to incidents is received by means of call

letters.


messages at regional level. Messages used in communication consist of

a unique XML model composed of different information segments.

Different combinations of information segments can give place to

different messages types.


referred to?

1. Fire Brigade YES

2. Police YES


c. Data communication is operated as two-way system (PSAP <-> ECC).

Once the incident/accident is registered, the system allows the exchange


105 Version 1.1

of two-way information.


a. The PSAP receives information within the GSM network on the position of

the caller whenever a 112 call is involved


technology of Push (information is received automatically)


first 15 seconds from the reception of the call. POSIC112 protocol

version 2. Based on the antenna localization and a probability sector

(made up of an external radius, an internal radius and a probability

percentage)

Table 8: PSAP – Spain Castilla y León

6.1.6.4 PSAP Systems Comunitat Valenciana

Q Report


services








(1+19)

3 1) Software application for the processing of information on events



information support. CoordCom system by Ericsson AB is an

emergencies management and communications integrated system. The

system integrates both communications by phone, radio, etc. and

incidents management, resources management, action


106 Version 1.1

planning/protocols, contacts lists, geographic information system, as well

as other communication means, both voice and data.

b. The Emergency Control Centres (ECC) of Fire Brigades are equipped


support. All the Emergency Control Centres (ECC) of Fire Brigades are

equipped with the CoordCom terminal of the “1·1·2 Comunitat

Valenciana” platform, including all its features.


processing the events and with information support. Currently the ECCs

of the Police are equipped with CoordCom terminal of the “1·1·2

Comunitat Valenciana” platform, with the indicated features, the

Complex Operations Centres of the Civil Guard, the Province

Headquarters of the Spanish National Police (CNP), the

Communications Headquarters of the CNP Attached Unit to the regional

Police and numerous local Polices. At this date, the number of integrated

Control Centres corresponding to the Police sector amounts to 90.


application for processing the events and with information support. The

ECCs of Emergency Medical Services are totally integrated in the “1·1·2

Comunitat Valenciana” system, making use of the same CoordCom

system described above. Moreover, all the emergency health calls are

performed through the unique phone number 112.



equipped with a geographical information system (GIS) at a regional

level. The motorway and road network is stored in a shape (ESRI)

format file that contains all the communication network (highways,

motorways, roads) supplied by the regional Public Authorities on

Infrastructures and Transport (Conselleria de Infraestructuras y

Transporte de la Generalitat). Moreover, the layers corresponding to the

ICV 1:10.000 vectorial series (shape format) with locations of bridges,

exits, and different types of geographical objects are also available.

Other cartographic source exists for the visualization and management

of interest points stored at a spatial database, with the information


107 Version 1.1

organized by categories and with associated metadata. The GIS does

not enable the identification of line topographic elements


systems. As aforementioned, all the ECCs of Fire Brigades are equipped

with the CoordCom terminal of the “1·1·2 Comunitat Valenciana”

platform, that also includes a GIS. The technical specification is the

same as in 5a.

i. The GIS contains data only on an regional level

ii. The GIS contains a detailed data on the motorway and road

network (stops, bridges, exits, objects)


elements

c. The ECCs of the Police are equipped with geographic information

systems. As aforementioned, many of the ECCs of the Police are

equipped with the CoordCom terminal of the “1·1·2 Comunitat

Valenciana” platform, that also includes a GIS. The technical

specification is the same as in 5a.





elements


information systems. As aforementioned, many of the ECCs of the

Police are equipped with the CoordCom terminal of the “1·1·2 Comunitat

Valenciana” platform, that also includes a GIS. The technical

specification is the same as in 5a.






108 Version 1.1

elements





ii. to Policy YES


iv. Other entities and agencies with an active role in emergencies

management: CEGESEV (Regional Centre for Road

Infrastructure Management), Adif, Ferrocarrils de la Generalitat,

Red Cross, Emergencies Military Unit, Maritime Rescue and

others. The interconnection is carried out at voice and data level,

by sharing a unique management and communications system.

b. Information about a definition of a uniform format of data communication

messages is not available. The data exchange format is system

proprietary, while different external interfaces for integration with third

party systems are defined.

c. Data communication is operated as Two-way system (PSAP <-> ECC)

and Multi-way system (PSAP <-> ECC <-> ECC). Two-way system with

star topology PSAP <-> ECC for incidents management and grid system

(multi-way system) in the cooperation/coordination between all the

agencies that participate in a same service.





technology of Push (mobile network) and Pull (fixed network).

Mobile calls localization: (PUSH) the network operator sends the

information to the 112 PSAP via TCP/IP at the call moment.

Fixed calls localization: (PULL) a search on the ANI/ALI local database

with the caller phone number is performed.


109 Version 1.1

c. The accuracy of the localisation is determined by the size of the

corresponding network operators’ cells, as well as by the technical

parameters used by these for the position calculation. According to the

POSIC112 protocol, the following data are provided:

Uncertainty radius

Offset angle

Opening angle

Origin: sector origin point (UTM coordinates)

Probability

Table 9: PSAP – Spain Comunitat Valenciana

6.1.6.5 PSAP Systems Galicia

Q Report


services




Number of PSAPs receiving the eCall messages after the Europe-wide eCall (2014)

system is launched: If it is agreed to extend the architecture within HeERO2 framework,

it will consist of an intermediate PSAP and 19 centres 112 to which eCall (previously

filtered) will be forwarded (1+19)


a. The PSAPs designed for receiving the eCall messages (see 2b) are not


information support

b. Information about the Emergency Control Centres (ECC) of Fire

Brigades equipment with software application for processing the events

and with information support is not available.

c. Information about the ECC of the Police equipment with software

application for processing the events and with information support is not


110 Version 1.1

available.

d. Information about the ECC of Emergency Medical Service equipment


support is not available.



equipped with a geographical information systems (GIS) containing data

on a regional level.


network (stops, bridges, exits, objects) SmartStore of GeoMedia

ii. The GIS does not enable the identification of line topographic

elements

b. Information about the ECCs of Fire Brigades equipment with geographic

information system is not available

c. Information about the ECCs of Police equipment with geographic

information system is not available

d. Information about the ECCs of Emergency Medical Service equipment

with geographic information system is not available





ii. to Policy YES

iii. to Emergency Medical Service NO

iv. Web application based on Web services YES


messages

i. Data communication is operated as Two-way system (PSAP <->

ECC). The system allows the exchange of information on

emergencies in real-time. The information runs from the PSAP to


111 Version 1.1

the external entities and from those towards the PSAP.

Information is received in the form of notations, messages,

images and documents. From the technical point of view, it

consists of a web development based on web services; the

information runs in a ciphered way and access to the system is

performed by means of digital certificates.





technology of Push


first 15 seconds from the reception of the call.

d. The accuracy of the localisation within mobile phone network: In urban

areas, the radio range accuracy is between 100 and 300m; in rural

areas, it is from 500m to 10km. For calls originated from mobile

networks, the POSIC112 v2 protocol is used, that is utilized to send,

from the mobile network operator to the PSAPs, information on the

position of the mobile terminal that is making the 112 call. It is applied to

all calls, including those of international or national roaming services.

The positioning information complies with the structures defined in the

document ETSI TS 101.109 V7.1.0. Universal Geographical Area

Description (GAD) 9. The “sector with uncertainty” (Ellipsoid ARC)

(circular sector) is used together with the probability that the mobile

terminal finds inside of it. UTM coordinates, instead of geodesic ones,

are used.

Table 10: PSAP – Spain Galicia

6.1.6.6 PSAP Systems Madrid

Q Report

1 The operation of commercial eCall service is provided by insurance companies.




112 Version 1.1

territory is Currently 0





(1+19)

Moreover, in compliance with the normative, the 112 PSAPs will directly

receive all the 112 voice (with associated data or not) calls processed at

citizen’s will.




information support? It is a customised application.



support. They have the application of the PSAP and an information

exchange bridge with their application.


processing the events and with information support. They have the

application of the PSAP and, in some cases, an information exchange

bridge with their application.


application for processing the events and with information support. They

have the application of the PSAP and, in some cases, an information

exchange bridge with their application.



equipped with a geographical information system (GIS). The GIS

contains data only on a regional level.



b. Information about the ECCs of Fire Brigades equipment with geographic


113 Version 1.1

information system is not available.

c. Information about the ECCs of the Police equipment with geographic

information system is not available.

d. Information about the ECCs of Emergency Medical Service equipment

with geographic information system is not available.





ii. to Policy YES


iv. other – please specify: _______________________________

An information exchange bridge with their application exists.


messages at regional level.

i. Units of the emergency system using the format referred:

1. Fire Brigade YES

2. Police YES


c. Data communication is operated as Two-way system (PSAP <-> ECC).

Once the information from an entity is received, the PSAP transmits it to

the rest of entities cooperating in the incident.





technology of Push.


first 15 seconds from the reception of the call.


114 Version 1.1


depending on if it is in urban or rural areas. It depends on the MNO

network deployment.

Table 11: PSAP – Spain Madrid

6.1.7 Turkey PSAP report

Q Report


services


a. Number of PSAPs receiving the 112 Call on the Member State’s territory

There are 81 provinces in Turkey. According to the national regulations,

each province has its own PSAP. Antalya and Isparta were the pilots of

“Turkish 112 Single Emergency Number Project”. All of the emergency

agencies are working together at the same PSAP location, by using the

same 112 infrastructure. New system is deployed in 10 more cities this

year, and it will be deployed nationwide. Those systems are designed

by ASELSAN. It is planned to implement new 112 system in about 15

provinces each year.


eCall (2014) system is launched: 1, in Antalya (the exact decision will be

taken by the Ministry of Interior, according to the HeERO-2 results)

Antalya was also the pilot for the 112 Single Number Project. As a result

of that project, Antalya PSAP personnel are experienced in new 112 pilot

projects. We should also mention that the Turkish eCall system is going

to be a separate eCall test system. According to the results of the eCall

project, the exact decision about the Number of e-call PSAPs will be

taken by the Ministry of Interior.




information support


115 Version 1.1



support





Antalya PSAP is explained in the document related to the D2.1, with its details.

In Antalya, ECC operators are able to use the;

1. Call Taker

2. Call Dispatcher

3. AVL and GIS

4. System Management and Diagnostics

5. Voice Recording

software, in accordance with their roles in the PSAP.




(Note: e-call PSAP is going to be at the same physical place (call centre)

with ordinary 112 PSAP system. But, it is going have a completely

separate and different infrastructure.)


systems




c. The ECCs of the Police is equipped with geographic information systems





116 Version 1.1

d. The ECCs of Emergency Medical Service is equipped with geographic

information systems






emergency units (Fire Brigade, Police, and Emergency Medical Service

(Note: Antalya PSAP is a common PSAP for all of the emergency

associations. So, they are working together at the same infrastructure.

There is no other ECCs in Antalya. All of the emergency associations

are working together at the same PSAP.)

Antalya PSAP is explained in the document related to the D2.1, with its

details.





technology of Pull.



d. Accuracy of the localisation within mobile phone network: In city: 2km2;

In county: 10km2. GSM operators provide information about: Latitude,

longitude, inner Radius, outer Radius, start angle, stop angle. In the

sample drawing below, the coordinates of the point O are the latitude

and the longitude information of the MNO’s base station point. [OA] =

inner Radius, [OB] = outer Radius, COB angle: start angle, COD angle:

stop angle. These parameters tell that the exact position is in the

shaded region.

Table 12: PSAP – Turkey


117 Version 1.1

6.1.8 Greece PSAP report

Q Report


services



territory: 1






information support



information support

c. The ECC of the Police are not equipped with software application for


d. The ECC of Emergency Medical Service are not equipped with software




equipped with a geographical information system (GIS

b. The ECCs of Fire Brigades are not equipped with geographic information

system


system





118 Version 1.1




messages





technology of Pull


first 15 seconds from the reception of the call


according to Cell ID. It depends on Cell operator antenna position.

Table 13: PSAP – Greece

6.2 Mobile network operators MNO


Part 1. General information on Mobile Network Operator

1. Company name

2. Country

3. Role in HeERO2 project

Part 2. Analysis of existing telecommunication infrastructure

General information on mobile network

1. Mobile network generation which will be utilized in pilot:

2G

3G

Both

Other (please explain)

2. Number of MSC/MSS which will be utilized in pilot?


119 Version 1.1

3. Equipment manufacturer?

4. MSC/MSS – Please define hardware, software, adaptations and customizations

specifications?

5. Is MSC stand-alone or co-located? If it is co-located please describe.

6. Existing 112 emergency system calls support?

7. Support of routing emergency calls to PSAP?

8. Current status of eCall support in network?

9. Roaming support for 112 calls?

10. Availability of test plant (Test network)?

11. Test network coverage?

12. Test network hardware and software specifications?

Part 3. Identification of hardware and software needs*

Please answer if the information is available

1. Is existing hardware which will be utilized in eCall pilot compatible with available eCall

standard requirements?

2. Is existing software compatible with available eCall standard requirements?

3. Availability of required modification/upgrade components?

* list of current version of eCall standards is provided in Annex1 of this document

Part 4. Identification of required modification on existing infrastructure*

1. Definition of modification process (if needed)

2. Identification of hardware upgrades process? (if needed)

3. Identification of software upgrades process? (if needed)

4. Testing off new equipment/releases? (if needed)

5. Definition of estimated time frame for upgrades/modifications? (if needed)

6. Identification of the best practices for modifications and upgrades. (if needed)

7. If alternatives regarding hardware and software upgrades are available, describe. (if

needed)

* if live network differs from test network, please provide answers for both cases.


120 Version 1.1

Part 5. Implementation plan

1. Implementation steps for enabling eCall (according to standards in Annex 1) on Test

plant?

2. Estimation of required time period for setting up eCall (according to standards in

Annex 1) on test plant?

3. Estimation of required time period required for testing?

4. Differences between test plants and live network?

5. Ability of test plant to route eCalls to PSAP?

6. Estimated time required for implementation of eCall on live network after being

successfully tested in test plant?

7. Availability of test SIM cards (voice and data) for domestic and roaming use? (both

for test and live network if different)

Part 7. Prerequisites and assumptions

Please state any prerequisites or restrictions which might be related to eCall pilot activities.

6.2.2 Belgium MNO report

Q Report

1 General information on Mobile Network Operator

1. Mobistar nv/sa

2. Belgium

3. Business Development & eCall

2 Analysis of existing telecommunication infrastructure



2G and 3G

2. Number of MSC/MSS which will be utilized in pilot? Answer: 1 MSC will be

applied for the pilot.

3. Equipment manufacturer? Answer: Equipment vendor is Huawei



121 Version 1.1

specifications? Answer: To be defined in function of software roadmap CS9.2/10

approval.

5. Is MSC stand-alone or co-located? If it is co-located please describe. Answer:

stand-alone

6. Existing 112 emergency system calls support? Answer: Yes, existing 112 calls

(not eCall) currently are handled as “100” call.

7. Support of routing emergency calls to PSAP? Answer: No, software upgrade is

required.

8. Current status of eCall support in network? Answer: Upgrade and testing

currently rescheduled to Q4

9. Roaming support for 112 calls? Answer: Roaming in users can dial 112 as any

local Mobistar user. Same routing to existing 112 (100) destinations. When

eCall will be possible, this should also apply for roaming in users.

10. Availability of test plant (Test network)? Answer: Yes, testing is scheduled Q3

2013.

11. Test network coverage? Answer: Yes, testing is scheduled Q3 2013

12. Test network hardware and software specifications? Answer: Yes, testing is

scheduled Q3 2013. The internal tests will be performed on release CS9.2

3 Identification of hardware and software needs*

1. Is existing hardware which will be utilized in eCall pilot compatible with available

eCall standard requirements? Answer: no hardware modification or upgrade will

be needed to support eCall. Question: Could you provide the list of current

version of eCall standards that is provided in Annex1 of this document”?


Answer: No, software upgrade required.

5. Availability of required modification/upgrade components? Answer: No,

software upgrade required.

4 Identification of required modification on existing infrastructure*




122 Version 1.1





7. If alternatives regarding hardware and software upgrades are available,

describe. (if needed).

5 Implementation plan

1. Implementation steps for enabling eCall (according to standards in Annex 1) on

Test plant? Answer: Will be defined in a later phase.


Annex 1) on test plant? Answer: Will be defined in a later phase.

3. Estimation of required time period required for testing? Answer: Will be defined

in a later phase.

4. Differences between test plants and live network? Answer: Key difference is real

coverage outdoor on live network vs. local simulated LAB coverage.

5. Ability of test plant to route eCalls to PSAP? Answer: Will be defined in a later

phase.

6 Prerequisites and assumptions

Please state any prerequisites or restrictions, which might be related to eCall pilot

activities.

Answer: The pilot will be restricted to a demo in lab environment (faraday cage).

Table 14: MNO – Belgium

6.2.3 Bulgaria MNO report

Q Report

1 General information on MNO

1. Company name - Mobiltel EAD

2. Country - Bulgaria

3. Role in HeERO2 project - Major partner in the local test pilot


123 Version 1.1




· Both 2G and 3G - Both will be used

2. Number of MSC/MSS which will be utilized in pilot? - All 5 of them

3. Equipment manufacturer? - Ericsson


specifications? - SW R13.2, HW APZ21250/21260

5. Is MSC stand-alone or co-located? If it is co-located please describe. - Stand-

alone in Mobiltel facility, PSAP connected to MSCs via E1s

6. Existing 112 emergency system calls support? - Yes

7. Support of routing emergency calls to PSAP? - Yes

8. Current status of eCall support in network? - No such, eCall flag not

implemented; initially in the tests eCall-calls to be recognized via routing of the

test-number calls to dedicated time-slots

9. Roaming support for 112 calls? - Yes

10. Availability of test plant (Test network)? - Tests will be run on live operational

network

11. Test network coverage? - Sofia district first, than national reach

12. Test network hardware and software specifications? - Same as live, no separate

test network to be built

3 . Identification of hardware and software needs*


eCall standard requirements? - Yes

2. Is existing software compatible with available eCall standard requirements? -

Currently no. With expected upgrade of MSC in 2013 - yes

3. Availability of required modification/upgrade components? - Yes, in Q3 or Q4 of

2013

4 Part 4. Identification of required modification on existing infrastructure*


124 Version 1.1

1. Definition of modification process (if needed) - Software upgrade of MSC (re-

conf. of interconnect E1 lines from Mobiltel to PSAP centre, for the purposes of

the pilot)

2. Identification of hardware upgrades process? (if needed) - n.a.

3. Identification of software upgrades process? (if needed) - (standard operation)

4. Testing off new equipment/releases? (if needed) - (standard operation)

5. Definition of estimated time frame for upgrades/modifications? (if needed) -

Within 2 weeks



describe. (if needed) - No such regarded



Test plant? - Software upgrade of MSC, re-conf. of interconnect E1 lines from

Mobiltel to PSAP centre


Annex 1) on test plant? - Within 1 month in Q4/2013

3. Estimation of required time period required for testing? - Within the

implementation 1 month in Q4/2013

4. Differences between test plants and live network? - No such, tests from the start

will use the live network

5. Ability of test plant to route eCalls to PSAP? - Yes


successfully tested in test plant? - Deployment within 1 month at most

7. Availability of test SIM cards (voice and data) for domestic and roaming use?

(both for test and live network if different) - Specific test SIMs profiles - not in

scope of the pilot for Mobiltel


Please state any prerequisites or restrictions which might be related to eCall pilot

activities - No any, besides the timeframe - MSC upgrade in Q4/2013


125 Version 1.1

Table 15: MNO – Bulgaria

6.2.4 Denmark MNO report

Q Report

1

2

3

4

5

6

7

Table 16: MNO – Denmark

6.2.5 Luxembourg MNO report

Q Report

1

2

3

4

5

6

7

Table 17: MNO – Luxembourg

6.2.6 Spain MNO report

Q Report


1. Company name: TELEFÓNICA ESPAÑA


126 Version 1.1

2. Country: SPAIN

3. Role in HeERO2 project: participant in HeERO2 Spanish consortium




Both 2G and 3G

2. Number of MSC/MSS which will be utilized in pilot?

a. Only the MSC operating on the geographical area involved in pilot

(Galicia, Castilla y León, Madrid and Comunidad Valenciana). It

represents about 30% of total Spanish area and about 36% of total

Spanish population.

b. Nevertheless, the solution will be deployed over every MSC / MSS of

Telefónica network.

3. Equipment manufacturer?

a. Ericsson


specifications?

a. The network is based in AXE System from Ericsson. The actual release

is R13.2.


a. Unknown

6. Existing 112 emergency system calls support?

a. Telefónica network actually supports the 112 emergency number calls.

7. Support of routing emergency calls to PSAP?

a. Telefónica network actually supports the routing of 112 emergency calls

from the caller to the geographical PSAP that must respond to the call.

In Spain there are 19 PSAPs, directly related with geographical regions.

8. Current status of eCall support in network?

a. Actually, there is no support for eCall in network.


127 Version 1.1

9. Roaming support for 112 calls?

a. Currently, Telefonica’s network supports 112 calls from national and

international roamers.

10. Availability of test plant (Test network)?

a. Currently, Telefónica uses a test laboratory where every hardware or

software new version, adaptation, etc. is proved before its deployment in

the live network. But there is no a formal test network.

11. Test network coverage?

a. The coverage of Telefonica’s laboratory is very limited and restricted

mainly to a little area inside the laboratory building.

12. Test network hardware and software specifications?

Telefónica labs supports the live network hardware and software specifications

3 Identification of hardware and software needs


eCall standard requirements?

a. The actual hardware network infrastructure could support the managing

and routing of emergency eCalls, but it will need a change in network

software.


a. The actual software network infrastructure could support the managing

and routing of emergency eCalls, but it will need a modification to work

properly.

3. Availability of required modification/upgrade components?

a. The actual network software provider (Ericsson) doesn`t have the

modification needed in the actual network software version. It will have

to be developed specifically for this version of network software.



a. The modification in network software consist in the availability for read

the double bits eCall discrimination flag and in the availability for use this


128 Version 1.1

information for modifying the routing process of any mobile phone call

and for modifying the prioritisation network rules for this type of call.

b. Once deployed in Telefónica network the software modification defined,

it will be necessary to modify the 112 calls routing: if the 112 call comes

from an eCall device, it will be routed to DGT PSAP intermediate; if not,

it will be routed to the geographical PSAP (the actual routing).


a. There is no need of hardware upgrades.


a. The required software update will be defined by the actual network

software provider, Ericsson.


a. It will be necessary to test this software modification in Telefonica’s

laboratory, previously to its deployment in the real network.


a. This time will be defined for the actual network software provider,

Ericsson.


a. These best practices will be defined for the actual network software

provider, Ericsson.


describe. (if needed)

a. There is no alternative for this software upgrade because the actual

network software version doesn’t read the double bits eCall

discrimination flag and, so, it can’t use this information for properly

rerouting the eCall.



Test plant?

a. Once the network software modification is available for its deployment, it


129 Version 1.1

will be deploy in Telefonica’s laboratory for the final test and its validation

from a functional and operational point of view.


Annex 1) on test plant?

b. Once the network software modification is available for its deployment, it

will take some weeks to deploy it in Telefonica’s laboratory. It’s no

defined the number of weeks required.

3. Estimation of required time period required for testing?

c. It’s not defined the amount of time required for testing.

4. Differences between test plants and live network?

d. There’s no test plant in Telefónica. The hardware and software existing

in Telefonica’s laboratory is the same that the one existing in real

network

5. Ability of test plant to route eCalls to PSAP?

a. Telefonica’s laboratory can’t route eCalls. to any PSAP The tests that

will be done in Telefonica’s laboratory, only test the right eCall ability for

routing mobile phone calls using the value of the double bits eCall

discrimination flag.


successfully tested in test plant?

e. There’s no estimated time defined. It would depend on the general

software deployment schedule. The software modification for eCall

project will be included on the next software deployment, once the

software modification is tested and validated from laboratory experts.


(both for test and live network if different)

f. Telefónica doesn’t provide test SIM cards for domestic and roaming use.




130 Version 1.1

activities.

The fact of answering this Questionnaire does NOT imply that Telefónica assumes the

development and deployment of eCall service over its live mobile network.

The information given in this Questionnaire is only a draft / a first approach about the

tasks that must be done when eCall service was required to all Spanish MNOs.

The development and deployment of the software changes needed in live mobile

network in order to implement eCall service will be done when it is required to all

Spanish MNOs by the Spanish Government over a formal and legal procedure.

Table 18: MNO – Spain

6.2.7 Turkey MNO report

Q Report


1. Company name TURKCELL

2. Country TURKEY

3. Role in HeERO2 project Mobile Network Operator




Both 2G and 3G

2. Number of MSC/MSS which will be utilized in pilot? 1 production MSC-S + 1 test

MSC-S will be utilized in pilot

3. Equipment manufacturer? Ericsson


specifications? R.14.1 E-Call Specific Adaptation will be done on MSC-S SW,

add to this our emergency IN platform called Location Based Call Router will be

modified on SW level.

5. Is MSC stand-alone or co-located? If it is co-located please describe. This MSC-

S will be one of the MSC-S in one of our MSC-S pool. While giving special

commands test cards will be forced to take service from the above mentioned


131 Version 1.1

MSC-S.

6. Existing 112 emergency system calls support? Yes, There will be some

changes done on our emergency 112 system to support E-Call.

7. Support of routing emergency calls to PSAP? Yes, Turkcell will redirect the calls

via landline carrier Turk Telekom to PSAP.

8. Current status of eCall support in network? Currently, there is no support for E-

Call, after the upgrade on MSC-S E-Call will be supported.

9. Roaming support for 112 calls? Yes it is supported

10. Availability of test plant (Test network)? There will be dedicated MSC Server

and Media GW for this test on our test network

11. Test network coverage? Due to CDR related issues and regulations test

network has a limited coverage, but the coverage is planned to be extended to

cover our partners test Labs.

12. Test network hardware and software specifications? Ericsson R.14.1 MSC-S

and Ericsson MGWs R.6.3



eCall standard requirements? Yes, there will be no HW additions.

2. Is existing software compatible with available eCall standard requirements? No,

there will be some changes made on the current SW level.

Availability of required modification/upgrade components? There was a working trial on

TIM Italy network. Probably the same market corrections will be implemented on

Turkcell network.


1. Definition of modification process (if needed) Called Party Number, IN tables,

switch software will be modified.

2. Identification of hardware upgrades process? (if needed) No upgrades on HW

3. Identification of software upgrades process? (if needed) A new Market

Correction will be implemented on the test network however; this market

correction could be modified in order to support Turkcell specific software.


132 Version 1.1

4. Testing off new equipment/releases? (if needed) Only the new software will be

tested.

5. Definition of estimated time frame for upgrades/modifications? (if needed) This

modification process could take up to 5 months.


TIM Italy have a best practice for this upgrade. Our plan is to use the same SW.


describe. (if needed) Also there could be change on our Location Based Call

Router platform.



Test plant?

a. Acquisition of the implementation procedure from vendor.

b. Implementation on test network

c. Called Party Number (B#) analysis and modification

d. Disabling echo cancellation.

e. Receiving service from test base station and trying to perform test call.


Annex 1) on test plant? It most probably depends on the retrieval of the

correction from the vendor. In two- weeks this process could be done. However

there is a risk of malfunctions of market development. During development and

field tests Turk Telekom should also perform routings from Turkcell to PSAP.

3. Estimation of required time period required for testing? After the completion of

implementation testing could be done in three months. It also depends on the

readiness of the remote ends (e.g. Call centre and car manufacturer, PSTN

operator)

4. Differences between test plants and live network? The number series could be

different; some network specific market corrections could interfere with the new

E-Call correction. If more than one Call Centre will be used than there will be a

change on our LBCR platform

5. Ability of test plant to route eCalls to PSAP? After implementation of new SW,


133 Version 1.1

the MSC-S could route the eCalls to PSAP via PSTN (Turk Telekom). Automatic

and manual initiated eCalls can be differentiated with the ability of MSC-S new

SW. Routing is differentiated with called party number on PSTN side. So there

will be different called party numbers for manual/automatic eCalls. Afterwards

Turkcell and Turk Telekom will perform routings according to the new called

party numbers


successfully tested in test plant? For pilot only one MSC-S is planned to use the

E-Call. In only one week this implementation can be done. If spreading on the

entire network is needed after the completion of E-Call, this rollout can be done

within 2 months.


(both for test and live network if different) Existing test SIM cards will be used.



activities.

First acquisition of IVS device is needed. Also readiness of the call centre side could be

a prerequisite for end to end testing. If the MSC-S correction is not working properly

there could be some modifications done on MSC-S SW side this could lead a delay on

project schedule for 5-6 months.

Table 19: MNO – Turkey

6.2.8 Greece MNO report

Q Report


1. Company name: COSMOTE, VODAFONE, WIND

2. Country: GREECE

3. Role in HeERO2 project: The participation of the MNOs in the HeERO pilot is

not defined, since there is no consortium constructed, that would include at least

one of them.


134 Version 1.1




a. Both 2G and 3G

2. Number of MSC/MSS which will be utilized in pilot? Not confirmed yet.

3. Equipment manufacturer? Nokia Siemens, Ericsson

4. MSC/MSS – Please define hardware, software, adaptations and

customizations specifications? N/A yet.


Unknown

6. Existing 112 emergency system calls support? YES

7. Support of routing emergency calls to PSAP? YES

8. Current status of eCall support in network? Not supported

9. Roaming support for 112 calls? YES

10. Availability of test plant (Test network)? Not confirmed yet.

11. Test network coverage? N/A yet.

12. Test network hardware and software specifications? N/A yet.



eCall standard requirements? N/A


Unknown

3. Availability of required modification/upgrade components? YES



a) S/W upgrade for eCall flag support

b) eCall routing on PSTN

2. Identification of hardware upgrades process? (if needed) Unknown


135 Version 1.1

3. Identification of software upgrades process? (if needed) S/W patch or new

S/W

4. Testing off new equipment/releases? (if needed) NO


In principle the MNOs have accepted to modify and upgrade their H/W and S/W

according to the time plan described at the EC’s recommendations under the

condition that they receive financial support



describe. (if needed) N/A



Test plant? N/A


Annex 1) on test plant? N/A

3. Estimation of required time period required for testing? Unknown

4. Differences between test plants and live network? Unknown

5. Ability of test plant to route eCalls to PSAP? N/A


successfully tested in test plant? Unknown


(both for test and live network if different) YES



activities.

Table 20: MNO – Greece

6.3 In-Vehicle System (IVS)


Part 1 - General information In Vehicle System


136 Version 1.1

1. Company name

2. Country

3. Role in HeERO2 project

Part 2 - Analysis of existing IVS

b) System description

c) Functions supported

d) Equipment specifics

Part 3 - Identification of HW and SW needs

a) Will existing HW be used and is it compatible with available eCall requirements

b) Will existing SW be used and is it compatible with available eCall requirements

c) Number of units

Part 4 - Identification of required modification on existing IVS

a) Definition of modification process

b) Identification of HW changes or basic development

c) Identification of SW changes or basic development

d) Identification of test need for updated/new IVS

Part 5 - Implementation plan

Identification of implementation steps for enabling the HeERO2 IVS functionality

Part 6 - Prerequisites and assumptions

Please state any prerequisites or restrictions which might be related to eCall pilot activities.


137 Version 1.1

6.3.2 Belgium IVS report

6.3.2.1 NXP

Q Report

1 General information In Vehicle System

1. Company name: NV. NXP Semiconductors Belgium

2. Country Belgium

3. Role in HeERO2 project: System know how, supplier of in car solution

2 Analysis of existing IVS

a) System description: ATOP based eCall unit e112 –Stand alone after market unit

with alarm button

See http://www.nxp.com/news/meet-nxp/shows-and-events/eCall/eCall3.html

b) Functions supported : Full E112 and in car services

c) Equipment specifics: Aftermarket self-install unit

3 Identification of HW and SW needs


Potentially, we are also looking to a current new development


Yes

c) Number of units: 5

4 Identification of required modification on existing IVS


Uploading releases of new software into existing unit via existing mechanisms


Attention point might be Audio quality and external interface towards car (Via USB?)


Upload of last releases inside ATOP


138 Version 1.1


Continuous tests done towards OECON server


a) Identification of implementation steps for enabling the HeERO2 IVS functionality

Integration of HLAP into ATOP –full deliverable planned July 2013

Partly deliverable with existing status available for testing by March 2012



activities.

Assumption is that E112 is only activated via Alarm button functionality

Table 21: IVS – Belgium NXP

6.3.3 Bulgaria IVS report

6.3.3.1 ICOM Ltd.

Q Report


1. Company name: ICOM Ltd.

2. Country: Bulgaria

3. Role in HeERO2 project: IVS supplier for retrofit devices, R&D for creating of

low-cost IVS for retrofit installation in used vehicles


a) System description

Icom’s own emergency and crash alerting service is operational throughout Bulgaria

since February 2012. The system called “EuroGPS CrashAlert” is based on Icom’s on-

board units EuroGPS SmartTracker ALM-3A, equipped with crash sensors, gyro- and

accelerometers-based inertial system, speaker, microphone, and an emergency button

for manual emergency call initiation. The service is available as a managed value-

added service to all users of our fleet management systems (about 20,000 units

installed in Bulgaria) for passenger cars and LCV’s and is operated by our own


139 Version 1.1

proprietary Control Centre via instant alerting with vehicle and crash-related data and

automatic or manual initiation of regular cellular voice calls with the control centre

personnel.

The IVS used in HeERO2 is an adjusted version of our main fleet management module

EuroGPS SmartTracker ALM-3A, with modifications to comply with the eCall

requirements.

b) Functions supported

Icom’s main OBU – EuroGPS SmartTracker ALM-3A - which is the basis for the eCall

ISV unit, supports several GPS chip models from different manufacturers with 50 to 65

satellite channels and both GPS and GLONASS compatibility. Several different GSM

data modems are available in different modification (dual- and quad-band) and a

functional prototype with in-band data modem is available.

EuroGPS SmartTracker ALM-3A is a highly customizable GPS OBU with OTA setup,

remote diagnostics and firmware updates remote service additions, service

activation/deactivation, remote operational parameter control and settings and allows

connection to external devices, touch screen LCD displays, for two-way communication

with the driver, navigation, multimedia applications, etc.

It works with Icom’s own telematics service platform – EuroGPS eVehicle - enabling a

number of specific commercial fleet management solutions as well as UBI, B-Call and

road user charging scenarios.

c) Equipment specifics

The IVS collects PVT data (position, velocity, time) in real time (every 1 second) as well

as data for direction on road, engine status, fuel level, and other readings from

optionally connected sensors (like doors, gates, engine speed in RPM’s, temperature in

refrigerated cargo sections or the cabin, panic buttons, RFID readers, low battery when

disconnected from vehicle, actual fuel quantity (when appropriate fuel sensor is

installed, or a connection to a non-defective standard vehicle fuel sensor is made),

number of passengers in vehicle (when appropriate sensor installed), and allows the

connection of multiple additional sensors or devices like flow-meters, fuel sensors,

temperature and pressure sensors, security devices, etc.

Further the device has built-in CAN bus interface controller and features a proprietary

CAN expansion network, allowing both functional and interface expansion and

multiplication and multiple CAN connections.


140 Version 1.1

Inertial data can be collected and processed at 1ms intervals to ensure proper incident

detection.

As Bulgaria does not have a strong OEM auto manufacturing industry and the current

passenger car park is one of the oldest in Europe, the IVS unit is targeted at the retrofit

market with a focus to lows-cost yet fully functional and eCall compliant IVS.



As already mentioned the eCall ISV unit, which will be used during HeERO2 is based

on Icom’s main OBU – EuroGPS SmartTracker ALM-3A.

A functional prototype implementing an in-band modem is available. Compliance to

finalized certification guidelines is going to be achieved by minor modifications.


The existing firmware of EuroGPS SmartTracker ALM-3A will be largely used. Certain

modifications will be required to achieve compliance to certification guidelines.

c) Number of units

Currently more than 20,000 units are in the field in Bulgaria in active systems. All new

hardware produced for commercial fleet management and other consumer telematics

scenarios are going to include eCall functionality after the eCall ISV (which is available

as prototype at this stage) is fully productized, tested, and ready for certification.



Minor modifications are going to be done iteratively following the implementation plan of

HeERO2, and based on actual results in different test scenarios.


No major new development is envisaged as most of the hardware components in the

prototype ISV are compatible with European eCall. The GPS module with in-band

modem is already implemented as a prototype version, minor changes might be

necessary before readiness for mass production. The unit casing and the voice

subsystem will be modified to meet all the eCall requirements for reliability of triggering


141 Version 1.1

following through eCalls in different scenarios (automatic and manual)


The unit firmware is very flexible, extendable, with more than 2000 settable parameters

and with full integration with our own telematics platform, which supports apart from

basic eCall functionality a number of telematics scenarios for both consumer and

corporate environments, and services for the public and private sectors (commercial

fleet management in a number of specialized industries, UBI, road user charging, mass

transit management and control, etc.)

No major SW changes are envisaged, just minor modification to achieve full

compliance to finalized standards requirements.


Extensive testing is planned within the pilot with equipping of 10 vehicles and testing

many different scenarios in various GSM coverage conditions and different ways of

triggering the eCall (manual, simulated, automatic, etc.



Icom will provide the eCall telematics devices for retrofit installation in passenger cars

and LCV’s, implementing the eCall in-band modem standardized by ETSI in our own

OBUs (on-board units), and prepare all necessary documentation.

This will be done through modification of our existing OBU’s for emergency and crash

alerting to achieve compliance to all relevant auto-motive standards and still be

available as retrofit devices.

The provided OBU’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




142 Version 1.1

activities.

Basic assumption for completing of all necessary changes to both HW and SW

elements is the availability of finalized guidelines for certification of eCall IVS for retrofit

installation within the project time frame.

Table 22: IVS – Bulgaria ICOM

6.3.3.2 Technical University of Sofia

Q Report

1 Company: Technical University of Sofia

Country: Bulgaria

Role in HeERO2 project: Participant in Bulgarian Subproject

2 System description: eCall IVS module

Functions supported: eCall, additional functions in development

Equipment specifics: Unit with external GSM/GPS antenna, offering manual and automatic

eCall trigger options. Requires external power supply connection.

3 Existing eCall modem used. Assumed to be fully eCall compliant according to

manufacturer reference.

Existing SW will be compatible. eCall flag implementation in progress

Number of units: One prototype ready. Two release candidate units pending production.

Additional units could be provided upon request (lead time to be confirmed).

4 Identification of SW or HW modifications: No SW or HW modifications are planned to the

moment.

Identification of test need for updated/new IVS: overall eCall compliance test, when RC

units and PSAP server become available, eCall flag implementation

5 It is assumed the HeERO2 requirements are similar to existing eCall standards, so no

additional steps are required based on current solution.

6 As a prerequisite we anticipate the IVS to be temporarily installed in vehicles for performing

different test scenarios, using external antennae provided with an IVS installation kit.


143 Version 1.1

112 might be used at a later point in time; in the beginning a normal, pre-defined landline

number will be called.

Identification of the IVS will be based on the MSISDN or the VIN number.

The SIM is assumed to be an exchangeable standard SIM card.

Table 23: IVS – Bulgaria Technical University of Sofia

6.3.4 Denmark IVS report

6.3.4.1 FICOSA

Q Report


1. Company name : FICOSA

2. Country DENMARK

3. Role in HeERO2 project IVS supplier



Ficosa has developed a smart and compact communication platform to satisfy the

increasing demand of telematic services in the vehicular, whether the issue is

connecting vehicles to each other (Car2Car or C2C for short) or to the infrastructure

(Car2Infrastructure or C2I) . The TCU – Telematic Control Unit – platform

comprises compact and cost effective solutions to enable safety and infotainment

applications in the vehicle. Furthermore, the TCU product family is designed to

minimize the installation costs and maximize system robustness in case of accident

and external manipulation. The TCU is state-of-the-art OBU (on board unit).

Ficosa’s Telematic Control Unit system includes integrated antennas based on

fractal technology. Telematic modules allow internal and external communications

within the vehicle integrating various telecommunication technologies, such as

mobile telephony, CAN bus, and positioning systems, in a single unit.


Enabled by current technology and capable to integrate new ones to support

future telematic services.

Cost effective and compact electronic design.

Optimal design and performance of integrated antennas.


144 Version 1.1

Easy installation, only one connector to the vehicle.

System robustness in case of accident and external manipulation thanks to

integrated antennas in the same module.

Automotive conformance.


TCU eCall for Emergency Services - eCall 112 -

The TCU eCall has been specifically designed to support driving

assistance and emergency services. Additionally, the TCU eCall

complies with the European Commission directives on eCall. FICOSA

participates in several European initiatives on the field of vehicular safety

and communications and has signed the Memorandum of Understanding

of eCall.


The TCU Anti-Theft is presents an optimal design to enable location and

immobilization of stolen vehicles. Furthermore, it is adjusted to comply

with international and national regulations, such as the Brazilian

legislation (from the DENATRAN).


Remote Diagnosis

Remote setting

Fleet Management

Pay As You Drive

Car Sharing

c) Equipment specifics:

Operating Temperature -40ºC to 85ºC

Power Supply 6.5V to 16V

Current consumption: Avg transmitting 250mA, 2A peak.

Internal Battery

USB Device: USB 2.0 12 Mbps

2 CAN Interfaces: CAN 2.0b

Microphone Input

Microphone Output (Microphone Input bypass)

Speaker output

HU mute output

http://www.ficosa.com/Ficosa/WebPublica_EN/Productos/ListadoGrupoProductos/ProductosAC/ListadoGrupoProductosAC/Telematica/ListadoProductosTelematicos/Producto1_A2C




145 Version 1.1

HMI interface:

o 3 LEDs

o 2 buttons

GNSS Chipset (GPS, GLONASS as an option)

o Internal GNSS Antenna

o External GNSS Antenna

GSM modem (GSM, GPRS, EDGE, In Band) (Quad Band)

o Internal Antenna

o External Antenna

o SIM Holder

o eSIM

IOs (Several IOs are equipped in order to allow smooth vehicle integration)

o Airbag detection

o Head Unit Mute info

o Output on request signalling



The TCU eCall HW has been specifically designed to support driving assistance

and emergency services. Additionally, the TCU eCall complies with the

European Commission directives on eCall. FICOSA participates in several

European initiatives on the field of vehicular safety and communications and has

signed the Memorandum of Understanding of eCall.


The TCU eCall SW ought to be customized in order to be able to execute eCall

functionality in HeERO Scenario. ECall should be available in a non-CAN

scenario, in order to make it possible some software change ought to be

considered.

c) Number of units

5 units will be provided for HeERO Luxembourg consortium.




146 Version 1.1

Analysis of HeERO Application Scenario and detect SW requirements in

order to make possible ECALL execution with Ficosa’s TCU HW.

Implement SW modifications (ECALL in non-CAN vehicle)

HW/SW Integration and Testing


No HW change need detected at the moment, pending to analyse final

vehicle installation, in case for power supply reasons, an external DC/DC

converter may be considered to adapt IVS power supply to target vehicle

main power supply.


Ignition signal should wakeup or Sleep Ficosa’s TCU.

Custom SW should be configured for HeERO eCall scenario.

o Call centre, GSM operator, etc.


a. TCU HeERO custom SW will be test in Ficosa’s premises.

b. TCU HeERO custom SW should be test in HeERO actual scenario.



Functional requirements analysis for IVS on field testing (testing features

to be added over standard eCall feature).

SW requirements analysis over existing platform

Customized Ficosa’s TCU should be integrated on HeERO IVS actual

infrastructure.


147 Version 1.1

o Assure GSM connectivity between TCU and infrastructure.

o Integrate TCU on HeERO vehicle.

Locate TCU inside CAR.

Connect TCU to CAR battery and Ignition signal.

Test eCall function



activities.

Specific Test modes should be discussed in order to foresee SW

implementation, for instance during test fields may be necessary to allow

to perform eCall not only on 112 but also standard phone number due to

PSAP initial unavailability, and also autonomous and periodic eCall

communications feature to allow intensive testing for performance

analysis.

Handling assumptions must be observed, IVS units will be shipped

completely closed and their manipulation must be restricted to FICOSA

authorized personnel only.

Table 24: IVS – Denmark FICOSA

6.3.4.2 Fujitsu Ten

Q Report


Company name : FUJITSU TEN Ltd., Japan

Country : FUJITSU TEN (Europe) GmbH, Germany

Role in HeERO2 project : In Vehicle System supplier


a) System description: FUJITSU TEN’s IVS consists of a main unit, controller-

indicator, external antennas, microphone and loudspeaker. This IVS supports

pan-European eCall service that is activated by a signal from vehicle, manual

button on controller or the acceleration sensor in main unit. The main unit has

CAN bus interface so that it is able to collect the valuable data from a vehicle.


148 Version 1.1

b) Functions supported :

a. pan European eCall

b. ERA-GLONASS

c) Equipment specifics : IVS dimensions

IVS main unit : approx W130 x D75 x H35 [mm]


Wire harness between IVS main unit and Indicator : 1.5 m





d) specifications

item specifications







SIM card SIM / eSIM

Backup battery yes


Microphone external



Software update yes


149 Version 1.1

Communication log


DATA








a) Will existing HW be used and is it compatible with available eCall requirements :

FUJITSU TEN’s IVS supports mandatory functions for telematics service and

implementation in simply configured functions for voice calls, sending SMS,

packet communication and telematics service, corresponding to the

specifications of the planned legislation from around the year 2015 over Europe

and Russia.

b) Will existing SW be used and is it compatible with available eCall requirements:

FUJITSU TEN has modified SW based on existing IVS which is able to adapt

PSAP application (OECON) at YRP Japan where there is test bed for GSM

environment.

c) Number of units: 2 units will be provided for HeERO Luxembourg Consortium



a. Combine HeERO application scenario with eCall Day Japan’s one to

define eCall execution on FUJITSU TEN’s IVS

b. HW and SW integration, testing and logging


a. No HW change from on-going resize model

b. Additionally equipping of internal GNSS and Mobile Network antenna


a. Automatically eCall and MSD sending every 30 minutes


150 Version 1.1

b. Logging the communication result to SD card


a. Updated IVS will be test in FUJITSU TEN and YRP’s test facility.

b. SW custom identification will be test in the field of HeERO’s environment


b) Identification of implementation steps for enabling the HeERO2 IVS functionality

a. IVS installation to HeERO2 test vehicle

- Installation with effectual reception of internal TEL and GPS antennas

- Connection to vehicle battery and Ignition signal

b. Connectivity confirmation to GSM and UMTS

c. eCall functional test

d. Connectivity confirmation to Luxembourg infrastructure

e. Roaming service check around the border of Luxembourg (if possible)



activities.

- In case optional MSD, n-1 position data will be requested, IVS needs a request

signal from PSAP

- It could make better performance if the IVS is designed with the information how

MNOs cooperate with other operators around the border. How IVS should set SIM

profile, MNO relationship, etc.

Table 25: IVS – Denmark Fujitsu Ten

6.3.5 Luxembourg IVS report

6.3.5.1 NXP

Q Report


4. Company name: NV. NXP Semiconductors Belgium


151 Version 1.1

5. Country Belgium

6. Role in HeERO2 project: System know how, supplier of in car solution


d) System description: ATOP based eCall unit e112 –Stand alone after market unit

with alarm button

See http://www.nxp.com/news/meet-nxp/shows-and-events/eCall/eCall3.html

e) Functions supported : Full E112 and in car services

f) Equipment specifics: Aftermarket self-install unit


d) Will existing HW be used and is it compatible with available eCall requirements

Potentially, we are also looking to a current new development

e) Will existing SW be used and is it compatible with available eCall requirements

Yes

f) Number of units: 5


e) Definition of modification process

Uploading releases of new software into existing unit via existing mechanisms

f) Identification of HW changes or basic development

Attention point might be Audio quality and external interface towards car (Via USB?)

g) Identification of SW changes or basic development

Upload of last releases inside ATOP

h) Identification of test need for updated/new IVS

Continuous tests done towards OECON server


c) Identification of implementation steps for enabling the HeERO2 IVS functionality


152 Version 1.1

Integration of HLAP into ATOP –full deliverable planned July 2013

Partly deliverable with existing status available for testing by March 2012



activities.

Assumption is that E112 is only activated via Alarm button functionality

Table 26: IVS – Luxembourg NXP

6.3.5.2 FICOSA

Q Report



5. Country LUXEMBOURG



d) System description


















153 Version 1.1






e) Functions supported







of eCall.







Remote Diagnosis

Remote setting

Fleet Management

Pay As You Drive

Car Sharing

f) Equipment specifics:




Internal Battery



Microphone Input


Speaker output





154 Version 1.1

HU mute output

HMI interface:

o 3 LEDs

o 2 buttons





o Internal Antenna

o External Antenna

o SIM Holder

o eSIM


o Airbag detection




d) Will existing HW be used and is it compatible with available eCall requirements






e) Will existing SW be used and is it compatible with available eCall requirements




considered.

f) Number of units




155 Version 1.1










main power supply.









b) Identification of implementation steps for enabling the HeERO2 IVS functionality





156 Version 1.1


infrastructure.





Test eCall function



activities.






analysis.




Table 27: IVS – Luxembourg FICOSA

6.3.5.3 Fujitsu Ten

Q Report


Company name : FUJITSU TEN Ltd., Japan

Country : FUJITSU TEN (Europe) GmbH, Germany

Role in HeERO2 project : In Vehicle System supplier


e) System description: FUJITSU TEN’s IVS consists of a main unit, controller-

indicator, external antennas, microphone and loudspeaker. This IVS supports


157 Version 1.1

pan-European eCall service that is activated by a signal from vehicle, manual

button on controller or the acceleration sensor in main unit. The main unit has

CAN bus interface so that it is able to collect the valuable data from a vehicle.

f) Functions supported :

a. pan European eCall

b. ERA-GLONASS

g) Equipment specifics : IVS dimensions

IVS main unit : approx W130 x D75 x H35 [mm]


Wire harness between IVS main unit and Indicator : 1.5 m





h) specifications

item specifications







SIM card SIM / eSIM

Backup battery yes


Microphone external



158 Version 1.1


Software update yes

Communication log


DATA








d) Will existing HW be used and is it compatible with available eCall requirements :

FUJITSU TEN’s IVS supports mandatory functions for telematics service and

implementation in simply configured functions for voice calls, sending SMS,

packet communication and telematics service, corresponding to the

specifications of the planned legislation from around the year 2015 over Europe

and Russia.

e) Will existing SW be used and is it compatible with available eCall requirements:

FUJITSU TEN has modified SW based on existing IVS which is able to adapt

PSAP application (OECON) at YRP Japan where there is test bed for GSM

environment.

f) Number of units: 2 units will be provided for HeERO Luxembourg Consortium



a. Combine HeERO application scenario with eCall Day Japan’s one to

define eCall execution on FUJITSU TEN’s IVS

b. HW and SW integration, testing and logging


a. No HW change from on-going resize model

b. Additionally equipping of internal GNSS and Mobile Network antenna


159 Version 1.1


a. Automatically eCall and MSD sending every 30 minutes

b. Logging the communication result to SD card


a. Updated IVS will be test in FUJITSU TEN and YRP’s test facility.

b. SW custom identification will be test in the field of HeERO’s environment


d) Identification of implementation steps for enabling the HeERO2 IVS functionality

f. IVS installation to HeERO2 test vehicle

- Installation with effectual reception of internal TEL and GPS antennas

- Connection to vehicle battery and Ignition signal

g. Connectivity confirmation to GSM and UMTS

h. eCall functional test

i. Connectivity confirmation to Luxembourg infrastructure

j. Roaming service check around the border of Luxembourg (if possible)



activities.

- In case optional MSD, n-1 position data will be requested, IVS needs a request

signal from PSAP

- It could make better performance if the IVS is designed with the information how

MNOs cooperate with other operators around the border. How IVS should set SIM

profile, MNO relationship, etc.

Table 28: IVS – Luxembourg Fujitsu Ten

6.3.6 Spain IVS report

6.3.6.1 FICOSA

Q Report


160 Version 1.1



8. Country: Spain



g) System description






















h) Functions supported








161 Version 1.1


of eCall.







Remote Diagnosis

Remote setting

Fleet Management

Pay As You Drive

Car Sharing

i) Equipment specifics:




Internal Battery



Microphone Input


Speaker output

HU mute output

HMI interface:

o 3 LEDs

o 2 buttons





o Internal Antenna

o External Antenna

o SIM Holder

o eSIM




162 Version 1.1


o Airbag detection




g) Will existing HW be used and is it compatible with available eCall requirements






h) Will existing SW be used and is it compatible with available eCall requirements




considered.

i) Number of units



i) Definition of modification process





j) Identification of HW changes or basic development





163 Version 1.1

main power supply.

k) Identification of SW changes or basic development




l) Identification of test need for updated/new IVS




c) Identification of implementation steps for enabling the HeERO2 IVS functionality





infrastructure.





Test eCall function



activities.




164 Version 1.1




analysis.




Table 29: IVS – Spain FICOSA

6.3.6.2 Grupo Mecánica del Vuelo Sistemas (GMV)

Q Report


1. Company name: Grupo Mecánica del Vuelo Sistemas, S.A.U. (GMV)

2. Country: Spain

3. Role in HeERO2 project: IVS provider for Madrid demonstration site (Spain) (as

well as WP2 coordinator of Spanish pilot, provider of specific modules of

intermediate PSAP and overall coordinator of pilot in Madrid (set up, registering

of data and support to evaluation))



GMV’s IVS U10A is a mobile location unit that implements GNSS location and

eCall (automatic and manual) features according to applicable standards (in

addition to other value-added services). Based on GPS signals, it also

incorporates GPRS/GSM communications and in-band modem technology, and

a complete set of peripherals interfaces for different sensors to be used in

customized applications to meet specific applications’ needs and requirements

(including microphone, audio and panic button for eCall purposes). GMV’s U10A

OBU is intended to be compatible for both After Market and OEM in-vehicle

installation (with necessary adaptations).


GMV’s IVS allows for the following functionalities:


165 Version 1.1

- Communications management

- eCall management (automatic and manual)

- Voice communications

- Messaging capabilities

- Panic button

- Integration with fare collection systems and sending of information

- Management of external console

- Routes download

- Auto-diagnosis and programming

- Stop detection

- Fleet tracking and monitoring

- Over the air configuration and remote firmware download

- Geofence alarms and notifications

- Private mode

- eCall additional functions in development

- Highly accurate distance calculation

- Supports multiple services architecture


- Dimensions (length x width x height): 35mmx115mmx90mm

- Integrated GPS/GSM/GPRS antennae

- Easy-to-install: adaptable to any type of vehicle

- Integrated in-band modem,

- Microphone and panic button for eCall purposes in external component

- Built-in inertial sensor (accelerometer)

- Built-in Backup Battery (optional)

- GPS receiver with EGNOS capabilities

- 32 Mb Storage memory (more than 1 month of data position)


166 Version 1.1

- Low power consumption

- Inputs: 1A, 4D Outputs: 2D (5V to 12V)

- Standard Keyboard and display compatible

- External RS232/485 port



Existing HW will be used with necessary modifications for eCall purposes as

pointed out in Part 4 below.


Existing SW will be used with necessary customization and configuration for

eCall purposes as detailed in Part 4 below.

c) Number of units: 4 (They are to be used for eCall tests in Madrid demonstration

site and for cross-bordering eCall tests between Madrid and Castilla y León. To

be installed in 4 vehicles from one of GMV’s customers).



Modification process for GMV’s IVS includes some HW and SW modifications

and customizations on GMV’s OBU, as detailed below.


- Integration of microphone, audio and panic button peripheral unit.


- Firmware modifications derived from use of in-band modem and integration

of audio, microphone and panic button peripheral unit

- Development of procedures for eCall triggering (automatic and manual )

- MSD implementation and transmission

- Adoption of latest developments from Standardisation Task Force on eCall

IVSs

- Development of platform to monitor test vehicles for detailed information

registering: PVT, activated eCall signals, MSD, FSD etc.


167 Version 1.1


- Main activities: IVS SW configuration, IVS integration on preliminary test

vehicle, verification of IVS correct operation (eCall triggering, IVS-PSAP

communication, MSD transmission etc.), registering of IVS information on

developed platform for analysis.

- The SIM card to be used will be an exchangeable standard SIM card



- HW modification to be compliant with eCall requirements

- SW customization according to applicable eCall standards

- IVS unitary conformance tests following eCall standards

- IVS-PSAP communication conformance tests following eCall standards


As a prerequisite we anticipate the IVS to be temporarily installed in (GMV’s)

vehicles for testing.

Test calls can be selected to be triggered manually, or in pre-defined intervals

(of e.g. 5 minutes) after a GPS position fix has been made. Additionally, having

a built-in accelerometer, IVS can be configured to trigger automatic eCall under

predefined status of accelerometer.

112 and PSAP might be used at a later point in time; in the beginning a normal,

pre-defined landline number will be called for preliminary tests.

Identification of the IVS will be based on the IMEI or the VIN number, coded

according a scheme defined in the HeERO2 team within the given boundaries

(e.g. a virtual HeERO2 manufacturer identification).

The SIM is assumed to be an exchangeable standard SIM card.

Table 30: IVS – Spain GMV

6.3.6.3 CTAG

Q Report


168 Version 1.1


Company name: CTAG

Country: SPAIN

Role in HeERO2 project

Responsible of pilot test in Galicia

IVS integrator

PSAP support


a) System description:

The CTAG IVS system is composed by 2 subsystem:

- eCall Human Machine Interface (eCall HMI). Composed by all the

components related to a correct user interaction with the eCall service:

o eCall peripheral board with button and LED indicator for eCall

manual activation

o Microphone and speakers

- CTAG eCall and Telematics IVS Control Unit. The main functions of this

electronic control unit related to eCall service are:

o Collect all information related to eCall service messages, in order

to compose the required data messages

o Establish and maintain the voice channel with PSAP

b) Functions supported:

The described system has the next capabilities related to eCall:

- Collect car and GPS data and compose eCall messages

- Establish and maintain the eCall service manually or automatically when

a crash is detected.

- Keep online including disconnection from car battery condition

In addition it contains other telematic related functions.

c) Equipment specifics:

3G modem eCall compliance

CAN interface

GPS receiver

Audio interface


169 Version 1.1

Auxiliary battery

Interface for eCall HMI

Antenna

Host CPU for telematics services including eCall application


a) Will existing HW be used and is it compatible with available eCall requirements:


Yes, described hardware and its related software/firmware are compliant with

ETSI and 3GPP pan-European in-band technology standards.

c) Number of units: 4 units will be integrated in the 4 vehicles foreseen at Galicia


Not required


e) Identification of implementation steps for enabling the HeERO2 IVS functionality

In-vehicle integration: M5

Integration tests and verification: M6


Not applicable

Table 31: IVS – Spain CTAG

6.3.7 Turkey IVS report

6.3.7.1 Civitronic

Q Report


1. Company name : Civitronic

2. Country : Romania

3. Role in HeERO2 project : IVS Supplier for Turkey HeERO Pilot



170 Version 1.1

a) System description :

The product is based on Civitronic’s X700 platform, a proven base for both After

Market and OEM telecommunication boxes.

The main features of the board are summarized below:

CPU: ARM9 Core @66MHz. It is provided 1.7MByte Internal Flash Memory

and

400 Kbyte internal on CPU RAM

External Flash Memory: 0 Kbyte

External RAM Memory: 0 Kbyte

GSM: Quad band GSM 850/900/1800/1900MHz, GSM Class 1, EGSM

Class 4, and GPRS: Multislot Class 12. Internal or external quad band

antenna.

Audio: pre-amplified audio output and pre-amplified audio input or direct

microphone input.

GPS: External receiver with built-in active GPS antenna. SiRF Star III CPU

with 20 or 65 (optional) simultaneous Tracking Channels, <2s TTFF in Warm

Start and <10m autonomous position accuracy.

Accelerometer: 3 axes ±2g/±4g/±8g, measurement rate up to 250Hz.

Interrupt event and wakeup from acceleration activity is supported.

Efficient Power Supply: low stand by current

Key and Button: three digital inputs, for key and two buttons, with individual

wakeup is supported

Analogue Input: an analogue input able to read a voltage between 0 and

30V directly from power line is provided, so engine ON/OFF status can be

detected for both 12V and 24V systems

LED: the device has status indication LEDs for device, GPRS connectivity

and GPS receiver

Main Battery: wakeup from main battery missing is supported

Backup Battery: a 1250 mAh Lithium-Polymer

rechargeable internal backup battery is provided to supply the device if the

CAR battery is disconnected. It is automatically kept charged and has

failsafe mechanisms for under-voltage, over-voltage, over-temperature,

overcharging detection and auto-disconnection.

External Device Supply: it is possible to supply an external device working at


171 Version 1.1

5V. This is used for powering external RS232 interface and sensors

connected to the 1Wire interface (driver ID, temperature sensors,)

CAN network: a CAN V2.0B standard interface port is available. Wakeup

from CAN activity is supported

Easy Installation: due to small size the installation and commission time for

an unit is very short


The unit is able to perform the following functions:

Tracking Mode and Fleet Monitoring

Alarm Status

Private and Business Modes

Panic Button

Driving Style Monitoring

Theft Detection and Stolen vehicle tracking

Over the Air Configuration and Firmware Download

Accelerometer Auto Calibration and Crash Detection

Driver identification based on unique DallasKey

Geo-fence alarms and notifications



Yes, existing HW will be used and is it compatible with available eCall

requirements.


Yes, existing SW will be used and is it compatible with available eCall

requirements.

c) Number of units : 2






172 Version 1.1


No modification will be done on existing IVS


f) Identification of implementation steps for enabling the HeERO2 IVS functionality

- Understanding of Turkey HeERO project scope and setup.

- Project planning, production of units required.

- Implementation work for IVS setup and integration.



activities.

Table 32: IVS – Turkey Civitronic

6.3.7.2 TOFAS

Please use one table for every single IVS system

Q Report


As a vehicle manufacturer TOFAS will purchase an IVS from Magneti Marelli. MM took

part as an IVS provider in the HeERO1 and was one of the partners of Italy’s side. The

device which TOFAS is planning to use in the HeERO2 had already been tested in

terms of HeERO1 in the ITALY side.

1. Company name: TOFAS (Vehicle Manufacturer)

2. Country: Turkey

3. Role in HeERO2 project: Integration of the eCall devices


a) System description: eCall telematic unit for demonstration

b) Functions supported: Manuel eCall, bCall

c) Equipment specifics: GPS Functionality, 2G, GSM module including in band

modem made by Sierra Wireless, Backup Battery, Manuel eCall and bCall

functionality, Microphone, Speaker, eCall and bCall Button.


173 Version 1.1


a) Will existing HW be used and is it compatible with available eCall requirements:

It is still under development and not compatible with all of the requirements. E.g.

automatic eCall is not supported.


It is still under development and not compatible with all of the requirements. E.g.

automatic eCall is not supported.

c) Number of units: 2


As it is not an R&D project such activities will not be considered in terms of HeERO2.

a) Definition of modification process: Not planned

b) Identification of HW changes or basic development: Not planned

c) Identification of SW changes or basic development: Not planned

d) Identification of test need for updated/new IVS: Not planned



Integration of eCall devices from Magneti Marell will be applied into selected

FIAT demonstrator vehicles. It will be installed as After Market (e.g. power

supply from the cigarette lighter)

Following tests are the possibilities to be applied during the implementation

period.

eCall Activation

o –Manual eCall Activation through eCall SOS button

o –Verification of MSD sent to a PSAP using the pan-European eCall

o –Analysis of voice call


174 Version 1.1

o –Voice quality

o –Reliability of the call with internal antennas

o –Reliability of MSD sending in case of low signal strength

bCall Activation

o –Manual bCall activation

o –Verification of MSD sent using private protocols to the emergency

call centre

o –Analysis of voice call

o –Voice quality

o –Reliability of the call with internal antennas

o –Reliability and delay of MSD reception in case of low signal strength


TOFAS will not be able to test automatic eCall functionalities.

Table 33: IVS – Turkey TOFAS

6.3.8 Greece IVS report

6.3.8.1 Civitronic

Q Report


a) Company name: Civitronic

b) Country: Romania

c) Role in HeERO2 project: IVS & test equipment manufacturer & supplier



ubiq eCall is an IVS device specially designed for the testing phase of the

HeERO project. The product is based on Civitronic's ubiqAVL fleet management

platform, already running on more than 20K units. ubiq eCall IVS adds in-band

GSM modem for eCall functionality to existing state-of-art processing ARM9

core and GSM/GPRS modem with integrated GPS receiver, automotive power


175 Version 1.1

supply and GSM antenna. System core is TC65i, a high performance open

platform Java module from Cinterion. A second GSM module, AH3 from

Cinterion, is used as in-band modem with integrated eCall functionality. The

integrated GPS receiver delivers precise location, speed and heading

information, while external buttons allow for manual control of eCall scenarios.

Cigarette lighter allows for quick installation in any vehicle, no other cables or

external parts required.

Tested against simulated PSAP in 2011

Tested in January 2012 against PSAP Romania

Tested against Croatian PSAP in February 2012

Tested against 4 more PSAPs in June 2012 during the first eCall

Plugtests Interoperability Event organized by ETSI


Based on existing eCall standards (EN 15722:2011, EN 16072:2010, EN

16062:2010), the IVS supports the following functionality:

1. MSD transmission / reception /acknowledgment

2. Voice communication after receipt of AL-ACK

3. Retransmission of MSD on request from PSAP

4. Voice communication after retransmission of MSD

5. Clear down / PSAP initiated network clear down

6. Clear down / PSAP initiated application layer AL-ACK Clear-down

7. Call Back / PSAP initiated call back to IVS

8. Emergency call set-up with eCall identifier (flag) set to ‘Automatically

Initiated’ in Service Category message

9. Emergency call set-up with eCall identifier (flag) set to ‘Manually

Initiated’ in Service Category message

10. MSD call type indicator set to ‘Automatically Initiated’

11. MSD call type indicator set to ‘Manually Initiated’

12. MSD call type indicator set to ‘Test Call’

13. Mute IVS audio during MSD transmission and un-mute after application

layer acknowledgment

14. Auto redial following busy / no-answer during call set-up

15. Auto redial if call drops before MSD acknowledged and does not redial if

MSD has been acknowledged (LL)


176 Version 1.1

16. Un-mute IVS audio when SEND MSD not received (T5 expired)

17. Un-mute IVS audio when AL-ACK not received (T6 expired)

18. Un-mute IVS audio when LL-ACK not received (T7 expired)

19. Format of encoded and decoded MSD in accordance with EN 15722

20. IVS configured for eCall ‘only’ service (restricted)

21. IVS maintains register of recent calls

The IVS implements also the following additional functionality (if activated):

- GPS tracking mode

- engine status detection (on/off)

- collect dashboard parameters for trucks (odometer, total-fuel-used, tank-

fuel-level, RPM, etc.)

- complete fleet monitoring reports via web-based portal (journeys, trails, daily

activity, driving style, fuel consumption, etc.)


- ultra-robust integrated eCall solution, ready to use, no installation required

- universal 12/24V automotive power supply via standard cigarette lighter

- integrated on-board microphone as audio input for voice communication

- integrated line-out/headphones standard 3.5mm jack as audio output for voice

communication

- 3 axes accelerometer, supports wake-up from acceleration activity (e.g. crash)

- CAN interface with native support the FMS protocol (for trucks), able to ready

dashboard parameters directly (odometer, total-fuel-used, tank-fuel-level, RPM,

etc.)

- designed for testing purposes

- integrated GPS & TCP/IP connectivity

- online real-time remote testing and configuration via web portal

- easy editable MSD content, real-time

- automatic, manual and test buttons for manual eCall control

- remote triggering & control via GPRS or SMS

- software updates can easily be performed remotely using Over The Air

Programming (OTAP) via GPRS

- on-board LEDs for quick status check and diagnosis:


177 Version 1.1

• green LEDs indicates power and device status

• blue LEDs indicates GSM networks status

• red LED indicates GPS signal status


c) Will existing HW be used and is it compatible with available eCall requirements

Yes, the existing HW will be used and it is compatible.

d) Will existing SW be used and is it compatible with available eCall requirements

Yes, the existing SW will be used and it is compatible.

e) Number of units

More than 10pcs produced and used for in-house and third-party testers

(HeERO members). Small series production available on request in 1-4 weeks.

The Greek pilot will use 2 units.


- Definition of modification process

In case of any modifications related to the eCall standard or other specific

requirements, the current version of ubiq eCall IVS supports OTAP (Over The

Air Provisioning) via GPRS. This means that part or all algorithms for eCall or

other functionality can be modified on request and upgraded on the existing IVS

devices, without any user intervention. Algorithm modification/development time

depends of specific requirements, but usually it takes about 1-4 weeks or less.

Algorithm upgrade process via GPRS usually takes 2-5 minutes and can be

done individually for each device or for many at once.

Minor changes, like possible timeout values changes for some timers specified

in eCall standards, can be done real-time, immediately, by the client/user via the

provided web portal using the configuration tab or by the manufacturer

(CIVITRONIC) following a client request.

Medium changes, like changing eCall algorithms or other functionality can be

done by the manufacturer (CIVITRONIC) following a client request.

Major changes, like replacing hardware components or additional functionality


178 Version 1.1

can be done only by the manufacturer (CIVITRONIC), may not be done

remotely and may require the IVS device to be shipped to manufacturer's

headquarters for upgrade.

- Identification of HW changes or basic development

Improve manufacturing process for small scale production.

- Identification of SW changes or basic development

Improve power management and update T4 and T5 with new values (5s vs 2s).

This can also be done now, as the device is remotely configurable, but default

values for the 2 timers shall be updated for new devices.

- Identification of test need for updated/new IVS

Tests already performed for updated T4 & T5 values.

For each new installed IVS the following tests shall be performed:

external power supply

GSM/GPRS connectivity

GSM/voice connectivity

GPS signal reception



The device is already capable for required HeERO2 IVS functionality


The current version of Civitronic's IVS (ubiq eCall) is specially designed for the testing

phase of HeERO and can't be used for mass production, to be integrated by vehicle

manufacturers. The IVS must be powered from existing cigarette lighter and it must be

placed on the dashboard or in other accessible place, with GPS antenna side facing up,


179 Version 1.1

for clear sky view.

Table 34: IVS – Greece Civitronic

D2.1 State of the art analysis, operational and functional ... · 31/10/2013 Grant agreement no.:...

Documents

Transcript of D2.1 State of the art analysis, operational and functional ... · 31/10/2013 Grant agreement no.:...