CEN/TS 14821-6:2003

SLOVENSKI STANDARD
01-oktober-2003
3URPHWQHLQSRWRYDOQHLQIRUPDFLMH77,6SRURþLOD77,SUHNFHOLþQLKRPUHåLM±
GHO=XQDQMHVWRULWYH
Traffic and Travel Information (TTI) - TTI messages via cellular networks - Part 6:
External services
Verkehrs- und Reiseinformationen (TTI)-TTI-Nachrichten über mobile Netzwerke - Teil 6:
Externe Dienste
Ta slovenski standard je istoveten z: CEN/TS 14821-6:2003
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 14821-6
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2003
ICS 35.240.60
English version
Traffic and Travel Information (TTI) - TTI messages via cellular
networks - Part 6: External services
This Technical Specification (CEN/TS) was approved by CEN on 10 May 2001 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available. It
is permissible to keep conflicting national standards in force (in parallel to the CEN/TS) until the final decision about the possible
conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway, Portugal, Slovakia, Spain, Sweden, Switzerland and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2003 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 14821-6:2003 E
worldwide for CEN national Members.

Table of contents
PAGE
TABLE OF CONTENTS 2
FOREWORD 4
INTRODUCTION 5
1. SCOPE 6
2. NORMATIVE REFERENCES 7
3. DEFINITIONS AND ABBREVIATIONS 7
3.1 Definitions 7
3.2 Abbreviations 10
4. SPECIFICATION OF EMERGENCY SERVICE AND BREAKDOWN ASSISTANCE 16
4.1 Introduction 16
4.2 General Procedures 17
4.3 Description of services 20
4.4 Terminal Requirements 30
5. ADP FOR EMERGENCY SERVICES AND BREAKDOWN ASSISTANCE 33
5.1 Assistance Message 33
5.2 Text Message 35
5.3 Acknowledge Message 35
5.4 Calling Request Message 36
5.5 Specification in ASN.1 37
6. SPECIFICATION OF INTERACTIVE TRAFFIC INFORMATION SERVICES 40
6.1 Introduction 40
6.2 General Handling Sequences 40
6.3 Basic Traffic Information Services 53
6.4 Bypass Information Service 60
6.5 Support Services 64
6.6 Service specific Terminal Requirements 67
6.7 Service specific Error Handling 68
7. SPECIFICATION OF BROADCAST TRAFFIC INFORMATION SERVICES 69
7.1 Introduction 69
7.2 Basic Handling Sequences 69
7.3 Broadcast of Other Downlink Messages 77
7.4 Service specific Terminal Requirements 78
7.5 Service-specific Error Handling 78
8. ADP FOR TRAFFIC INFORMATION SERVICES 79
8.1 Downlink Messages 79
8.2 Uplink Messages 82
8.3 TINFO Type 1 90
8.4 TINFO Type 2 (TMC coded) 100
8.5 Building Blocks 103
8.6 Definition of Semantics for Location Block within TINFO 111
8.7 Specification in ASN.1 112
9. SPECIFICATION OF NAVIGATION SERVICES 138
9.1 Introduction 138
9.2 General Procedures 139
9.3 Address Localization 144
9.4 Description of Services 148
9.5 Error Handling 162
9.6 Technical Requirements for Terminal Devices 164
10. ADP FOR NAVIGATION SERVICES 166
10.1 General Definitions and Information Elements 166
10.2 Specification of Message Types 166
10.3 Specification of Information Blocks 175
10.4 Specification in ASN.1 192
11. SPECIFICATION OF FLOATING CAR DATA 203
11.1 Introduction 203
11.2 Description of the FCD procedure 203
11.3 System architecture and interfaces 206
11.4 Functions of the FCD production cycle 212
11.5 Technical Requirements 219
11.6 Data protection and security 223
12. ADP FOR FLOATING CAR DATA 226
12.1 Overview 226
12.2 Specification of Message Types 228
12.3 Coding of Basic Information Elements 256
12.4 Specification in ASN.1 261
13. SPECIFICATION OF OPERATOR SERVICES 281
13.1 Introduction 281
13.2 Description of Procedure 281
13.3 Service-Specific Error Handling 284
13.4 Service specific parameters 285
14. ADP FOR OPERATOR SERVICES 286
14.1 Operator Service List Request Message 286
14.2 Operator Service List Message 286
14.3 Operator Request Message 286
14.4 Specification in ASN.1 287
15. SPECIFICATION OF GENERAL INFORMATION SERVICES 289
15.1 Introduction 289
15.2 Service Structure 289
15.3 Description of Procedure 290
15.4 Service-Specific Error Handling 297
15.5 Data Types 299
15.6 Service specific parameters 303
16. ADP FOR GENERAL INFORMATION SERVICES 304
16.1 Message Types 304
16.2 Data Types 312
16.3 Specification in ASN.1 316
BIBLIOGRAPHY 325
Foreword
This document (CEN/TS 14821-6:2003) has been prepared by Technical Committee CEN/TC 278 "Road
transport and traffic telematics", the secretariat of which is held by NEN, in collaboration with Technical

Committee ISO/TC 204 "Transport information and control systems".
This CEN/TS was prepared by Working Group 7 of CEN TC278. In the field of Traffic and Traveller
Information, the innovative rate is high, with many research and development projects under way in many
countries, and there is a need to establish prospective standards which allow manufacturers to introduce
competitive products to the market in the knowledge that they can accommodate the future issues of the
standard(s) without fundamental change to equipment.
In accordance with the CEN/CENELEC “Internal Regulations Part 2: Common Rules for standards work, 04-
1996“ the original copyright holders on the complete set of documents are Mannesmann Autocom GmbH and
TEGARON Telematics GmbH. The original copyright holders hereby grant CEN all necessary rights with
regard to said original copyrights to execute the standardisation process as described below.
No known national technical specifications (identical or conflicting) exist on this subject.
CEN/TS 14821 consists of eight parts; one part describing the framework and seven parts providing detailed
specifications of all components, protocols and services that are within the scope of CEN/TS 14821.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification: Austria, Belgium, Czech Republic,
Denmark, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Luxembourg, Malta,
Netherlands, Norway, Portugal, Slovakia, Spain, Sweden, Switzerland and the United Kingdom.
Introduction
Traffic and Traveller Information (TTI) may be disseminated through a number of services or means of
communication, covering static displays, portable terminals and in-vehicle equipment.
For all such services, the data to be disseminated, and the message structure involved in the various
interfaces, require clear definition and standards formats in order to allow competitive products to operate
with any received data.
This CEN/TS focuses on an application data specification whereby data is produced at a central location and
is disseminated via a cellular radio network. It addresses the data specifications for both downlink and uplink
existing between a central location and randomly located vehicles. It enables messages to be exchanged
between different systems and service providers adopting a variety of applications specifications.
Other technical specifications are being produced by the CEN TC278 Working Group 4 to cover TTI
dissemination via other means or services. This set of specifications is named GATS (Global Automotive
Telematics Standard). GATS provides the modular framework for implementing such traffic telematics
services on an open technology platform and is network - independent. In many details definitions are
necessary to ensure interoperability. Therefore, those detailed definitions are given in a network-specific part
(CEN/TS 14821-8). With the development of future mobile communication systems towards UMTS / IMT2000
the bottleneck of narrow-band data communication might fade. Due to its modular structure, the GATS
framework and applications are prepared for that due to its network-independence. The same holds for
emerging technologies for positioning which today is almost exclusively based on GPS.
Other relevant standard developments are, independent from telematics, the application-independent
Wireless Application Protocol (WAP), enabling mobile access to the Internet. It is understood that these
emerging technologies might fit into the framework of telematics applications in future WAP-versions. For the
time being, GATS already today independently from WAP enables access to telematics services. Utilisation
of GATS on a WAP protocol stack and identifying necessary adaptation of WAP specifications (if any) is
currently under investigation of the appropriate groups within WAP-Forum and GATS-Forum.
1. Scope
This CEN/TS defines the specific interfaces and functionality of traffic telematics (TT) services based on the
use of cellular networks. Device manufacturers are enabled to develop terminal equipment compatible to
services based on this CEN/TS. This will allow for interoperability of different terminal equipment and service
providers which allows competition between service providers and terminal manufacturers. Furthermore it
sets the scene for international availability of these services.
This CEN/TS specifies
• TT-specific interfaces between terminal and service centre. This especially incorporates the message

sets of the application data protocols and the service-independent communication handling (including
conditional access and transport protocols).
• Functionality, procedures and requirements of basic terminal components as well as their interaction with

the service centre. This especially comprises conditional access and security mechanisms.
• Service Specifications, which are essential to ensure consistent behaviour of terminal and service centre.
The services incorporated within this issue comprise:
• breakdown and emergency services
• interactive traffic information services
• broadcast traffic information services

• navigation services (route assistance, route advice, homing)
• operator services
• general information services
• floating car data collection

It is envisaged that future research and development will lead to improvements on the services listed above
as well as to the creation of new services. Nevertheless this CEN/TS provides the framework for seamless
integration of new features and services into the existing architecture.
2. Normative references
This CEN/TS incorporates by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed hereafter.
For dated references, subsequent amendments to or revisions of any of these publications apply to this
CEN/TS only when incorporated in it by amendment or revision. For undated references the latest edition of
the publication referred to applies (including amendments).
EN ISO 14819 Traffic and traveller Information (TTI) - TTI Messages via Traffic Message
Coding
3. Definitions and abbreviations
3.1 Definitions
For the purpose of this CEN/TS, the following definitions apply:
3.1.1 Attribute (of a Traffic Information Message)
A Traffic Information Message is made up of separate parts that can be called attributes. This includes, for
example, an item of information and a length of validity.
3.1.2 Authorisation
Reciprocal proof that the identity provided by the communications partner is valid
3.1.3 Broadcast Service
Data service within a cellular wireless network that allows for mono-directional dissemination of data from a
service centre to multiple users in the area of signal reception
3.1.4 Bypass Description
Representation of a Bypass, consisting of a Bypass Hint and/or a Bypass Route.
3.1.5 Bypass Hint
Representation of a hint for a Bypass
3.1.6 Bypass Link
Prominent waypoints on a Bypass Route
3.1.7 Bypass Route
Representation of the route for a Bypass
3.1.8 Cell Broadcast
Broadcast service of the GSM network
3.1.9 Customer
User of the terminal device (onboard unit) (see User)
3.1.10 Data telegram
Digital message exchanged between two systems
3.1.11 Delivery Notification
Network acknowledgement for successful/ unsuccessful delivery of a message to the mobile device
3.1.12 FCD Message
The message transmitted by an onboard unit (OBU) to the FCD server.
3.1.13 FCD Server
The collection point for incoming FCD messages.
3.1.14 Floating Car
A vehicle which is equipped with an intelligent onboard unit for assessment of the traffic situation.
Note : Onboard units are referred to as « intelligent » if they are capable of collecting, pre-interpreting and
transmitting vehicle-specific measured data to the FCD server. Vehicles equipped with onboard units which
are « only » capable of retrieving service information and not collecting data for traffic situation analysis are
not referred to as floating cars.
3.1.15 Floating Car Data
Measured data which are collected in floating cards on a certain time cycle and which contain data on the trip
profile and derived quantities.
3.1.16 Functional Road Class
A classification based on the importance of the road element in the connectivity of the total road network
3.1.17 Functional Road Class 0
Motorways
3.1.18 Functional Road Class 1
All non-Motorways that are part of a connection used for nation wide traffic and transport
3.1.19 Geocode
Geocodes are unique identifiers unmistakably defining important points on road networks. Geocodes can be
derived from / converted into WGS84 co-ordinates by the algorithm described in CEN/TS 14821-3.
3.1.20 Hardware service agents

Partner companies of the traffic telematics service providers who are authorised to install onboard equipment
into vehicles and to maintain it
3.1.21 Homing
Simple form of guidance to destination, in which the direction and straight-line distance of the destination are
indicated
3.1.22 Information Element
Information unit of a message
3.1.23 Intersection
Junction of two or more roads
3.1.24 Job
A request to the FCD server which may comprise both the collection of additional measured data from a
specific geographical area and the cancellation of a previous request.
Note : collection jobs are converted into control information by the FCD server and relayed to the floating
cars.
3.1.25 Length of a Speech Report
Length of a Speech Report, including pauses, in tenths of a second
3.1.26 Mobile Originated
Data telegram sent from the onboard equipment to the Service Centre.
3.1.27 Mobile Terminated
Data telegram sent by the Service Centre to the onboard equipment.
3.1.28 Onboard equipment
A system, generally mobile, interacting with the service centre to handle traffic telematics services
3.1.29 Parameter message
A message transmitted by the FCD server to the floating cars and containing onboard-unit specific
parameters.
3.1.30 Road Junction
Intersection of two or more roads
3.1.31 Route description
Description of a route showing the geometry of street intersections, manoeuvre instructions, street and place
names, and geographical co-ordinates
3.1.32 Service centre
System produced by the traffic telematics operators / service providers to handle traffic telematics services
3.1.33 Short Message Service
Packet-based form of data transfer within the GSM network
3.1.34 Speech connection
Communications channel between two systems for the bi-directional transmission of speech
3.1.35 Speech Report
Traffic Information Report transmitted by a speech system
3.1.36 Terminal Device
Generally mobile system interacting with the service centre for implementation of telematics services
3.1.37 TINFO
Traffic Information Report
3.1.38 TINFO Version
Unique identification of a Traffic Message, consisting of a number and a time stamp
3.1.39 Traffic Data
Data for qualification of Traffic Events. This includes:
• Values: speed, traffic flow, traffic density

• Places: position, place designation
• Facts: description of situation
3.1.40 Traffic Event
An occurrence on a road or in an area that is worthy of reporting, such as a traffic jam, wrong-way driver, or
fog.
3.1.41 Traffic Information
Technical representation of a Traffic Situation within the onboard equipment, accomplished by a number of
Traffic Information Reports.
This Traffic Information can be displayed to the customer via suitable terminals.
3.1.42 Traffic Information Report
Technical representation of a Traffic Event produced by processing traffic data. Each Traffic Reports uniquely
identified by a number, the TINFO ID, a time stamp, the TINFO version.
Note: If the Traffic Event changes, the time stamp changes, but the TINFO ID number does not.
3.1.43 Traffic Situation
The total number of all Traffic Events taking place that deserve reporting within an area. The Traffic Situation
is always linked to an area. Thus, for example, an areas could be a conurbation or a geometrically
demarcated area; an example is the radius around a point.
3.1.44 User
User of the terminal device (onboard unit) (see Customer)
3.1.45 Voice connection
Circuit-switched channel between two systems for bi-directional voice transmission
3.1.46 Waypoint
Significant points on the route
3.2 Abbreviations
For the purpose of this CEN/TS, the following abbreviations apply:
3.2.1 % ott
percent of the time
3.2.2 ADP
Application Data Protocol, i.e. a message set for a telematics service
3.2.3 AM
Acknowledge Message
3.2.4 ASN.1
Abstract Syntax Notation
3.2.5 BC
Broadcast
3.2.6 BCS
Broadcast Service
3.2.7 CA
Conditional Access
3.2.8 CAS
Conditional Access and Security
3.2.9 CB
Cellular Broadcast
3.2.10 CBC
Cipher Block Chaining
3.2.11 CLI
Calling Line Identification
3.2.12 CRM
Calling Request Message
3.2.13 CSD
Circuit Switched Data
3.2.14 DES
Data Encryption Standard: symmetrical encryption procedure
3.2.15 DRM
Digital Road Map
3.2.16 DSC
Data Service Centre: depending on the mobile communication network
3.2.17 ELB
Extended Location Block
3.2.18 FCD
Floating Car Data
3.2.19 FCDGM
FCD General Message
3.2.20 FCDPM
FCD Parameter Message
3.2.21 FCDNSM
FCD Notification Set-up Message
3.2.22 FCDRM
FCD Revoke Message
3.2.23 FCDVDSUM
FCD Virtual Detection Site Update Message
3.2.24 GATS
Global Automotive Telematics Standard
3.2.25 GEM
General Error Message
3.2.26 GPS
Global Positioning System NAVSTAR GPS
3.2.27 GSM
Global System for Mobile Communication
3.2.28 IE
Information Element
3.2.29 IEG
Information Element Group
3.2.30 ICV
Initial Chaining Value
3.2.31 L_max
Max. length of transferable data in one data transaction
3.2.32 MAC
Message Authentication Code
3.2.33 MNA
Mobile Network Address
3.2.34 MF
Mandatory Fixed
3.2.35 MO
Mobile Originated Message
3.2.36 MT
Mobile Terminated Message
3.2.37 MV
Mandatory Variable
3.2.38 N_min
Minimum number of ELB waypoints
3.2.39 OBU
Onboard Unit, synonymously used : telematics device, telematics terminal
3.2.40 OD
Origin/Destination
3.2.41 OF
Optional Fixed
3.2.42 OV
Optional Variable
3.2.43 PDU
Protocol Data Unit
3.2.44 PFA
Probability of false alarm (i.e. estimated error is too large)
3.2.45 PMD
Probability of missed detection (i.e. estimated error is too small)
3.2.46 Ptp
Point to point
3.2.47 RSA
Asymmetrical encryption procedure by Rivest, Shamir and Adleman
3.2.48 SAE
Society of Automotive Engineers, Inc.
3.2.49 SDI
Data Item
3.2.50 SMS
Short Message Service
3.2.51 SMSC
SMS Centre
3.2.52 SV
Space Vehicle
3.2.53 TD
Terminal Device
3.2.54 TEG
Telematics Expert Group – Group within the WAP-Forum Ltd.
3.2.55 TINFO
Traffic Information Report
3.2.56 TOC
Telematics Operator Code
3.2.57 TRP
Transport Protocol
3.2.58 TT
Traffic Telematics
3.2.59 TTI
Traffic and Traveller Information
3.2.60 TTFF
Time to First Fix
3.2.61 UTC
Universal Time Co-ordinated
3.2.62 VDS
Virtual Detection Site
3.2.63 VDSTAB
Virtual Detection Site Table
3.2.64 vel, V
Velocity
3.2.65 VIN
Vehicle Identification Number
3.2.66 WAP
Wireless Application Protocol
3.2.67 WGS84
World Geodetic System 84
4. Specification of Emergency Service and Breakdown Assistance
4.1 Introduction
The following services are included within this specification:
• Emergency Service
• Breakdown Assistance
• Call for Help (the procedures are identical to the Breakdown Assistance)
The services are distinguished within the service center using the application ID. This information is detailed
within the Call Type of the AssistanceMessage. In case of an emergency, this Assistance Message (generic
term) is called “Emergency Call Message“, in case of a breakdown, it is called “Breakdown Assistance
Message“.
The availability of the Emergency Call and Breakdown Call services depends on the service authorisation as
well as the mobile network in which the vehicle is located. The administration of the means of access is
described in CEN/TS 14821-5. If access is not possible, the Emergency Call service can only be used in a
limited form, both nationally and internationally (Mobile Network Emergency Call structure without data
communication).
4.1.1 Breakdown Assistance
The aim of the Breakdown Assistance is to improve existing assistance both for the customer and the
assistance provider, whilst including the "traditional" operating partners (Breakdown Assistances). The task
offered is to process the information submitted with the breakdown alarm and to optimize the assistance,
taking into account prearranged action plans.
The service is designed to be carried out automatically as far as possible, using data communication between
customer and traffic telematics service centerprovider as well as traffic telematics service centerprovider and
assistance provider. An operator is used as fall back and to handle unforeseen constellations.
The benefit to the user is an increased efficiency in organising the assistance:
• Alarm given directly from vehicle; no extra time loss before alarm

• More rapid and efficient assistance through precise and robust location of vehicle and transmission of

additional information
which is closely related to the advantages for the assistance provider:
• Exact information on position of customer
• Vehicle information
• Automatic breakdown diagnosis (depending on manufacturer), if availablenecessary

4.1.2 Emergency Service
The aim of the emergency service is to improve existing assistance both for the customer and emergency
services or the police.
The service incorporates an operator and uses both data and voice communication between customer and
traffic telematis service provider as well as traffic telematis service provider and assistance provider.
The benefit to the user is a more rapid and more effective assistance:
• Alarm given directly from vehicle
• No time loss until alarm is submitted
• More rapid and efficient assistance through precise and robust location of vehicle and transmission of
additional information (e.g. medical hazards)
• Automatic triggering of emergency call, if necessary and available

• The users benefit is closely related to the advantages offered to the police / emergency service:

• Exact information on position

Information on vehicle and driver
Automatic emergency call diagnosis, if necessary
Check for preliminary diagnosis of triggered emergency calls with regard to abuse/accidental triggering by an
operator before forwarding emergency calls to the police/emergency service.
4.1.3 Call for Help
This kind of Service is used for terminals, which do not meet the requirements of the emergency service,
especially according to the quality of the positioning function as specified in CEN/TS 14821-7.
In cases of medical requests, after accidents or attacks help- or service-organizations can be called. Due to
the character of service and process delays, caused by the operator based acknowledgement of the position,
this service can not be recommended for real emergencies and rapid responses, it is predominant an
interactive information service. It can not be triggered atomatically.
The emphasis of benefit to the user is depending on the performance of the service-center. Other advantages
are:
• Alarm given directly from the vehicle
• Efficient assistance through rough vehicle location and transmission of additional information
• Vehicle information which is related to improved response and to the performance of the service center.

4.2 General Procedures
4.2.1 Time-control of communication processes
The following timers are relevant for the security service procedures. The depositing and updating of the
timers in the terminal device are described in CEN/TS 14821-5.
Para
Designation Function Default Max. Effect during Effect on terminal
me-
value value processing in device during
ter
[s] [s] Service Center processing
ID
1 BD1ACK Maximum time, in the event of a 90 600 Timer only Termination of
breakdown call/call for help, up to effective at service
the first Acknowledge from the terminal device
Service Center
2 BD2ACK Maximum time, in the event of a 600 3200 Timer only Terminationof
breakdown call/call for help, effective at service
between the first Acknowledge and terminal device
the next Acknowledge/Calling
Request from the Service Center
3 TXTtoACK Maximum time between a Text 300 3200 Service procedure See 4.3.2.6
Message from the Service Center in acc. with
with an expected active 4.3.2.6
Acknowledge and a positive
Acknowledge message from the
customer
4 EC1ACK Maximum time, in the event of an 90 600 Service Center Termination of
Emergency Call, between the attempts to service
transmission of the Emergency process service
st
Call Message and the 1
Acknowledge from the Service via telephone
Center
5 EC1xACK Time, in the event of an 600 3200 Service Center Termination of
st
Emergency Call, between the 1 attempts to service
Acknowledge and the last process service
Acknowledge from the Service via telephone
Center
6 C2FALLBACK Time, between triggering the 60 600 Service Center Termination of
service and dialing a fallback cannot operate service
number if there are any problems via telephone
Dial Fallback
with telephony
number
In the event of an Emergency,
dialing the MNEC applies, in the
event of a Breadown, dialing the
service backup number applies.
The minimum value of every timer is 0. The interval length should be at most +/-10% of the default value
which is also a requirement for the exactness of a clock of the terminal device. The values themselves are
transmitted as unsigned integer values. The scaling factor for the timer values received via Configuration
Update is 1 sec.
Parameters exceeding the maximum values given in column 5 of the table above shall be ignored by the
terminal if received via Configuration Update.
The default values given in column 4 shall be setup by the terminal whenever the terminal is resetted to the
„No operator assignment“ state (see CEN/TS 14821-5) Each parameter value can be changed by the Service
Center via Configuration Update.
Update of parameters in the terminal device:
If the default values are used in the terminal device and the menue „update“ is executed, this shall be
signalized during a ConfigurationRequest by setting Parameter-Version=0.
All parameter will be transmitted from the service center to the onboard unit as absolute values, without any
scaling or offset. In the table the given scaling factors, min. and max. values might be used in the unboard
unit for compressed data storage, since the parameter update will be carried out with fixed IE-lengths for
each parameter. For details on parameter update, see CEN/TS 14821-5.
4.2.2 Conditional Access and Security
4.2.2.1 Encryption
At least all messages for the emergency service are expected to be transmitted unencrypted. Encryption
might be necessary in cases of authorization proof, especially telematics service roaming.
4.2.2.2 Master Data
The terminal device shall offer the option of depositing the following master data in the terminal device (for
coding, see CEN/TS 14821-3). The following conditions shall be observed for depositing and transmitting
data:
Information Element Coding
Colour of Vehicle See CEN/TS 14821-3
Chassis Number max. 18 characters
Text ISO 8859-1
Vehicle Model max. 9 characters
Text ISO 8859-1
Year of Construction 2 characters Text ISO 8859-1
License Plate max. 11 characters
Text ISO 8859-1
4.2.2.3 Administration of Communication Addresses
4.2.2.3.1 Breakdown Assistance and Call for Help

Two primary addresses (the Mobile Network Address MNA) and a service center destination address
(Destination), if needed in addition to the primary address, shall be stored in the terminal device for the
breakdown and the call for help service.
4.2.2.3.2 Emergency Call
Two primary addresses (one default, one backup number), two call numbers (one default, one backup
number) and a service center destination address, if needed in addition to the primary address, shall be
stored in the terminal device for the Emergency service.
Both primary addresses can be used. If there any communication faults with one of the primary two MNA
numbers, a retry using another number is recommended.
The depositing and updating of service addresses in the terminal device is described in CEN/TS 14821-5.
4.2.3 Service-Specific Definitions with Respect to the Application Data Protocol
4.2.3.1 Assistance Message
The Assistance Message is a generic term for a mobile originated message that normally is used to initiate
one of the services “Emergency Service“, “Breakdown Assistance“ or “Call for Help“. In case of Emergency
Service, this type of message is called „Emergency Call Message“, in case of a Breakdown Assistance, it is
called “ Breakdown Assistance Message“.
The Breakdown Reasons Type field indicates in cases of an Emergency Service the presence of information
about a crash.
In the event of a breakdown, zero should be entered in the Breakdown Reasons Type field, in case damage
selection is not possible at the terminal device. The Breakdown Reasons field is then omitted.
If the terminal device offers the option of damage selection, the values 1, 2 or 3 should be entered in the
Breakdown Reasons Type field.
Filling the Extended Location Block for an Emergency Call Message is dependent on the variable length of
other IE. Therefore the following mandatory regulations apply:
The Emergency Call Message shall be filled according to the priority listed below. It shall be ensured by the
terminal the maximum length of an Emergency Call Message including the necessary application-
one
independent protocols never exceeds the maximum length L_max of the transferable data in data
transaction:
L_max length(TRP) + length(CAS) + length(ADP).
L_max is dependent on the type of mobile network service used.
• highest priority: localization data with N_min ELB-waypoints (excluding GPS raw data) coded according
to the definition of Extended Location Block
• Master Data
• Loads (if applicable)
• lowest priority: GPS raw data, if space allows
If the remaining space in the data telegram is large enough to transmit the satellite raw data for the DGPS,
the Extended Location Block is filled with the raw data in accordance with the coding of the Extended
Location Block. Here, the GPS Raw Data Present flag shall be set to 1.
4.2.3.2 Text Message from Service Center to Vehicle
The Status field within the Text Message is coded as follows.
Value Direction Text Message Type
0 Reserved
1 Center fi Customer Text Message with expected reply
2 Center fi Customer Information on position
3 Center fi Customer Display text only
4 Center fi Customer Display text only and set back
timer BD2ACK and EC1ACK
5 - 255 Reserved
4.2.3.3 Acknowledge Message
The Status field within the Acknowledge Message is coded as follows:
Value Direction Acknowledge Type
0 Reserved
1 Center fi Customer Receipt acknowledgement for the
Assistance Message
2 Last Acknowledge Message within
Center fi Customer
any service procedure
4 Customer fi Center Acknowledge from the terminal device
to the Service Center, with which the
customer is signalling that he
accepts/does not accept the operating
partner
5 - 255 Reserved
4.2.3.4 Calling Request Message

The address format applies to the Assistance Partner Address. It shall be given as international number for
mobile network speech.
4.2.4 Execution of system tests
Authorised persons can initiate a test scenario (with an extra application ID) at the terminal device (test
mode). It is left to the service provider to define the test procedures and access control.
4.3 Description of services
4.3.1 Description of procedures

4.3.1.1 Breakdown assistance (Individual driver)
On concluding an agreement with the Service Center, the customer states his desired Breakdown Assistance
organisation (the customer can also designate several Breakdown Assistance organisations, which are
stored in a plan of action. If the first Breakdown Assistance organisation is unable to accept the order, the
order is sent to the next Breakdown Assistance organisation in the plan of action). This data is stored at the
Service Center. If, in the event of a breakdown, the customer selects the menu "Breakdown" (or presses the
breakdown button), the data telegram is prepared by the terminal device, in order that the designated
Breakdown Assistance organisation can be activated. In the event of a breakdown, the terminal device takes
the type of damage into consideration, in accordance with 4.2.3.1. The vehicle position is calculated and sent
to the Service Center, together with the previously compiled data, as a data telegram (Breakdown Assistance
Message, coded according to the Assistance Message).
After the access authorisation for this service has been checked and the contents of the telegram
successfully read, confirmation of receipt of the order is sent to the customer within the BD1ACK time
(Positive Acknowledge Message). The timer is triggered by positive notification.
The current position of the vehicle is determined in the Service Center by means of map-matching, using the
location data. The aim is to use destination routing systems with a map integrated into the vehicle (e.g.
navigators) as a supplement for transmitting street-related location data. The processed set of data, which is
supplemented by certain master data, is transmitted to the relevant Breakdown Assistance organisation
(Assistance Link Message). The latter sends confirmation of acceptance of the order (Positive
Acknowledge Message) to the Service Center. This order acceptance may contain other information on
breakdown assistance which is relevant for the customer. Depending on the procedure agreed upon with the
operating partner, the Service Center sends a data telegram to the terminal device, which sets up a voice
connection from the terminal device to the operating partner (Calling Request Message with the
corresponding field entry "Trigger call automatically"“ or "Trigger call following confirmation from customer")
[see 4.3.2.1] or informs the customer of the impending return call from the operating partner (Positive
Acknowledge Message) [see 4.3.2.2]. The reply to the terminal device takes place within the BD2ACK time.
The service is then concluded as far as the terminal device is concerned. The messages from the Center
may contain, in accordance with the ADP, the name of the designated company and the time of the expected
arrival of the breakdown assistance.
If the operating partner designated by the customer cannot be activated or the customer has not specified
any breakdown assistance organisation, the customer is asked if the partner from the Service Center is
acceptable instead (Text Message with expected active acknowledgement in accordance with the status
bytes). On receipt of the active acknowledgement of this by the customer (Positive Acknowledge
Message), the partner of the Service Center is contacted and the service concluded, as mentioned above
(Positive Acknowledge Message or Calling Request Message) [see 4.3.2.3 and 4.3.2.5]. If the customer
rejects this or the TXTtoACK time available for replying runs out (Negative Acknowledge Message / time-
out), the customer is informed of the termination of the service and receives information, within the text field
of the Negative Acknowledge Message from the Service Center to the terminal device, on a separately
priced operator service from the Service Center (Customer Care) which may then be of further help [see
4.3.2.6].
Moreover, the Service Center can transmit additional texts (e.g. "Please be patient") at any time. The Text
Messages used for this show in their status bytes (see 4.2.3.2) that the contents of the telegram should be
displayed and the BD2ACK timer set back, and that no reply is expected.
Once the message has been sent, the customer has the chance to inform the operator of the cancellation of
the order during subsequent verbal communication. The service center confirms this cancellation (Negative
Acknowledge Message from the service Center) and the terminal device is restored to a neutral status on
receipt of this Negative Acknowledge Message, i.e. the reporting process is terminated. There is no Order
Cancellation Message from the customer.
The Breakdown Assistance service is concluded either by a timer running out (BD1ACK, BD2ACK or
TXTtoACK) or with one of the following messages in the terminal device:
• Calling Request Message
• Acknowledge Message with the value 2 in the status field

Negative Acknowledge Message
• with the value 2 in the status field
As far as the terminal device is concerned, avoid triggering a second breakdown message until the BD1ACK,
BD2ACK and TXTtoACK timers have run out and final confirmation has been received from the Service
Center. The same applies if the ignition is switched off for a short time and switched on again whilst the
BD1ACK, BD2ACK and TXTtoACK timers are running.
4.3.1.2 Breakdown assistance (Fleet customers)

Even in the fleet sector, customer-related plans of action are usually stored at the Service Center, to be used
in the event of a breakdown. These also include breakdown assistances (e.g. tyre service) and the fleet
control center as possible operating partners. The latter is either just informed of the breakdown and confirms
processing of the plan of action, or provides assistance/arranges for assistance at the breakdown location. In
the event of a breakdown, additional information, in the case of fleet vehicles, on the vehicle and cause of the
breakdown can be held and transmitted as an option.
In other cases, the procedure for the Breakdown Assistance for fleet customers is identical to that of the
Breakdown Assistance for individual drivers.
4.3.1.3 Call for Help
The procedures of the Call for Help are identical to the Breakdown Assistance for individual customers except
for the following difference:
The service organisation is chosen by the service center and cannot be chosen individually by the user.
Therefore the proposal and acknowledgement procedure for the choice of the service organisation does not
apply.
4.3.1.4 Emergency call
As with a breakdown, the vehicle ID and location data are transmitted to the Service Center by data telegram
Emergency Call Message
( , coded according to the Assistance Message). Vehicle and driver-related data is
gathered in the Service Center from the master data, in accordance with the vehicle ID. A description of the
current location is taken from the location data by means of map-matching. This description is sent in text
form to the terminal device within the EC1ACK time and with the first Acknowledge Message. It is intended
that, where the position is not yet fully clear, a plain text message with an improved description of the location
shall be sent to the terminal device (Text Message).
As planned for the Breakdown Assistance, destination routing systems for processing emergency calls are to
be used in the vehicle in future as a supplement to the localisation system.
The vehicle position as well as all relevant master data are passed on to the responsible police
station/emergency service (either orally or via an Emergency Call Assistance Message). Driver-related
data comprises, for example, medical data which gives warning of certain risks. The Service Center receives
confirmation from the police station that the data has arrived (orally or via an Acknowledge Message) and
that the necessary action will be taken.
The customer then receives within the EC1xACK time further confirmation that the emergency services have
been alarmed (Acknowledge Message). As far as the terminal device is concerned, the service is now
concluded.
If the customer accidentally presses the emergency call button, he informs the voice operator. In this case,
the voice operator sends a cancellation message to the terminal device (Negative Acknowledge Message).
A cancellation from the terminal device is not possible.
Parallel to the transmission of data, a voice connection between the driver and the Service Center is set up. If
necessary, the Service Center connects the call with the relevant police station/emergency services.
Note: For mobile networks, where parallel set-up of data transmission and voice call is impossible, the data
should be transmitted prior to the establishement of a voice connection.
Until all police and emergency services authorities have been equipped with the relevant infrastructure, it is
necessary to pass on information orally, in the form of a telephone conference call (customer, Service Center,
police/emergency services staff)
If the relevant infrastructure is available, the vehicle, customer and location data can be transmitted in
electronic form to the relevant authority. If necessary, the voice connection between the customer and
Service Center can be subsequently linked up to this authority in the form of a c
...