SIST-TS CEN/TS 14821-4:2003

Traffic and Travel information (TTI) - TTI messages via cellular networks - Part 4: Service-independent protocols

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.

Verkehrs- und Reiseinformationen (TTI)-TTI-Nachrichten über mobile - Teil 4: Dienstleistungsunabhängige Protokolle

Prometne in potovalne informacije (TTI) - Sporočila TTI prek celičnih omrežij – 4. del: Storitveno neodvisni protokoli

General Information

• Status: Withdrawn
• Publication Date: 30-Sep-2003
• Withdrawal Date: 01-Dec-2014
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 9900 - Withdrawal (Adopted Project)
• Start Date: 11-Nov-2014
• Due Date: 04-Dec-2014
• Completion Date: 02-Dec-2014
• Mandate: M/018 - Standardization Mandate forwarded to CEN/CENELEC/ETSI in the field of Information Technology and Telecommunications concerning Road Transport and Traffic Telematics
• Ref Project: CEN/TS 14821-4:2003 - Traffic and Travel information (TTI) - TTI messages via cellular networks - Part 4: Service-independent protocols

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 14821-4:2003
01-oktober-2003
3URPHWQHLQSRWRYDOQHLQIRUPDFLMH77,6SRURþLOD77,SUHNFHOLþQLKRPUHåLM±
GHO6WRULWYHQRQHRGYLVQLSURWRNROL
Traffic and Travel information (TTI) - TTI messages via cellular networks - Part 4: Service
-independent protocols
Verkehrs- und Reiseinformationen (TTI)-TTI-Nachrichten über mobile - Teil 4:
Dienstleistungsunabhängige Protokolle
Ta slovenski standard je istoveten z: CEN/TS 14821-4: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-4: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-4:2003

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

SIST-TS CEN/TS 14821-4:2003
TECHNICAL SPECIFICATION
CEN/TS 14821-4
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2003
ICS 35.240.60
English version
Traffic and Travel information (TTI) - TTI messages via cellular
networks - Part 4: Service-independent protocols
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-4:2003 E
worldwide for CEN national Members.

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
Table of contents
PAGE
TABLE OF CONTENTS 2
FOREWORD 3
INTRODUCTION 4
1. SCOPE 5
2. NORMATIVE REFERENCES 6
3. DEFINITIONS AND ABBREVIATIONS 6
3.1 Definitions 6
3.2 Abbreviations 8
4. SERVICE - INDEPENDENT PROTOCOLS 13
4.1 General Definitions and Information Elements 13
4.2 Specification in ASN.1 22
5. ADP FOR SERVICE - INDEPENDENT MESSAGES 28
5.1 General Definitions and Information Elements 28
5.2 Specification in ASN.1 34
BIBLIOGRAPHY 43
2

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
Foreword
This document (CEN/TS 14821-4: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 This Technical Specification was
prepared by Working Group 7 of CEN TC278. In the field of Traffic and Traveller Information, the
innovative rate is high, with many research and development projects under way in many countries, and
there is a need to establish prospective standards which allow manufacturers to introduce competitive
products to the market in the knowledge that they can accommodate the future issues of the standard(s)
without fundamental change to equipment.
No known national technical specifications (identical or conflicting) exist on this subject.
CEN/TS 14821 consists of eight parts; one part describing the framework and seven parts providing
detailed specifications of all components, protocols and services that are within the scope of CEN/TS
14821.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to announce this CEN Technical Specification: Austria, Belgium, Czech
Republic, Denmark, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Luxembourg,
Malta, Netherlands, Norway, Portugal, Slovakia, Spain, Sweden, Switzerland and the United Kingdom.
3

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4: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 a
network-specific part (CEN/TS 14821-8). With the development of future mobile communication
systems towards UMTS / IMT2000 the bottleneck of narrow-band data communication might fade. Due
to its modular structure, the GATS framework and applications are prepared for that due to its network-
independence. The same holds for emerging technologies for positioning which today is almost
exclusively based on GPS.
Other relevant standard developments are, independent from telematics, the application-independent
Wireless Application Protocol (WAP), enabling mobile access to the Internet. It is understood that these
emerging technologies might fit into the framework of telematics applications in future WAP-versions.
For the time being, GATS already today independently from WAP enables access to telematics
services. Utilisation of GATS on a WAP protocol stack and identifying necessary adaptation of WAP
specifications (if any) is currently under investigation of the appropriate groups within WAP-Forum and
GATS-Forum.
4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
4. Service - Independent Protocols

4.1 General Definitions and Information Elements
4.1.1 Transport Protocol

4.1.1.1 Functionality of Transport Protocol

The standard transport protocol is optimized for packet-oriented communication with low bandwidth. It
offers the following functionality to the layers above:
• Packaging
• Routing of data within the terminal or service center; definition of the service
• Relation of a message to a service context

• Indication of the Application Data Protocol Version
• Transmission of additional data (Mailbox-Flag) used for all services.
The tiny version, planned for broadcast services offers less functionality:
• Routing of data within the terminal or service center; definition of the service
• Indication of the Application Data Protocol Version

• Time since last received Broadcast PDU
• Packaging is only possible if features of the underlying bearer allow reassembly.
4.1.1.1.1 Packaging
The following examples illustrate the packaging mechanism. For the transport protocol CAS and
application data are handled as transparent user data. Reassembly is performed on the basis of the
combination of the application ID and the complete IE context number.
• Single Packet
User Data (CAS + ADPU)
Coding: Transport Layer
Transport-
User Data (CAS + ADPU)
Header
• Multiple Packets:
User Data
Coding: Transport Layer
Transport- Transport- Transport- User Data
User Data (1. Part) User Data (2. Part)
...
Header Header Header (last Part)
4.1.1.1.2 Routing of Data for Services

A terminal or a service center may implement more than one service. Therefore, addressing of services
becomes an issue. The transport PDU carries an Application Identifier value to unambiguously
distinguish services from each other.
13

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
These services may be related to one another but this is not necessarily the case. Because of this
independence, any device must be prepared to receive requests for more than one service in parallel.
This may involve special buffer handling procedures if packaging is required for the services.
4.1.1.1.3 Service Context

Several transactions may be carried out simultaneously by the same application. These are referred to
as service contexts. The relation of an application message to a service context is done unambigiously
by exploiting the combination of Application ID and the fields Context Originator, Context Sequence
Number from the IE Context Number.
This is done at application level. Therefore the complete information of the context number is available
for the application.
A terminal must be prepared to receive data unsolicitedly (on both existing and new service contexts).
This is not only true for broadcasting applications but may happen with data updates for arbitrary
applications. The terminal’s buffer management procedures must be able to deal with these situations.
4.1.1.1.4 Time since last received Broadcast PDU

For broadcasting applications it is vital to know about the availability of the broadcast channel. Any
terminal implementing a broadcast transport protocol must record date and time of the last broadcast
PDU received, independent of the application that PDU is addressed at, so that the transport layer can
return (on request of an application) the number of seconds elapsed since the last broadcast PDU
received.
4.1.1.1.5 Transmission of Additional Data

See the individual transport PDU descriptions.
4.1.1.2 Standard Transport PDU
4.1.1.2.1 Transport Protocol Discriminator

The discriminator is used to distinguish between different types and versions of transport protocols.
The assigned value is 2 hex.
4.1.1.2.2 Application ID

The Application ID identifies the service for routing within the receiving unit (server or terminal). As this
can be seen as a target application, the correct ID must be known to the initiating unit.
4.1.1.2.3 ADP Version

This IE is used to distinguish between different versions of the application data protocol on this level.
4.1.1.2.4 Initiative Flag

If the transmitted message is an initiative message (e.g. a service request) this flag is set to 1. If it is a
message within a service context already established (e.g. an answer) the flag is set to 0.
4.1.1.2.5 Context Number

The context number identifies a service context and allows to distinguish between different application
messages sent within this context. It has the following structure:
4.1.1.2.6 Context Originator

This flag indicates the originator of the service context to avoid collisions from context numbers
generated at the same time from the terminal and service centre:
Figure 4-1: Flag originator
Value Originator
0 Service Centre
1 Terminal
The initiating unit that has to take care that no collisions occur.
14

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
4.1.1.2.7 Context Sequence Number

The number is defined by the initiating unit that has to take care that no collisions occur. It remains
constant over the complete service context.
4.1.1.2.8 Message Sequence Number

Sequence number of the application messages sent from this entity within the service context. Each
party starts with sequence number 0 and increments it for every new message (with cyclic overflow: 7 is
followed by zero).
4.1.1.2.9 More Flag

This flag may be used to support the terminal in cases more than one application message is sent at the
same time or following one another immediately.
4.1.1.2.10 Total Number of Packets

The number of TPDUs N is calculated from the transmitted unsigned integer X as N = X + 1. Therefore
the number of packages may vary in the range 1 . 32.
4.1.1.2.11 Index of Current Packet

The index is calculated from the transmitted unsigned binary number X as: index = X + 1 (⇒ range of
index: 1 . 32). The first packet gets the index 1.
4.1.1.2.12 Mailbox Flag

This flag is set to 1 if the customers mailbox contains at least one message. Otherwise it is set to zero.
The mailbox flag currently is not used for GATS-applications defined in CEN/TS 14821-6.
4.1.1.2.13 Maximum Length Indicator / Length of User Data

It is possible to support short and long packages.
This is indicated to the receiver, using the flag „Maximum Length Indicator“; the IE Length of user data is
transmitted with a field length corresponding to the maximum packet length:
Figure 4-2: Flag: maximum length
Maximum Length Maximum Length of User Width of IE
Indicator Data per packet Length of User Data
0 255 byte 8 bit
1 65535 byte 16 bit
The length of user data for the current packet is submitted as an unsigned binary number.
4.1.1.3 Tiny Transport PDU for Low Bandwidth Channels
The tiny transport PDU defined here can be used if the limitations of the communication channel do not
allow for the standard transport protocol (see 4.1.1.2) and the following features are not needed:
• Relation of message to a service context,
• Transmission of additional data.

This transport PDU may typically be used with Broadcast Services. In that case, multiple pages may be
combined to a longer PDU (marcopage). Even if such page concatenation is used, all of these pages
carry a transport header.
Terminals shall assume unique service contexts with each page (macropage resp.).
4.1.1.3.1 Transport Protocol Discriminator

The discriminator is used to distinguish between different types and versions of transport protocols.
The assigned value is 3 hex.
4.1.1.3.2 Length of User Data

The length (in byte) of user data within the packet is given as an unsigned binary number (range 0 .
127 byte).
15

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
4.1.2 CAS Protocol
A unified CAS protocol is used. The CAS PDU has the following format.:
4.1.2.1 CAS Protocol Discriminator
The discriminator is used to distinguish between different types and versions of CAS protocols. The bits
are set to 0010 (binary) for this version of general purpose CAS protocol.
4.1.2.2 Encryption Method
This value defines the encryption method used and acts as a switch to control the presence of other IEs
in the CAS PDU.
The selection of cryptographic algorithms is defined as follows:
Table 4-1: Cryptographic algorithms
Code 01 234567
Name NO_ENC RSA DES1 DES2MAC DES2ENC DES2FULL DES1BC DES2BC
Encryption no RSA DES DES DES DES DES DES
method encryption
Triple MAC -- -- no yes no yes no yes
Triple Cipher -- -- no no yes yes no yes
time stamp for -- -- per hour per hour per hour per hour per day per day
key dynamiza-
tion
4.1.2.2.1 Control of Triple MAC Generation and Triple Ciphering
If the Triple MAC Feature is activated (yes) the information element MAC is calculated by using Triple
MAC method with a double length key, otherwise (no) standard MAC calculation with a single length key
is used.
If the Triple Ciphering Feature is activated (yes) user data are encrypted by using Triple DES method
with a double length key, otherwise (no) standard DES ciphering with a single length key is used.
Triple mode MAC generation / DES ciphering needs a double length MAC/DES transaction key to be
calculated from double length MAC/DES base keys. If the base keys referenced by the Key Generation
Number are double length keys and the Triple MAC / Triple ciphering feature is deactivated (set to no),
standard length MAC/DES transaction keys are to be calculated.
If the base keys referenced by the Key Generation Number are standard length keys the MAC
calculation / DES ciphering using a double length MAC/DES transaction keys is not possible and the
Triple Mode option shall be ignored for the short key(s).
16

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
The presence of other information elements in the CAS PDU is defined as follows:
Table 4-2: Definition of other data elements in the CAS PDU
Code 01 234567
Name NO_ENC RSA DES1 DES2MAC DES2ENC DES2FULL DES1BC DES2BC
Flag Equip- Yes yes yes Yes yes yes no no
ment ID
Flag MAC No no yes Yes yes yes yes yes
Length
Spare No no yes Yes yes yes no no
EquipmentID Yes/no yes yes/no yes/no yes/no yes/no no no
MCC Yes yes yes Yes yes yes no no
TOC Yes yes yes Yes yes yes no no
Key Gene- No yes yes Yes yes yes yes yes
ration Number
Key No no yes Yes yes yes yes yes
Parameter
MAC No no yes Yes yes yes yes yes
Length No no yes Yes yes yes no no
Information
4.1.2.3 Flag Equipment ID
This IE is only present if the encryption method is not set to DES1BC or DES2BC. It controls the
presence of the IE Equipment ID (see 4.1.2.5) and the key dynamization process.
• In case of DES:
Flag Meaning
0 Equipment ID is not present;
non-individual key dynamization process
1 Equipment ID is present and
is used for individual key dynamization process
• In case of no encryption:
Flag Meaning
0 Equipment ID is not present
1 Equipment ID is present
• In Case of RSA:
The IE Equipment ID shall always be present, the flag shall be set to 1.
4.1.2.4 Flag MAC Length
Controls the length of the IE MAC (see 4.1.2.9). This IE is only present in case of DES, i.e. if the
encryption method is not set to NO_ENC or RSA.
17

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

SIST-TS CEN/TS 14821-4:2003
CEN/TS 14821-4:2003 (E)
4.1.2.5 Equipment ID
The Equipment ID is a number identifying the terminal equipment and individual cryptographic keys.
This IE is only present, if the Flag Equipment ID is set to 1.
If in the case of RSA the terminal is in the „no operator assignment“ state (see CEN/TS 14821-5) it shall
set the IE to the value Initial Equipment ID for MO messages. Otherwise the Temporary Equipment ID is
to be used.
4.1.2.6 Mobile Country Code, Telematics Operator Code
The Mobile Country Code (MCC) and the Telematics Operator Code (TOC) are numbers which are
used to identify the telematics operator. The presence of these IEs depends on the encryption mode.
They are present except for encryption modes DES1BC, DES2BC (see Table in 4.1.2.2).
If in the case of RSA the terminal is in the „no operator assignment“ state (see CEN/TS 14821-5) it has
no actual value for MCC/TOC; the IEs shall be set to zero for MO messages.
4.1.2.7 Key Generation Number
This parameter controls the key selection at the receiver. This IE is only present, if the Encryption
Method is not set to NO_ENC.
4.1.2.8 Key Parameter
This parameter is used to generate dynamic transaction keys in case of DES ciphering and/or MAC
generation. This IE is only present, if the Encryption Method is not set to NO_ENC or RSA.
4.1.2.9 MAC
The MAC is used as a cryptographic checksum to ensu
...