Architecture of the

Dedicated Short-Range Communications (DSRC) Protocol

Christian Cseh
Department of Computer Science, Informatik IV
Aachen University of Technology (RWTH), Germany
email: cseh@i4.informatik.rwth-aachen.de

Abstract --- This paper describes the architecture and functional aspects of the dedicated short-range communications
(DSRC) protocol. DSRC provides a communication link
between vehicles and roadside beacons for road transport and
traffic telematics (RTTI') applications. The DSRC technology
was proposed for standardization in Europe (CEN TC 278) and
ENV-standards were developed. The following chapters will
give an overview of the three DSRC communication layers,
with a special focus on the functional aspects provided by the
application layer. Finally, a presentation of the European Telematics Applications Programme research project VASCO,
which deals with the validation of the DSRC ENV-standards,
concludes this paper.

I. Introduction
The increasing need for mobility in modern industrial
societies, mainly induced by large common trade markets,
imposes new problems on traffic management. A promising
approach to tackle these problems is the use of road transport
and traffic telematics (RTIT) applications ([ 11, [2]). Services
in the area of traffic and travel information that provide
medium-range pre-information for car drivers or for automatic
fee collection need a reliable communication link between
vehicles and roadside beacons adapted to their needs.

II

CEN TC 278

Fig. 1 DSRC Standardization

11. DSRC Protocol Architecture

The DSRC protocol for vehicle-beacon communications has
been defined as a light-weight, OS1 communication stack ( [ 5 ] ) .
It consists of three layers: the physical layer (Ll), the data link
layer (L2) and the application layer (L7), see Fig. 2. This architecture is popular for real-time systems as it reduces protocol
overhead and meets timing constraints. The system was
designed to support different physical media, multi-application
scenarios and a multi-lane environment. This will guarantee a
large variety of possible application areas for this technology.

(RTTT- Aq plication)

In order to establish a European DSRC system with a common

technology for users and operators, leading to a joint market
for all manufacturers, the European Commission launched a
standardization initiative. The European Center for Standardization (CEN) assigned the task of specifying DSRC standards to the Technical Committee TC 278 for road transport
and traffic telematics. The corresponding working group 9
([3]) drafted pre-standards (prENV) for the DSRC system in
close cooperation with its global mirror group, I S 0 TC 204
([4]), see Fig. 1.
These draft documents were adopted as European ENV standards by the national standardization bodies during a voting
procedure in summer 1997.

I S 0 TC 204

service primitives

L7

Logical Link Control

Medium Access

L2

Fig. 2 DSRC Protocol Stack

A. Physical Layer
The physical layer was designed to support different media
types. At the moment, a European ENV standard for microwave transmission at 5.8 GHz ([6]) is available. For infrared
communication at 850 nm ([7]) a pre-standard (prENV) was
drafted, but has not been released for voting yet, due to lack of

0-7803-4320-4/98/$5.00 0 1998 IEEE

2095

VTC '98

111. Application Layer Functionality

commercial interest.
Regarding the microwave transmission, the default data rate
for the downlink is 500 kBit/s, although lower or higher data
rates, up to 1000 kBit/s can be negotiated. FMO or NRZI data
coding may be used. On the uplink data rates up to 750 kBit/s
are possible, 250 kBit/s being the default. The coding scheme
employed is NRZI. On both up- and downlink a bit error rate
of 10 -6 is assumed as reference value for an operational communication link. Due to the antenna characteristics and the
transmission power used, the communication zone has a typical length of 3 to 15 meters.

B. Data Link Layer

The data link layer ([SI) is composed of two sublayers: the
logical link control (LLC), which provides service primitives
for an (un)acknowledged, connectlonless data transfer, and the
medium access control (MAC), that coordinates the access to
the physical medium.
The access control is realized by allocating time slots (windows) on the link. The beacon sends a list of present RTTT
applications, the ,,Beacon Service Table" (BST) on the downlink, followed by a public window allocation (PuWA) and a
number of public windows (PuW). The vehicle randomly
chooses one of these public windows to issue a private window
request (PrWR) on the uplink. If a packet collision occurs, the
vehicle randomly picks another public window for retransmission. The beacon acts as a master for the communication link
and assigns on the uplink a private window (PrW) dedicated to
the vehicle. This is announced to the vehicle by sending a private window allocation (PrWA) on the downlink. The vehicle
obtains the uplink exclusively during its private window and
sends (as an answer to the BST) a list of the applications that
are present in the BST as well as on the vehicle side, the
,,Vehicle Service Table" (VST). Please refer to Fig. 3 for an
illustration of the medium access technique.

time

Uplink

Each RTTT application, or DSRC service user, implemented

on beacon- or vehicle-side, belongs to a certain application
class, identified by its DSRC application entity id (AID), e.g.
automatic fee collection. Furthermore, it may be identified by
an optional DSRC entity id. If the application wishes to communicate with its peer entity, the steps depicted in Fig. 4 are
executed.
First the corresponding application has to register with the
I-KE (1). During the initialization phase the I-KE of the beacon
distributes a list of the registered applications, the BST (2).
Upon reception of the BST by the on-board unit (OBU) of the
vehicle, its I-KE compares this list with the registered applications on vehicle side. All matches are noted in a ,,Vehicle Service Table" (VST), and the corresponding applications are
notified about the presence of a peer entity (3). The VST is
returned to the beacon (4),which in turn notifies the corresponding applications (5).
The application may then use the service primitives of the
T-KE, e.g. ,,GET", to transmit or retrieve data. The
,,Get.request" issued from the application, for example from
beacon side, is transmitted over the air interface and received
by the vehicle's OBU. The command is passed as a ,,GET.indication" (7) to the application on the vehicle side. A possible
,,GET.response" answer is returned to the beacon. It is passed
to the application as a ,,GET.confirm" (9) message. After the
communication has finished, the service user issues a
,,ReadyApplication" message to the I-KE (10). The kernel element closes the connection by a ,,Release" command (1 I), if
all active applications have completed their transactions.

Beacon

air interface

Vehicle

-4
Fig. 3 Medium Access

_____,

ReadyAppl~catton

C. Application Layer

10

The application layer consists of three kernel elements (KE),

which realize the initialization (I-KE), the transmission of
broadcast messages (B-KE) and the transfer (T-KE) of protocol data units (PDU) ([9]). The following chapter will give
detailed information on the application layer services and the
functionalities of the different kernel elements.

0-78034320-4/98/$5.00 0 1998 EEE

Release

bl
11

Fig. 4 Communication Transaction

2096

VTC '98

A. Transfer Kernel Element (T-KE)

The T-KE provides service primitives of the following classes:
0

GET, enables the retrieval of data from the peer entity,

SET, changes information at the communication partner,
ACTION, executes an operation at the peer service
user,
EVENT-REPORT, notifies an event to the partner, and
INITIALIZATION initializes the communication
between vehicle and beacon.

These service primitives are either directly invoked by the

application, in order to transfer service data units (SDU), or by
the I-KE (INITIALIZATION only) and B-KE (SET).
Due to the light-weight design of the protocol stack, the application layer T-KE also has to implement some functionality of
the empty layers 3 to 6.

I
I

Encoder

encoded PDU

Fragmenter

Decoder
Deconcatenation

t,

PDU Fragments4

encoded PDU or
concatenated PDUs

Upon the reception of a LSDU at the lower SAP, it is passed to

a demultiplexer. The different PDU fragments are demultiplexed according to a PDU number indicated in the fragmentation header. The defragmenter removes the fragmentation
header and reassembles the entire coded PDU. If the PDU is
concatenated, the header of the attached PDU is not removed.
Subsequently the coded PDU is passed to the decoder, where
padding bits are removed and the original PDU is restored. In
case of multiple concatenated PDUs, the fragmentation header
is deleted and the remainder is further decoded. Finally, the
PDU is reconverted to an SDU at the SAP to the application.
For an overview of the different steps, please refer to Fig. 5 .

B. Broadcast Kernel Element (B-KE)

The B-KE enables the applications on beacon-side to insert
files that hold the information to be distributed into a broadcast
pool (BP). In addition to the files stored in the BP, it contains a
directory for indexing by file names. The BP is sent periodically to all vehicles within the communication zone, using the
,,SET" service primitive of the T-KE and a broadcast address
for transmission. This feature is used, for example, by traffic
and travel information services to distribute medium-range
pre-information about upcoming traffic situations (accidents,
jams, weather conditions, etc.) to all vehicles traveling in the
related direction. On the vehicle-side the B-KE offers the
,,GetBroadcastData" service primitive, which enables the
application to retrieve a file from the BP, indicating the corresponding file name.

C. Initialization Kernel Element (I-KE)

Fig. 5 Functionalities of the T-KE [9]

Applications have to register with the I-KE prior to communication, using the ,,RegisterApplicationVehicle" and ,,RegisterApplicationBeacon" service primitives, respectively. Upon
registration the applications indicate their DSRC AID and a
priority for transmission scheduling. On the beacon-side the
service user specifies in addition, whether or not the application is mandatory or not. Through registration the applications
demonstrate their ability to establish a communication link to a
peer entity. If the application is not going to participate in the
communication any more, it must deregister, using the
,,DeregisterApplication" service.

For the sending of SDUs it realizes the transformation of SDUs

to PDUs at the service access point (SAP) and the coding
according to ASN.1 Packed Encoding Rules ([lo]). The coded
PDU is then segmented into fragments, including a one to three
octet header. After octet alignment the PDU fragments are sent
to a multiplexer, where different fragments are multiplexed
based on priorities indicated by the I-KE. Multiple consecutive
PDU fragments may be concatenated if they contain an unfragmented PDU, use the same LLC service, have the same destination and do not exceed the maximum size for a LLC frame.
At the lower SAP the LLC service data unit (LSDU), consisting of the PDU fragment(s) and a link identifier, indicating
the destination, is mapped onto the corresponding LLC service.

The beacon I-KE periodically sends a list of the registered

mandatory and non-mandatory applications, the BST, via the
initialization service of its T-KE. Upon reception of the BST at
the T-KE of the vehicle it is passed to the I-KE. It chooses a
unique link identifier (LID) associated with the connection,
compares the application lists of the BST with its registered
applications and notifies the corresponding service users. The
notification signals the entrance into a new communication
zone to the service user and contains the received beacon id,
the associated LID as well as a priority. For the mandatory
applications the priority is denoted by their position in the
mandatory list. For the registered applications contained in the
non-mandatory application list of the BST, the priority is cal-

Defragmenter
PDU Fragments

LSDU

------

tf

&&

4 t

SLPt

PDU Fragments

LSDU

- 2 SAL - - - -

0-78034320-4/98/$5.00 0 1998 EEE

2097

VTC '98

culated as the number of mandatory applications plus the

registered priority on vehicle-side. All applications notified are
inserted into the ,,Vehicle Service Table" (VST), which is sent
back to the beacon together with the LID and the configuration
of the on-board unit (OBU). The VST, the LID, the beacon id
and the time are stored in the OBU. The VST is received by the
T-KE of the beacon and is inspected by its I-KE. The applications, which are contained inside the VST, are notified, indicating a priority, the LID chosen by the vehicle and the OBU
configuration. The priority corresponds to the position in the
VST application list. The beacon stores the VST together with
the LID, and the initialization procedure is completed. The
applications on beacon- and vehicle-side may then start their
data transmissions.
If a service user has finished the communication transaction
with its current peer entity and wants to remain registered, a
,,ReadyApplication" command is sent to the I-KE. When all
active applications that have been notified have issued a
,,ReadyApplication", the I-KE sends a ,,Release" command
using the ,,EVENT-REPORT" service of the T-KE. Upon
reception of a ,,Release" the I-KE deletes the corresponding
VST together with the LID.

A. Validation of the DSRC Application Layer

To show the use of formal description techniques for the specification of protocol definitions and the derived validation
approach, its application to the DSRC layer 7 will be presented. As a basis for the development of a simulator, the
application layer was specified in SDL ([ 1 l]), using the SDT
tool Ver. 3.01 from Telelogic ([13]) under SunOS. The layer 7
structure of the kernel elements was translated into corresponding SDL block definitions. One additional block for the
layer management, to handle the priorities of different applications, was introduced. The SDT environment serves as an
interface to the application and the lower data link layer, see
Fig. 6. In order to check the correctness of the SDL specification with respect to the ENV standard definition, a simulator
was developed by the use of the C code generator of SDT.

SDT Environment

IV. Validation of DSRC

In the framework of the European Telematics Applications
Programme the main objective of the VASCO (Validation of
Dedicated Short-Range Communications) project ([ 111) is the
validation of the DSRC standards, in order to proof their correctness, completeness and suitability to support RTIT applications.

----_-a

Block BEACON
SDT Environment

In a first step the user requirements have been analyzed, taking

into account the needs of different groups, like car drivers, fleet
operators, road authorities, vehicle manufacturers and motorway operators. A detailed validation plan was derived and the
approach pursued is twofold: on the one hand, tests using system models for analysis and simulation are carried out. On the
other hand, DSRC prototype equipment, provided by six European manufacturers, is tested in laboratory and field trials. Six
test-sites throughout Europe have been set up to analyze different driving scenarios under real-life conditions, using cars,
motorcycles and trucks. The coexistence between existing low
data rate solutions for vehicle-roadside communications and
new DSRC systems is investigated, in order to develop migration strategies for motorway operators.

Based on the simulator, derived from the SDL specification,

and a test suite defined in TTCN ([ 141) the basic functionality
of the DSRC application layer was tested. Since SDL block
definitions (B-KE, I-KE, T-KE and Mngt) correspond to the
layer 7 kernel elements, their interfaces can be used as points
of control and observation (PCO). This allows a modular test
of the behaviour specified in the ENV standard for each kernel
element. The conformance of the SDL specification with
respect to standard definitions can be validated through the
generated simulator code and an appropriate 'ITCN test suite.

First results from the laboratory tests carried out for the different manufacturers confirmed the capabilities of the DSRC
link for data transmission at the envisaged data and bit error
rates. Tests conducted under nordic winter conditions showed
no impact of the weather situation on the DSRC equipment.
The field trials and coexistence tests are scheduled to finish in
January 1998. Preliminary results demonstrate the ability of
the DSRC equipment to successfully perform data transactions
required by automatic fee collection applications.

Corresponding results have been obtained for an SDL implementation of the DSRC Data Link Layer.

0-7803-4320-4/98/$5.000 1998 EEE

Fig. 6 Definition of SDL Blocks for Layer 7 (Beacon)

The validation procedure confirmed the conformance of the

SDL specification to the behaviour described in the ENV standard. Furthermore the execution of the tests proved that the
standard is complete, correct and suffers from no major shortcomings, except for minor flaws.

2098

VTC '98

V. Conclusion
The paper presented the standardized DSRC protocol for vehicle-roadside communications, supporting a wide range of
RTTT applications, operating in a multi-lane and multi-application environment. Benefits for car drivers, fleet and motorway operators result from the inter-operability between DSRC
equipment of different manufacturers, which allow seamless
communication across administrative boundaries.
The different DSRC protocol layers were introduced, paying
special attention to the application layer. The generic communication services, techniques for initialization and distribution
of information were explained. Results from the European
transport telematics research project VASCO, regarding validation and conformance testing of the DSRC standards were
presented.

[ 113

,,VASCO (Validation of Dedicated Short-Range

Communications) Home Page", http://
www.comnets.rwth-aachen.de/-vasco

[ 121

,,Recommendation 2.100 - CCITT specification and

description language (SDL)", March 1993,
ITU(CC1TT) Geneva

[ 131

,,Telelogic SDT Ver. 3.01", http://www.telelogic.se/

[ 141

,,Recommendation X.292 - OS1 conformance testing

methodology and framework for protocol
recommendations for CCITT applications - The Tree
and Tabular Combined Notation (TTCN)", September
1992. ITU Geneva

The results show, that the standards are well designed, free of
severe errors and able to fulfill the requirements of different
RTTT applications. The implementation of DSRC prototype
systems and the field trials prove that real time constraints are
met and that complex transactions can be completed during a
passage through the communication zone at regular driving
speeds.

References
,,Road Transport Informatics: New Applications for
Communication and Navigation Systems", S. Hoff, J.
Kassubek, The Space Congress, Bremen, May 1995
,,Telecommunications Media for Transport
Telematics", P. A. Wingfield, IEEE Communications
Magazine, Vol. 34 No. 10, October 1996
,,CEN TC 278 WG 9 Home Page", http://

www.comnets.rwth-aachen.de/-ftp-wg9/
,,IS0 TC 204 Home Page", http://web.jhk.com/tc204/
,,Recommendation X.200 - Information technology Open Systems Interconnection - Basicreference model:
The basic model", July 1994, ITU Geneva
,,DSRC Physical Layer using Microwave at 5.8 GHz",
CEN TC 278 ENV 12253, CEN Brussels
,,DSRC Physical Layer using Infrared at 850 nm", CEN
TC 278 prENV278/9/#63, December 95, CEN Brussels
,,DSRC Data Link Layer" CEN TC 278 ENV 12795,
October 95, CEN Brussels
,,DSRC Application Layer" CEN TC 278 ENV 12834,
February 96, CEN Brussels
,,Recommendation X.691 - Information technology ASN. 1 encoding rules - Specification of packed
encoding rules (PER)", April 1995, ITU Geneva

0-7803-4320-4/98/$5.000 1998 IEEE

2099

VTC '98