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
06-May-2003
Withdrawal Date
28-Oct-2014
Current Stage
9960 - Withdrawal effective - Withdrawal
Completion Date
29-Oct-2014

Buy Standard

Technical specification
-TS CEN/TS 14821-4:2003
English language
42 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-4:2003
01-oktober-2003

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

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

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

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

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

Questions, Comments and Discussion

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