Traffic and Travel Information (TTI) - TTI messages via cellular networks - Part 1: General specifications

Migrated from Progress Sheet (TC Comment) (2000-07-10): WIs 129-136 are the result of the splitting of WI 025 (TC Res C 1/2000) (CC/000607).
!!! Resolution BT 19/2002: Finalization of prENV ISO 14821-1 as CEN/TS 14821-1 by CMC under CA7 in English only and submitted to the new translation procedure (NT/021014) !!!

Verkehrs- unds Reiseinformationen (TTI)-TTI-Nachrichten über mobile Netzwerke- Teil 1: Allgemeine Spezifikation

Prometne in potovalne informacije (TTI) - Sporočila TTI prek celičnih omrežij – 1. del: Splošne specifikacije

General Information

Status
Withdrawn
Publication Date
30-Sep-2003
Withdrawal Date
01-Dec-2014
Technical Committee
Current Stage
9900 - Withdrawal (Adopted Project)
Start Date
11-Nov-2014
Due Date
04-Dec-2014
Completion Date
02-Dec-2014

Buy Standard

Technical specification
SIST-TS CEN/TS 14821-1:2003
English language
41 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 14821-1:2003
01-oktober-2003

3URPHWQHLQSRWRYDOQHLQIRUPDFLMH 77, 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
---------------------- 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.
---------------------- 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.

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

---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 14821-1:2003
CEN/TS 14821-1:2003 (E)
2 Normative references
Not applicable.
---------------------- 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

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

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.