CEN/TS 14821-1:2003

SLOVENSKI STANDARD
01-oktober-2003
3URPHWQHLQSRWRYDOQHLQIRUPDFLMH77,6SRURþLOD77,SUHNFHOLþQLKRPUHåLM±
GHO6SORãQHVSHFLILNDFLMH
Traffic and Travel Information (TTI) - TTI messages via cellular networks - Part 1:
General specifications
Verkehrs- unds Reiseinformationen (TTI)-TTI-Nachrichten über mobile Netzwerke- Teil
1: Allgemeine Spezifikation
Ta slovenski standard je istoveten z: CEN/TS 14821-1: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-1
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2003
ICS 35.240.60
English version
Traffic and Travel Information (TTI) - TTI messages via cellular
networks - Part 1: General specifications
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-1:2003 E
worldwide for CEN national Members.

Table of contents
PAGE
1SCOPE 5
2 NORMATIVE REFERENCES 6
3 DEFINITIONS AND ABBREVIATIONS 7
3.1 Definitions 7
3.2 Abbreviations 9
4 ARCHITECTURAL ELEMENTS 14
4.1 System Overview 14
4.2 Time Base 14
4.3 Communication 14
4.4 Mandatory Terminal Functions 17
4.5 Error Handling 17
ANNEX A. (INFORMATIVE) ARCHITECTURE DESCRIPTION 18
A.1 General 18
A.2 System Overview 18
A.3 Protocol Architecture 19
A.4 Information Flow 20
A.5 Logical Architecture of a Terminal 23
A.6 Logical Architecture of a Service Centre 29
ANNEX B. (INFORMATIVE) BASIC SERVICE OVERVIEW 31
B.1 General 31
B.2 Breakdown Service 31
B.3 Emergency Service 34
B.4 Interactive Traffic Information Services 35
B.5 Broadcast Traffic Information Services 36
B.6 Navigation Services 37
B.7 Operator Services 38
B.8 Floating Car Data Collection 39
B.9 General Information Services 39
BIBLIOGRAPHY 41
Foreword
The document (CEN/TS 14821-1: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 Technical Specification was prepared by Working Group 7 of CEN TC 278. 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 Technical Specifications which allow
manufacturers to introduce competitive products to the market in the knowledge that they can accommodate
the future issues of the Technical Specification(s) without fundamental change to equipment.
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.
In order to utilise even subsets from this Technical Specification and to over co-existence with other,
proprietary protocols as requested by the market, it is planned to introduce an additional layer for routing
purposes. This TLV concept is currently under investigation and may be proposed as an additional part to
this Technical Specification.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this 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 Technical Specification 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 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 Technical Specification 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 standard. 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 Technical Specification 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 Technical Specification provides the framework
for seamless integration of new features and services into the existing architecture.
2 Normative references
Not applicable.
3 Definitions and abbreviations

3.1 Definitions
For the purposes of this Technical Specification, the following terms and 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 Data telegram
Digital message exchanged between two systems
3.1.10 Delivery Notification
Network acknowledgement for successful/ unsuccessful delivery of a message to the mobile device
3.1.11 Functional Road Class
A classification based on the importance of the road element in the connectivity of the total road network
3.1.12 Functional Road Class 0

Motorways
3.1.13 Functional Road Class 1

All non-Motorways that are part of a connection used for nation wide traffic and transport
3.1.14 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.15 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.16 Homing
Simple form of guidance to destination, in which the direction and
straight-line distance of the destination are indicated
3.1.17 Information Element
Information unit of a message
3.1.18 Intersection
Junction of two or more roads
3.1.19 Length of a Speech Report
Length of a Speech Report, including pauses, in tenths of a second
3.1.20 Mobile Originated
Data telegram sent from the onboard equipment to the Service Centre.
3.1.21 Mobile Terminated
Data telegram sent by the Service Centre to the onboard equipment.
3.1.22 Onboard equipment
A system, generally mobile, interacting with the service centre to handle traffic telematics services
3.1.23 Road Junction
Intersection of two or more roads
3.1.24 Route description
Description of a route showing the geometry of street intersections, manoeuvre instructions, street and place
names, and geographical co-ordinates
3.1.25 Service centre
System produced by the traffic telematics operators / service providers to handle traffic telematics services
3.1.26 Short Message Service
Packet-based form of data transfer within the GSM network
3.1.27 Speech connection
Communications channel between two systems for the bi-directional transmission of speech
3.1.28 Speech Report
Traffic Information Report transmitted by a speech system
3.1.29 Terminal Device
Generally mobile system interacting with the service centre for implementation of telematics services
3.1.30 TINFO
Traffic Information Report
3.1.31 TINFO Version
Unique identification of a Traffic Message, consisting of a number and a time stamp
3.1.32 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.33 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.34 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.35 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.36 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.37 Voice connection
Circuit-switched channel between two systems for bi-directional voice transmission
3.1.38 Waypoint
Significant points on the route
3.2 Abbreviations
For the purpose of this Technical Specification, 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 ICV
Initial Chaining Value
3.2.30 L_max
Max. length of transferable data in one data transaction
3.2.31 MAC
Message Authentication Code
3.2.32 MNA
Mobile Network Address
3.2.33 MF
Mandatory Fixed format
3.2.34 MO
Mobile Originated Message
3.2.35 MT
Mobile Terminated Message
3.2.36 MV
Mandatory Variable format
3.2.37 N_min
Minimum number of ELB waypoints
3.2.38 OBU
Onboard Unit, synonymously used telematics device, telematics terminal
3.2.39 OF
Optional Fixed format
3.2.40 OV
Optional Variable format
3.2.41 PDU
Protocol Data Unit
3.2.42 PFA
Probability of false alarm (i.e. estimated error is too large)
3.2.43 PMD
Probability of missed detection (i.e. estimated error is too small)
3.2.44 RSA
Asymmetrical encryption procedure by Rivest, Shamir and Adleman
3.2.45 SAE
Society of Automotive Engineers, Inc.
3.2.46 SMS
Short Message Service
3.2.47 SMSC
SMS Centre
3.2.48 SV
Space Vehicle
3.2.49 TEG
Telematics Expert Group – Group within the WAP-Forum Ltd.
3.2.50 TINFO
Traffic Information Report
3.2.51 TOC
Telematics Operator Code
3.2.52 TRP
Transport Protocol
3.2.53 TT
Traffic telematics
3.2.54 TTI
Traffic and Traveller Information
3.2.55 TTFF
Time to First Fix
3.2.56 UTC
Universal Time Co-ordinated
3.2.57 VDS
Virtual Detection Site
3.2.58 vel, V
Velocity
3.2.59 VIN
Vehicle Identification Number
3.2.60 WAP
Wireless Application Protocol
3.2.61 WGS84
World Geodetic System 84
4 Architectural elements
This section defines normative architectural elements.
4.1 System Overview
The general Architecture can be understood as a client-server architecture with communication using
(cellular) mobile radio networks.
The clients are vehicles, equipped with telematics terminals. These terminals have the capability to determine
their position in real time.
On the servers side special service centres provide information to the clients or perform special actions if
requested. It may have external interfaces to third parties. These interfaces are not part of this Technical
Specification.
The communication model for data transmission between terminal and service centre is message-oriented,
which is well suited for (but not limited to!) connectionless transmission. Two modes are supported:
1. Point-to-Point data communication between a terminal and the service centre.
2. A broadcast channel may be used for information and parameter distribution.
Additionally voice communication is used for certain applications, which includes automatic call set-up by the
terminal.
4.2 Time Base
The common time base for server and clients is UTC. This time base is used, whenever time stamps (or
similar information) are transmitted over the air interface.
4.3 Communication
4.3.1 Protocol Architecture
The so-called lower layers (in OSI terminology: physical, data link, network) are taken from existing
communication systems. Consequently they are not part of this Technical Specification.
The upper layers are designed to meet the requirements of telematics. The separation of layers is not as
strict as it would be in an OSI architecture. Redundant information (e.g. length information) may be omitted in
the transmitted protocol data unit in order to conserve bandwidth. The receiving party takes this information
from a layer below.
Service Center Terminal
Application Application
Application Data Protocol Application Data Protocol
CAS Protocol CAS Protocol
Transport Protocol Transport Protocol
Lower Layers Lower Layers
(defined by existing (defined by existing
Communication System) Communication System)
Figure 4-1: Protocol Architecture (point-to-point)
Service Center Terminal
Application Application
Application Data Protocol Application Data Protocol
CAS Protocol CAS Protocol
Lower Layers Lower Layers
(defined by existing (defined by existing
Communication System) Communication System)
Figure 4-2: Protocol Architecture (Broadcast)
4.3.2 Bit Ordering
The protocols of this Technical Specification (ADP, CAS Protocol, Transport Protocol) are bit-oriented. For
transmission and representation in octets the bit ordering is specified as follows:
The bit number within an information element decreases with rising octet number.
Within an octet the bit number decreases with decreasing bit number.
That is, the MSB is represented by the highest numbered bit of the lowest numbered octet; the LSB is
represented by the lowest numbered bit of the highest numbered octet.
Bit-No.: 7 654 321 0
Octet fl
MSB fifififi
fifififi fifififi
fiLSB
Figure 4-3: Bit-Ordering
4.3.3 Functions and their Controlling Elements

Routing / Application Addressing is done exploiting the Application ID (IE of the Transport Protocol
Header). Thus this function is independent from the message type on the ADP level allowing different
services to use the same message types.
Relation to Service Context: To relate a received message to a context already established (e.g. an answer
to the request) the combination of Application ID and Context Number is analysed. On the service centre
side, also the communication address of the calling party or the equipment ID must be taken. The Initiative
Flag indicates, whether previous exchange of messages has taken place.
Target Addresses of outgoing messages are taken from the parameter database. The same holds for the
call address if a speech connection is established from the terminal.
The determination of Protocol Version (mainly for upward compatible modifications) and Syntax is done as
follows:
• Transport Protocol: exploiting the Transport Protocol Discriminator (first byte of TPDU)
• CAS Protocol: exploiting the CAS Protocol Discriminator (first 4 bit of CAS PDU)
• Application Data Protocol: The version is determined from the IE ADP Version within the Transport
Protocol Header (point-to-point only). Afterwards the message type, defining syntax and semantics of the
application data, is determined by the ADP message header (within the first 2 bytes of the ADPU).
Packaging / Reassembly: The transport protocol for point-to-point communications allows to send
messages not fitting into a single packet of the underlying communication network or service. Each packet is
sent as an independent TPDU. Reassembly of the CAS PDU is done by exploiting the IEs Application ID,
Context Number, Index of actual Packet and Total Number of Packets (all IEs of the TP header). Due to the
structure of the transport header the following restrictions apply:
• It is not possible to transmit more than one series of packets within one service context at the same time.

• Single packets can be transmitted in parallel to a series of packets because they do not require
reassembly.
• Incomplete series have to be deleted from the buffer in the communication handler after a predefined
period of time. This timer is not yet specified due to lack of experience on timing behaviour of data
telegrams, but a relatively long value is recommended (< 30 minutes).
All information related to Conditional Access and Security can be obtained from the information of the CAS
Header and the Application ID.
Mailbox and Debit Info are included in the header of the transport protocol for further use.
4.4 Mandatory Terminal Functions
4.4.1 Mobile Radio Interface
The mobile terminal must support voice and data communication via cellular radio.
The following functions must be supported by the mobile radio interface:
• automatic (voice) call set-up
• access to call status
• automatic call termination
If a calling line identification is provided by the network, this must not be suppressed for traffic telematics
services. If other settings in the mobile radio equipment may exist, the terminal must be able to override
these settings.
4.4.2 Conditional Access and Security

The terminal must support the following functionality:
• Access Control to services for both mobile terminated and mobile originated messages
• Encryption and Decryption according to access parameters
• Configuration Management: administration and update of communication addresses, access parameters,
control parameters, master data.
• Key Management: exchange and storage of keys in a secured environment

4.4.3 Diagnostics
The terminal must support remote diagnostics, providing on request a history of positioning quality measures
from the positioning module and on error behaviour from the communication handler.
4.4.4 Positioning and Localisation

The terminal must have the capability of autonomous positioning. Minimum requirements are defined in
CEN/TS 14821-7.
Furthermore it must be able to store information on the last travelled distance and assemble an extended
location block.
4.5 Error Handling
The terminal must support a unified error handling procedure.
The service centre indicates errors to the terminal by sending a general error message (a service-
independent application message) to the terminal. This message shall be forwarded to the service module.
The related service context must be aborted after processing the message. Further actions may be taken by
the service module. If the error is not handled automatically, it shall be displayed to the user in an appropriate
way and without further delay.
Errors that do not force an abortion of the service context must be handled within the service itself. All related
procedures are part of the service specification.
Annex A.
(informative)
Architecture Description
A.1 General
After a brief overview of the system concept (A.2) the functionality of the protocol layers will be described
(see A.3) followed by a more detailed description of the communication handling, which is basically identical
on both sides (see A.4). The more detailed architecture is described here in terms of terminal functionality
(A.5). This of course will have a great impact on hardware and software architecture of a concrete
implementation but does not limit the design as long as the functionality can be supported. The architecture of
a service centre will be quite similar, although additional functionalities have to be added (e.g. customer
administration). A brief overview of the service centre architecture will be given in A.6.
A.2 System Overview
The general Architecture can be understood as a client-server architecture with communication using
(cellular) mobile radio networks as illustrated in Figure A-1.
The clients are vehicles, equipped with telematics terminals capable of independent real-time positioning
using satellite navigation (GNSS) and optionally additional sensors for independent positioning.
On the servers side special service centres provide information to the clients or perform special actions if
requested. It may have external interfaces to third parties. These interfaces are not part of this Technical
Specification.
Common Time Base: UTC
GNSS Positioning
External
Interfaces
equipped Vehicle
Service Center
Cellular Mobile
Radio Network
Figure A-1: System Overview
The communication model for data transmission between terminal and service centre is message-oriented,
which is well suited for (but not limited to!) connectionless transmission. Two modes are supported:
Point-to-Point data communication between a terminal and the service centre.
A broadcast channel may be used for information and parameter distribution.
Additionally voice communication is used for certain applications.
UTC is used as a common time base for server and clients.
A.3 Protocol Architecture
This Technical Specification defines a stack of three traffic telematics specific protocol layers on top of
existing communication networks as described in 4:
• Application Data Protocol
• CAS Protocol
• Transport Protocol
The functionality of these protocols will be described in the following subsections.
A.3.1 Transport Protocol
Two transport protocols are defined: the „Standard Transport Protocol“ and the „Tiny Transport Protocol“
intended for broadcast or other low-bandwidth channels.
The standard transport protocol offers the following functionality to the layers above:
Routing of data to the addressed service module within the terminal or service centre; identification of the
service
Relation of a message to a service context or identification of initiative messages
Packaging / Reassembly
Identification of Application Data Protocol Version (in order to allow further development)
The first two are related to the client-server behaviour of most telematics services. The third one shall enable
transmission of messages that do not fit into a single packet. The transport protocol does not ensure error
free delivery, i.e. timeouts and undelivered messages must be handled within the application itself. This is a
consequence of the fact that the transport protocol is used for services with very different timing and security
requirements. The reception of one data packet shall be indicated to the destination application, so that a
restart of a timer and the adaptation of timeouts to the actual number of packets can be triggered by that
application.
Additionally a mailbox flag is included for future extensions: indication whether messages are stored within a
mailbox at the service provider.
The tiny transport protocol provides:
Routing of data to the addressed service module within the terminal or service centre; identification of the
service
Identification of Application Data Protocol Version (in order to allow further development)
Packaging / Reassembly may be implemented based on capabilities of the underlying bearer.
A.3.2 CAS Protocol
CAS stands for "Conditional Access and Security". This layer provides all functionality related to encryption,
authentication and integrity of messages. The CAS header provides information concerning the used
features, which is necessary to decrypt the message.
The CAS header provides key information and supports dynamic and individual key selection. Data may also
be transmitted without encryption, if the security of underlying networks is sufficient. In this case the overhead
introduced by the CAS header is very low.
The following encryption algorithms are supported:
1. Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode according to ISO/IEC 10116

2. Triple Mode DES according to ISO 11568-3

3. RSA
The CAS protocol supports dynamic and individual key selection. The information necessary to perform the
key selection on the receiver side is transmitted within the CAS header.
In case of DES encryption a message authentication code (MAC, according to ISO/IEC 9797; in triple mode
according to ISO/IEC 9797 annex A) can be transmitted to ensure integrity and authentication. Its length can
be chosen to be 32 bit or 8 bit respectively. In the latter case the MAC may only be used as a checksum to
ensure integrity. The triple mode may be selected independently for DES encryption and MAC.
No length of user data is transmitted within the CAS header; this information has to be taken from the TP
header.
To meet the special requirements of broadcast communication, two dedicated modes are defined, supporting:
1. Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode according to ISO/IEC 10116

2. Triple Mode DES according to ISO 11568-3

Dynamic key selection is supported. The information necessary to perform the dynamic key selection on the
receiver side is transmitted within the CAS header. In case of DES encryption a MAC is used in the same
way as for point-to-point transmission except for the fact that triple mode cannot be chosen independently for
encryption and MAC.
A.3.3 Application Data Protocol
The general service concept is based on exchange of small packets of data. The application data protocol
(ADP) specifies the coding of these messages. Therefore, in the first place protocol design is a
transformation of intended information flow into concrete message formats and thus service dependent.
A.4 Information Flow
This section covers the communication handling of a terminal from the viewpoint of functions and graphically
outlines the flow of information necessary to perform the various operations. The different operations are
given as boxes. User data and PDUs (on either of the three protocol layers) are displayed with black arrows.
Additional information obtained from received data is displayed with grey arrows. From those, the elements
used to perform a certain task are given within the corresponding box. In Figure A-5 an abstract architecture
of the communication handler is displayed.
...
Service N
Service 1
Application ID
ADPU
Context Number
(data + length)
Initiative Flag
ADP Version
Multiplexing
Application ID
ADPU
Context Number
(data + length)
Initiative Flag
ADP Version
Access Control &
Ciphering
Keys
uses: Application ID
CAS Parameter
Keys
Parameter
Application ID
CAS PDU
Context Number
(data + length)
Initiative Flag
ADP Version
Coding Transport
Protocol
uses: Application ID
Context Number
Initiative Flag
ADP Version
Application ID TPDU(s)
Communication Interface
GSM Interface
Parameter
uses: Application ID
Address Parameter
Message
Figure A-2: Information flow (send)
...
Service N
Service 1
Application ID
ADPU
Context Number
(data + length)
Initiative Flag
Routing /
ADP Version
Demultiplexing
uses: Application ID
Application ID
Context Number
ADPU
Initiative Flag
(data + length)
ADP Version
Keys
Access Control &
Ciphering
uses: Application ID
Parameter
Originator Address
Application ID
CAS PDU
Context Number
(data + length)
Initiative Flag
ADP Version
Reassembly
Originator Address
uses: Application ID
Context Number
Index of Packet
Application ID
Total No of Packets
Context Number
Initiative Flag
single packet
ADP Version
(user data + length)
Index of Packet
Total No of Packets
Decoding
Originator Address
Transport Protocol
incoming TPDU
Originator Address
Communication Interface
GSM Interface
Figure A-3: Information Flow (Receive: Standard Transport Protocol)
...
Service N
Service 1
Application ID
ADPU
ADP Version
(data + length)
Routing /
Demultiplexing
uses: Application ID
Application ID
ADPU
ADP Version
(data + length)
Access Control &
Keys
Ciphering
: Application ID
uses
Originator Address
Parameter
(GSM: Cell Broadcast
Message ID)
CAS PDU
Application ID
(data + length)
ADP Version
Originator Address
Reassembly
uses: Application ID,
Information on
fragmentation, taken
from underlying bearer
Application ID single packet
(user data + length)
ADP Version
Originator Address
Decoding
Transport Protocol
incoming TPDU
Originator Address
(GSM: Cell Broadcast
Message ID)
Communication Interface
GSM Interface
Figure A-4: Information Flow (Receive: Tiny Transport Protocol)
A.5 Logical Architecture of a Terminal
The logical architecture defines the functionality of a terminal compatible to the standardised traffic telematics
services. This is done by specifying the components as well as their interactions and interfaces on an
abstract level. A block diagram is given in Figure A-5. The components that are part of this Technical
Specification are displayed grey:
• dark grey: components related to user services and floating car data collection
• light grey: service-independent components for administration and handling

The components displayed as white blocks are not part of this Technical Specification although some
requirements may be listed.
Some service-independent units (Configuration Management, Key Management and Diagnostics) have
persistent databases. Access to those data is modelled to be carried out via an interface included in the
corresponding module. Non-persistent storage of data is not modelled explicitly on this level of abstraction.
Internal communication between different modules is indicated by a bus-like connection but not modelled in
detail within this architecture definition. Interfaces and corresponding information flows are listed below.
MMI
User Services
Perm. Data
FCD Unit
Positioning Localization
Module
Sensors
Terminal
Diagnost. DB
Diagnostics
Configuration
Parameter DB
Management
Key
Key DB
Management
Access Control
Communication
and Ciphering
Handler
Conditional Access &
Security Module (CAS)
GSM Module /
Cellular Phone
Figure A-5: Logical Architecture
A.5.1 User Services
The modules for different services are modelled as independent units. They perform all operations specific for
the service(s) in question, e.g.
• Sending Requests (including interaction with the user)

• Processing Replies or other received messages (including display of information to the user)
• Administration of Speech Connections
• Error handling
Internal Data
Transfer
Messages (ADP) from/to Service Center

or any other operations to be performed. Details are specified within the service specifications. Control of the
functionality is possible to some extent using parameters (see 0, „A.5.5.1 Configuration
Management“).
A user service module has the following interfaces:
• to Communication Handler: sending and receiving messages
• to Communication Handler (in case of broadcast services): polling of time since last received packed
• to Configuration Management: reading parameters from Parameter Database

• to Configuration Management: reading access status

• to MMI: choice of service options, presentation of information
• to Localisation Module [only if required]: obtain current position or data to form an extended location block
Service requests are typically triggered by the user, but triggering from other services is possible as well.
A.5.2 FCD Unit
The Floating Car Data Unit collects data from the localisation module (position, velocity,.) and transmits
relevant information to the service centre. Specific algorithms are installed to detect incidents to be reported
(in order to reduce communication volume) and to extract parameters appropriate for the description.
In terms of functionality and interfaces the Floating Car Data Unit (FCD) is similar to a user service module
(except for the fact that no MMI is involved).
A.5.3 Localisation Module
This module provides the following information to calling modules:
• data on current position, velocity and heading

• optimised data for precise localisation (extended location block)
Furthermore the module periodically forwards results from quality measurements to the Diagnostics module.
This module relies on input from positioning sensors. Technology-independent requirements are part of this
Technical Specification. These requirements address quality parameters like accuracy, availability and
continuity. Special requirements may be listed for some services.
A.5.4 Diagnostics
An additional internal service offers diagnostic information to the service centre. This module gets data on
positioning quality measures from the navigation module and on error behaviour from the communication
handler. The task of the diagnostic module is to store a history of positioning quality estimates and failed
communication transactions.
Additionally the transmission of terminal-specific data is possible, but related specifications are not part of this
Technical Specification.
A.5.5 Conditional Access and Security
A.5.5.1 Configuration Management
This unit is responsible for managing and updating the following kinds of parameters:
• Communication Addresses (of service provider incl. addresses for use of services in foreign countries)
• Access Parameters (e.g. encryption method required)

• Control Parameters (e.g. timer, supported features)

• Master Data (identifying the vehicle)
It offers an interface to other components of the terminal (communication handler, service modules, FCD unit,
terminal diagnostics) to read out parameters from the internal parameter database. A similar interface is
offered to the access control and ciphering unit.
For update of parameters it offers the internal services Configuration Update and Master Data Update. In this
context the interface to the communication handler is similar to a user service module. Service requests may
be triggered from other components. Furthermore a parameter update is possible in connection with key
update. For this reason an interface to the key management unit exists.
A.5.5.2 Access Control and Ciphering
This unit is responsible for all operations related to access and security of received or sent messages. These
operations are carried out in a secure environment. In the future these functions may be located on chip
cards.
1. Access Control: For mobile terminated messages the accessibility of the requested service is checked.

Within this operation the originator address and the parameters of the CAS protocol are checked and
compared to the stored access parameters.
For mobile originated messages a check of service availability is performed. If necessary a configuration
update or key update is initiated.
Encryption: The CAS unit takes care of coding and decoding of the CAS protocol including
2.
encryption/decryption of application data. This includes derivation of dynamic and individual session keys.
The base keys are obtained from the key management unit.
3. Debiting / Electronic Payment: If debiting or electronic payment will be included, all security relevant

operations also are carried out within the Conditional Access and Ciphering unit.
The operations are invoked by the communication handler and the results are returned to this handler
(exception: messages related to key management are directly sent to or received from the key management
unit).
A.5.5.3 Key Management:
This unit is responsible for exchange and update of keys and their storage within the secured environment:
• exchange of keys between terminal and service centre. This can be seen as a basic function. In contrary
to other services the external interface on the application data protocol level is within the secured
environment, because keys must not leave the secured environment unencrypted. Therefore the Access
Control & Ciphering unit sends the decrypted application data directly to the key management unit and
vice versa. Key updates may contain configuration data, which are forwarded to the configuration
management.
• storage of keys
• providing base keys to the ciphering unit

A.5.6 Communication Handler
This module acts as an interface between the cellular phone on one side and the service units (both user
services and central components) on the other side. It sends and receives messages via the mobile radio
network and takes care of the protocol handling below the Application Data Protocol Layer. The architecture
of the communication handler is closely related to the protocol architecture. For this reason this section
describes only the functional componen
...