ISO/TS 14822-1:2006

Traffic and Travel Information - General specifications for medium-range pre-information via dedicated short-range communication - Part 1: Downlink

ISO 14822-1:2005 addresses the passive DSRC issues associated with Medium Range Pre-Information (MRPI) as applied to Traffic and Travel Information (TTI) issued from an information service provider to a suitably equipped moving vehicle. The AID (Application Identification) number for all MRPI Application entities is defined as No. 8 in accordance with ISO 15628.

Information sur le trafic et le transport — Spécifications générales pour la préinformation de gamme moyenne via la communication de gamme courte dédiée — Partie 1: «Downlink»

General Information

• Status: Withdrawn
• Publication Date: 22-May-2006
• Withdrawal Date: 22-May-2006
• ICS: 35.240.60 - IT applications in transport
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 20-Oct-2009
• Completion Date: 13-Dec-2025

Relations

• Consolidates: ISO/IEC 10728:1993/Amd 1:1995 - Information technology - Information Resource Dictionary System (IRDS) Services Interface - Amendment 1: C language binding
• Effective Date: 06-Jun-2022

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 14822-1
First edition
2006-06-01
Traffic and Travel Information — General
specifications for medium-range
pre-information via dedicated
short-range communication —
Part 1:
Downlink
Information sur le trafic et le transport — Spécifications générales pour
la préinformation de gamme moyenne via la communication de gamme
courte dédiée —
Partie 1: «Downlink»
Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 General. 2
3.2 Data dictionary. 3
3.3 Abbreviated terms . 7
4 Application protocol (similar to TPEG). 7
4.1 Transport level . 8
4.2 service level. 9
4.3 Application multiplex level . 10
4.4 Conventions and symbols . 12
5 Application data . 14
5.1 DSRC headers . 15
5.2 Incident information (Entity 2). 17
5.3 Static road signs mandatory (Entity 5). 18
5.4 Static road signs information (Entity 6). 20
5.5 Variable message signs (text messages) (Entity 7) . 22
5.6 Pictograms (Entity 8). 24
5.7 Speed recommendation (Entity 9). 25
5.8 Variable mandatory signs (Entity 10). 27
5.9 Weather information (Entity 11) . 29
5.10 Road condition (Entity 12) . 31
5.11 Rest area information (Entity 13) . 33
5.12 Fuel station information (Entity 14) . 34
5.13 Parking information (Entity 15) . 36
5.14 Request for emergency call information (Entity 17) . 38
5.15 Traffic conditions (Entity 20) . 40
5.16 Diversion path (Entity 21) . 41
5.17 Special vehicles (special transport) (Entity 22) . 43
5.18 Journey time (Entity 23) . 44
5.19 Roadwork (Entity 24) . 46
Bibliography . 49

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 14822-1 was prepared by the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, in collaboration with Technical Committee ISO/TC 204,
Intelligent transport systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
ISO/TS 14822 consists of the following parts, under the general title Traffic and Travel Information — General
specifications for medium-range pre-information via dedicated short-range communication:
⎯ Part 1: Downlink
iv © ISO 2006 – All rights reserved

Introduction
Traffic and Travel Information 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 message structure involved in the various interfaces,
require clear definition and standard formats in order to allow competitive products to operate with any
received data. This Technical Specification focuses on the application data specification whereby data are
produced at a central location and disseminated via a network of Dedicated Short-Range Communication
(DSRC) beacons. This part of ISO 14822 addresses the data specifications for the downlink data flows
between a central location and moving vehicles passing a predetermined location. ISO 14822-2 addresses the
data specification for the uplink data flows that emanate from a moving vehicle, passing a predetermined
location, to a central location. In order to facilitate all the demands of ISO 14822-2, four bytes in the downlink
message are reserved for the beacon to insert the date/time stamp of the download. Due to the need for the
in-station to generate message CRCs, these bytes are not included in the header CRC.
Other documents are being produced by the CEN/TC 278 Working Group 4 and ISO/TC 204 Working
Group 10 to cover TTI dissemination via other communication means and services.
This Technical Specification specifies the application protocols and message structures for delivering Medium
Range Pre Information (MRPI) as accepted within CEN TC 278 for Traffic and Travel Information (TTI) via
Dedicated Short Range Communication (DSRC) devices.
DSRC has specific characteristics that differentiate this communication medium from other communication
media envisaged for traffic and traveller information, i.e. RDS-TMC (and later DAB) and GSM.
These characteristics are:
⎯ bi-directional communication, which is useful for collecting information/data from the vehicle or perhaps
selecting vehicles for a particular dialogue; and
⎯ spot communication, i.e. communications that can only take place at a precise point. This is a particularly
important characteristic. The communication zone does not exceed some 10 m or 20 m in front of the
beacon. At the time of communication, the position of the vehicle is accurately known, not only in terms of
geographical localization (i.e. comparable to what can be obtained with a GPS receiver) but in terms of
road and travel direction on this road. This localization feature is used beyond the communication zone.
By combining initial location information with information from the vehicle's speed sensor or odometer, the
position of the vehicle is known with great accuracy for several kilometres and reasonable accuracy for
tens of kilometres. Location information is updated when the vehicle passes the next beacon, probably at
the next junction. This may be a small distance in urban areas or a large distance on motorway or
expressway networks.
This part of ISO 14822 describes the application protocol, data definitions and message structures for each
MRPI service defined.
It forms part of a series of Technical Specifications defining the framework of a DSRC link in the Road
Transport Traffic Telematics (RTTT) environment.
The communication requirements of many RTTT applications can be fulfilled by DSRC. The DSRC
International Standards enable compliant communication systems to serve multiple RTTT application in
parallel.
This Technical Specification deals with the Application layer only.
CEN has issued the following set of European Standards for the DSRC link:
⎯ EN 12253 Road transport and traffic telematics — Dedicated short-range communication — Physical
layer using microwave at 5,8 GHz;
⎯ EN 12795 Road transport and traffic telematics — Dedicated Short Range communication (DSRC) —
DSRC data link layer: medium access and logical link control;
⎯ EN 12834 Road transport and traffic telematics — Dedicated short range communication — Application
layer;
⎯ EN 13372 Road transport and traffic telematics — Dedicated short range communication — Profiles for
RTTT applications.
ISO has issued the following International Standard for the DSRC link:
⎯ ISO 15628 Transport information and control systems (TICS) — Dedicated Short-Range Communication
(DSRC) — DSRC application layer.
General architecture of MRPI application
For simple applications, the information transmitted defines an event or a characteristic and the distance from
the point of delivery to this event or characteristic. Information from the vehicle odometer is used to measure
the distance driven by the vehicle and modify the distance shown on the driver's display or operate alert
messages as the event is approached. The vehicle equipment need not possess geographic localization
knowledge as the information is presented relative to the position of the last beacon passed. Whilst
information will often be related to the road conditions immediately following a beacon, the architecture will
allow the transmission of data covering much larger distances (up to two hours travelling time may be
appropriate on Trans European network roads). Such information will be updated by subsequent beacons.
The bi-directional communication facility can be used to retrieve information from vehicles such as average
speed data, location of fog, heavy rain, slippery roads, etc. This information can provide valuable floating car
data for Road Network Managers and subsequently as a warning to the following traffic.
Application architecture description
From analysis carried out within the MARTA project WP2, a typical architecture is based on:
⎯ a central control system which configures information broadcast by each beacon, based on the various
sources of information available. It also retrieves information collected from vehicles at the different
beacon sites;
⎯ beacons located along the road network. Each beacon consists of a beacon controller with one or more
heads as required to provide full coverage over multi-lane roads. The controller interfaces to the
communication network;
⎯ on-board terminals located in vehicles. Equipment is composed of a tag for communication which may be
linked to a terminal supporting the application. The complexity and cost of this equipment will vary
according to the applications supported.
vi © ISO 2006 – All rights reserved

Beacon equipment may take different forms. Complicated beacons handling dynamic information and two-way
communications with vehicles will be connected to a high-speed communications network. Less complicated
beacons handling static information (which may be changed) will be connected to low-speed networks and at
the other extreme the simplest beacons, warning perhaps of black spots or advertising some infrastructure
detail, could be stand-alone.
Information flow
This Technical Specification assumes that the DSRC supporting architecture will be as follows:
⎯ a central system configures beacons with appropriate information to be transmitted to vehicles, and
regularly polls beacons to retrieve information collected from vehicles;
⎯ each beacon broadcasts a signal to indicate its presence; when a tag is present in the communication
zone of the beacon, it indicates its presence and receives information from the beacon; in parallel, it
transmits to the beacon information stored and configured by the on-board application;
⎯ when receiving data collected from vehicles, a beacon can, where the network allows, send information
directly to the control centre, without waiting for the poll, especially if the information is related to safety;
⎯ the application running on the on-board terminal may regularly poll the tag (communication controller) to
detect new data, and to update vehicle-based information stored in the tag, ready for transmission to the
next beacon.
It is important to note that these information flows can run in parallel, i.e. for MRPI applications no real
dialogue is expected between the on-board equipment, beacons and central system; information processing is
detached from the transmission process.
On-board terminals
One key aspect of the transmission of traffic and travel information on DSRC is that different types of on-board
terminals can be envisaged, covering a wide range of end-users' prices.
The simpler terminal envisaged for MRPI is a tag developed for electronic fee collection, with limited
possibilities to warn the driver of equipped vehicles in case of incidents on the next 4 km or 5 km (i.e. with a
LED or a buzzer); the terminal could indicate two or three levels of seriousness (from incident to major
accident, for example).
A second level of terminal could consist of an after-sale terminal with simple graphic display and limited
interface with the vehicle (power, possibly speed sensor).
The third level of terminal consists of a fully integrated terminal, available as an option on the vehicle, and
possibly having connection with other communication media (GSM or RDS-TMC). In this case, more
information can be retrieved from the vehicle (activation of fog lamp, high-speed wipers, etc.).
Characteristics of applications from an HMI point of view
The information transmitted to a beacon will generally consist of an event and a relative distance from the
beacon. The information does not need to be immediately presented to the driver of equipped vehicles. The
time of presentation is related to the nature of the information as well as the location.
This feature is important, as it means that the place where the transmission takes place (i.e. the position of the
beacon) does not need to be correlated with the nature of the information transmitted (nature and location).
This means that the driving factor for the installation of the beacons is mainly the refreshment rate of the
information on board the vehicle, rather than the exact position of the beacon.
Therefore, for the driver of equipped vehicles the transmission of information can be completely transparent.
For example, information about road works can be transmitted at a beacon, with an indication of, for example,
5 km. For the benefit of the driver, there is no need to announce the information immediately, as in this case
the information will not modify the route (which is not the case for a big accident) and an early warning will
have no impact on the driving attitude. On the contrary, information can be announced 1 km before the
roadwork, which in this case will have an impact on the driver of equipped vehicles (he/she should be more
alert during the following minutes and could even start to reduce his/her speed).
One characteristic of the announcements, from an HMI point of view, is that information about an event is
presented to the driver of equipped vehicles depending on the relative distance between the vehicle and the
event, which brings advantages, as compared to information which can be given through channels such as
FM radio (where the “absolute” location of the problem is given, for example “Roadwork after ROISSY toward
LILLE”).
Information is correctly filtered (information displayed is pertinent for the driver) and there is no ambiguity on
the location, especially for drivers who are not familiar with the environment and who do not know place
names.
An advantage of such a way to present the information to the driver of equipped vehicles is that the
information transmitted is self-sufficient, i.e. there is no need to have an on-board database to decode
geographic names. Geographic names can still be used for some MRPI applications (to indicate distances or
journey times to given places, for example), but due to the high data rate of the DSRC, it seems possible to
achieve such an application without on-board decoding database.
Of course, information transmitted can be language-independent, following for example the coding of events
proposed by RDS-TMC.
viii © ISO 2006 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 14822-1:2006(E)

Traffic and Travel Information — General specifications for
medium-range pre-information via dedicated short-range
communication —
Part 1:
Downlink
1 Scope
This part of ISO 14822 addresses the passive DSRC issues associated with Medium Range Pre-Information
(MRPI) as applied to Traffic and Travel Information (TTI) issued from an information service provider to a
suitably equipped moving vehicle.
The AID (Application identification) No. for all MRPI Application entities is defined as No. 8 in accordance with
ISO 15628.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 4217, Codes for the representation of currencies and funds
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes
ISO 14819-2, Traffic and Traveller Information (TTI) — TTI messages via traffic message coding — Part 2: Event
and information codes for Radio Data System — Traffic Message Channel (RDS-TMC)
1)
ISO/TS 14823 , Traffic and Travel Information — Messages via media-independent stationary dissemination
systems — Graphic data dictionary for pre-trip and in-trip information dissemination system
ISO 15628, Transport information and control systems (TICS) — Dedicated Short-Range Communication
(DSRC) — DSRC application layer

1) To be published.
3 Terms, definitions and abbreviated terms
3.1 General
For the purposes of this document, the following terms and definitions apply.
3.1.1
beacon
roadside DSRC device
3.1.2
dam
message variable addressed in tens of metres
NOTE dam = deca [da] × metre [m].
3.1.3
hm
message variable addressed in hundreds of meters
NOTE hm = sector [h] × metre [m].
3.1.4
journey time
travel time plus delay
3.1.5
link (road)
length of motorway between two locations
3.1.6
link (telecom)
electronic or wireless interface between two matching devices
3.1.7
Motorway Applications for Road Traffic Advisor
MARTA
European-funded project to review similar existing projects throughout Europe with the aim to establish the
foundation of this Technical Specification
3.1.8
on-board unit
OBU
electronic equipment closely coupled with the tag that interprets the messages and presents the embodied
information to the Driver
3.1.9
pkmp
motorway network physical address in kilometres, represented in the number of kilometres at the referenced
location from the start of the designated motorway
3.1.10
road network manager
authority responsible for the smooth operation and maintenance of the motorway or trunk roads on which the
DSRC device is installed
3.1.11
route
series of links
2 © ISO 2006 – All rights reserved

3.1.12
tag
in-vehicle passive DSRC device to provide by-directional communication between the vehicle and a roadside
beacon
3.1.13
Transport Protocol Experts Group
TPEG
protocol commissioned by the EBU's Broadcast Management Committee for the multimedia broadcast of TTI
3.1.14
trans-European transport network roads
roads comprising the network that handles almost half of all goods and passenger traffic and is therefore the
veritable lifeblood of the EU
NOTE In recent years, the excessive use made of roads for the transport of goods, the tremendous expansion in
travel by air and the shortcomings in the rail system have seen a sharp increase in congestion on the main European
arteries.
3.1.15
travel time
unimpeded time to transverse a link in free flow
3.2 Data dictionary
3.2.1
application-crc
cyclic redundancy characters that are used to validate the integrity of the concatenated DSRC message,
16 12 5
based on the ITU polynomial x + x + x + 1
3.2.2
application-data
concatenated MRPI messages intended for delivery to and from a single DSRC outstation
3.2.3
average-speed
single byte field containing the average speed in kilometres per hour (km/h) of a slow-moving vehicle
3.2.4
callbox-offset-in-dam
two-byte field defining the distance offset in tens of metres between the DSRC and the first device or the
distance offset in tens of metres between subsequent devices
3.2.5
country-code
two-byte numeric field defining the country code in accordance with the three-digit code taken from ISO 3166-
1 that signifies the dictionary's country of origin
3.2.6
currency
three-byte field defining the currency of the monitory fields in the message in a form that corresponds to
ISO 4217
3.2.7
date/time-of-information-generation
four-byte field containing the number of seconds since 1970
3.2.8
date/time-of information-transfer
four-byte field containing the number of seconds since 1970
3.2.9
dictionary-code
single-byte numeric field defining the pictogram dictionary from which the pictogram codes have been taken
3.2.10
displayextent-in-dam
distance offset in tens of metres in advance of the roadside indicator or device that the message is deemed as
valid
3.2.11
distance2next-dsrc
distance in tens of metres form the DSRC dispatching the message to the next DSRC on the designated
highway
3.2.12
dsrc-application-id
DSRC application identifier
NOTE For MRPI messages this will always be set to eight.
3.2.13
dsrc-network-id
unique network address of the DSRC used also as the electronic address
3.2.14
forward-link-id
variable containing the link identity of the downstream message block where the DSRC dispatches information
for a different link in advance of the next DSRC
3.2.15
information-type
single-byte encoded value defining the structure of the message
3.2.16
journey-time
two-byte field containing the journey time in minutes to the associated exit or destination
3.2.17
junction-id
20-byte character string containing the exit description or destination
3.2.18
length-of-route-affected-in-hm
distance offset in hundreds of metres between the incident and the location in advance of the incident at which
message becomes valid
3.2.19
length-of-the-frame
two-byte field that defines the number of bytes in the complete message including this header
3.2.20
link-block length
two-byte field containing the number of bytes in the concatenated message block including this header
4 © ISO 2006 – All rights reserved

3.2.21
mandatory-speed
mandatory speed in kilometres per hour (km/h)
3.2.22
message-duration
duration in minutes from the date/time stamp of information generation that the message is deemed to be
valid
3.2.23
mrpi-application-entity-id
MRPI message identifier that defines the structure and format of the message block
3.2.24
name-of-the-road
seven-byte ASCII field containing the name of the designated road network on which the link resides
3.2.25
name-of-exit
ASCII string defining the name of the exit associated with the service station or rest area terminated by an
ASCII carriage return
3.2.26
name-of-facility
ASCII string defining the name of the service station or rest area terminated by an ASCII carriage return
3.2.27
no-instruments
single-byte field containing the number of emergency telephone instruments that are recorded in the
information message
3.2.28
no-of-jt-elements
single-byte binary field defining the number of exists or destinations for which journey times have been
incorporated into the information message
3.2.29
offset2device-in-dam
distance offset in tens of metres, from the DSRC to the roadside indicator or device
3.2.30
offset2event-in-dam
distance from the DSRC to the TMC event in tens of metres
3.2.31
offset2vadid
distance offset in tens of metres, from the DSRC to the location where the message becomes valid
3.2.32
pkmp-reference
kilometre point or marker post reference indicating a road network location address
3.2.33
recommended-speed
recommended speed in kilometres per hour (km/h)
3.2.34
referenced-distance-in-hm
distance referenced in the message in hundreds of metres
3.2.35
rest-area-facilitates
two-byte bit map defining the facilities available at the rest area
3.2.36
road-length
two-byte field containing the distance from the DSRC to the next road network divergence or termination in
kilometres
3.2.37
road-network-link-id
block identity relating to concatenated messages for a designated section of road network link
3.2.38
road-type
one-byte field defining the characteristics of the designated road network link
3.2.39
road-works-no
single byte containing the number of roadwork entities included in this information message
3.2.40
rw-configuration
single-byte binary field defining the configuration of the roadwork in accordance with Table 1 below
NOTE The encoding defines a lane closed when the bit is set.
Table 1 — rw-configuration
rw-configuration Bit number
exit slip hard shoulder 0
exit slip inside lane 1
exit slip outside lane 2
hard shoulder 3
lane 1 4
lane 2 5
lane 3 6
lane 4 7
3.2.41
site-identifier
DSRC site address that is unique within a designated region of the road network
3.2.42
speed-events
variable defining the number of speed events contained in the one information message
3.2.43
tcc-telephone-no
character string containing the telephone number of the TCC or PCO that is responsible for the current section
of road network
6 © ISO 2006 – All rights reserved

3.2.44
tmc-evt
two-byte field containing the Alert-C RDS-TMC event code that can be translated into any descriptive
language as defined in ISO 14819-2
3.2.45
tmc-oq
one-byte field containing the optional quantifier associated with the incident
3.2.46
tmc-sl
one-byte field containing the speed limit in kilometres (km) associated with the incident
3.2.47
type-of-vehicle
single-byte binary field depicting the special vehicle type
3.2.48
validity-extent-in-dam
distance offset in tens of metres after the roadside indicator or device that the condition applies
3.3 Abbreviated terms
AID Application identification
ASCII American Standard Code for Information Interchange
DSRC Dedicated Short-Range Communication
HMI Human Machine Interface
ITU International Telecommunication Union
MARTA Motorway Applications for Road Traffic Advisor
MRPI Medium-Range Pre-Information
OBU On-board unit
PCO Police Control Office
RDS Radio Data System
TCC Traffic Control Centre
TMC Traffic Message Channel
TPEG Transport Protocol Experts Group
TTI Traffic and Travel Information
VMS Variable Message Sign
4 Application protocol (similar to TPEG)
Following the emerging TPEG model, the DSRC application protocol can be described as follows; however, it
must be assumed that the service provider generating the DSRC data stream has constructed the application
level frames that have been targeted at a specific roadside DSRC device:
Figure 1 — DSRC description hierarchy
4.1 Transport level
Overall frame structure level 1
The byte stream contains consecutive transport frames.
Each frame includes:
The Synchronization Word (syncword) 2 bytes: FF0FH
The length of the frame (field length) 2 bytes
The Header CRC 2 bytes
The service Frame n bytes (n = length of frame)
ASN.1 format
TransportHeader ::= SEQUENCE {
sync-word ::= INTEGER (65295),
field-length ::= INTEGER (0 . 65536),
header-crc ::= INTEGER (0 . 65536)
}
The byte stream is built according to the above-mentioned repetitive structure of transport frames.
Syncword
The syncword is two bytes long and has a value of FF0F hex.
8 © ISO 2006 – All rights reserved

Field length
The field length consists of two bytes and represents the number of bytes from the start of the header CRC up
to and including the end of the service frame.
Header CRC
16 12 5
The header CRC is two bytes long, and is based on the ITU polynomial x + x + x + 1.

Figure 2 — Header CRC
The header CRC is calculated on the first eleven bytes and includes the sync word through to the encryption
indicator.
4.2 Service level
Overall frame structure level 2
Each service frame comprises:
The service provider ID 2 bytes
The service ID 2 bytes
The encryption indicator 1 byte
Date/Time stamp of information transfer 4 bytes
The Application Data n bytes
ASN.1 format
serviceHeader ::= SEQUENCE {
service-provider-id ::= INTEGER (0 . 65295),
service-id ::= INTEGER (0 . 255)
encryption-indicator ::= INTEGER (0 . 255)
date-time-of-information-transfer ::= INTEGER (0 . 4294967295)
}
The service level is defined by the service frame. Each transport frame carries one and only one service
frame.
The service frame includes an application multiplex comprising one or more application frames. Each service
frame may contain a different range and number of application frames as required by the service provider.
4.2.1 Service information
Each transport frame may be used by only one service provider and one dedicated service which can
comprise a mixture of applications.
A multiplex of service providers or services is realized by concatenation of multiple transport frames. Each
service frame includes service information, which comprises the service provider identification, the service
identification and the encryption indicator.
The service provider ID is unique worldwide, and the service IDs are unique to each service provider.
4.2.2 Service provider identification
Length: 2 bytes
This is assigned worldwide. Each service provider has a unique number.
The use of a country code is not regarded as being appropriate, since applications and services will be
assigned on a worldwide basis.
However, this implies that the numbers need to be assigned on a worldwide basis.
4.2.3 Encryption indicator
Length: 1 byte
The service provider may freely choose the encryption technique and compression algorithms.
0 no encryption/compression.
1 to 127 reserved for standardized methods.
128 to 255 may be freely used by each service provider, may indicate the use of proprietary methods.
4.2.4 Date/time stamp of information transfer
Length: 4 bytes
In accordance with the CEN/TC 287 time format, this field defines the timestamp at which the information was
compiled at the in-station. This field is not included in any of the CRC calculations performed by the in-station
and is inserted into the byte stream by the beacon.
4.3 Application multiplex level
The application multiplex is a collection of one or more application frames, the type and order of which are
freely determined by the service provider.
Overall frame structure level 3
Each application frame comprises:
DSRC Application ID 2 bytes
Date/Time stamp of information generation 4 bytes
The length of the frame (field length) 2 bytes
The Application CRC 2 bytes
The Application Data n bytes
10 © ISO 2006 – All rights reserved

ASN.1 format
dsrc-id DsrcApplicationEntityId ::= medium-range-pre-information
ApplicationHeader ::= SEQUENCE {
application-id ::= DsrcApplicationEntityId,
date-time-of-information-generation ::= INTEGER (0 . 4294967295),
application-length ::= INTEGER (0 . 65536),
application-crc ::= INTEGER (0 . 65536)
}
4.3.1 Application identity
Length: 2 bytes
In accordance with ISO/TC204 WG15 this field is the first two bytes of the application frame being made up as
follows:
DSRCApplicationID ::= INTEGER{
system (0),
automatic-fee-collection (1),
freight-fleet-collection (2),
public-Transport (3),
traffic-traveller-information (4),
traffic-control (5),
parking-management (6),
geographic-road-database (7),
medium-range-pre-information (8),
man-machine-interface (9),
intersystem-interface (10),
automatic-vehicle-identification (11),
emergency-warning (12),
private (13),
multi-purpose-payment (14),
dsrc-resource-manager (15),
after-theft-system (16),
cruise-assist-highway-system (17),
multi-purpose-information-system (18),
multi-mobile-information-system (19),
reserved-for-ISO-DSRC-application0 (20),
reserved-for-ISO-DSRC-application1 (21),
reserved-for-ISO-DSRC-application2 (22),
reserved-for-ISO-DSRC-application3 (23),
reserved-for-ISO-DSRC-application4 (24),
reserved-for-ISO-DSRC-application5 (25),
reserved-for-ISO-DSRC-application6 (26),
reserved-for-ISO-DSRC-application7 (27),
reserved-for-ISO-DSRC-application8 (28),
private1 (29),
private2 (30),
reserved-for-ISO-DSRC-application9 (31),
} (0.31)
4.3.2 Date/time stamp of information generation
Length: 4 bytes
In accordance with the TC 287 time format this field defines the timestamp at which the information message
was generated at the in-station and is the reference time against which all the individual message durations
are compiled.
4.3.3 Length of frame
Length: 2 bytes
The inclusion of this field enables the decoder to skip an unknown application. The length includes the six
bytes of the header plus the application data.
4.3.4 Application Header CRC
Length: 2 bytes
16 12 5
The application CRC is two bytes long, and based on the ITU polynomial x + x + x + 1.

Figure 3 — Application CRC
The application CRC is calculated on all the bytes from the application ID to the end of the application data.
4.4 Conventions and symbols
4.4.1 Conventions
Naming conventions
Names shall start with a capital letter and contain no word separation characters. Variable names shall be in
lower case with the words separated by a hyphen.
12 © ISO 2006 – All rights reserved

Byte ordering
All numeric values using more than one byte shall be coded in “big endian” format (most significant byte first).
Where a byte is subdivided into bits, the most significant bit (“b7”) shall be at the left-hand end and the least
significant bit (“b0”) shall be at the right-hand end of the structure.
Method of describing the byte-oriented protocol
This textual representation is designed to be unambiguous, easy to understand and to modify, and does not
require a detailed knowledge of programming languages.
Data types are built up progressively. Primitive elements that may be expressed as a series of bytes are built
into compound elements.
More and more complex structures are built up with compound elements and primitives.
Reserved data fields
If any part of a DSRC data structure is not completely defined, then it shall be assumed to be available for
future use. No particular value is assigned to it.
The notation is UAV (unassigned value). A decoder that is not aware of the use of any former UAVs can still
make use of the remaining data fields of the corresponding information entity.
However, the decoder shall not be able to process the newly defined additional information.
4.4.2 Symbols
Variable numbers
Symbols shall used to represent numbers whose values are not predefined within the TPEG specifications. In
these cases, the symbol used shall always be local to the data type definition.
For example, within the definition of a data type, symbols such as n or m are often used to represent the
number of bytes of data within the structure, and the symbol id is used to designate the occurrence of the
identifier of the data type.
Implicit numbers
Within the definition of a data structure it is frequently necessary to describe the inclusion of a component that
is repeated any number of times, zero or more.
In many of these cases it is convenient to use a numerical symbol to show the component structure being
repeated a number of times, but it is not necessary to include the number itself within the definition of the data
structure.
Often, the symbol m is used for this purpose.
Printable stings
Within the message structure, where variable length text is to be transmitted at the end of a message then the
message length shall determine the length of the field. Where the variable length text is imbedded within the
message the last character shall be an ASCII carriage return character (CR). When the text is deemed to be
in multiple rows then the row separator shall be an ASCII line feed character (LF).
5 Application data
The following DSRC MRPI application entities are defined in this Technical Specification:
MRPIApplicationEntityID ::= INTEGER{
dsrc-message header (0), -- Downlink defined in part 1
highway-link-header (1), -- Downlink defined in part 1
incident-information (2), -- Downlink defined in part 1
incident-indication (3), -- Uplink: defined in part 2
journey-time-data (4), -- Uplink: defined in part 2
static-road-signs-mandatory (5), -- Downlink defined in part 1
static-road-signs-information (6), -- Downlink defined in part 1
Vms (5), -- Downlink defined in part 1
pictograms (8), -- Downlink defined in part 1
speed-recommendation (9), -- Downlink defined in part 1
variable-mandatory-signs (10),
...