SIST-TS CEN/TS 14821-1:2003

SLOVENSKI STANDARD
SIST-TS CEN/TS 14821-1:2003
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
SIST-TS CEN/TS 14821-1:2003 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TS CEN/TS 14821-1:2003

---------------------- Page: 2 ----------------------

SIST-TS CEN/TS 14821-1:2003
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.

---------------------- Page: 3 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
2

---------------------- Page: 4 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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.
3

---------------------- Page: 5 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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.
4

---------------------- Page: 6 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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.
5

---------------------- Page: 7 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
2 Normative references

Not applicable.
6

---------------------- Page: 8 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
7

---------------------- Page: 9 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
8

---------------------- Page: 10 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
9

---------------------- Page: 11 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
10

---------------------- Page: 12 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
11

---------------------- Page: 13 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
12

---------------------- Page: 14 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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
13

---------------------- Page: 15 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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.
14

---------------------- Page: 16 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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)
15

---------------------- Page: 17 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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).
16

---------------------- Page: 18 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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.
17

---------------------- Page: 19 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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.
18

---------------------- Page: 20 ----------------------

SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
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 protoco
...