DRAFT

Specification for

Dedicated Short Range Communications (DSRC) for Commercial Vehicles

ver 0.0.1

November 1999

![](media/image1.png){width="0.9311023622047244in"
height="0.9437007874015748in"}

United States Department of Transportation

Federal Highway Administration

Intelligent Transportation Systems Joint Program Office

DRAFT

Contents

  ------------- --- ------------------------------------------ ----------
  1                 Overview                                   3

                                                               

  2                 Background Information                     5

                                                               

  3                 Physical Layer                             7

                                                               

  4                 Data Link Layer                            15

                                                               

  5                 Transponder Resources                      37

                                                               

  6                 Transponder Commands and Memory Access     49

                                                               

  7                 Resource Manager                           77

                                                               

  8                 ITS Application Messages                   84

  9                 Application Layer                          105

                                                               

  Attachment A      Compatibility Philosophy                   110
  ------------- --- ------------------------------------------ ----------

1.  **Introduction**

The primary objectives of this document are to specify the
characteristics of the Dedicated Short Range Communication (DSRC) air
interface which will be used in commercial vehicle applications and to
specify the DSRC equipment that will be resident in a commercial
vehicle. The air interface specification is focused on the interaction
between equipment on-board a commercial vehicle called a transponder or
On-Board Equipment (OBE) and fixed roadside equipment, called a beacon
or Road Side Equipment (RSE). The specification uses a three-layer
version of the Open Systems Interconnection interface model (i.e.,
physical, data link and application layers) which reflects the approach
taken in current North American and international DSRC standards
activities.

1.1 Overview of Specification

The air interface specification adheres to the general DSRC architecture
in which the RSE controls the medium, allocating its use to OBEs within
range of the RSE. As such, it was possible to take advantage of existing
standardization efforts. Specifically, the physical layer specification
is based on the characteristics of the active technology described in
the ASTM standard PS 111-98. The primary deviation from the active
portion of the standard is the elimination of the fast wake-up time
requirement. The data link layer specification is based on the data link
layer portion of the ASTM draft standard, " Standard for Dedicated,
Short Range, Two-Way Vehicle to Roadside Communications Equipment, Draft
6," dated 23 Februrary 1996. Primary deviations from this effort include
elimination of the requirement for a lane-based mode. Finally, the
application layer is a simplified version of the application layer
defined in the IEEE 1455-99. It does not explicitly specify services or
interfaces since the application layer and interface to the lower layer
services are not exposed and thus not testable. It also redefines the
vehicle service table used in the initialization process.

The equipment specification defines characteristics of the OBE such as
minimum memory requirements and user interface devices along with a
command set that allows the RSE to manage OBE resources. It is adopted
directly from IEEE 1455-99; however, there are three significant
extensions. First, the specification provides for backwards
compatibility with existing deployments within a number of CVO programs
including Advantage CVO, Help Prepass and numerous border crossing
deployments. Compatibility with the existing deployments is maintained
by preserving the internal memory structures and capabilities of the
deployed OBEs. Thus, all OBEs conforming to this specification will be
required to have internal memory (as defined by OBEs deployed in current
CVO programs) and external memory defined in this specification.
Attachment A discusses the implications of this specification to
compatibility with existing OBEs and RSEs.

Second, the transfer of memory pages up to 64 Kbytes in length requires
new logical link control features. Supported functions include a
fragmentation counter, flow control, and additional status bits needed
for longer DSRC sessions. The first sixteen bits of the Slot Data
Message have been set aside exclusively to support these functions.

Third, the specification defines a file transfer application that
supports transfers of large data files between a device on the
commercial vehicle, such as an on-board computer, connected to the OBE
and the roadside back-office application. The file transfer capability
operates in a similar fashion to the mailbox application defined in IEEE
1455-99, but requires specialized capability referred to as a Transfer
Page.

Note that all the deviations listed above are also identified in the
introductory text for each relevant section and are underlined and
highlighted in bold text.

1.2 Scope of Specification

Although the air interface and equipment specifications define the
critical elements of the DSRC capability, there are several critical
practical considerations that are not addressed by this specification.
They include: (1) definition of other DSRC system interfaces, (2) memory
page registration and (3) security architecture.

This specification does not address two important interfaces. On the
roadside, the interface between the RSE and the back office application
is not defined. On the vehicle, the interface between the OBE and an
in-vehicle device (e.g., on-board computer, vehicle data bus) is not
defined. This is consistent with the approach taken in IEEE 1455-99. It
is expected that the interface to the back office application will be
defined by a vendor, but its specification should not be proprietary.
Every effort should be made to define an open specification. The
interface between the OBE and an in-vehicle device will likely be based
on one of several computer network or vehicular data bus standards.

One critical component of the IEEE 1455-99 OBE memory architecture is
the use of paged memory. However, the allocation of pages to specific
users is left to a currently undefined IEEE registration process. In
order to develop an OBE with the capabilities necessary to support US
Department of Transportation Federal Highway Administration (FHWA)
sanctioned Commercial Vehicle Operations (CVO) applications as well as
other public and private applications, it will be necessary for FHWA,
vendors, and other agencies to register a number of CVO pages.

The final unaddressed practical consideration is the DSRC security
architecture. Although it is anticipated that it will be necessary to
control access to financial, personal and business sensitive information
on the OBE, this specification does not define a security approach.
(IEEE 1455-99 does not define a specific information security approach,
but does provide opportunities in which a user could implement a variety
of approaches.) IEEE is currently proposing to develop methods to
provide access controls and privacy within the IEEE 1455-99 standard. It
is expected that this specification will rely on the proposed effort to
define the overall security architecture for DSRC used by commercial
vehicles.

**2. Background Material**

**2.1 References\
**

The following documents shall be used, when applicable, in the process
of developing equipment and systems that will be compliant with the
Sandwich Protocol DSRC Standard. When the following documents are
superseded by an approved revision, then that revision shall apply.

ASTM Preliminary Standard-111-98, Specification for Dedicated Short
Range Communication (DSRC) Physical Layer using Microwave in the 920 to
928 MHz band

ASTM Draft Standard for Dedicated, Short Range, Two-Way Vehicle to
Roadside Communications Equipment, Draft 6, dated 23 Februrary 1996

IEEE Standard 1455-99, Standard for Message Sets for Vehicle/Roadside
Communications

**2.2 Abbreviations and Acronyms**

APDU -- Application Protocol Data Unit

ASK - Amplitude Shift Keying

ASN.1 - Abstract Syntax Notation One

AID -- Application Identification

ASTM -- American Society of Testing and Materials

BER -- Bit Error Rate

BOA -- Back Office Application

BST -- Beacon Service Table

CEN -- Center for European Normalization

CFR -- Code of Federal Regulations

C/R -- Command/Response

CRC -- Cyclic Redundancy Check

CVO - Commercial Vehicle Operations

DSRC -- Dedicated Short Range Communications

EID -- Entity Identification

EIRP - Effective Isotropic Radiated Power

FC -- Flow Control

FCC - Federal Communications Commission

FCM -- Frame Control Message

FHWA - Federal Highway Administration

GMT -- Greenwich Mean Time

ID -- Identification

ITS -- Intelligent Transportation Systems

IEEE -- Institute of Electrical and Electronics Engineers

LED -- Light Emitting Diode

LID -- Link Identification

MRA - Media Request Activation

OBC -- Onboard Computer

OBE -- Onboard Equipment

OSI - Open Systems Interconnection

PPM - Parts Per Million

RF -- Radio Frequency

RM -- Resource Manager

RSE -- Roadside Equipment

SDM -- Slot Data Message

S/I - Signal-to-Interference

s-TDMA -- Slotted ALOHA, Time Division Multiple Access

VRC -- Vehicle Roadside Controller

VST -- Vehicle Service Table

**3. Physical Layer**

# 

# 3.1 Introduction

This standard defines the Open Systems Interconnection (OSI) layer 1,
physical layer, for DSRC equipment, operating in two-way, half-duplex,
active mode.

This standard establishes a common framework for the physical layer in
the 902 to 928 MHz LMS band. This band is allocated for DSRC
applications by the Federal Communications Commission (FCC) in Title 47,
Code of Federal Regulations (CFR), Part 90, Subpart M and by Industry
Canada in the Spectrum Management, Radio Standard Specification,
Location and Monitoring Service (902-928 MHz), RSS-137.

The physical layer described within this standard is nearly identical to
the 'Standard Specification for Dedicated Short Range Communication
(DSRC) Physical Layer using Microwave in the 902 to 928 MHz band," ASTM
PS 111-98, with regard to active technology. **[Backscatter technology
is not addressed in this physical layer specification. In addition, an
exception was made in the wake-up time requirements to facilitate
transition from existing products to this specification (see section
3.2.15).]{.underline}** Information not addressed by this document
concerning active technology is identical to that addressed within ASTM
PS 111-98.

# 3.2 Downlink Parameters

3.2.1 Carrier Frequencies: Values of the downlink carrier frequency

Value: The RSE may be operated anywhere within the 915 to 918.75 MHz
band.

3.2.2 Tolerance of Carrier Frequencies: Maximum deviation of the carrier
frequency caused by any means, expressed in parts per million (ppm)

Value: +/- 275ppm

3.2.3 RSE Transmitter Spectrum Mask: Maximum power emitted by an RSE
transmitter as a function of the frequency.

Value: In-band power =\< +44.77 dBm

Out of band power: =\< -25 dBm transmitter power measured in 100 kHz.

3.2.4 RSE Transmitter Spectrum Mask for Modulated Carriers: Relative
power emitted with a modulated carrier by an RSE transmitter as a
function of the frequency.

Value: The in-band emissions shall be attenuated from the peak in-band
power by the indicated value at each frequency offset in the classes
listed below:

Class A: Frequency Deviation (+/-) Attenuation

1.0 MHz \>=12 dB in 100 kHz

1.5 MHz \>=20 dB in 100 kHz

2.0 MHz \>=25 dB in 100 kHz

2.5 MHz \>=33 dB in 100 kHz

3.0 MHz \>=40 dB in 100 kHz

3.5 MHz \>=44 dB in 100 kHz

4.0 MHz \>=48 dB in 100 kHz

4.5 MHz \>=52 dB in 100 kHz

5.0 MHz \>=56 dB in 100 kHz

5.5 MHz \>=60 dB in 100 kHz

6.0 MHz \>=60 dB in 100 kHz

Class B: Frequency Deviation (+/-) Attenuation

1.0 MHz \>=12 dB in 100 kHz

1.5 MHz \>=20 dB in 100 kHz

2.0 MHz \>=35 dB in 100 kHz

2.5 MHz \>=45 dB in 100 kHz

> 3.0 MHz \>=55 dB in 100 kHz and have an output power \<=-25 dBm
>
> 3.5 MHz \>=60 dB in 100 kHz and have an output power \<=-25 dBm
>
> 4.0 MHz \>=63 dB in 100 kHz and have an output power \<=-25 dBm

Any class may be used in a manufacturer's RSE. Not all classes have to
be supported by all RSE.

Note 1: The resolution bandwidth of the instrument used to measure the
peak in-band emission power and the frequency offset in-band emission
power shall be 100 kHz and the video bandwidth shall be 100 kHz.

Note 2: Equipment complying with the different classes will require
different separation distances.

5.  OBE Minimum Operating Frequency Range

Minimum range of frequencies that must be received by the OBE receiver.

Value: All active OBE must meet the requirements of the slow and fast
wake-up operations while receiving emissions from RSE operating on or
between 915 and 918.75 MHz.

3.2.6 Maximum Effective Isotropic Radiated Power (EIRP): The maximum
peak envelope power transmitted by the RSE referred to an isotropic
antenna. The value is normally expressed in dBm, where 0 dBm equals 1
mW.

Value: The maximum EIRP. for each class is limited to the values listed
below or a value less than listed if specified by the installation
country's governing body.

Class A: for f = 915 and 915.75 MHz only, EIRP =\< +40 dBm

Class B: for f= 918.75 MHz only, EIRP =\< +44.77 dBm

3.2.7 Antenna Polarization: Locus of the tip of the vector of the
electrical field strength in a plane perpendicular to the transmission
vector. Examples are horizontal and vertical linear polarization and
left and right-hand circular polarization.

Value: Limited to either Horizontal linear or Left-hand circular

3.2.8 Modulation: Keying of carrier wave by coded data.

Value: Binary Amplitude Modulation (Two-level Amplitude Shift Keying
\[ASK\], with one level being off)

3.2.9 Eye Pattern for RSE: Description of the acceptable amplitude
compared with the time envelope values of the modulated signal created
by an RSE.

Class A&B: Parameter Value

Maximum 'off' carrier to minimum 0.103

'on' carrier ratio

Maximum 'on' carrier to minimum 1.14

'on' carrier ratio

½ of bit period 1 microsecond

Allowed time variance 165 nanoseconds

3.2.10 Data Coding: Baseband signal presentation, such as a mapping of
logical bits to physical signals.

Value: Manchester

3.2.11 Bit Rate: Number of bits per second

Value: 500 kbps

3.2.12 Tolerance of Bit Clock: Maximum deviation of the bit clock
expressed in ppm or percentage (%).

Value: +/- 100 ppm

3.2.13 Bit Error Rate (BER): Averaged number of erroneous bits related
to all transmitted bits. The realized BER assumes an established link,
depends on the application, and does not consider any specific
distribution of errors. Within the maximum horizontal range, the
effective BER may be different from the reference value due to time
variant and stochastic impacts.

Value: 10^-6^ in a non-fading channel (for reference only)

3.2.14 Signal to Interference (S/I): The signal-to-interference ratios
over which the OBE must provide a BER of 10^-5^, or better for downlink
communications. Signal strength is limited to the range 210
millivolts/meter (-30 dBM with 0 dBi ant.) to 9377 millivolts/meter (+3
dBm with 0 dBi ant.) horizontal field strength. S/I measurements will be
made with a signal strength 2 dB above the OBE sensitivity level.

In Band: Interference on the downlink frequency.

> Value: S/I =\> 15 dB

##### LMS Band: Interference located in the 904 to 909.75 MHz and 921.75 to 

#####  928 MHz portions of the LMS Band.

######## Value: S/I =\> 8 dB 

Out of Band: Interference located at the listed frequency offsets from
915 MHz.

###### Values: +/- 13 MHz S/I =\> 0 dB 

> +/- 30 MHz S/I =\> -5 dB
>
> +/- 65 MHz S/I =\> -25 dB

3.2.15 Wake-up Process for OBE: The wake up process within the OBE
switches the OBE main circuitry from standby mode (sleep mode) to the
active mode.

Value: Wake-up is initiated by a received RF carrier at the OBE for the
following specified amounts of time. Under this specification only Slow
Wake-up is required. Fast Wake-up may be implemented at the vendor's
discretion.

Slow Wake-up: \<=50 msec within the power levels specified in the OBE
receiver

operating range for Slow Wake-up. (In testing this parameter an

RSE Write message should be provided in slot 4 of the TDMA

frame.)

Fast Wake-up: \<= 2 msec within the power levels specified in the OBE
receiver

operating range for Fast Wake-up. (Fast Wake-up is not required for
compliance with this specification.)

3.2.16 OBE Receiver Operating Range: Minimum and maximum signal
strengths in which the OBE will respond to the RSE. These two values
also specify the minimum dynamic range of the OBE receiver.

Value:

Slow Wake-up: Minimum signal strength: None -- The OBE may wake-up at
any signal strength less than the maximum indicated below and have a
downlink BER less than 10^-5^.

-   Required Signal Strength: Downlink BER of 10^-5^ at 210
    millivolts/meter\
    (-30dBm with 0 dBi antenna) horizontal signal strength or greater.

```{=html}
<!-- -->
```
-   Maximum Signal Strength: Downlink BER of 10^-5^ at 9377
    millivolts/meter (+3dBm with 0 dBi antenna) horizontal signal
    strength.

Fast Wake-up: Minimum signal strength: Downlink BER of 10^-5^ at 450
millivolts/meter minimum (-23dBm with 0 dBi antenna). (Fast Wake-up is
not required for compliance with this specification.)

-   Required Signal Strength: Downlink BER of 10^-5^ between 450
    millivolts/meter (-23.38dBm with 0 dBi antenna) and 550
    millivolts/meter maximum (-21.63 dBm with 0 dBi antenna) horizontal
    signal strength. (The OBE must not wake-up before the lower signal
    strength and must wake-up on or before the larger signal strength).

-   Maximum Signal Strength: 9377 millivolts/meter (+3dBm with 0 dBi
    antenna) horizontal signal strength.

3.2.17 Preamble/Postamble: The preamble and postamble are sequences of
bits that do not convey information. The preamble is a modulated carrier
designed to facilitate notification of an incoming message and
synchronization of the receiver with the incoming bit stream. The
postamble is designed to facilitate recognition of the end of a message.

Value: All data frames shall be preceded by a preamble. The preamble
shall consist of the following set of 8 bits: 01010101 Binary or 55 Hex.
A postamble will not be used.

# 3.3 Uplink Parameters 

3.3.1 Carrier Frequencies: Values of the uplink carrier frequency

Value: The OBE will generate a carrier of 915 MHz.

3.3.2 Tolerance of Carrier Frequencies: Maximum deviation of the carrier
frequency caused by any means, expressed in parts per million (ppm)

Value: +/- 819ppm for an OBE temperature range of --40 to +75 C
continuous and up to +85 C for up to 30 minutes. (The temperature range
limitation is a deviation from ASTM PS 111-98.)

3.3.3 OBE Transmitter Spectrum Mask[:]{.underline} Maximum power emitted
by an OBE transmitter as a function of the frequency.

Value: In-band power: See Maximum EIRP

Out of band power: =\< -25 dBm in 100 kHz.

3.3.4 RSE Receiver RF Bandwidth: Bandwidth of the RSE receiver

Value: 3 MHz nominal

3.3.5 Maximum EIRP: Maximum EIRP transmitted by the OBE. The value is
normally expressed in dBm where 0 dBm equals 1 mW. All power values are
referred to an isotropic antenna.

Value: The EIRP shall be 3 dBm +/- 3 dBm for a range of 0 to +6 dBm
measured as 170 mV/m to 350 mV/m at one meter with a 0 dBi horizontally
polarized antenna.

3.3.6 Antenna Beamwidth: The angle, measured across the center of the
antenna beam, at each end of which the signal is 3 dB less than the
maximum level.

Value: The OBE transmit and receive antennas shall have a beamwidth of
140 degrees minimum in elevation and 70 degrees minimum in azimuth. The
antenna boresight axis of the OBE transmit and receiver antenna field of
view is composed of the common bisector of both field of view angles.

3.3.7 Vehicle Mounted Antenna Beam Orientation: The position of the
antenna beam relative to the vehicle direction of travel.

Value: The antenna boresight axis, in the required mounting position,
shall be within +/- 10 degrees in azimuth from the direction of travel
and between 0 and 70 degrees above horizontal.

3.3.8 Antenna Position Tolerance: Deviation of the OBE sensitivity as an
effect of rotation about the horizontal, vertical, and boresight axes of
the OBE.

Value: Decreases from maximum sensitivity when the OBE is rotated away
from precise orientations as follows:

+/- 25 degrees rotation around the horizontal axis: =\< 2 dB

+/- 25 degrees rotation around the vertical axis: =\< 2 dB

+/- 25 degrees rotation around the boresight axis: =\< 2 dB

Rotation around any combination of axes: =\< 4 dB

3.3.9 Antenna Polarization: Locus of the tip of the vector of the
electrical field strength in a plane perpendicular to the transmission
vector. Examples are horizontal and vertical linear polarization and
left and right-hand circular polarization.

Value: Horizontal linear

3.3.10 Modulation: Keying of carrier wave by coded data.

Value: Binary Amplitude Modulation (Two-level ASK, with one level being
off)

3.3.11 Eye Pattern for OBE: Description of the acceptable amplitude
compared with the time envelope values of the modulated signal created
by an RSE.

Class A&B: Parameter Value

Maximum 'off' carrier to minimum 0.103

'on' carrier ratio

Maximum 'on' carrier to minimum 1.14

'on' carrier ratio

½ of bit period 1 microsecond

Allowed time variance 165 nanoseconds

3.3.12 Data Coding: Baseband signal presentation, such as a mapping of
logical bits to physical signals.

Value: Manchester

3.3.13 Bit Rate: Number of bits per second

Value: 500 kbps

3.3.14 Tolerance of Bit Clock: Maximum deviation of the bit clock
expressed in ppm or percentage (%).

Value: +/- 450 ppm

3.3.15 BER: Averaged number of erroneous bits related to all transmitted
bits. The realized BER assumes an established link, depends on the
application, and does not consider any specific distribution of errors.
Within the maximum horizontal range, the effective BER may be different
from the reference value due to time variant and stochastic impacts.

Value: 10^-6^ in a non-fading channel (for reference only)

3.3.16 S/I: The signal-to-interference ratios over which the OBE must
provide a BER of 10^-5^, or better for downlink communications. Signal
strength is limited to the range 210 millivolts/meter (-30 dBM with 0
dBi ant.) to 9377 millivolts/meter (+3 dBm with 0 dBi ant.) horizontal
field strength. S/I measurements will be made with a signal strength 2
dB above the OBE sensitivity level.

In Band: Interference on the downlink frequency.

> Value: S/I =\> 15 dB

##### LMS Band: Interference located in the 904 to 909.75 MHz and 921.75 to 

#####  928 MHz portions of the LMS Band.

######## Value: S/I =\> 8 dB 

Out of Band: Interference located at the listed frequency offsets from
915 MHz.

###### Values: +/- 13 MHz S/I =\> 0 dB 

> +/- 30 MHz S/I =\> -5 dB
>
> +/- 65 MHz S/I =\> -25 dB

3.3.17 Preamble/Postamble: The preamble and postamble are sequences of
bits that do not convey information. The preamble is a modulated carrier
designed to facilitate notification of an incoming message and
synchronization of the receiver with the incoming bit stream. The
postamble is designed to facilitate recognition of the end of a message.

Value: All data frames shall be preceded by a preamble. The preamble
shall consist of the following set of 8 bits: 01010101 Binary or 55 Hex.
A postamble will not be used.

**4. Data Link Layer**

**4.1 Introduction**

The beacon shall control all transactions with the transponder, and
implement a slotted ALOHA, time division multiple access (s-TDMA) data
link control protocol as defined within this document. The protocol is
based on a cyclic structure, known as a frame, as shown in Figure 4.1-1.
Frames are transmitted continuously and contiguously. The frame consists
of a Message Control Phase (with the Frame Control Message), a
Transaction Phase (with data message slots), and an Activation Phase
(with activation slots). The protocol permits multiple transponders to
simultaneously request permission to perform a transaction. The beacon
then commands up to four transponders to communicate in one or more
specific message slots within the frame. At the conclusion of each
transaction, a confirmation mechanism is used. If the transaction fails
for any reason, a mechanism to repeat the transaction is initiated.

This specification is based on the data link layer described in the ASTM
draft DSRC standard. However, it differs from the standard in two
significant ways. **[First, the specification alters the network entry
philosophy (of the ASTM draft DSRC specification) to align with the
approach described in IEEE 1455-99. Activation is no longer required by
all compatible OBE's entering the read zone, but a decision to activate
is made by each OBE (see section 4.5). Second, the specification
identifies a logical link control sublayer which is used to facilitiate
the transfer of large data files (see section 4.8.5).]{.underline}**

**4.2 Frame Structure**

The DSRC protocol can be implemented as a dual frame structure to
optimize performance for both wide area (open-road) and land-based
applications. However, only the wide area protocol is required for
compliance with this specification.

4.2.1 Wide Area Frame

There shall be four message slots and sixteen activation slots in a
9.676 millisecond frame. All OBEs shall be capable of transmitting or
receiving in at least two message slots per frame.

4.2.2 Lane-Based Frame

There shall be one message slot and four activation slots. This option
is not required under this specification, but may be needed to support
some legacy applications.

**4.3 Message Control Phase**

The frame structure, synchronization, message slot assignments,
transaction type, and data link control shall be commanded by the beacon
during this phase via the Frame

![](media/image2.wmf){width="5.999305555555556in"
height="7.309722222222222in"}

Figure 4.1-1 Frame Structure and Timing

Control Message (FCM). Assignments are based upon requests received
during Activation Phases of preceding frames. The beacon may assign
multiple message slots and/or multiple frames to a transaction with a
transponder. In this case, the slot command and Transponder ID will
appear in multiple slot assignment fields in the FCM.

**4.4 Transaction Phase**

The slot command in the FCM shall indicate the type of transaction and
in which slot(s) the transaction shall be performed. A transaction may
be transmit or receive, addressed or broadcast, and internal or external
data messages.

4.4.1 Message Acknowledgement

The beacon shall send an acknowledgement message after each scheduled
addressed transponder transmission. The transponder shall send an
acknowledgment message after each scheduled addressed transponder
reception. The acknowledgment shall be set positive if a valid message
is received (i.e., no Cyclic Redundancy Check \[CRC\] error and no link
validation error). Otherwise, the acknowledgment shall be set negative.
An incorrectly received acknowledgment shall be considered negative.

**4.5 Activation Phase**

The Beacon shall transmit a FCM at the beginning of each frame to define
the frame structure, enable activation, and establish synchronization
with transponders. In accordance with IEEE 1455 requirements, the reader
suppresses activation by legacy OBE's and FHWA OBE's that do not contain
the application information desired by the RSE. This is accomplished by
using Frame Control bits 1 and 2 in the FCM to Inhibit Transponder
Activation and Enable External Activation. Both normal and external
activation may be permitted during a transition period when data from
both FHWA OBE's and legacy OBE's must be read. To inform OBE's which
memory pages are desired, the reader periodically transmits a beacon
service table (BST) to the global ID using an External Memory Write.
When transmitting the BST the Slot Command (section 4.8.7) must indicate
the presence of a BST and "Transaction Not Complete" shall be asserted
to guarantee sufficient processing time on the OBE. The BST structure is
defined in Section 9.

The OBE processor examines the requested page ID's in the BST and
determines whether or not the requested pages are present. If both of
the requested pages are present, the OBE initiates External Activation
by randomly choosing an Activation Slot and preparing to send an
External Transponder ID message. The beacon shall listen for Transponder
ID Messages in all of the activation slots at the end of the current
frame, and shall make appropriate transaction assignments in the next
available frame.

Upon receiving External Activation, the RSE allocates uplink slots to
receive the VST. The VST consists of the requested pages. OBE Page 1
will be returned only when specifically requested. The OBE configuration
bits identified in IEEE 1455-99 Table 9.5.2-1 will not be included.
Since the VST is a response to an implicit Read Memory Page command, the
standard command response format described in section 7.5 will be
utilized. A "No Request" page ID (page 0) is always considered present
on the OBE, but does not result in the transmission of data. (An RSE
requesting Page 0 and Page 0 will not assign uplink slots when OBE
activation is detected since the VST has no content.)

**4.6 Guard Bands and Extended Headers**

4.6.1 Guard Bands

Guard Bands, defined as a period of no RF transmission, shall be as
follow:

-   Following each Activation Phase 250sec +10%,-0%

-   Following each Transponder ID Msg 8sec

-   Preceding the Extended Header of each 40sec

Originated Slot Data Message (SDM) or Acknowledgement

-   Preceding each Transponder-Originated 100sec

SDM or Acknowledgement

2.  Extended Headers

An extended header, consisting of one of the following data patterns --
all binary "1's", all "0's", or alternating 1's and 0's -- shall be
transmitted prior to the messages specified below. The preferred data
pattern is "0101...". The number of bits of extended header shall be as
follows:

-   Prior to the FCM 375 bits

-   Prior to each Reader-Originated 30 bits

> Acknowledgement Message

-   Prior to each Reader-Originated SDM 30 bits

**4.7 Message Formats and Field Sequencing:**

4.7.1 Frame Control Message

The Frame Control Message provides link control, frame parameters, and
dictates the transaction assignments that are to be performed by
transponders in the current frame.

## Field Definition [No.]{.underline} Bits Binary Value

Header Code

Selsyn 8 01010101

Flag 8 10001101

Frame Control 4 -

Message Type 4 1100

Slot 1 Command 8 -

Slot 1 Transponder ID 32 -

Slot 2 Command 8 -

Slot 2 Transponder ID 32 -

Slot 3 Command 8 -

Slot 3 Transponder ID 32 -

Slot 4 Command 8 -

Slot 4 Transponder ID 32 -

Sleep Timeout 4 -

Spare 2 00

Activation Response Parameter 2 -

Validation Seed 64 -

CRC [16]{.underline} -

Total bits 272

2.  Slot Data Message

The Slot Data Message contains a data packet to or from the transponder.
Content of the Message Data is application specific. Unused bits should
be set to zero. Note that for External Memory transactions 16 bits of
the Message Data have been set aside for Logical Link Control functions.
The number of Message Data bits is reduced to 496. For Internal Memory
transactions none of the Message Data bits are used for Logical Link
Control.

## Field Definition [No.]{.underline} Bits Binary Value

Header Code

Selsyn 8 01010101

Flag 8 10001101

Data Link Header 4 1000

Message Type 4 01xx

Logical Link Control (Internal/External) 0/16 -

Message Data (Internal/External) 512/496 -

Validation Check 8 -

CRC [16]{.underline} -

Total bits 560

4.7.3 Acknowledgement Message

The Acknowledgement Message indicates whether or not the prior Slot Data
Message was received properly. The format is the same for both the
beacon and transponder. All SDMs shall be acknowledged with a positive
or negative response, except for Broadcast messages.

## Field Definition [No.]{.underline} Bits Binary Value

Header Code

Selsyn 8 01010101

Flag 8 10001101

Data Link Header 4 1000

Message Type 4 1001 (Positive Ack)

1000 (Negative Ack)

CRC [16]{.underline}

Total bits 40

4.7.4 Transponder ID Message

The Transponder ID Message is used by the transponder to notify the
beacon that it is present in the communication zone, and to request
establishment of a logical link to perform a transaction with the
beacon. Battery condition detection status is a vendor option. When
detection is implemented, Message Type filed shall be coded as shown.
Otherwise, Message Type filed shall return a 0001 response.

## Field Definition [No.]{.underline} Bits Binary Value

Header Code

Selsyn 8 01010101

Flag 8 10001101

Transponder Type 4 -

Message Type 4 0000 (Low Battery)

0001 (Battery OK)

Transponder ID 32 -

CRC [16]{.underline} -

Total bits 72

4.7.5 External Transponder ID message (Media Request Activation message)

The External Transponder ID Message is transmitted by an OBE to notify
the RSE that an attached application layer process has data to send.
This message is equivalent to a system interrupt. This message is also
referred to as a Media Request Activation (MRA) message and is
transmitted in an Activation Slot.

## Field Definition [No.]{.underline} Bits Binary Value

Header Code

Selsyn 8 01010101

Flag 8 10001101

Transponder Type 4 -

Message Type 4 0010

Transponder ID 32 -

CRC [16]{.underline} -

Total bits 72

**4.8 Field Formats and Bit Definitions:**

All data fields shall be transmitted most significant byte first and
most significant bit first.

4.8.1 Activation Response Parameter

This 2-bit field specifies the probability transponders will use to
determine if they will transmit a Transponder ID message in the current
frame, or defer activation to a future frame. This field permits the
beacon to modulate the level of activity in systems where large numbers
of transponders are in the communications zone. The field is coded as
follows:

[Code]{.underline} [Activation Probability]{.underline}

1.  100%

2.  50%

10 25%

11. 12.5%

4.8.1.1 If the transponder chooses to respond in the current frame, the
transponder shall interpret the Frame Control field to determine the
current frame structure. The transponder shall then randomly select one
of the activation slots in which to send the Transponder ID message.

4.8.1.2 If the transponder chooses to defer to a future frame, then no
Transponder ID message shall be transmitted in the current frame.

4.8.2 Data Link Header

A 4-bit field reserved for future message control between the
transponder and beacon. Field shall be set to a value of binary 1000 to
define "no operation".

3.  Frame Control

> This 4-bit field identifies the type of beacon protocol and activation
> control.

[Bit]{.underline} [Code]{.underline} [Definition]{.underline}

3 1 Wide Area Frame

1.  Lane-Based Frame (not used under CVO protocol)

2 1 Transponder Activation Inhibited

1.  Transponder Activation Enabled

1 1 External Activation Inhibited

1.  External Activation Enabled

0 1 Extended Variable Framing

0 Normal TDMA Framing

4.8.3.1 Frame Type -- Bit 3 shall identify which frame structure shall
be used for the current frame, as shown in Figure A-1.

4.8.3.2 Transponder Activation Enabled -- If Bit 2 = 0, transponders
entering the communications zone shall make an attempt to gain entry by
transmitting an appropriate Transponder ID Message during the Activation
Phase. The probability of responding during the Activation Phase,
however, shall be governed by the Activation Response Parameter.

3.  Transponder Activation Disabled -- Bit 2 = 1, transponder shall not
    respond with a Transponder ID Message during the current Activation
    Phase. The remainder of the FCM shall still be interpreted and
    processed, however, and the transponder shall perform any command
    operations.

4.  External Activation Enabled -- If Bit 1 = 0, then transponders shall
    be allowed to respond with an External Transponder ID Message (Media
    Request Activation Message) during the current Activation Phase. The
    probability of responding during the Activation Phase, however,
    shall be governed by the Activation Response Parameter.

5.  External Activation Inhibited -- If Bit 1 = 1, then transponders
    shall not respond with an External Transponder ID Message (Media
    Request Activation Message) during the current Activation Phase. The
    remainder of the FCM shall still be interpreted and processed,
    however, and the transponder shall perform any commanded operations.

6.  Normal TDMA Framing -- If Bit 0 = 0, then remaining Frame Control
    field bits define normal protocol operation as shown in Figure A-1.

7.  Extended Variable Framing -- If Bit 0 = 1, then remaining Frame
    control bits must be set as follows: Bit 3 = 0, Bit 2 = 0, bit 1
    = 1. This combination provides a means to permit a beacon to
    generate an extended variable frame messaging structure. This
    feature is designed for future expansion. The specific protocol is
    outside the scope of this standard.

```{=html}
<!-- -->
```
3.  Message Type

This 4-bit field identifies the specific type of DSRC message. The bits
are coded as follows:

[Code]{.underline} [Definition]{.underline}

0000 Transponder ID Message with Low Battery Indication

0001 Transponder ID Message with Battery OK Indication

0010 External Transponder ID Message (Media Request Activation Message)

0011 (unused)

0100 Normal Slot Data Message

0101 (unused)

0110 Reserved for Factory Programming Message

0111 Reserved for Agency Programming Message

1001 Positive Acknowledgment Message

1010 (unused)

1011 (unused)

1100 Frame Control Message

1101 (unused)

1110 (unused)

1111. (unused)

4.8.4.1 Reserved Codes -- Message Type codes 0110 and 0111 are not user
accessible and shall be reserved only for Factory and Agency programming
functions.

4.8.5 Logical Link Control

Link control features have been added to support the transfer of large
memory pages. These include a fragment counter for
fragmentation/defragmentation and flow control. Several status bits have
been added to clarify link operation. These link control bits are
implemented only for external memory operations. Operations using
internal memory will not implement these bit fields. The following bit
fields have been defined:

> a\. Flow Control (FC), 1 bit --This bit is used by the OBE to request
> a pause in flow for either uplink or downlink operations. The bit is
> used by the RSE to indicate that the next uplink slot allocated to the
> OBE is intended to read the flow control status. When the RSE needs a
> pause in data flow due to an internal resource limitation, the RSE
> simply stops allocating slots.
>
> \- OBE Uplink Flow Control. A pause in uplink flow ("Stop allocating
> uplink slots") is requested by the OBE by setting the Flow Control
> bit. No new data will be transmitted by the OBE after setting the bit;
> transmissions may be stopped (if an ACK was received) or data may
> simply be repeated if slot allocations continue. If the RSE is still
> assigning uplink slots to the OBE when the OBE is ready to continue,
> the data flow continues as before the stoppage with the Flow Control
> bit cleared. If the RSE has stopped assigning uplink slots to the OBE,
> the OBE requests a continuation of data flow by transmitting a MRA
> Message. Upon receiving the MRA, the RSE restarts the assignment of
> uplink slots. The OBE LLC status bits should reflect normal operation;
> Flow Control bit cleared and Fragment Counter set to the number of the
> current fragment. Valid Message Data starts with the first uplink
> slot.
>
> \- OBE Downlink Flow Control. No explicit signaling is provided for
> Downlink Flow Control. When the OBE needs a pause during a downlink
> operation, it begins replying to downlink slots with a negative
> acknowledgement (NACK). If the pause is short, the RSE repeats the
> unacknowledged slot. The OBE clears its backlog and continues
> acknowledging downlink data. Layer 2 is never expected to accommodate
> a flow control delay of more than a few frames since transactions
> occur only as page transfers and the full page memory space must be
> available on the tag in order to initiate the transaction.
>
> b\. Sequence Number (S), 1 bit - Whenever a Layer 2 acknowledgment of
> a Slot Data Message is received, the Sequence bit is toggled to
> indicate the next transmission is new data. This bit permits Layer 2
> (even though it's in the external processor, it's still Layer 2) to
> differentiate between successive, single-fragment transactions without
> resorting to examining the data.
>
> c\. Command/Response (C/R), 1 bit -- Used by the RSE to command an
> application layer response consisting either of data or a confirmation
> that a command was successful. Setting the RSE C/R bit The bit is used
> by the OBE to indicate the status of the requested response, 1
> indicates that the response is ready (and provided), 0 indicates that
> the OBE response is not yet available. When the response is not ready,
> the RSE may continue to assign uplink slots to receive the response.
> If slot assignments are available when the response becomes available,
> the OBE sets the C/R bit and returns the response. If the RSE has
> stopped assigning slots during the wait, the OBE transmits a Media
> Request Activation Message to indicate that the response is now
> available.
>
> d\. First (F), 1 bit -- The "First" bit is set for the first fragment
> in a transaction. This permits the OBE to more easily identify the
> start of a broadcast transmission (so the OBE can tell when it has the
> whole message).
>
> e\. Activation (A), 1 bit -- Set to 1 by the OBE on the first uplink
> slot assigned after activation of a new session. Set to 0 for all
> other uplink slots indicating the continuation of a session. This bit
> permits the RSE to identify an OBE that has declared a failure in an
> incomplete session and initiated a new session.
>
> f\. Fragment Counter (Frag), 11 bits - This is large enough to span a
> 64 K[bytes]{.underline} page and header divided into 496 bit fragments
> (512 bit slots minus the 16 control bits per slot). The counter counts
> down from N-1 for an N fragment transaction. A zero counter-value
> indicates the last fragment. Frag0 is the least significant bit and is
> transmitted last.

  ----------- ------- ------- ------- ------- ------- -------- ------- -------
  **Bit       **7**   **6**   **5**   **4**   **3**   **2**    **1**   **0**
  Number**                                                             

  **First     FC      S       C/R     F       A       Frag10   Frag9   Frag8
  Byte**                                                               

  **Second    Frag7   Frag6   Frag5   Frag4   Frag3   Frag2    Frag1   Frag0
  Byte**                                                               
  ----------- ------- ------- ------- ------- ------- -------- ------- -------

4.8.6 Message Data

This contains the packet of information that is transferred to or from
the transponder. This data could be either a single internal transponder
data packet, or external single or multi-packet application data,
depending upon bit 4 of the associated Slot command in the Frame control
Message.

For External Memory transactions the packet is a 496-bit field with 16
bits dedicated to Logical Link Control (4.8.4). For Internal Memory
transactions the packet is a 512-bit field. For a Downlink Internal
Message only, the first eight bits of the message are reserved for a
driver interface command field. The coding is given below:

[Field Definition]{.underline} [Bit]{.underline} [Coding]{.underline}

Visual Signal Activation 7,6 00 = Visual Signal Off

01 = Activate Green

10 = Activate Red

11 = Activate Yellow

Audio signal Activation 5,4 00 = Audio Signals Off

01 = Activate Continuous

10 = Activate Intermittent

11 = Not Used

Data Field Indicator 3,2 00 = Data Field Valid

01 = Driver Interface Command Only -- Ignore Data Field

10 = Not Used

11 = Not Used

# 

Reserved 1,0 Reserved

4.8.7 Sleep Timeout

This 4-bit field defines the period of time that a transponder shall not
attempt activation after a completion of the current transaction with
the beacon. This field is coded as binary values from 0000 to 1111. Each
value is then multiplied by 2 seconds, i.e. 0-30 seconds. (This
mechanism for commanding sleep is required in addition to the IEEE 1455
Sleep Transponder command (6.4.8).)

4.8.8 Slot Command

This 8-bit field identifies the transaction assignment for a specific
Message Slot. The bits are coded as follows:

[Bit]{.underline} [Code]{.underline} [Definition]{.underline}

7 1 Transmit Message to Beacon

0 Receiver Message from Beacon

6 1 Acknowledge Message

1.  Unacknowledged Message

5 1 Last Frame of Transaction

1.  Transaction Not Complete

4 1 Internal Memory/Application

1.  External Memory/Application

3,2 00 Normal Slot

01 Idle Slot

10 Continuous Wave Slot

11 **(**undefined)

1 1 BST Present

0 BST Not Present

0 0 Reserved

4.8.8.1 Bit 7: Transmit/Receive -- The transponder shall transmit or
receive in the indicated slot depending on the value of this bit field.

4.8.8.2 Bit 6 =1: Acknowledged Message -- The transponder shall perform
the commanded transmission or reception, with acknowledgment. Global ID
is not permitted. Positive or negative acknowledgment status shall be
passed to the application layer. If the transponder receives an
error-free message during the associated slot, then the transponder
shall transmit a positive acknowledgement at the end of the slot.
Otherwise, the transponder shall transmit a negative acknowledgment. If
the transponder transmits a message during the associated slot, then the
transponder shall expect an acknowledgment from the beacon at the end of
the slot. If no acknowledgment is received, then a negative
acknowledgment shall be assumed.

4.8.8.3 Bit 6 = 0: Unacknowledged Message -- The transponder shall
perform the commanded transmission or reception without acknowledgment.
No acknowledgment message shall be transmitted or expected. This bit
shall be ignored when the beacon uses the Global ID to broadcast
messages to all transponders.

4.8.8.4 Bit 5 = 1: Last Frame -- The transponder shall attempt to
complete the assigned transaction in the current frame, then process the
sleep function. If the transaction is completed successfully, the
transponder shall initiate the sleep function at the end of the frame,
using the sleep timeout value included in the FCM. If the transaction is
not completed successfully, the transponder shall not initiate the sleep
function at the end of the frame.

4.8.8.5 Bit 5 = 0: Transaction Not Complete -- Transponder shall
maintain link activation as additional messages are pending to complete
the transaction.

4.8.8.6 Bit 4 =1 : Internal Memory/Application -- A single packet
message will be sent from or received to the memory within the
transponder. If the single packet is a transponder receive message, then
the most significant 8 bits of the 512-bit field are reserved for
transponder application layer control purposes. The remaining 504 bits
are interpreted as the data field. If the single packet is a transponder
transmit message, then the entire 512 bits shall be constructed using
internal transponder memory and ID information.

4.8.8.7 Bit 4 = 0: External Memory/Application -- Single packet or
multi-packet messages shall be transferred to or from an attached
application buffer, depending upon whether the Slot Command indicates
receive or transmit. That is, none of the 512 bits in each packet are
interpreted by the transponder. The data field is considered to be an
end-to end message between the beacon and transponder-attached
application process.

4.8.8.8 Bit 3 & 2: Slot Type -- These two bits shall be coded as follows
to determine what type of slot commanded:

> [Code]{.underline} [Definition]{.underline}

1.  A normal communication slot, as commanded by bits 7 through 4

> 01 The addressed transponder shall remain idle for the associated
> slot. In this case, bits 7, 6, and 4 shall be ignored.
>
> 10 The addressed transponder shall transmit a continuous wave signal
> for the 560-bit duration of the assigned message slot. In this case,
> bits 7, 6, and 4 shall be ignored.

11 Currently undefined. When these bits are set to 11, the transponder
shall

default to idle.

4.8.8.9 Bit 1: Broadcast Service Table -- A BST as defined in Section 9
shall be transferred in this slot. (This slot is expected to be a global
external write.)

4.8.9 Transponder ID

A 32-bit binary value that uniquely identifies the link address of each
transponder. A mechanism shall be established by an approved authority
or organization to allocate unique ID values among manufacturers. Unique
ID values shall be in the hexadecimal range between 0000 0001 through
FFFF FFFE, inclusive. Remaining addresses are reserved. Four types of
transponder IDs are permitted:

4.8.9.1 Global ID -- A reserved address with the hexadecimal value of
0000 0000. Every transponder shall decode this value. It shall be used
exclusively for broadcast transmission from the beacon to all
transponders in the communication zone.

4.8.9.2 Public ID -- A permanent, unique 32-bit identifier that is used
to determine the link address of each transponder. This identifier shall
be programmed once into the unit during factory programming. This
identifier shall be used as the Transponder ID only if the Transponder
Type field indicates "Public Link Entry". Otherwise, this identifier
shall not be used. The global ID value is not permitted.

4.8.9.3 Random ID -- A 32-bit identifier that is chosen at random by the
transponder, for the purpose of "Anonymous Link Entry". This identifier
shall be chosen only once, upon wake-up, and shall not change value
until the transponder exits the logical link (sleeps & re-awakens). This
identifier shall be used as the Transponder ID only if the Transponder
Type field indicates "Anonymous Link Entry". Otherwise, this identifier
shall not be used. The Global ID value is not permitted.

4.8.9.4 Private ID -- A permanent, unique 32-bit identifier which may be
used exclusively to validate Agency Programming Messages (Message Type
code 0111). This identifier shall be programmed into the unit during
factory programming. The Global ID value is not permitted. The contents
of the Private ID are not governed by this specification.

4.8.10 Transponder Type

This 4-bit field specifies the type of transponder, what capabilities
are available for the transaction, and identifies which transponder ID
is used for activation.

[Bit]{.underline} [Code]{.underline} [Definition]{.underline}

3 1 Open-Road Frame capable

0 Open-Road or Lane-Based capable

2 1 Anonymous Link Entry (Use Random ID for Transponder ID)

1.  Public Link Entry (Use Public ID for Transponder ID)

1,0 00 Extended Protocol Capable\*

01 Internal Read-Only

10 Internal Read/Write

11 Internal and External Read/Write

\*Extended Protocol -- Transponder Type field must be set to binary 0000
to signal the beacon of a capability to support an extended protocol.
This feature is designed for future expansion. Any specific protocol is
outside the scope of this standard.

4.8.11 Validation Check

This 8-bit field is generated by the link validation algorithm and is
used by the beacon or transponder to validate a received Slot Data
Message. All fields except the Header Code are included in the
calculation.

4.8.12 Validation Seed

This 64-bit field contains the random number seed used to initialize the
validation algorithm in a given frame. This seed is used in the
validation of every Slot Data Message transmitted in the Transaction
Phase. This feature provides uplink playback protection for the beacon.

**4.9 Message Processing**

4.9.1 Link Protocol Flow

The DSRC communications protocol permits two-way messaging between the
beacon and one or more transponders in an application specific
communications zone. Messages are separated into one or more data
packets of 512 bits each.

1.  Packet Communications may be accomplished by, but not limited to,
    any of the following means:

-   Single packet per vehicle, one to four vehicles simultaneously each
    frame

-   Multiple packets per vehicle per frame.

-   Multiple packets per vehicle in multiple frames.

-   Multiple packets between one or more vehicles in multiple frames.

    1.  Protocol flowcharts are shown in Figures 4.9.1.2-1 through
        4.9.1.2-4.

    ```{=html}
    <!-- -->
    ```
    1.  Transponder ID Message

The Transponder ID Message is not used within the CVO protocol since
only the External Transponder ID Message (MRA Message) is used. This
message is nonetheless needed to maintain compatibility with legacy
systems and is therefore required.

Upon first entering the beacon communication zone (after sleep timeout
expires) and receiving a valid FCM, the transponder shall determine
whether or not it is allowed to respond during the Activation Cycle. If
the Frame Control field in the FCM indicates "Transponder Activation
Enabled", then the transponder is allowed to respond in the Activation
Cycle with a Transponder ID Message. In the case, the transponder shall
use the Activation Response Parameter provided in the FCM in order to
determine the response probability. The response probability shall be
used to determine if the transponder will choose to respond in the
current frame, or defer to a future frame. If the transponder chooses to
defer to a future frame, then no activation message shall be transmitted
in the current frame.

However, if the transponder chooses to respond in the current frame, the
transponder shall interpret the Frame Control field in order to
determine the current frame structure (i.e., how many activation slots).
The transponder shall then randomly select one of the activation slots
in which to send this message as shown in Figure 4.9.2-1. So long as the
Frame Control field indicates "Transponder Activation Mode", the

![](media/image3.wmf){width="5.517361111111111in"
height="6.770833333333333in"}

Figure 4.9.1.2-1 Top Level Protocol Flowchart

![](media/image4.wmf){width="5.5777777777777775in"
height="8.596527777777778in"}

Figure 4.9.1.2-2 Transponder Activation Phase Processing

![](media/image5.wmf){width="5.215277777777778in"
height="7.638888888888889in"}

Figure 4.9.1.2-3 Transaction Phase Processing

![](media/image6.wmf){width="5.839583333333334in"
height="8.698611111111111in"}

Figure 4.9.1.2-4 Message Slot Processing

![](media/image7.wmf){width="5.9944444444444445in"
height="6.105555555555555in"}

Figure 4.9.2-1 Sample Link Activation and Entry Sequence

transponder shall repeat this process each frame until link entry is
successful, as evidenced by an internal or external message slot
assignment that is specifically addressed to the transponder. A message
slot assignment with the Global ID of 0000 0000 shall not be considered
sufficient to assume that a link entry is successful. However, any such
message slot assignment shall be processed properly.

If the Frame Control field indicates "Activation Inhibit", then the
transponder shall refrain from responding during the Activation Cycle of
the current frame.

4.9.3 External Transponder ID Message (Media Request Activation Message)

Upon receiving a transmit request from an attached application layer
host, the transponder shall determine whether or not it is allowed to
respond during the Activation Cycle. If the Frame Control field in the
FCM indicates "External Activation Enabled", and if the transponder is
currently in the link (i.e., the transponder has been previously
assigned a message slot with its own Transponder ID), then the
transponder is allowed to respond in the Activation Cycle with External
Transponder ID Message.

In this case, the transponder shall use the Activation Response
Parameter provided in the FCM in order to determine the response
probability. The response probability shall be used to determine if the
transponder will choose to respond in the current frame, or defer to a
future frame. If the transponder chooses to defer to a future frame,
then no activation message shall be transmitted in the current frame. If
the transponder chooses to respond in the current frame, the transponder
shall interpret the Frame Control field in order to determine the
current frame structure (i.e., how many activation slots). The
transponder shall then randomly select one of the activation slots in
which to send this message. So long as the Frame control field indicates
"External Activation Enabled", and the transponder remains in the link,
The transponder shall repeat this process each frame until host link
access is provided, as evidenced by an external message slot assignment.
A message slot assignment with the Global ID of 0000 0000 shall not be
considered sufficient to assume that link entry is successful. However,
any such message slot assignment shall be properly processed.

If the Frame control field indicates "External Activation disabled",
then the transponder shall refrain from responding during the Activation
Cycle of the current frame.

4.9.4 Downlink Internal Message Slot

The Downlink Internal Message is not used within the CVO protocol since
only external memory operations are performed. Likewise, the driver
interface implemented through this message has been replaced for CVO
operations with the IEEE 1455-99 user interface. This message and driver
interface are nonetheless needed to maintain compatibility with legacy
systems and are therefore required.

A message from the beacon to the transponder internal 512 bit message
buffer. If the message was received without error then a positive
acknowledgment shall be sent to the beacon if so commanded. If the data
was received in error, the information shall be discarded and a negative
acknowledgment sent to the beacon, if so commanded.

If the data field valid field in the driver interface command field
indicates that the message data is valid, then the 256 least significant
bits of the message shall be stored in the general-use portion of the
transponder's internal memory. If the data field valid field in the
driver interface command field indicates that the message data are not
valid, the message data shall be discarded. However, the driver
interface command shall be executed in all cases of a valid message
reception.

Upon receipt of a valid Downlink Internal Message, the transponder shall
activate the appropriate signals immediately. These signals shall be
activated independently of the sleep function. Furthermore, the
specified signal command shall override any previous signal command that
is still active.

5.  Downlink External Message Slot

A message from the beacon to a 512-bit buffer not located in the
transponder. If the message was received without error then a positive
acknowledgement shall be sent to the beacon if so commanded. If the data
were received in error, the information shall be discarded and a
negative acknowledgement sent to the beacon, if so commanded.

6.  Uplink Acknowledgement Message

During an assigned message slot in which the transponder is scheduled to
receive an addressed Slot Data Message, the transponder shall transmit
an Acknowledgment Message with either a positive or negative indication.
[Note that, during non-addressed message slots, acknowledgments are not
expected, and should be ignored entirely.]{.underline}

7.  Uplink Internal Message Slot

A scheduled transmission in an assigned message slot from the
transponder to the beacon. The entire 512-bit field shall be constructed
using internal transponder memory and ID information. The least
significant 256 bits of this field shall be copied directly from the
General-use memory. The lower 192 bits of the most significant 256 bits
shall be copied directly from the agency memory. The most significant 64
bits shall be used for transponder identification. Of these 64 bits, the
most significant 32 bits shall be set equal to the Transponder ID (which
could be either the Public ID or the Random ID). The lower 32 bits of
the 64-bit field shall be set to zero (the Private ID shall never be
transmitted). The bit positions of each field in the uplink message are
defined below:

[Field Definition]{.underline} [Field Size (bits)]{.underline} [Bit
Number]{.underline}

Public ID 32 480-511

All Zeros 32 448-479

Agency Memory Contents 192 256-447

General-Use Memory Contents 256 0-255

8.  Uplink External Message Slot

A scheduled transmission in an assigned message slot from the
transponder to the beacon. The transponder shall obtain the message
packet from an external 512 bit buffer (application layer) and build the
Slot Data Message.

9.  Downlink Acknowledgement Message

During an assigned message slot in which the transponder is scheduled to
transmit an addressed Slot Data Message, the beacon shall transmit an
Acknowledgment Message with either a positive or negative indication.
[Note that, during non-addressed message slots, acknowledgments are not
expected, and should be ignored entirely]{.underline}*.*

**5. Transponder Resources**

Transponders that are compliant with this document shall provide
internal resources in accordance with the specifications described in
this section. While a range of transponders having various capabilities
may be defined in a manner compliant with those specifications, the
basic structure and the capabilities definitions shall be adhered to in
all cases. Not all resources defined in this section are mandatory in
compliant transponders.

Many transponder identifiers provide for values that are available for
registration. The registration process is controlled by the IEEE and is
not defined within this document.

Note that this section is nearly identical to Clause 5 of IEEE 1455-99
with **[one primary exception, the requirement to support a Transfer
Page. The Transfer Page is intended to support the transfer of data
files between the RSE and an on-vehicle data system or Onboard Computer
(OBC) connected to the OBE (see Section 5.1.7).]{.underline}**

1.  **Transponder resources definition**

This section functionally identifies and specifies the transponder
resources requirements. These requirements shall in no way constrain the
actual hardware implementation of transponders as long as the associated
resources are partitioned in a manner compliant with this specification.
A transponder compliant with this specification shall provide resources
as defined in 5.1.1 through 5.1.12. These resources are illustrated in
Figure 5.1-1.

![](media/image8.wmf){width="4.132638888888889in"
height="3.5076388888888888in"}

Figure 5.1-1 Transponder Resources

1.  Wireless interface

The transponder shall provide a wireless interface with the RSE. The
characteristics of this interface are outside the scope of this
specification. It is expected that this specification may be implemented
in conjunction with a wide variety of radio frequency (RF) interfaces.
However, the wireless interface must support the data transfers
specified within this specification.

2.  Controller

The controller shall interpret and implement commands (listed in Section
6) when received across the wire­less interface. Implementation of those
commands will typically require access to or control of the other
transponder resources listed in this section. The controller may also
implement the interface with other OBE.

3.  External interface

Compliant transponders may provide an external interface. The
availability and characteristics of this inter­face shall be indicated in
the read-only memory (as defined in 5.2). If implemented, this interface
shall pro­vide other pieces of OBE with access to the transponder's
resources and through those resources provide communications with the
roadside. The characteristics of this interface and the command set used
across the external interface are outside the scope of this
specification. However, it is anticipated that the command set will be
comparable to that implemented across the wireless interface with the
roadside.

4.  Memory management and page identification

Memory within the transponder is formatted into partitions and pages. A
partition is an area of memory that may be controlled by access
credentials within which pages may be allocated. A page is an area of
memory within a partition, which may also be protected with access
credentials and from which data may be read or written.

As defined in 5.1.5 through 5.1.7, transponders may provide read-only
memory, read/write memory, and/or extended read/write memory. While
read-only memory and read/write memory pages are predefined, com­mands
defined in Section 6 allow dynamic configuration of the extended
read/write memory. This dynamic configuration may be accomplished by
allocating partitions within the extended read/write memory or by
reserving pages.

Pages may be reserved either within an existing partition or within the
overall extended read/write memory area. A partition identifier is
specified when a partition is allocated, and it is referenced when a
page is reserved within the partition. A page identifier is specified
when a page is reserved, and it is referenced when a page is accessed. A
sample of partition identifiers is provided in Table 5.1.4-1.

Table 5.1.4-1 Sample partition identifiers

  ------------------------------- ---------------------------------------
  Partition number                Partition designation

  hex( 0000 )                     Reserved

  hex( 0001 -- FFFF )             Available for registration
  ------------------------------- ---------------------------------------

Compliant transponders shall comply with the following requirements:

-   The minimum memory page size shall be 128 bits.

-   The maximum memory page size shall be 64 Kbytes. This limitation is
    based upon the maximum length of a read/write memory page command.

-   The first memory page shall always exist and shall be a read-only
    memory page as defined in 5.1.5.

-   All memory pages shall have an associated 16-bit page identifier
    that can be used by the transponder commands described in Section 6.

-   The first three transponder memory pages shall always be assigned
    the Page Identifiers hex( 1 ) through hex( 3 ).

-   Page Identifiers hex( 4 ) through hex( 7 ) refer to predefined
    combinations of the first three memory pages.

-   The page identifiers associated with the transponder user interface
    (UI) shall be assigned from values above hex( FEFF ). These default
    values may be overridden by aliasing other page identifiers to the
    default identifiers using the commands defined in Section 6.

-   Unreserved page identifiers may be assigned to agencies on an
    implementation-specific basis.

A sample of defined page identifiers is provided in Table 5.1.4-2. Page
numbers shall be unique within a transpon­der, i.e., duplicate page
numbers shall not be used in different partitions.

Table 5.1.4-2 Sample page identifiers

  -------------------------- --------------------------------------------
  Page number                Page designation

  hex( 0 )                   Reserved

  hex( 0001 .. FFFF )        Specific values are defined in Table E.2 of
                             IEEE 1455-99
  -------------------------- --------------------------------------------

1.  Read-only memory

Compliant transponders shall provide 16 bytes (128 bits) of read-only
memory. The information within this region shall be formatted as
specified in 5.2.

The read-only memory shall be transmitted to the RSE within the VST (as
defined in 9.5). The VST is returned by the OBE in response to a BST
received from the RSE. The read-only memory may also be accessed using
other memory access commands listed in Section 6.

This region of memory is "read only" from the roadside.

5.1.6 Read/write memory

Compliant transponders may provide zero, one, or two read/write memory
regions. The availability of these memory regions shall be as indicated
in the read-only memory as defined in 5.2.

When present, the read/write memory regions shall have the following
characteristics:

-   The short read/write memory region shall provide 16 bytes (128 bits)
    of storage.

-   The long read/write memory region shall provide 32 bytes (256 bits)
    of storage.

The read/write memory images may be transmitted to the RSE within the
VST command response, as defined in Section 6. The read/write memory
regions may also be accessed using other memory access com­mands listed
in Section 6.

5.1.7 Extended read/write memory

Compliant transponders may provide one or more extended read/write
memory regions. The availability of these memory regions shall be as
indicated in the read-only memory, as defined in 5.2. The extended
mem­ory may be configured into logical pages by the manufacturer and/or
by issuance of the Reserve Memory Page command, as defined in 6.4.9. The
size of a dynamically created page is specified as an operand of the
Reservation command. Associated with each page is a 16-bit page number.
Permanent page numbers shall be reserved for specific purposes or
agencies by registering the number. Table E.2 of IEEE 1455-99 provides a
list of pre- assigned page numbers and their associated use. These pages
may, optionally, have access credentials to protect the page for write
or read/write access.

The list of reserved pages for a given transponder may be requested by
issuing the Query Memory Configu­ration command, as defined in 6.4.11.

5.1.7.1 Transfer Page

This specification defines a new type of Extended Read/Write memory page
called a Transfer Page. A Transfer Page is intended to support the
transfer of data files between the RSE and an on-vehicle data system or
Onboard Computer (OBC) connected to the OBE. On-vehicle data systems
shall use the Transfer Page for data transfers to or from the roadside.
The interface between the OBE and the OBC may be chosen at the vendor's
discretion.

**Definition**: A Transfer Page is a scratchpad in the OBE memory. It
can be written to and read from by both the DSRC interface and the OBC
interface. Data written to a Transfer Page by one interface shall be
transferred out via the other interface. Transfer Pages are registered
as normal memory pages and accessed by the RSE by normal Read Memory
Page and Write Memory Page commands. The OBE shall contain a list of
page numbers that will be treated as Transfer Pages. The list may be
fixed within OBE memory during manufacture or may be field programmable
at the discretion of the vendor. The interface to the OBC must be
implemented with a "handshake" protocol, assuring that data flow to and
from the OBC is under control of the OBE and data transfers are reliably
received in either direction. A Transfer Page conforms to the size
constraints for Extended Read/Write Memory and is not protected by
access credentials.

**Operation**: Files are broken down by the sending application into
blocks appropriate to the defined size of the Transfer Page. Each block
transfer is handled as a separate IEEE 1455 Read Memory Page or Write
Memory Page command. Each block will include a Transfer Page Header. The
Transfer Page Header is derived from the IEEE 1455-99 ITS Application/
Utility Messages.

> **Downlink** **Flow Summary**
>
> \- The BOA breaks the file into transfer page sized blocks.

\- The BOA requests a page write to the OBE Transfer Page and passes the
first block to the Resource Manager.

> \- The RM performs a page write operation to the Transfer Page using
> the IEEE 1455 Write Memory Page command.
>
> \- Upon receiving data in the Transfer Page, the OBE initiates
> transfer to the OBC. The IEEE 1455 Command Response is not returned to
> the RSE until the complete contents of the block have been written to
> the OBC and the required handshake has been fulfilled.
>
> \- Upon receiving confirmation that the first block has been
> successfully written to the OBE (and therefore to the OBC) the BOA
> requests another page write to the Transfer Page and passes the next
> block of the file. This process continues until the entire file is
> transferred.
>
> **Uplink Flow Summary**
>
> \- The BOA requests a page write to the Transfer Page. The data
> contained on the page consists of OBC application commands requesting
> the uplink of the desired data files. As a result of these commands,
> the OBC writes a page-sized block of the requested data to the
> Transfer Page.
>
> \- The BOA requests a page read from the Transfer Page. The Resource
> Manager holds this request until a "command successful" indication is
> received from the previous RSE page write (indicating that the request
> has been written to the OBC) and then commands a page read of the
> Transfer Page.

When the BOA receives the page from the Resource Manager, it requests
another read of the Transfer Page. This process continues until the
entire file is transferred.

**Transfer Page Header**: The Transfer Page Header combines the function
of the IEEE 1455 ITS Application Message Header and the "RSE to Other
OBE" and "Other OBE to RSE" utility messages. Table 5.1.7.1-1 provides
the layout of the header. Table 5.1.7.1-2 specifies the fields and
values.

Table 5.1.7.1-1 Header Layout

  -------------- -------------- -------------- -------------- --------------
  **Message      **OBE          Message Length **Error Detect **Message
  Identifier**   Address**                     Code**         Body**

  Bits 0 .. 7    Bits 8 .. 39   Bits 40 .. 55  Bits 56 .. 63  Remainder of
                                                              page
  -------------- -------------- -------------- -------------- --------------

Table 5.1.7.1-2 Header Fields and Values

+-----+-----------------+-----------+----------+-----------------------+
| #   | **Field Name**  | **Type**  | **       | **Values**            |
|  Fi |                 |           | Length** |                       |
| eld |                 |           |          |                       |
+-----+-----------------+-----------+----------+-----------------------+
| 1   | Message         | Integer   | 8 bits   | hex 01, other values  |
|     | Identifer       |           |          | are reserved for      |
|     |                 |           |          | future use            |
+-----+-----------------+-----------+----------+-----------------------+
| 2   | OBE Address     | Bit       | 32 bits  | Vehicle bus address,  |
|     |                 | String    |          | vehicle device, or    |
|     |                 |           |          | vehicle application   |
+-----+-----------------+-----------+----------+-----------------------+
| 3   | Message Length  | Integer   | 16 bits  | (0..65535); Length of |
|     |                 |           |          | Message Body minus    |
|     |                 |           |          | one, in bytes, does   |
|     |                 |           |          | not include the       |
|     |                 |           |          | header                |
+-----+-----------------+-----------+----------+-----------------------+
| 4   | Error Detect    | Bit       | 8 bits   | XOR Checksum of the   |
|     | Code            | String    |          | Message Body          |
+-----+-----------------+-----------+----------+-----------------------+
| 5   | Message Body    | Octet     | 1 to     | binary data           |
|     |                 | String    | 65636    |                       |
|     |                 |           | bytes    |                       |
+-----+-----------------+-----------+----------+-----------------------+

8.  Lamps

Compliant transponders may provide a red, a green, and a yellow lamp; it
is not necessary for all lamps to be present. The availability of these
lamps shall be as indicated in the read-only memory, as defined in 5.2.
Lamps are controlled using the Set User Interface command specified in
6.4.6.

5.1.9 Enunciators

Compliant transponders may provide one or more enunciators. The
availability of these enunciators shall be as indicated in the read-only
memory, as defined in 5.2. Enunciators are controlled using the Set User
Inter­face command specified in 6.4.6.

Character readout

Compliant transponders may provide a digital readout. The availability
of a digital readout shall be as indi­cated in the read-only memory, as
defined in 5.2. The digital readout is controlled using the Set User
Inter­face command specified in 6.4.6 and the Map User Interface command
specified in 6.4.7.

The digital readout shall display Text String messages (defined in
8.7.1) that are stored in the memory page to which the digital readout
is mapped. Controls may be provided that enable the user to scroll from
one message to another within the mapped memory page.

5.1.11 Keypad

Compliant transponders may provide a keypad. The availability of a
keypad shall be as indicated in the read- only memory, as defined in
5.2.

The data that are entered using the keypad shall be stored as a Text
String message in the memory page to which the keypad is mapped. The
memory-related commands specified in Section 6 shall be used to retrieve
data entered at the keypad and to clear previously entered data.

5.1.12 Future resources

Future revisions of this specification may provide for additional UI
resources. The availability of these resources is defined in 5.2; they
shall be controlled using the Set User Interface command specified in
6.4.6 and the Map User Interface command specified in 6.4.7.

5.2 Read-only memory definition

Information within the read-only memory region shall be formatted as
defined in Table 5.2-1 and described in 5.2.1 through 5.2.18.

Table 5.2-1 Read-only memory fields

  --------------- ------------ ----------- -------------------------------
  Field name      Location     Length      Specification and description
                  (bits)       (bits)      

  T-APDU Tag      0-3          4           ASN.1 tag for an
                                           INITIALISATION.response (i.e.,
                                           a VST) = hex( 9 )

  Fill            4-7          4           Nonfunctional bits used to
                                           maintain byte boundaries

  Profile         8-15         8           Profile field of VST

  Number of\      16-23        8           Number of applications in the
  Applications                             applications list = hex( 1 )

  Application     24-31        8           Mailbox AID = hex( D )
  Identifier                               
  (AID)                                    

  EID/Revision    32-39        8           EID; shall be used for the IEEE
  Level                                    Std 1455-1999 revision level

  Container Tag   40-47        8           Octet string tag = hex( 4 );
                                           used to encapsulate the VST
                                           parameter

  Octet String    48-55        8           The actual length (in octets)
  Length                                   of the subsequent data in the
                                           octet string

  Octet String                 Includes    An octet string used for ASN.1
  Data                         following   compliance, which comprises the
                               fields      subsequent fields defined in
                                           this table

  Returned Pages  56-57        2           Bits that correspond to the two
  Flag                                     memory images returned, as
                                           specified in the BST

  Reserved 1      58-60        3           Reserved by IEEE for future use

  Memory          61-63        3           Defines the availability of
  Configuration                            various memory regions

  Transponder     64-71        8           Defines the availability of
  Configuration                            various transponder
                                           peripherals, such as lamps and
                                           enunciators

  Service Agency  72-87        16          Identifies the unique agency
                                           that is primarily responsible
                                           for issuing statements
                                           corresponding to services
                                           received by the transponder's
                                           user

  Serial Number   88-91        4           Indicates how the serial number
  Type                                     and manufac turer identifier
                                           should be interpreted

  Manufacturer    92-107       16          Identifies the manufacturer of
  Identifier                               the transponder

  Serial Number   108-127      20          Uniquely identifies the
                                           transponders produced under a
                                           single Manufacturer Identifier
                                           value
  --------------- ------------ ----------- -------------------------------

5.2.1 T-APDU Tag

The T-APDU Tag field is required to provide ASN.1 compliance (see the
ASN.1 definition of T-APDUs in Annex Aof IEEE 1455-99). This field shall
be set to hex( 9 ) to indicate an INITIALISATION.response.

5.2.2 Fill

The Fill field is required to maintain byte boundaries. This field shall
be set to hex( 0 ).

5.2.3 Profile

The Profile field contains communications profiles as defined by the
specific lower layer service. The values for this field are defined in
Table E.3 of IEEE 1455-99, and a sample is shown in Table 5.2.3-1.

Table 5.2.3-1 Sample profile field values

  ---------------------------------- ------------------------------------
  Value                              Definition

  hex( 0 )                           Reserved

  hex( 1 )                           Unspecified profile

  hex( 0 .. FF )                     Available for registration
  ---------------------------------- ------------------------------------

5.2.4 Number of Applications

This field contains the number of applications in the subsequent
application list. The value for this field shall always be set to hex( 1
).

5.2.5 AID

The AID field is required to provide compatibility with the CEN VST
definition. This field shall be set to hex( D ), which is the AID for
the Mailbox application.

5.2.6 EID/Revision Level

The EID field is required to provide compatibility with the CEN VST
definition. Within this specification, the EID/Revision Level field
indicates the revision level of this specification with which the
transponder complies. Values shall be interpreted as defined in Table
5.2.6-1. 

Table 5.2.6-1 EID/Revision Level field values

  ------------------------------ ----------------------------------------
  Value                          Interpretation

  hex( 0 )                       Reserved

  hex( 1 )                       Prerelease (field testing; current
                                 value)

  hex( 2 )                       Initial release

  hex( 3 .. FF )                 Reserved
  ------------------------------ ----------------------------------------

5.2.7 Container Tag

The Container Tag field is required to provide ASN.1 compliance. This
field shall be set to hex( 4 ), which indicates an octet string.

5.2.8 Octet String Length

The Octet String Length field, which is required to provide ASN.1
compliance, indicates the length of the subsequent octet string data.
The low order bit of octet string length must always be set to zero for
ASN.1 compliance (meaning that this octet is used for actual length
designation). The remaining 7 bits of the Octet String Length field
contain the actual length (in octets) of the subsequent data in the
octet string. Therefore, the maximum length for the data is 127 bytes.

The Octet String Length field shall be overwritten dynamically by the
OBE transponder application during VST transmission. It is overwritten
with a value that represents the sum of the size of the memory images
being returned in the VST, which includes the read-only memory.

5.2.9 Octet String Data

The Octet String Data field is descriptive only and has no actual bit
representation in and of itself. The pur­pose of this descriptive field
is to indicate that the octet string data that follow the Octet String
Length field include the subsequent fields defined for read-only memory
and represent the balance of the VST structure.

5.2.10 Returned Pages Flag

The Returned Pages Flag field indicates which memory pages requested in
the BST are present in the tran­sponder and, therefore, which memory
pages are being returned as part of the VST. This field shall be
inter­preted as defined in Table 5.2.10-1.

Table 5.2.10-1 Returned Pages field interpretation

  --------------------------- -------------------------------------------
  Location (bits)             Interpretation

  0                           First page flag; a value of 1 indicates
                              that the first page is returned within the
                              VST

  1                           Second page flag; a value of 1 indicates
                              that the second page is returned within the
                              VST
  --------------------------- -------------------------------------------

5.2.11 Reserved 1

The Reserved 1 field is required to maintain byte boundaries. This field
shall be set to hex( 0 ).

12. Memory Configuration

The Memory Configuration field indicates which read/write memory regions
are present. Values shall be interpreted as defined in Table 5.2.12-1.

Table 5.2.12-1 Read/write Memory Configuration field values

  --------------------- -------------------------------------------------
  Value                 Interpretation

  hex( 0 )              No read/write memory present

  hex( 1 )              Short read/write memory present

  hex( 2 )              Long read/write memory present

  hex( 3 )              Short read/write and long read/write memory
                        present

  hex( 4 )              Extended memory present

  hex( 5 )              Short read/write and extended memory present

  hex( 6 )              Long read/write and extended memory present

  hex( 7 )              Short read/write, long read/write, and extended
                        memory present
  --------------------- -------------------------------------------------

5.2.13 Transponder Configuration

The Transponder Configuration field indicates the configuration of
installed transponder peripherals. The method of interpreting the field
values is dependent upon the status of Bit 7. If Bit 7 is 1, then the
remaining seven bits shall be individually interpreted to determine the
peripherals configuration as defined in Table 8. If Bit 7 is 0, then the
remaining seven bits shall be interpreted as an enumerated value using
Table E.4 of IEEE 1455-99 (sam­ple shown in Table 5.2.13-1).

Table 5.2.13-1a Transponder Configuration field interpretation, Bit 7
Set to 1

  -------------------- --------------------------------------------------
  Location (bits)      Interpretation

  7 (msb)              Always 1 when field is interpreted as binary flags
                       rather than an enumerated value; if 0, then Table
                       9 applies

  6                    Red, yellow, and green lamps all present

  5                    Enunciator present

  4                    External network interface present

  3                    Character readout present

  2                    Keypad present

  1                    Reserved

  0 (lsb)              Reserved
  -------------------- --------------------------------------------------

  

Table 5.2.13-1a Transponder Configuration enumerated field values, Bit 7
Set to 0

  --------------------------- -------------------------------------------
  Value                       Interpretation

  hex( 0 )                    Reserved

  hex( 1 .. 7 )               Available for registration. Specific values
                              are defined in Table E.4.
  --------------------------- -------------------------------------------

5.2.14 Service Agency

The Service Agency field indicates the service agency that is
responsible for collecting fees incurred by the person using this
transponder. Values shall be interpreted as defined in Table E.5 of IEEE
1455-99.

5.2.15 Serial Number Type

The Serial Number Type field indicates the nature of the Manufacturer
Identifier and the Serial Number fields when they are transmitted to the
RSE. Those fields may be protected by encryption or masking, as
indicated by the Serial Number Type field. The Serial Number Type field
shall not be encrypted or masked. Values shall be interpreted as defined
in Table 5.2.15-1.

Table 5.2.1-1 Serial Number Type field values

  ------------------------ ----------------------------------------------
  Value                    Interpretation

  hex( 0 )                 Reserved

  hex( 1 )                 Clear; Manufacturer Identifier and Serial
                           Number fields are not altered

  hex( 2 )                 Encrypted; Manufacturer Identifier and Serial
                           Num­ber fields are encrypted

  hex( 3 )                 Masked; Manufacturer Identifier and Serial
                           Number fields are masked

  hex( 4 .. F )            Reserved
  ------------------------ ----------------------------------------------

5.2.16 Manufacturer Identifier

The Manufacturer Identifier field indicates the manufacturer that
produced the transponder. Values shall be interpreted as defined in
Table E.6 of IEEE 1455-99. The Manufacturer Identifier field may be
masked or encrypted when transmitted to the RSE.

5.2.17 Serial Number

The Serial Number field shall uniquely identify a transponder within a
set of devices having the same Man­ufacturer Identifier field value. The
method of assigning values to this field shall be entirely controlled by
the manufacturer. However, uniqueness shall be preserved. The Serial
Number field may be masked or encrypted when transmitted to the RSE.

5.2.18 Unique identifier

The 40-bit sequence of data consisting of the Serial Number Type,
Manufacturer Identifier, and Serial Num­ber fields may be referred to as
the transponder's unique identifier. The characteristics of the
constituent fields shall be preserved as defined in 5.2.15 through
5.2.17.

5.3 Interoperability requirements

Compliant transponders meet all the requirements specified in this
specification. Interoperable transponders additionally provide optional
features. The following features defined in this subsection shall be
provided in interoperable transponders:

-   Read-only memory (128 bits), which shall not be protected by access
    credentials.

-   Short read/write memory (128 bits), which shall not be protected by
    access credentials.

-   Long read/write memory (256 bits), which shall not be protected by
    access credentials.

-   Extended read/write memory (at least 512 bits).

-   Red, yellow, and green lamps.

-   An enunciator.

Interoperable transponders may also provide additional optional features
such as using access credential protection.

Additional interoperability requirements are specified in 6.6.

**6. Transponder Commands and Memory Access**

6.1 Basic concepts

Transponders that are compliant with this specification shall provide
the capability to process the commands specified in this section (which
is taken directly from Clause 6 of IEEE 1455-99). These commands
reference the memory, processing, and UI resources that may be present
on the transponder. The commands are independent of the BOA that may be
utilizing those resources. The availability of the resources that may be
referenced by commands is indicated by bits allocated in read-only
memory that are defined in 5.2 and by the results of the Query Memory
Configuration command.

The RSE shall not intentionally generate commands to the transponder
that reference resources known to be absent from the addressed
transponder. However, each of the commands defined in this section
specifies the behavior that shall be exhibited when such absent
resources are referenced.

The OBE is not in all cases required to provide the full set of
behaviors specified for each of the commands specified in this section.
For each command, abnormal behaviors are specified that include the
method (if any) by which the OBE shall notify the RSE if a received
command is optional and has not been fully imple­mented in the receiving
OBE.

Some of the commands defined in this section, such as Read Memory Page
and Write Memory Page, require transmission of an entire memory page
image. The End Of Data message may be used to terminate the region of a
memory page that contains valid messages. When an End Of Data message is
present, the RSE and OBE may transmit only that initial portion of a
memory page that contains valid mes­sages. If this optional feature is
not implemented, then the area of a memory image that does not contain
valid messages shall be transmitted and shall be set to zeroes.

6.2 Command set template

Each command shall consist of the fields shown in Table 6.2-1 and
described in 6.2.1 through 6.2.6.

Table 6.2-1 Command set fields

  ------------ ------------- ----------- ----------- ----------- ------------
  Command      Command       Command     Access      Access      Command
  Identifier   Transaction   Length      Control     Control     Parameters
               Identifier                Length                  

  1 byte       1 byte        2 bytes     1 byte      1 to 32     Variable
                                                     bytes       
  ------------ ------------- ----------- ----------- ----------- ------------

6.2.1 Command Identifier

6.2.1.1 Length

The length of the Command Identifier field shall be 1 byte.

6.2.1.2 Usage

The Command Identifier field shall identify the command to be performed
and shall take on the values shown in Table 6.2.1.2-1. The high order
bit (bit 7) of this field indicates the presence or absence of access
creden­tials in the command. If bit 7 is 1, then the Access Control
Length and Access Control fields shall be present after the Command
Length field. If bit 7 is 0, then the Access Control Length and Access
Control fields shall be omitted and the Command Length field shall be
followed by the Command Parameter field.

Table 6.2.1.2-1 Command Identifiers (continued)

  ------------ ----------------- ----------------------- ----------------------
  Codes        Codes with        Meaning                 OBE command support
               credentials                               

  hex( 0 .. F  hex( 80 .. 8F )   Reserved                
  )                                                      

  hex( 10 )    hex( 90 )         Read Memory Page        Required to access
                                                         memory other than
                                                         through memory images
                                                         returned in the VST

  hex( 11 )    hex( 91 )         Write Memory Page       Optional[^1]\
                                                         (required if
                                                         read/write memory is
                                                         present)

  hex( 12 )    hex( 92 )         Append Message          Optional^\*^\
                                                         (required if
                                                         read/write memory is
                                                         present)

  hex( 13 )    hex( 93 )         Initialize Circular     Optional\
                                 Queue                   (required for circular
                                                         queues)

  hex( 14 )    hex( 94 )         Write Circular Queue    Optional^\*\
                                                         ^(required for
                                                         circular queues)

  hex( 15 ) .. hex( 95 ) .. ( 9F Reserved                
  ( 1F )       )                                         

  hex( 20 )    hex( A0 )         Set User Interface      Optional^\*\
                                                         ^(required if OBE has
                                                         UI)

  hex( 21 )    hex( A1 )         Map User Interface      Optional

  hex( 22 ..   hex( A2 .. AF )   Reserved                
  2F )                                                   

  hex( 30 )    hex( B0 )         Sleep Transponder       Optional

  hex( 31.. 3F hex( B1.. BF )    Reserved                
  )                                                      

  hex( 40 )    hex( C0 )         Reserve Memory Page     Optional\
                                                         (required if extended
                                                         memory is present)

  hex( 41 )    hex( C1 )         Release Memory Page     Optional\
                                                         (required if Reserve
                                                         Memory Page command is
                                                         implemented)

  hex( 42 )    hex( C2 )         Query Memory            Optional\
                                 Configura­tion           (required if Reserve
                                                         Memory Page command is
                                                         implemented)

  hex( 43 )    hex( C3 )         Reserve Memory          Optional
                                 Partition               

  hex( 44 )    hex( C4 )         Release Memory          Optional\
                                 Partition               (required if Reserve
                                                         Memory Par­tition
                                                         command is
                                                         implemented)

  hex( 45 ..   hex( C5 .. EF )   Reserved                
  6F )                                                   

  hex( 70 ..   hex( F0 .. FF )   Available for           Optional---shall not
  7F )                           manufacturer-specific   be used in production
                                 test­ing                 units deployed in the
                                                         field
  ------------ ----------------- ----------------------- ----------------------

6.2.2 Command Transaction Identifier

6.2.2.1 Length

The length of the Command Transaction Identifier field shall be 1 byte.

6.2.2.2 Usage

The Command Transaction Identifier field shall be an identifier that is
uniquely calculated for each instance of a command. This identifier is
returned in the command response and allows the resource manager to
match a received response to a specific sent command.

6.2.3 Command Length

6.2.3.1 Length

The length of the Command Length field shall be 2 bytes.

6.2.3.2 Usage

The Command Length field shall specify the total length in bytes of the
command instance, including all fields except the Command Identifier
field, the Command Transaction Identifier field, and this Command Length
field. The maximum value of this field effectively constrains the
maximum size of a transferred memory image.

6.2.4 Access Control Length

6.2.4.1 Length

The length of the Access Control Length field shall be 1 byte.

6.2.4.2 Usage

The Access Control Length field shall specify the length of the Access
Control field in bytes. This field, if present, will never be zero.

6.2.5 Access Control

6.2.5.1 Length

The length of the Access Control field shall vary up to 32 bytes, as
specified by the Access Control Length field.

6.2.5.2 Usage

The Access Control field shall be used to provide access controls for
command instances. The actual value of the Access Control field is
implementation-specific and would typically follow some type of
encryption and/or authentication scheme.

6.2.6 Command Parameters

6.2.6.1 Length

The length of the Command Parameters field shall be fixed for each
command except for the Write Memory, Append Message, Write Circular
Queue, and Set User Interface commands, which have variable parameter
lengths.

6.2.6.2 Usage

The Command Parameters field shall be specific to each command set.

3.  Command information flow

This specification provides for two communication modes. In the
"connected" mode, all communications are prefaced by a BST/VST exchange
that connects the RSE to a specific transponder. In the "broadcast"
mode, transponder commands are broadcast from the RSE to all passing
transponders without first establishing an RSE-to-OBE connection using a
BST/VST. Transponders shall remain ready to receive a communication at
all times, subject to vendor-specific power consumption optimization.

The connected mode is recommended because it allows the RSE to verify
the transponder configuration before additional commands are transmitted
to the transponder. However, the broadcast mode may be appro­priate in
certain applications where the communication opportunity is constrained.

Section 9 discusses all application layer services in detail. Annex C
provides illustrations for the flow of commands from the resource
manager to the OBE transponder application via the application layer.

6.3.1 Connected mode information flow

In the connected mode, the following RSE-to-OBE information flow shall
be observed:

a.  The resource manager shall register itself as part of its startup
    sequence by using the RegisterAppli­cationBeacon service in the
    application layer. This registration causes the RSE application
    layer to construct a BST and initiate communication with potential
    OBE transponders.

```{=html}
<!-- -->
```
b.  The connection is established when the OBE application layer returns
    a VST to the resource manager.

c.  The resource manager shall determine appropriate commands, based
    upon registration requests from the connected BOAs.

d.  The resource manager shall formulate the command instance using
    supplied information.

e.  The resource manager shall use the ACTION.request service in the
    application layer to transmit the command to the OBE. The OBE shall
    provide a response if required by the Mode field in the
    Action.request.

f.  The OBE shall process the command received from the resource manager
    as an ACTION.indication service and shall respond, if required,
    using the ACTION.response service of the OBE application layer.

g.  The resource manager shall process the received ACTION.confirm,
    potentially resending the com­mand with appropriate access controls.

6.3.2 Broadcast mode information flow

The broadcast mode is used to transmit a command or a fixed set of
commands to every transponder that passes through the RSE communication
zone. In the broadcast mode, the following RSE-to-OBE informa­tion flow
shall be observed:

a.  The resource manager may use the BroadcastData.request service of
    the RSE application layer to broadcast to the OBE.

```{=html}
<!-- -->
```
b.  In that case, the OBE transponder application shall use the
    GetBroadcastData.request service of the OBE application layer to
    access a command or command set that was broadcast from the resource
    manager.

c.  The resource manager may also use the ACTION.request service of the
    RSE application layer to broadcast a command or command set in a
    broadcast mode. This may be accomplished by setting the LID field of
    the ACTION.request to a global LID; in this case a response from the
    OBE may also be requested by setting the Mode field of the
    ACTION.request.

d.  This ACTION.request will fail if the lower layer service associated
    with the application layer does not support the optional
    DATASEND_RESPOND_REPEAT or DATASEND_NORESPOND\_ REPEAT messages
    defined in 9.3.2. In this case, the RSE application layer may choose
    to repeat the command.

Also, subject to the capabilities of the lower layer media, the RSE must
provide for the case that mul­tiple transponders are within the
communications zone at the time of transmission. The OBE tran­sponder
application shall use the ACTION.response service of the OBE application
layer to send command responses back to the resource manager in response
to a command received as a result of the resource manager sending that
command using a broadcast ACTION.request.

6.4 Command definitions

The commands shall be created by the RSE and processed by the OBE as
specified in 6.4.1 through 6.4.13. The command identifier values are
shown with the Access Credential flag set to 0. The Command Parameter
field locations are shown as if the Access Control Length and Access
Control fields were not present. Details regarding command responses are
provided in 6.5.

6.4.1 Read Memory Page (mandatory)

The Read Memory Page command shall initiate transmission of the
specified OBE memory pages to the RSE.

1.  Command set definition

The Read Memory Page command shall consist of the fields shown in Table
6.4.1.1-1.

Table 6.4.1.1-1 Read Memory Page command fields

+-----------------+-------------+------------+-------------------------+
| Field name      | Location    | Length     | Specification and       |
|                 | (bytes)     |            | description             |
+-----------------+-------------+------------+-------------------------+
| Command         | 0           | 1          | hex( 10 ) / hex( 90 )   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command         | 1           | 1          | Identifies an instance  |
| Transaction     |             |            | of a command            |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command Length  | 2 .. 3      | 2          | Defines the total       |
|                 |             |            | length (bytes) of all   |
|                 |             |            | fields in this command  |
|                 |             |            | excluding the length of |
|                 |             |            | the Command Identifier  |
|                 |             |            | field, Command          |
|                 |             |            | Transaction Identifier  |
|                 |             |            | field, and this Command |
|                 |             |            | Length field            |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 4           | 0/1        | (Optional.) Number of   |
| Length          |             |            | access creden­tial       |
|                 |             |            | bytes. A nonzero value  |
|                 |             |            | indicates that the Page |
|                 |             |            | Identifier field will   |
|                 |             |            | be off­set by the        |
|                 |             |            | indicated number of     |
|                 |             |            | bytes (max. 32)         |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 5 .. n      | 0/1 .. 32  | (Optional.) Access      |
|                 |             |            | credentials             |
+-----------------+-------------+------------+-------------------------+
| Command         | End of      | 2          | Identifies referenced   |
| Parameter:      | Access\     |            | memory page (as per     |
|                 | Control     |            | specification in Table  |
| Page Identifier | field + 1   |            | E.2)                    |
|                 |             |            |                         |
|                 | End of      |            |                         |
|                 | Access\     |            |                         |
|                 | Control     |            |                         |
|                 | field + 2   |            |                         |
+-----------------+-------------+------------+-------------------------+

6.4.1.2 OBE normal behaviors

The OBE shall access the memory page specified by the Read Memory Page
command.

If the OBE successfully executes the Read Memory Page command, the OBE
shall send a response with the Response Identifier field set to Command
Success, the Response Data Length field set to the length of the read
memory image, and the memory image itself in the Response Data field.

6.4.1.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions. See Table 6.5.3.4-1
for definitions.

Command Not Recognized

Access Control Error

Page Not Defined

Memory Access Error

Command Failed

6.4.2 Write Memory Page (optional)

The Write Memory Page command is suffixed by a memory image that shall
be stored in the specified OBE memory page.

6.4.2.1 Command set definition

The Write Memory Page command shall consist of the fields shown in Table
6.4.2.1-1.

Table 6.4.2.1-1 Write Memory Page command fields (continued)

+-----------------+-------------+------------+-------------------------+
| Field name      | Location    | Length     | Specification and       |
|                 | (bytes)     |            | description             |
+-----------------+-------------+------------+-------------------------+
| Command         | 0           | 1          | hex( 11 ) / hex( 91 )   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command         | 1           | 1          | Uniquely identifies an  |
| Transaction     |             |            | instance of a command   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command Length  | 2 .. 3      | 2          | Defines the total       |
|                 |             |            | length (bytes) of all   |
|                 |             |            | fields in this command  |
|                 |             |            | excluding the length of |
|                 |             |            | the Command Identifier  |
|                 |             |            | field, Command          |
|                 |             |            | Transaction Identifier  |
|                 |             |            | field, and this Command |
|                 |             |            | Length field            |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 4           | 0/1        | (Optional.) Number of   |
| Length          |             |            | access creden­tial bytes |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 5 .. n      | 0/1 .. 32  | (Optional.) Access      |
|                 |             |            | credentials             |
+-----------------+-------------+------------+-------------------------+
| Command         | End of      | 2          | Identifies referenced   |
| Parameter:      | Access\     |            | memory page (as per     |
|                 | Control     |            | specification in Table  |
| Page Identifier | field + 1   |            | E.2)                    |
|                 |             |            |                         |
|                 | End of      |            |                         |
|                 | Access      |            |                         |
|                 | Control     |            |                         |
|                 | field + 2   |            |                         |
+-----------------+-------------+------------+-------------------------+
| Memory Image    | End of      |            | The information that    |
|                 | Access\     |            | shall consist of        |
|                 | Control     |            | sequenced messages      |
|                 | field + 3   |            | followed by zero- fill  |
|                 | .. n        |            | bytes or an End Of Data |
|                 |             |            | message identifier. The |
|                 |             |            | length of this image is |
|                 |             |            | only constrained by the |
|                 |             |            | maximum com­mand length  |
|                 |             |            | defined in 6.2.3.       |
+-----------------+-------------+------------+-------------------------+

6.4.2.2 OBE normal behaviors

The OBE shall store the memory image within the received command by
completely overwriting the refer­enced agency memory page.

If the OBE successfully executes the Write Memory Page command, the OBE
shall send a response with the Response Identifier field set to Command
Success. The response shall contain no data in the Response Data field.

6.4.2.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

-   Command Not Recognized

-   Access Control Error

-   Page Not Defined

-   Page Length Mismatch

-   Memory Access Error

-   Command Failed

6.4.3 Append Message (optional)

The Append Message command is suffixed by a message image that shall be
appended to the end of the pre­viously used memory within the specified
OBE memory page.

6.4.3.1 Command set definition

The Append Message command shall consist of the fields shown in Table
6.4.3.1-1.

Table 6.4.3.1-1 Append Message command fields

+-----------------+-------------+------------+-------------------------+
| Field name      | Location    | Length     | Specification and       |
|                 | (bytes)     |            | description             |
+-----------------+-------------+------------+-------------------------+
| Command         | 0           | 1          | hex( 12 ) / hex( 92 )   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command         | 1           | 1          | Uniquely identifies an  |
| Transaction     |             |            | instance of a command   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command Length  | 2 .. 3      | 2          | Defines the total       |
|                 |             |            | length (bytes) of all   |
|                 |             |            | fields in this command  |
|                 |             |            | excluding the length of |
|                 |             |            | the Command Identifier  |
|                 |             |            | field, Command          |
|                 |             |            | Transaction Identifier  |
|                 |             |            | field, and this Command |
|                 |             |            | Length field            |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 4           | 0/1        | (Optional). Number of   |
| Length          |             |            | access creden­tial bytes |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 5 .. n      | 0/1 .. 32  | (Optional). Access      |
|                 |             |            | credentials             |
+-----------------+-------------+------------+-------------------------+
| Command         | End of      | 2          | Identifies referenced   |
| Parameter:      | Access\     |            | memory page (as per     |
|                 | Control     |            | specification in Table  |
| Page Identifier | field + 1   |            | E.2)                    |
|                 |             |            |                         |
|                 | End of      |            |                         |
|                 | Access\     |            |                         |
|                 | Control     |            |                         |
|                 | field + 2   |            |                         |
+-----------------+-------------+------------+-------------------------+
| Message Image   | End of      |            | The information that    |
|                 | Access\     |            | shall be appended to    |
|                 | Control     |            | the specified memory    |
|                 | field + 3   |            | page                    |
|                 | .. n        |            |                         |
+-----------------+-------------+------------+-------------------------+

6.4.3.2 OBE normal behaviors

The OBE shall append the message image within the command to the end of
existing messages in the speci­fied page. Positioning within the page
shall be determined by chaining through the stored messages until the
first occurrence of either an End Of Data message or hex( 00 ) following
a message, where the next message header would begin. The message image
shall be inserted at this point, overwriting the End Of Data message, if
present. The new data shall be suffixed by either an End Of Data message
or by zero filling the remainder of page.

If the OBE successfully executes the Append Message command, the OBE
shall send a response with the Response Identifier field set to Command
Success. The response shall contain no data in the Response Data field.

6.4.3.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

Command Not Recognized

Access Control Error

Page Not Defined

Insufficient Memory

Memory Access Error

Command Failed

4.  Initialize Circular Queue (optional)

The Initialize Circular Queue command shall cause all of the memory
within the specified OBE extended memory page to be cleared to zeros and
shall set any control data to indicate that the queue is empty.

6.4.4.1 Command set definition

The Initialize Circular Queue command shall consist of the fields shown
in Table 6.4.4.1-1.

Table 6.4.4.1-1 Initialize Circular Queue command fields (continued)

+-----------------+-------------+------------+-------------------------+
| Field name      | Location    | Length     | Specification and       |
|                 | (bytes)     | (bytes)    | description             |
+-----------------+-------------+------------+-------------------------+
| Command         | 0           | 1          | hex( 13 ) / hex( 93 )   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command         | 1           | 1          | Uniquely identifies an  |
| Transaction     |             |            | instance of a command   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command Length  | 2 .. 3      | 2          | Defines the total       |
|                 |             |            | length (bytes) of all   |
|                 |             |            | fields in this command  |
|                 |             |            | excluding the length of |
|                 |             |            | the Command Identifier  |
|                 |             |            | field, Command          |
|                 |             |            | Transaction Identifier  |
|                 |             |            | field, and this Command |
|                 |             |            | Length field            |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 4           | 0/1        | (Optional.) Number of   |
| Length          |             |            | access creden­tial bytes |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 5 .. n      | 0/1 .. 32  | (Optional.) Access      |
|                 |             |            | credentials             |
+-----------------+-------------+------------+-------------------------+
| Command         | End of      | 2          | Identifies referenced   |
| Parameter:      | Access      |            | memory page (as per     |
|                 | Control     |            | specification in Table  |
| Page Identifier | field + 1   |            | E.2)                    |
|                 |             |            |                         |
|                 | End of      |            |                         |
|                 | Access      |            |                         |
|                 | Control     |            |                         |
|                 | field + 2   |            |                         |
+-----------------+-------------+------------+-------------------------+

6.4.4.2 OBE normal behaviors

The OBE shall clear the specified page to zeros and shall set any
control data to indicate that the queue is empty.

If the OBE successfully executes the Initialize Circular Queue command,
the OBE shall send a response with the Response Identifier field set to
Command Success. The response shall contain no data in the Response Data
field.

6.4.4.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

Command Not Recognized

Page Not Defined

Access Control Error

Memory Access Error

Command Failed

6.4.5 Write Circular Queue (optional)

The Write Circular Queue command is suffixed by a message image that
shall be written to the end of the circular queue within the specified
OBE memory page.

6.4.5.1 Command set definition

The Write Circular Queue command shall consist of the fields shown in
Table 6.4.5.1-1.

Table 6.4.5.1-1 Write Circular Queue command fields (continued)

+----------------+-------------+------------+-------------------------+
| Field name     | Location    | Length     | Specification and       |
|                | (bytes)     |            | description             |
+----------------+-------------+------------+-------------------------+
| Command        | 0           | 1          | hex( 14 ) / hex( 94 )   |
| Identifier     |             |            |                         |
+----------------+-------------+------------+-------------------------+
| Command        | 1           | 1          | Uniquely identifies an  |
| Transaction    |             |            | instance of a command   |
| Identifier     |             |            |                         |
+----------------+-------------+------------+-------------------------+
| Command Length | 2 .. 3      | 2          | Defines the total       |
|                |             |            | length (bytes) of all   |
|                |             |            | fields in this command  |
|                |             |            | excluding the length of |
|                |             |            | the Command Identifier  |
|                |             |            | field, Command          |
|                |             |            | Transaction Identifier  |
|                |             |            | field, and this Command |
|                |             |            | Length field            |
+----------------+-------------+------------+-------------------------+
| Access Control | 4           | 0/1        | (Optional.) Number of   |
| Length         |             |            | access creden­tial bytes |
+----------------+-------------+------------+-------------------------+
| Access Control | 5 .. n      | 0/1 .. 32  | (Optional.) Access      |
|                |             |            | credentials             |
+----------------+-------------+------------+-------------------------+
| Command        | End of      | 2          | Identifies referenced   |
| Parameter:     | Access\     |            | memory page (as per     |
|                | Control     |            | specification in Table  |
| Page           | field + 1   |            | E.2)                    |
| Identifier     |             |            |                         |
|                | End of      |            |                         |
|                | Access\     |            |                         |
|                | Control     |            |                         |
|                | field + 2   |            |                         |
+----------------+-------------+------------+-------------------------+
| Message Image  | End of      |            | The information that    |
|                | Access\     |            | shall be written to the |
|                | Control     |            | end of the circular     |
|                | field 3 ..  |            | queue in the specified  |
|                | n           |            | memory page             |
+----------------+-------------+------------+-------------------------+

6.4.5.2 OBE normal behaviors

The OBE shall write the message image within the received command by
locating the end of the current cir­cular queue contained in the
referenced memory page, placing the message image at the end of the
queue, and updating any queue control information. Existing messages
shall be deleted on a first-in-first-out (FIFO) basis if required to
create sufficient available memory for the insertion of the message
image. All memory in the page that is not used for message storage shall
be set to zero.

If the OBE successfully executes the Write Circular Queue command, the
OBE shall send a response with the Response Identifier field set to
Command Success. The response shall contain no data in the Response Data
field.

6.4.5.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

-   Command Not Recognized

-   Page Not Defined

-   Access Control Error

-   Insufficient Memory

-   Memory Access Error

-   Command Failed

6.4.6 Set User Interface (optional)

The Set User Interface command is suffixed by data specifying UI
behaviors that shall be implemented by the OBE. The RSE may determine
the UI elements that are available for a transponder by interpreting the
Transponder Configuration field that is stored in the OBE read-only
memory and transmitted to the RSE within the VST. The Transponder
Configuration field is defined in Table 3. The RSE shall not address UI
elements that are absent for a given OBE.

6.4.6.1 Command set definition

The Set User Interface command shall consist of the fields shown in
Table 6.4.6.1-1.

Table 6.4.6.1-1 Set User Interface command fields (continued)

+------------------+------------+-----+------------------------------+
| Field name       | Location   | Len | Specification and            |
|                  | (bytes)    | gth | description                  |
+------------------+------------+-----+------------------------------+
| Command          | 0          | 1   | hex( 20 ) / hex( A0 )        |
| Identifier       |            |     |                              |
+------------------+------------+-----+------------------------------+
| Command          | 1          | 1   | Uniquely identifies an       |
| Transaction      |            |     | instance of a command        |
| Identifier       |            |     |                              |
+------------------+------------+-----+------------------------------+
| Command Length   | 2 .. 3     | 2   | Defines the total length     |
|                  |            |     | (bytes) of all fields in     |
|                  |            |     | this command excluding the   |
|                  |            |     | length of the Command        |
|                  |            |     | Identifier field, Command    |
|                  |            |     | Transaction Identifier       |
|                  |            |     | field, and this Command      |
|                  |            |     | Length field                 |
+------------------+------------+-----+------------------------------+
| Access Control   | 4          | 0/1 | (Optional.) Number of access |
| Length           |            |     | credential bytes             |
+------------------+------------+-----+------------------------------+
| Access Control   | 5 .. n     | 0/1 | (Optional.) Access           |
|                  |            | ..  | credentials                  |
|                  |            | 32  |                              |
+------------------+------------+-----+------------------------------+
| Command          | End of     | 2   | Each command will affect     |
| Parameter:       | Access     |     | only the addressed elements  |
|                  | Control    |     | defined as follows:          |
| User Interface   | field + 1  |     |                              |
| Element          |            |     | Bit 0: Red lamp              |
|                  | End of     |     |                              |
|                  | Access     |     | Bit 1: Yellow lamp           |
|                  | Control    |     |                              |
|                  | field + 2  |     | Bit 2: Green lamp            |
|                  |            |     |                              |
|                  |            |     | Bit 3: Enunciator            |
|                  |            |     |                              |
|                  |            |     | Bit 4: Character display     |
|                  |            |     |                              |
|                  |            |     | Bits 5-15: Additional UI     |
|                  |            |     | elements                     |
+------------------+------------+-----+------------------------------+
| Type             | End of     | 1   | AbsoluteOff (0),             |
|                  | Access\    |     |                              |
| (ObeUICmdType)   | Control    |     | AbsoluteOn (1),              |
|                  | field + 3  |     |                              |
|                  |            |     | TimedCommand (2),            |
|                  |            |     |                              |
|                  |            |     | Flashing Command (3),        |
|                  |            |     |                              |
|                  |            |     | Reserved (4 .. 255)          |
+------------------+------------+-----+------------------------------+
| Attributes:      | End of     | 0   | (Unused for Absolute         |
|                  | Access\    |     | Command)                     |
| Absolute Command | Control    | 2   |                              |
| (0 bytes)        | field + 4  |     | Time period in 125 ms        |
|                  | .. n       | 4   | increments                   |
| Timed Command (2 |            |     |                              |
| bytes)           |            | 1   | Cycle state bitmap, 125 ms   |
|                  |            |     | per bit                      |
| Flashing Command |            |     |                              |
| (5 bytes)        |            |     | Repetition count (1 .. 255)  |
+------------------+------------+-----+------------------------------+

6.4.6.2 OBE normal behaviors

The OBE shall alter the UI element specified within the command
parameter in the following fashion, depending upon the value of the type
parameter:

-   [Absolute Off command]{.underline}. Turns the addressed UI element
    off. State is maintained until changed by a subsequent command.

-   [Absolute On command.]{.underline} Turns the addressed UI element
    on. State is maintained until changed by a subsequent command.

-   [Timed command]{.underline}. Turns the addressed UI element on for a
    specified period of time. The time period is specified in 125 ms
    increments.

-   [Flashing command]{.underline}. Cycles the state of the addressed UI
    element based upon a 4-byte bit map. Each bit in the map represents
    an interval of 125 ms (the total bit map represents 4 s). A
    repetition byte indicates the number of times the bit map cycle
    pattern should be performed (1 to 255 times).

If the OBE successfully executes the Set User Interface command, the OBE
shall send a response with the Response Identifier field set to Command
Success. The response shall contain no data in the Response Data field.

The OBE may arbitrarily turn off any element after a preset period of
time to preserve battery life.

The completion of a UI command shall not be affected by the reception of
any other transmissions from the RSE except for an overriding UI
command.

Table E.2 of IEEE 1455-99 defines a memory page associated with an
enunciator. This is intended to support systems that provide a synthetic
speech interface or other sophisticated auditory cues. The Set User
Interface command shall always be used to initiate changes to the UI,
but the data in the enunciator memory page may be used to control the
specific action.

Also, Table E.2 of IEEE 1455-99 defines a memory page associated with
the character readout. The Set User Interface com­mand shall always be
used to initiate changes to the character display, but the specific
information shown may be retrieved from the character display memory
page.

6.4.6.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

Command Not Recognized

Access Control Error

Device Error

Command Failed

6.4.7 Map User Interface (optional)

The Map User Interface command shall cause the OBE to map a page of
memory to the specified UI compo­nent. This reservation shall include the
establishment of access control procedures. Mapping a page of mem­ory to
a specified UI element affects the behavior of the transponder when a
Set User Interface command is subsequently received by indicating the
information that is enunciated or displayed.

1.  Command set definition

The Map User Interface command shall consist of the fields shown in
Table 6.4.7.1-1.

Table 6.4.7.1-1 Map User Interface command fields (continued)

+-----------------+-----------+-----------+---------------------------+
| Field name      | Location  | Length    | Specification and         |
|                 | (bytes)   |           | description               |
+-----------------+-----------+-----------+---------------------------+
| Command         | 0         | 1         | hex( 21 ) / hex( A1 )     |
| Identifier      |           |           |                           |
+-----------------+-----------+-----------+---------------------------+
| Command         | 1         | 1         | Uniquely identifies an    |
| Transaction     |           |           | instance of a command     |
| Identifier      |           |           |                           |
+-----------------+-----------+-----------+---------------------------+
| Command Length  | 2 .. 3    | 2         | Defines the total length  |
|                 |           |           | (bytes) of all fields in  |
|                 |           |           | this command excluding    |
|                 |           |           | the length of the Command |
|                 |           |           | Identifier field, Command |
|                 |           |           | Transaction Identifier    |
|                 |           |           | field, and this Com­mand   |
|                 |           |           | Length field              |
+-----------------+-----------+-----------+---------------------------+
| Access Control  | 4         | 0/1       | (Optional.) Number of     |
| Length          |           |           | access credentials bytes  |
+-----------------+-----------+-----------+---------------------------+
| Access Control  | 5 .. n    | 0/1 .. 32 | (Optional.) Access        |
|                 |           |           | credentials               |
+-----------------+-----------+-----------+---------------------------+
| Command         | End of    | 1         | Defines the UI element to |
| Parameter:      | Access\   |           | be mapped\                |
|                 | Control   |           | \                         |
| User Interface  | field + 1 |           | 0: Keypad\                |
| Element         |           |           | 1: Character Display\     |
|                 |           |           | 2: Enunciator voice 1\    |
|                 |           |           | 3-255: Reserved for       |
|                 |           |           | additional UI elements    |
+-----------------+-----------+-----------+---------------------------+
| Page Identifier | End of    | 2         | Identifies referenced     |
|                 | Access\   |           | memory page (as per       |
|                 | Control   |           | specification in Table    |
|                 | field + 2 |           | E.2 of IEEE 1455-99)      |
+-----------------+-----------+-----------+---------------------------+

6.4.7.2 OBE normal behaviors

The OBE shall first determine whether the specified page identifier has
already been reserved. If the page identifier exists, then that page
shall be used for all subsequent UI actions that reference the specified
UI ele­ment. The predefined UI page identifiers listed in Table E.2 of
IEEE 1455-99 may always be used to reference the specific pages that
have been currently selected using the Map User Interface command. See
5.1.8 through 5.1.11 for how the data within the UI memory pages shall
be utilized.

If the OBE successfully executes the Map User Interface command, the OBE
shall send a response with the Response Identifier field set to Command
Success. The response shall contain no data in the Response Data field.

6.4.7.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

Command Not Recognized

Access Control Error

Previously Reserved

Device Error

Command Failed

6.4.8 Sleep Transponder (optional)

The Sleep Transponder command shall cause the receiving transponder to
sleep (disable RF reception and transmission) for a period of time
specified in the command instance. (This mechanism for commanding sleep
is required in addition to the Sleep Timeout mechanism in the Frame
Control Message (4.7.1 and 4.8.7).)

6.4.8.1 Command set definition

The Sleep Transponder command shall consist of the fields shown in Table
6.4.8.1-1.

Table 6.4.8.1-1 Sleep Transponder command fields (continued)

+----------------+-------------+----------+--------------------------+
| Field name     | Location    | Length   | Specification and        |
|                | (bytes)     |          | description              |
+----------------+-------------+----------+--------------------------+
| Command        | 0           | 1        | hex( 30 ) / hex( B0 )    |
| Identifier     |             |          |                          |
+----------------+-------------+----------+--------------------------+
| Command        | 1           | 1        | Uniquely identifies an   |
| Transaction    |             |          | instance of a command    |
| Identifier     |             |          |                          |
+----------------+-------------+----------+--------------------------+
| Command Length | 2 .. 3      | 2        | Defines the total length |
|                |             |          | (bytes) of all fields in |
|                |             |          | this command excluding   |
|                |             |          | the length of the        |
|                |             |          | Command Identifier       |
|                |             |          | field, Command           |
|                |             |          | Transaction Identifier   |
|                |             |          | field, and this Com­mand  |
|                |             |          | Length field             |
+----------------+-------------+----------+--------------------------+
| Access Control | 4           | 0/1      | (Optional.) Number of    |
| Length         |             |          | access credential bytes  |
+----------------+-------------+----------+--------------------------+
| Access Control | 5 .. n      | 0/1 ..   | (Optional.) Access       |
|                |             | 32       | credentials              |
+----------------+-------------+----------+--------------------------+
| Command        | End of      | 2        | Sleep time duration in   |
| Parameter:     | Access\     |          | 125 ms increments        |
|                | Control     |          |                          |
| Sleep Duration | field + 1   |          |                          |
|                |             |          |                          |
|                | End of      |          |                          |
|                | Access\     |          |                          |
|                | Control     |          |                          |
|                | field + 2   |          |                          |
+----------------+-------------+----------+--------------------------+

6.4.8.2 OBE normal behaviors

The OBE shall cause the transponder to cease responding to RF signaling
for the specified period.

If the OBE successfully executes the Sleep Transponder command, the OBE
shall send a response with the Response Identifier field set to Command
Success. The response shall contain no data in the Response Data field.
Upon completion, the link shall be considered terminated.

When an RSE wishes an OBE to reinitialize, a sleep duration of 0 will
result in the OBE reinitializing with the next Frame Control Frame that
it receives.

6.4.8.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

Command Not Recognized

Access Control Error

Device Error

Command Failed

6.4.9 Reserve Memory Page (optional)

The Reserve Memory Page command shall cause the OBE to reserve a page of
memory for the specified agency. This reservation shall include the
establishment of access control procedures.

6.4.9.1 Command set definition

The Reserve Memory Page command shall consist of the fields shown in
Table 6.4.9.1-1.

Table 6.4.9.1-1 Reserve Memory Page command fields (continued)

+----------------+------------+--------+------------------------------+
| Field name     | Location   | Length | Specification and            |
|                | (bytes)    |        | description                  |
+----------------+------------+--------+------------------------------+
| Command        | 0          | 1      | hex( 40 ) / hex( C0 )        |
| Identifier     |            |        |                              |
+----------------+------------+--------+------------------------------+
| Command        | 1          | 1      | Uniquely identifies an       |
| Transaction    |            |        | instance of a command        |
| Identifier     |            |        |                              |
+----------------+------------+--------+------------------------------+
| Command Length | 2 .. 3     | 2      | Defines the total length     |
|                |            |        | (bytes) of all fields in     |
|                |            |        | this command excluding the   |
|                |            |        | length of the Command        |
|                |            |        | Identifier field, Command    |
|                |            |        | Transaction Identifier       |
|                |            |        | field, and this Command      |
|                |            |        | Length field                 |
+----------------+------------+--------+------------------------------+
| Access Control | 4          | 0/1    | (Optional.) Number of access |
| Length         |            |        | credential bytes             |
+----------------+------------+--------+------------------------------+
| Access Control | 5 .. n     | 0/1 .. | (Optional.) Access           |
|                |            | 32     | credentials                  |
+----------------+------------+--------+------------------------------+
| Partition      | End of     | 2      | Specifies the partition      |
| Identifier     | Access     |        | identifier in which the      |
|                | Control    |        | memory shall be allocated    |
|                | field + 1  |        | (as per specification in     |
|                |            |        | Table E.1). A value of 0     |
|                | End of     |        | implies that the page shall  |
|                | Access     |        | be allocated within          |
|                | Control    |        | unpartitioned memory.        |
|                | field + 2  |        |                              |
+----------------+------------+--------+------------------------------+
| Command        | End of     | 2      | Length (in bytes) of the     |
| Parameter:     | Access     |        | memory page that is          |
|                | Control    |        | requested                    |
| Page Size      | field + 3  |        |                              |
|                |            |        |                              |
|                | End of     |        |                              |
|                | Access     |        |                              |
|                | Control    |        |                              |
|                | field + 4  |        |                              |
+----------------+------------+--------+------------------------------+
| Page           | End of     | 2      | Specifies the page           |
| Identifier     | Access     |        | identifier that will be      |
|                | Control    |        | associ­ated with the          |
|                | field + 5  |        | allocated memory (as per     |
|                |            |        | specifica­tion in Table E.2)  |
|                | End of     |        |                              |
|                | Access     |        |                              |
|                | Control    |        |                              |
|                | field + 6  |        |                              |
+----------------+------------+--------+------------------------------+
| Page Access    | (End of    | 0/1    | (Optional.)\                 |
| Credential     | Page       |        | Bits 0 .. 1 indicate the     |
| Type and       | Identifier |        | access credential scope:\    |
| Length         | field + 1) |        | \                            |
|                |            |        | Bit 0 = Access Credentials   |
|                |            |        | applied to Read access\      |
|                |            |        | Bit 1 = Access Credentials   |
|                |            |        | applied to Write access\     |
|                |            |        | Bits 2 .. 7 : Number of      |
|                |            |        | access credentials bytes     |
|                |            |        | that shall be applied to     |
|                |            |        | reserved page; max value =   |
|                |            |        | 32                           |
+----------------+------------+--------+------------------------------+
| Page Access    | (End of    | 0/1 .. | (Optional.)                  |
| Credentials    | Access     | 32     |                              |
|                | Credential |        | Access credentials that      |
|                | Type and   |        | shall be applied to reserved |
|                | Length + 1 |        | page                         |
|                | .. n)      |        |                              |
+----------------+------------+--------+------------------------------+

6.4.9.2 OBE normal behaviors

The OBE shall determine whether sufficient unallocated memory exists in
the specified partition to satisfy the request and that the page
identifier is available. If so, the memory page shall be defined from
the avail­able memory in the specified partition. This reservation shall
then be honored when subsequent page-related commands are received.

If the OBE successfully executes the Reserve Memory Page command, the
OBE shall send a response with the Response Identifier field set to
Command Success. The response shall contain no data in the Response Data
field.

6.4.9.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

-   Command Not Recognized

-   Access Control Error

-   Partition Not Defined

-   Page Not Defined

-   Previously Reserved

-   Device Error

-   Command Failed

-   Insufficient Memory

6.4.10 Release Memory Page (optional)

The Release Memory Page command shall cause the OBE to release a page of
memory that had previously been reserved by the specified agency. This
release shall require the same access controls (if any) that were
specified at the time of page reservation.

6.4.10.1 Command set definition

The Release Memory Page command shall consist of the fields shown in
Table 6.4.10.1-1.

Table 6.4.10.1-1 Release Memory Page command fields (continued)

+-----------------+-----------+-------+-------------------------------+
| Field name      | Location  | L     | Specification and description |
|                 | (bytes)   | ength |                               |
+-----------------+-----------+-------+-------------------------------+
| Command         | 0         | 1     | hex( 41 ) / hex( C1 )         |
| Identifier      |           |       |                               |
+-----------------+-----------+-------+-------------------------------+
| Command         | 1         | 1     | Uniquely identifies an        |
| Transaction     |           |       | instance of a command         |
| Identifier      |           |       |                               |
+-----------------+-----------+-------+-------------------------------+
| Command Length  | 2 .. 3    | 2     | Defines the total length      |
|                 |           |       | (bytes) of all fields in this |
|                 |           |       | command excluding the length  |
|                 |           |       | of the Command Identifier     |
|                 |           |       | field, Command Transaction    |
|                 |           |       | Identifier field, and this    |
|                 |           |       | Command Length field          |
+-----------------+-----------+-------+-------------------------------+
| Access Control  | 4         | 0/1   | (Optional.) Number of access  |
| Length          |           |       | credentials bytes             |
+-----------------+-----------+-------+-------------------------------+
| Access Control  | 5 .. n    | 0/1   | (Optional.) Access            |
|                 |           | .. 32 | credentials                   |
+-----------------+-----------+-------+-------------------------------+
| Command         | End of    | 2     | Identifies referenced memory  |
| Parameter:      | Access    |       | page (as per specifi­cation in |
|                 | Control   |       | Table E.2)                    |
| Page Identifier | field + 1 |       |                               |
|                 |           |       |                               |
|                 | End of    |       |                               |
|                 | Access    |       |                               |
|                 | Control   |       |                               |
|                 | field + 2 |       |                               |
+-----------------+-----------+-------+-------------------------------+

6.4.10.2 OBE normal behaviors

The OBE shall release the previously reserved page, allowing it to be
reserved by other agencies and return­ing the associated extended memory
to the pool available for new reservation requests.

If the OBE successfully executes the Release Memory Page command, the
OBE shall send a response with the Response Identifier field set to
Command Success. The response shall contain no data in the Response Data
field.

3.  OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

-   Command Not Recognized

-   Access Control Error

-   Page Not Defined

-   Device Error

-   Command Failed

6.4.11 Query Memory Configuration (optional)

The Query Memory Configuration command shall cause the OBE to return to
the RSE the information that describes the organization of memory
including reserved memory partitions, reserved memory pages, and free
(unreserved) memory.

Execution of this command may be controlled by access credentials. When
this command is successfully executed, it shall return a complete
description of the transponder memory organization. The data returned in
response to this command shall not be affected by credentials required
for specific partition page or mem­ory access.

6.4.11.1 Command set definition

The Query Memory Configuration command shall consist of the fields shown
in Table 6.4.11.1-1.

Table 6.4.11.1-1 Query Memory Configuration command fields

  ----------------- -------------- ------------- -------------------------
  Field name        Location       Length        Specification and
                    (bytes)                      description

  Command           0              1             hex( 42 ) / hex( C2 )
  Identifier                                     

  Command           1              1             Uniquely identifies an
  Transaction                                    instance of a command
  Identifier                                     

  Command Length    2 .. 3         2             Defines the total length
                                                 (bytes) of all fields in
                                                 this command excluding
                                                 the length of the Command
                                                 Identifier field, Command
                                                 Transaction Identifier
                                                 field, and this Command
                                                 Length field

  Access Control    \(4\)          0/1           (Optional.) Number of
  Length                                         access creden­tials bytes

  Access Control    (5 .. n)       0/1 .. 32     (Optional.) Access
                                                 credentials

  Command Parameter                              None
  ----------------- -------------- ------------- -------------------------

6.4.11.2 OBE normal behaviors

The OBE shall return the roadside information that describes the memory
configuration.

If the OBE successfully executes the Query Memory Configuration command,
the OBE shall send a response with the Response Identifier field set to
Command Success, the Response Data Length field set to the length of the
returned memory configuration data, and the memory configuration data
itself shall be returned in the Response Data field (see 6.5.5).

6.4.11.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

-   Command Not Recognized

-   Access Control Error

-   Device Error

-   Command Failed

6.4.12 Reserve Memory Partition (optional)

The Reserve Memory Partition command shall cause the OBE to reserve a
partition of extended memory for the specified agency. This reservation
shall include the establishment of access control procedures.

6.4.12.1 Command set definition

The Reserve Memory Partition command shall consist of the fields shown
in Table 6.4.12.1-1.

Table 6.4.12.1-1 Reserve Memory Partition command fields (continued)

+---------------+----------------+-------+----------------------------+
| Field Name    | Location       | L     | Specification and          |
|               | (bytes)        | ength | Description                |
+---------------+----------------+-------+----------------------------+
| Command       | 0              | 1     | hex( 43 ) / hex( C3 )      |
| Identifier    |                |       |                            |
+---------------+----------------+-------+----------------------------+
| Command       | 1              | 1     | Uniquely identifies an     |
| Transaction   |                |       | instance of a command      |
| Identifier    |                |       |                            |
+---------------+----------------+-------+----------------------------+
| Command       | 2 .. 3         | 2     | Defines the total length   |
| Length        |                |       | (bytes) of all fields in   |
|               |                |       | this command excluding the |
|               |                |       | length of the Command      |
|               |                |       | Identifier field, Command  |
|               |                |       | Transaction Identifier     |
|               |                |       | field, and this Command    |
|               |                |       | Length field               |
+---------------+----------------+-------+----------------------------+
| Access        | 4              | 0/1   | (Optional.) Number of      |
| Control       |                |       | access credential bytes    |
| Length        |                |       |                            |
+---------------+----------------+-------+----------------------------+
| Access        | 5 .. n         | 0/1   | (Optional.) Access         |
| Control       |                | .. 32 | credentials                |
+---------------+----------------+-------+----------------------------+
| Command       | End of Access  | 2     | Length (in bytes) of the   |
| Parameter:    | Control        |       | memory partition that is   |
|               | field + 1      |       | requested                  |
| Partition     |                |       |                            |
| Size          | End of Access  |       |                            |
|               | Control        |       |                            |
|               | field + 2      |       |                            |
+---------------+----------------+-------+----------------------------+
| Partition     | End of Access  | 2     | Identifies the partition   |
| Identifier    | Control        |       | identifier that will be    |
|               | field + 3      |       | associated with this       |
|               |                |       | request; Table 1 defines   |
|               | End of Access  |       | the valid range of values  |
|               | Control        |       | for partition identifiers  |
|               | field + 4      |       |                            |
+---------------+----------------+-------+----------------------------+
| Partition     | (End of        | 0/1   | (Optional.) Number of      |
| Access        | Partition      |       | access credential bytes    |
| Credential    | Identi fier    |       | that shall be applied to   |
| Length        | field + 3 )    |       | this partition; max value  |
|               |                |       | = 32                       |
+---------------+----------------+-------+----------------------------+
| Partition     | (End of        | 0/1   | (Optional.) Access         |
| Access        | Partition      | .. 32 | credentials that shall be  |
| Credentials   | Access         |       | required when reserving    |
|               | Credential     |       | memory pages within this   |
|               | Type field +   |       | partition                  |
|               | 1.. n )        |       |                            |
+---------------+----------------+-------+----------------------------+

6.4.12.2 OBE normal behaviors

The OBE shall determine whether sufficient nonpartitioned memory exists
to satisfy the request and whether the partition identifier is
available. If so, the partition shall be defined from the available
memory. This par­tition shall then be honored when subsequent
partition-related commands are received.

If the OBE successfully executes the Reserve Memory Partition command,
the OBE shall send a response with the Response Identifier field set to
Command Success. The response shall contain no data in the Response Data
field.

6.4.12.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

-   Command Not Recognized

-   Access Control Error

-   Previously Reserved

-   Device Error

-   Command Failed

-   Insufficient Memory

6.4.13 Release Memory Partition (optional)

The Release Memory Partition command shall cause the OBE to release a
partition of memory that had pre­viously been reserved by the specified
agency. This release shall require the same access controls (if any)
that were specified at the time of partition reservation.

6.4.13.1 Command set definition

The Release Memory Partition command shall consist of the fields shown
in Table 6.4.13.1-1.

Table 6.4.13.1-1 Release Memory Partition command fields

+-----------------+-------------+------------+-------------------------+
| Field name      | Location    | Length     | Specification and       |
|                 | (bytes)     |            | description             |
+-----------------+-------------+------------+-------------------------+
| Command         | 0           | 1          | hex( 44 ) / hex( C4 )   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command         | 1           | 1          | Uniquely identifies an  |
| Transaction     |             |            | instance of a command   |
| Identifier      |             |            |                         |
+-----------------+-------------+------------+-------------------------+
| Command Length  | 2 .. 3      | 2          | Defines the total       |
|                 |             |            | length (bytes) of all   |
|                 |             |            | fields in this command  |
|                 |             |            | excluding the length of |
|                 |             |            | the Command Identifier  |
|                 |             |            | field, Command          |
|                 |             |            | Transaction Identifier  |
|                 |             |            | field, and this Command |
|                 |             |            | Length field            |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 4           | 0/1        | (Optional.) Number of   |
| Length          |             |            | access creden­tials      |
|                 |             |            | bytes                   |
+-----------------+-------------+------------+-------------------------+
| Access Control  | 5 .. n      | 0/1 .. 32  | (Optional.) Access      |
|                 |             |            | credentials             |
+-----------------+-------------+------------+-------------------------+
| Command         | End of      | 2          | Identifies the          |
| Parameter:      | Access\     |            | partition identifier    |
|                 | Control     |            | that will be associated |
| Partition       | field + 1   |            | with this request;      |
| Identifier      |             |            | Table E.1 defines the   |
|                 | End of      |            | valid range of values   |
|                 | Access\     |            | for partition           |
|                 | Control     |            | identifiers.            |
|                 | field + 2   |            |                         |
+-----------------+-------------+------------+-------------------------+

6.4.13.2 OBE normal behaviors

The OBE shall release the previously reserved partition and return the
memory to the pool available for partitioning.

If the OBE successfully executes the Release Memory Partition command,
the OBE shall send a response with the Response Identifier field set to
Command Success. The response shall contain no data in the Response Data
field.

6.4.13.3 OBE abnormal responses

The following Response Identifier field values defined in Table
6.5.3.4-1 may be returned for abnormal conditions:

-   Command Not Recognized

-   Access Control Error

-   Partition Not Defined

-   Device Error

-   Command Failed

6.5 Standard command responses

Each command response shall consist of the fields shown in Table 6.5-1
and described in 6.5.1 through 6.5.5.

Table 6.5-1 Command set fields

  -------------- -------------- ------------ -------------- --------------
  Response       Response       Response     Response Data  Response Data
  Command        Transaction    Identifier   Length         
  Identifier     Identifier                                 

  1 byte         1 byte         1 byte       2 bytes        Variable
  -------------- -------------- ------------ -------------- --------------

6.5.1 Response Command Identifier

6.5.1.1 Length

The length of the Response Command Identifier field shall be 1 byte.

6.5.1.2 Usage

The Response Command Identifier field shall contain the command
identifier of the original command that was sent to the OBE and effected
this response. Command Identifier field values are listed in Table
6.2.1.2-1.

6.5.1.3 Default value

The Response Command Identifier field has no default value.

6.5.2 Response Transaction Identifier

6.5.2.1 Length

The length of the Response Transaction Identifier field shall be 1 byte.

6.5.2.2 Usage

The Response Transaction Identifier field shall contain the transaction
identifier of the received command to which the response is addressed.

6.5.2.3 Default value

The Response Transaction Identifier field has no default value.

6.5.3 Response Identifier

6.5.3.1 Length

The length of the Response Identifier field shall be 1 byte.

6.5.3.2 Usage

The Response Identifier field shall contain a value indicating the
status of command execution in the OBE.

6.5.3.3 Default value

The Response Identifier field has no default value.

6.5.3.4 Response definitions

Table 6.5.3.4-1 lists the valid values and their interpretation. (See
ObeResponse in A.2 for ASN.1 definitions.) A command response will only
contain valid response data when the Response Identifier field is set to
Com­mand Success. All other values indicate failure conditions.

Table 6.5.3.4-1 Response Identifier values

  ------------------ ------------ ----------------------------------------
  Response name      Value        Specification and description

  Reserved           hex( 0 )     

  Command Success    hex( 1 )     Completion is normal.

  Command Failed     hex( 2 )     Completion is abnormal due to some
                                  unspecified condition.

  Command Not        hex( 3 )     The command was invalid or unsupported
  Recognized                      by the OBE. This response is used if the
                                  RSE references a UI element that is not
                                  present on a transponder.

  Access Control     hex( 4)      Access credentials may not have been
  Error                           supplied in a required sit­uation or the
                                  supplied credentials may be invalid; a
                                  nonce value is returned from the OBE.

  Page Not Defined   hex( 5 )     The page identifier does not match a
                                  reserved page in the OBE.

  Partition Not      hex( 6 )     The partition identifier does not match
  Defined                         an existing partition in the OBE.

  Device Error       hex( 7 )     A malfunction has occurred in the OBE
                                  hardware or software.

  Memory Access      hex( 8 )     The requested memory is faulty.
  Error                           

  Page Length        hex( 9 )     The length of the memory image is
  Mismatch                        greater than the length of the
                                  referenced memory page, or command
                                  execution would require crossing a page
                                  boundary.

  Insufficient       hex( A )     Available free memory is insufficient in
  Memory                          the referenced page to perform the
                                  command.

  Previously         hex( B )     The specified page or partition
  Reserved                        identifier has already been reserved by
                                  a previous Reserve command.

  Reserved           hex( C .. EF Reserved.
                     )            

  Vendor Area        hex( F0 ..   Available for vendor-specific failure
                     FF )         conditions.
  ------------------ ------------ ----------------------------------------

6.5.4 Response Data Length

6.5.4.1 Length

The length of the Response Data Length field shall be 2 bytes.

6.5.4.2 Usage

The Response Data Length field shall specify the total length (in bytes)
of the data contained in the Response Data field. Only the Read Memory
Page and Query Memory Configuration commands return response data.
Response data may also be created for a nonce if required access
credentials are incorrect. The Response Data Length field shall always
be present even if the response contains no response data.

6.5.4.3 Default value

The default value of the Response Data Length field shall be zero (0) if
the response contains no data.

6.5.5 Response Data

6.5.5.1 Length

The length of the Response Data field shall be variable.

6.5.5.2 Usage

Three cases exist for which response data are returned. These cases are
described in 6.5.5.2.1 through 6.5.5.2.3.

6.5.5.2.1 Case 1

Command = Read Memory Page

Response Identifier = Command Success

In this case, the Response Data field contains the requested OBE memory
image.

6.5.5.2.2 Case 2

Command = Query Memory Configuration

Response Identifier = Command Success

In this case the Response Data field contains a contiguous snapshot of
the transponder memory con­figuration represented as a set of triplets,
where each triplet in the set consists of three 16-bit values defined as
follows:

1.  Block Size: The size in bytes of this memory block.

```{=html}
<!-- -->
```
2.  Page Identifier: The page identifier associated with this block of
    memory. A value of hex( 0 ) means the memory is unallocated.

3.  Partition Identifier: The partition to which this block of memory
    belongs. A value of hex( 0 ) means no associated partition exists.

6.5.5.2.3 Case 3

Command = Any Command

Response Identifier = Access Control Error

In this case, the Response Data field contains a nonce value.

6.5.5.3 Default value

The Response Data field does not exist except for the three cases
specified in 6.5.5.2.

6.5.6 Response definitions

The OBE normal behaviors, which are described for each command
definition in 6.4, specifically state the values that shall be contained
in the Response Identifier field. The response data, if any, that shall
be returned in the response is also included in these descriptions.

The only abnormal response (any value for the Response Identifier field
other than Command Success) that shall return a non-null Response Data
field is the Access Control Error, which returns a nonce value.

The Received Transaction Identifier field of any response shall always
be set to the value of the Transaction Identifier field of the command
to which the OBE is responding.

6.6 Interoperability requirements

Compliant transponders shall meet all the requirements specified in this
specification. Interop­erable transponders shall additionally provide
specified features. The following commands defined in this subsection
shall be implemented in interoperable transponders:

-   Read Memory Page

-   Write Memory Page

-   Set User Interface

-   Sleep Transponder

-   Reserve Memory Page (If Reserve Memory Page is not supported, then
    available extended memory shall be preallocated into pages by the
    manufacturer.)

-   Release Memory Page (Required when Reserve Memory Page is present.)

-   Query Memory Configuration

Interoperable transponders may also implement additional optional
commands.

Additional interoperability requirements are specified in 5.3.

6.7 Error detection and processing

The following methods shall be applied on the OBE and RSE to detect and
process errors that may be present in commands and command responses.

6.7.1 OBE command error detection processing

The OBE shall check commands received from the RSE for the following
error conditions prior to execution:

Verify that the command identifier is defined.

Verify that the command length matches the length of the received
information.

For commands having fixed parameters, verify that the command length
matches the value defined in this specification.

For command parameters that have a limited value domain, verify that all
command parameters have values defined within this specification.

Additional, vendor-specific error checks may be provided.

If any of these conditions is detected, the OBE shall reject the command
and shall issue a command response with the appropriate response
identifier.

2.  RSE command response error detection processing

The RSE shall check command responses received from the OBE for the
following error conditions prior to execution:

a.  Verify that the response command identifier is defined.

```{=html}
<!-- -->
```
b.  Verify that the response identifier is defined.

c.  Verify that the response command identifier is the same as the
    command identifier used in the previously transmitted command having
    a matching response transaction identifier.

d.  Verify that the response data length matches the length of the
    received information.

Additional, vendor-specific error checks may be provided.

If any of these error conditions is detected, the RSE shall reject the
command response. The RSE may retransmit the command that resulted in
the erroneous command response, using the identical information. If the
OBE receives such a duplicated command, it shall regenerate and transmit
the appropriate command response, but shall not reexecute the defined
command processing. Reception of an erroneous command response may
indicate a flaw in the overall processing, and the command that
generated the condition should generally not be retransmitted.

# 7. Resource Manager

# 

The resource manager shall provide the roadside "operating system" that
accepts, arbitrates, implements, and responds to requests for DSRC
services that are received from one or more BOAs. The resource man­ager
shall be the initiator of all commands to the OBE controller, acting as
the master in a master-slave rela­tionship. The functional relationships
are illustrated in Figure 7-1.

![](media/image9.wmf){width="5.698611111111111in"
height="4.321527777777778in"}

Figure 7-1 Resource Manager Relationships

A typical DSRC roadside system shall consist of a single VRC controller
connected to one or more readers with each reader connected to one or
more antennas. Com­pliant DSRC roadside installations shall provide a
resource manager function as specified in this section, and it is
anticipated that the resource manager will in most cases be hosted
within the VRC controller so that it may manage the transponder
resources within an entire field of DSRC communications. However, this
specification does not require any specific mapping of the resource
manager to specific hardware.

Other equipment to accomplish functions such as automatic vehicle
classification, weigh-in-motion, vehicle detection, etc., may exist at
the roadside or in the roadway; however, this specification does not
govern such equipment.

This section (which is taken directly from Clause 7 of IEEE 1455-99)
specifies the characteristics of the resource manager function. An ITS
application may include RSE other than that required for DSRC to perform
functions such as vehicle classification or weigh-in- motion. This
equipment is not governed by this specification.

**7.1 Resource manager processing summary**

The resource manager shall implement the following processing flow:

a.  The resource manager shall initially accept registrations from BOAs
    that specify the set of DSRC resources to which each BOA requires
    access. This registration process is further specified in 7.2.2.

```{=html}
<!-- -->
```
b.  The resource manager shall then communicate with the connected
    beacons to configure each bea­con's initial transactions with
    transponders that may pass within the beacon's communications zone.
    This communication process is further specified in 7.3.

c.  When a transponder enters a beacon's communications zone, the beacon
    will notify the resource manager and may also transmit one or more
    memory images that have been retrieved from the tran­sponder. The
    resource manager may then request the retrieval of additional memory
    pages and may provide access credentials required for the retrieval.

d.  The resource manager shall then parse any received memory images and
    shall transmit the informa­tion contained within the memory images to
    the BOAs that have registered for it.

e.  In response, the BOAs may request that specific messages be deleted
    or that additional messages be stored within the specified
    transponder memory region.

f.  The resource manager shall then create a new memory image in
    response to the requests from the BOA and shall transmit that memory
    image to the beacon for storage within the transponder's mem­ory
    region. \[Steps d), e), and f) are further specified in 7.4.\]

g.  The resource manager shall also accept requests from the BOAs that
    the transponder's UI be manip­ulated. The resource manager shall
    arbitrate those requests when received from multiple BOAs and shall
    then communicate appropriate commands to the beacon for transmission
    to the transponder. This process is specified further in 7.5.

7.2 BOA interface

Since the BOA is the ultimate user of the DSRC information, it is
essential that this specification allow for such information
transmission. However, the actual specification of the interface between
the resource manager and the BOA is beyond the scope of this
specification. This subsection, therefore, specifies the capabilities
that are required within all implementations of that interface and also
provides guidance on how the interface might be implemented.

7.2.1 Physical media

BOAs shall be provided with a communications link via which they will

-   Be able to register themselves with the resource manager

-   Be able to specify messages of interest it wants to receive

-   Get the messages of interest as they are received

-   Have a means of updating these messages upon receipt

-   Have a means of specifying special actions that the resource manager
    must automatically perform upon receipt of these messages of
    interest

This specification does not govern the BOA interface; it is anticipated
that the interface may be implemented using a variety of physical media.
It is solely the responsibility of the system integrator and the user
agency to select and implement the BOA interface using the media or
combination of media appropriate for the cost, bandwidth, and physical
limitations applicable to the DSRC installation.

7.2.2 Registration

Prior to receiving any transponder-derived information from the resource
manager, the BOA shall register with the resource manager to define the
types of information required and the conditions under which it should
be transmitted. The classes of registration that are available and may
be supported by the resource manager are listed in Table 7.2.2-1.

Table 7.2.2-1 Registration parameters (continued)

  ---------------- ------------------------------------------------------
  Registration\    Description and usage
  information type 

  Unique           Specifies a set of transponders that are of interest
  Identifiers\     to the registering application; data reports shall be
  of Interest      made to the BOA only for transponders with included
                   unique identifiers.

  Unique           Specifies a set of transponders that are not of
  Identifiers\     interest to the registering application; data reports
  Not of Interest  shall never be made to the BOA for transponders with
                   included unique identifiers.

  Service          Specifies a set of service agencies that are of
  Agencies\        interest to the registering application; data reports
  of Interest      shall be made to the BOA only for transponders with
                   included service agencies.

  Service          Specifies a set of service agencies that are not of
  Agencies\        interest to the registering application; data reports
  Not of Interest  shall never be made to the BOA for transponders with
                   included service agencies.

  Beacon           Specifies a set of beacon identifiers that are of
  Identifiers      interest to the registering application; data reports
                   shall be made to the BOA only for transponders that
                   are in communication with an included beacon.

  Message          Specifies a set of message identifiers that are of
  Identifiers      interest to the registering application; only those
                   messages identifiers registered by the BOA shall be
                   reported to the BOA when a tran­sponder communicates
                   with a beacon.

  Transponder      Specifies a set of transponder resources, such as
  Resources        memory or peripheral configurations, that must be
                   present in the transponder; the registering BOA shall
                   be notified of messages only from transponders with
                   these resources identified in the read-only memory.

  Memory Page      Specifies a set of transponder memory pages that are
  Identifiers      of interest to the registering BOA; only information
                   that is stored within the memory pages registered by
                   the BOA shall be reported to the BOA when a
                   transponder communicates with a beacon.
  ---------------- ------------------------------------------------------

These registration parameters essentially restrict the volume of
information passed using the methods described in 7.2.3. Specific
resource manager implementations need not implement all the registration
parameters. However, the full set of unfiltered information defined in
7.2.3 may be transmitted to the BOA.

7.2.3 Information transmission to the BOA

In response to the registration information received from the BOA, the
resource manager shall utilize the beacon interface specified in 7.3 to
elicit transfer of information from the transponders that communicate
with connected beacons. As a result of this communication, the resource
manager will obtain one or more memory images. The resource manager
shall then determine whether the communicating transponder matches the
previously received registration filters.

If the transponder meets the registration constraints, then the resource
manager shall process the memory images for which the BOA has registered
to extract that information. For the read-only memory region, this
processing shall consist solely of formatting the binary information
contained within the memory region into appropriate data structures for
transmission. For all other memory regions, the resource manager shall
parse the memory region to extract individual messages. Each message
shall then be compared to the list of message identifiers that have been
registered with the BOA. If the BOA has registered for a message that is
present in the memory image, then the message shall be transmitted to
the BOA. Messages may be reformat­ted for transmission to the BOA.

Once the resource manager has extracted all information within the
transponders for which the BOA has registered, the resource manager
shall assign an identifier to each message that will be transmitted to
the BOA. The extracted information, including all messages and their
identifiers, shall then be transmitted to the BOA using the selected
communication channel.

7.2.4 Message reception from the BOA

After the BOA receives information from the resource manager that has
been extracted from memory regions within a communicating transponder,
the BOA may choose to alter the information stored within a specific
memory region of a transponder. Two methods of alteration shall be
provided:

a.  The BOA may request that a message be deleted from a specific memory
    region. This alteration is accomplished by specifying the
    corresponding message sequence number.

```{=html}
<!-- -->
```
b.  The BOA may request that an additional message be stored within the
    transponder's memory region. This alteration is accomplished by
    creating the desired message and then passing it to the resource
    manager.

These memory image alteration requests shall be processed as specified
in 7.4.

Due to vehicle movement and other factors, it is possible that the
resource manager will be unable to accom­plish the requested memory image
alterations. If this condition is detected by the resource manager, it
shall be reported to the requesting BOA.

7.2.5 UI requests from the BOA

After the BOA receives information from the resource manager that has
been extracted from a communicat­ing transponder, the BOA may choose to
manipulate the transponder's UI. The resource manager shall pro­vide
service methods that allow the BOA to individually manipulate each of
the UI resources defined in Section 5. These service requests shall be
processed as defined in 7.5.

Due to vehicle movement and other factors, it is possible that the
resource manager will be unable to accom­plish the requested UI actions.
If this condition is detected by the resource manager, it shall be
reported to the requesting BOA.

7.2.6 Predefined transponder sessions

In some cases, the BOA may require the capability to predefine sequences
of actions (which can be treated as a single logical action) that should
be taken by the resource manager upon arrival of a transponder. Such a
sequence is only executed when the transponder is within the beacon's
communications field. This is likely to occur when the BOA is connected
to the resource manager via a low-speed interface. In such a case, it is
unlikely that the communication of individual sequential commands can be
successfully accomplished dur­ing the period of time in which the vehicle
is within the beacon's communications field.

The resource manager may provide for this requirement by implementing
registration messages, configura­tion files, or custom software that
implements the required sequences of actions. If this capability is
pro­vided, the resource manager shall still report all pertinent
information received from or transmitted to the transponder using the
processes defined in 7.2.4 and 7.2.5.

7.3 Beacon interface (nonmandatory)

It is anticipated that in many cases the resource manager will be
implemented within a VRC controller that is physically distinct from,
but connected to, the beacon. In this case, it will be necessary for the
VRC control­ler to communicate with the beacon to control the beacon
configuration, elicit information from each tran­sponder that passes
through the beacon's communication region, and transfer information to
the beacon for storage on the transponders. However, this specification
recognizes that in some cases the VRC controller and the beacon will
actually be a single piece of equipment, hosting both the resource
manager and the beacon functionality.

This specification anticipates that future efforts may be undertaken to
specify a specification interface between the resource manager and the
beacon. Absent such a specification, the following guidelines are
recommended:

-   The interface will typically correspond to the interface between the
    application layer and lower layer service as described in Section 9.

-   The interface should allow the resource manager to initiate,
    terminate, monitor, and otherwise con­trol the communications channel
    with the beacon.

-   The interface should allow the resource manager to query the
    configuration and health of the beacon and any connected equipment.

-   The interface should allow the resource manager to mute the beacon,
    i.e., cause the beacon to cease RF transmission and reception.

-   The interface should allow the resource manager to specify that
    lower layer actions target a specific beacon.

-   The interface should allow the beacon to transmit to the resource
    manager a transponder command response (specified in Section 6).

-   In some DSRC systems, the vehicle speed and size of the beacon
    communications region will con­strain the period of time during which
    the beacon may communicate with a transponder. The physi­cal
    capabilities of the interface between the resource manager and the
    beacon should accommodate the correspondingly required transmission
    speeds.

7.4 Memory page management

The resource manager shall arbitrate, manage, and control all
transponder memory regions that may be mod­ified using the commands
listed in Section 6. This capability shall be provided as follows, and
in such a way as to meet the requirements specified in 7.2.3 and 7.2.4:

-   The resource manager shall retrieve all memory regions that have
    been previously requested as part of BOA registrations. The resource
    manager shall not retrieve or process in any way memory regions that
    have not been requested as part of a BOA registration. The resource
    manager shall not write to pages that are unchanged.

-   The resource manager shall parse all retrieved memory regions to
    isolate the messages stored within them.

-   The resource manager shall transmit the messages to the BOAs that
    have previously registered for the messages. Messages that are
    stored within pages that have been reserved to a specific agency
    shall only be transmitted to BOAs that specify that page identifier
    as part of their registration parameters.

-   If a BOA requests that messages be deleted from or added to a page,
    then the resource manager shall perform the memory consolidation
    process defined in 7.4.1. The resource manager shall only accept
    requests for changes to reserved memory pages from BOAs that
    specified the reserving page identi­fier as part of their
    registration parameters. If a page is not reserved, i.e., is a
    public page, then the resource manager shall accept requests for
    changes to that page from any (and potentially multiple) BOAs that
    request access to that page as part of their registration
    parameters.

-   After performing the memory consolidation process, the resource
    manager shall transmit the modi­fied memory image to the beacon for
    storage on the transponder. The resource manager may use the Write
    Memory Page, Append Message, or Write Circular Queue command as
    appropriate and as supported by the transponder.

7.4.1 Memory consolidation

After the resource manager has retrieved a memory region from a
transponder, parsed the messages from that region, passed the messages
to BOAs that have registered for them, and received requests for memory
image updates from the BOAs, the resource manager will have three sets
of information corresponding to the memory region:

-   Existing messages. A list of messages that were stored within the
    memory region when it was received.

-   Obsolete messages. A list of message sequence numbers corresponding
    to messages that one or more BOAs have requested be deleted.

-   Requested messages. A list of messages that BOAs have requested be
    added.

The resource manager shall then create a list of new messages by
performing the following steps:

a.  Each existing message shall be analyzed to determine whether it has
    expired. This shall be deter­mined by comparing the message
    expiration date stored within the specified message to the date at
    which the analysis is performed.

```{=html}
<!-- -->
```
b.  Each existing message that has not expired shall then be placed on
    the new message list if it is not present on the obsolete message
    list (in the resource manager).

c.  If room is available within the designated transponder memory
    region, all requested messages shall be added to the new message
    list. If insufficient room exists for all requested messages, the
    resource manager may add a subset of the requested message list to
    the new message list using a site-specific prioritization algorithm.
    The BOAs shall be notified if insufficient memory space exists for a
    message.

Once the new message list has been created, it shall be used to generate
a new memory image of the desig­nated transponder memory region.

7.5 UI management

The resource manager shall accept requests for UI services from the
communicating BOAs as specified in 7.2.5. When the resource manager is
servicing only a single BOA or when no conflicts exist in the UI
requests received from multiple communicating BOAs, then the resource
manager shall directly translate the UI service requests into the
transponder UI commands specified in Section 6.

In some cases, conflicts may arise between BOAs that request access to
the same UI resources. For example, an Electronic Toll Collection
application might request illumination of the green lamp, while a Border
Crossing application requests illumination of a red lamp. Site-specific
rules shall be established for the arbi­tration of conflicting UI
directives.

# 8. ITS application messages

8.1 Message concepts

Application messages are the data constructs that provide for
communication between applications and pos­itive identification of
vehicles, containers, chassis, etc. Each application area, such as
Electronic Toll Col­lection or Border Clearance, has messages that are
unique to the application. In addition, there are utility messages that
may be utilized in multiple applications. This section defines the
general format of messages, specific message sets for each application
area, and data element definitions for all messages.

Note that this section is the same as Clause 8 in IEEE 1455-99 with
**[the following two exceptions: (1) no ETC messages are specified
(since this is a CVO focused specification), and (2) the CVO Electronic
Screening Message Set has been slightly altered to align it with the
Commercial Vehicle Information Systems and Networks architecture (see
Section 8.6).]{.underline}**

8.1.1 Message format

Each application message shall consist of a header and a body. The
header component is defined across all applications. The message body
consists of the application data fields. Message body content is unique
to each message type within each application. The specific data elements
that are used in message headers are formally defined in 8.2.

8.1.2 Message encoding

The encoding and decoding of message fields into transfer syntax shall
be performed by the application. All messages shall be encoded according
to ASN.1 Packed Encoding Rules (PER), unaligned, as specified in ISO/IEC
8825-2:1996. The application may also encrypt the message body using an
application-specific technique.

The specification of each application message includes an ASN.1 value
specification of the message body with a specification header. Following
the sample value assignments is a bit-level layout of the resulting
encod­ing. Within the bit-level layouts, a period (.) is used to indicate
octet alignment and an "x" is used as a bit placeholder with no specific
value.

8.2 Message headers

Two forms of the message header exist. The specification, or "long
form," header, which is 5 bytes long, is used to prefix messages that
are stored in transponder memory pages that are at least 512 bits in
length. The "short form" header, which is 3 bytes long, is used to
prefix messages that are stored in transponder memory pages that are
less then 512 bits in length. Message headers shall not be encrypted.
Tables 8.2-1 and 8.2-2 provide a layout of each message type.

Table 8.2-1 Standard message format

  ------------- ------------ ------------ ----------- ----------- -----------
  Application   Message      Message      Message     Error       Message
  Identifier    Identifier   Expiration   Length      Detect Code Body
                             Date                                 

  Bits 0 .. 5   Bits 6 .. 11 Bits 12 ..   Bits 24 ..  Bits 32 ..  Variable
                             23           31          39          
  ------------- ------------ ------------ ----------- ----------- -----------

  

Table 8.2-2 Short message format

  -------------- -------------- -------------- -------------- -------------
  Message        Message        Message Length Error Detect   Message Body
  Identifier     Expiration                    Code           
                 Date                                         

  Bits 0 .. 4    Bits 5 .. 11   Bits 12 .. 15  Bits 16 .. 23  Variable
  -------------- -------------- -------------- -------------- -------------

8.2.1 Standard message header

Table 8.2.1-1 specifies the fields and the permissible field values for
the standard header. Messages using long headers are constrained to 255
bytes in length (excluding the header) by the definition of the Message
Length field.

Table 8.2.1-1 Standard message header fields (continued)

  ------- ------------------ --------- -------- ---------------------------
  Field   Field name         Type      Length   Values

  1       Application        Integer   6 bits   See Table 34
          Identifier                            

  2       Message Identifier Integer   6 bits   See Tables 35 through 38

  3       Message Expiration Integer   12 bits  (0 .. 4095); Days since
          Date                                  last decade; a message
                                                expiration date equal to
                                                hex( FFF ) indicates that
                                                the message never expires.

  4       Message Length     Integer   8 bits   (0 .. 255); Length of
                                                message body, in bytes
                                                (does not include header)

  5       Error Detect Code  Bit       8 bits   XOR Checksum of the message
                             string             body
  ------- ------------------ --------- -------- ---------------------------

Standard message headers shall have an application identifier and a
message identifier that uniquely identify the message type. Table
8.2.1-2 lists values for the application identifier. Table 8.2.1-3
through Table 8.2.1-6 list values for message identifiers within each
application.

The Message Expiration Date field shall specify the point in time after
which the message may be deleted. This field supports a message lifetime
of up to 180 days. The field shall be interpreted as follows:

-   If the message expiration date is less than or equal to 3652 and the
    current date within the decade is greater than the message
    expiration date, then the message shall be deleted.

-   If the message expiration date is greater than 3652 and the current
    date within the decade is greater than 180 and less than 3472, then
    the message shall be deleted.

-   If the message expiration date is greater than 3652 and the current
    date within the decade is less than 180, then the message shall be
    deleted if the message expiration date is less than the current date
    within the decade plus 3652.

    Table 8.2.1-2 Application identifiers

  ------------ ----------------------------------------------------------
  Code         Application

  0            Reserved

  1            Electronic Toll and Traffic Management (ETTM)

  2            Commercial Vehicle (CV) Management

  3            Common Utility Messages

  4 .. 59      Reserved

  60           Private (Uncontrolled); Message identifiers associated
               with this application identifier are available for
               uncontrolled use

  61           Private (Controlled); Message identifiers associated with
               this application identifier are available for registration

  62 .. 63     Reserved
  ------------ ----------------------------------------------------------

Table 8.2.1-3 Message identifiers: ETTM (continued)

  ------------------------- ---------------------------------------------
  Code                      Message description

  0                         Reserved

  1                         Toll System Entry

  2                         Toll Vehicle Classification

  3                         Toll Variable Pricing

  4                         Toll System Enroll

  5 .. 63                   Reserved
  ------------------------- ---------------------------------------------

Table 8.2.1-4 Message identifiers: CV Management

  --------------------- -------------------------------------------------
  Code                  Message description

  0                     Reserved

  1                     Border Trip Identification

  2                     Border Clearance Event

  3                     Border Lock Notification

  4                     Border Lock Status

  5                     Border Itinerary Identification

  6                     Commercial Motor Vehicle (CMV) Screening
                        Identification

  7                     CMV Screening Event

  8                     CMV Screening Identification---Expanded

  9                     CMV Screening Event---Expanded

  10 .. 63              Reserved
  --------------------- -------------------------------------------------

Table 8.2.1-5 Message identifiers: Common Utility Messages

  ------------------------ ----------------------------------------------
  Code                     Message description

  0                        Reserved

  1                        Text String

  2                        RSE to Other OBE---Generic Data

  3                        Other OBE to RSE---Generic Data

  4                        End Of Data

  5 .. 63                  Reserved
  ------------------------ ----------------------------------------------

  

Table 8.2.1-6 Message identifiers: Private Controlled

  ------------------ ----------------------------------------------------
  Code               Message description

  0                  Reserved

  01 .. 63           Available for registration of private reserved
                     messages
  ------------------ ----------------------------------------------------

8.2.1.1 ASN.1 specification

  ------------------ --------- --------------------- ---------------------------
  Dsrcmsg-Header ::=           SEQUENCE              

  {                                                  

  application-ID                                     INTEGER (0..63),

  message-ID                                         INTEGER (0..63),

  message-date                                       INTEGER (0..4095),

  message-length                                     INTEGER (0..255),

  message-checksum                                   BIT STRING (SIZE(8))

  }                                                  
  ------------------ --------- --------------------- ---------------------------

2.  ASN.1 sample values

  ------------------ --------- ---------------- -------------------------------
  Dsrcmsg-Header ::=           SEQUENCE         

  {                                             \-- Begin Standard Header

  application-ID                                1,

  message-ID                                    1,

  message-date                                  0,

  message-length                                0,

  message-checksum                              '00'H

                                                \-- End Header / Begin Body

  }                                             
  ------------------ --------- ---------------- -------------------------------

3.  ASN.1 PER encoding

  ----------- ---------------- ------------------- -------------------------
  **Bit**     **Bit value**                        **Field definition**

  0           000001                               application-ID

  6           00.0001                              message-ID

  12          0000.00000000.                       message-date

  24          00000000                             message-length

  32          xxxxxxxx\.                           message-checksum

  40                                               \-\-\-\-- \[end of
                                                   Header\]
  ----------- ---------------- ------------------- -------------------------

8.2.2 Short message header

Short message headers shall use the short message identifier instead of
the application identifier and mes­sage identifier. Table 8.2.2-1 lists
the fields and the permissible field values for the short message
header. Mes­sages using short headers are constrained to 30 bytes in
length (excluding the header) by the definition of the Message Length
field.

Table 8.2.2-1 Short message header fields (continued)

  --------- ------------- ----------- ---------- --------------------------
  Field     Field name    Type        Length     Values

  1         Message       Integer     5 bits     See Table 40
            Identifier                           

  2         Message       Integer     7 bits     (0 .. 127); Months since
            Expira­tion                           last decade. A value of
            Month                                127 indicates that a
                                                 message never expires.

  3         Message       Integer     4 bits     (1 .. 15); Length of
            Length                               message body in byte pairs
                                                 (does not include header)

  4         Error Detect  Bit string  8 bits     XOR checksum of the
            Code                                 message body
  --------- ------------- ----------- ---------- --------------------------

Short message headers shall use the short message identifier instead of
the application identifier and mes­sage identifier. Table 40 lists the
permissible values for short message identifiers.

Table 8.2.2-2 Short message identifiers (continued)

  ---------------- ------------------------------------------------------
  Code             Message description

  0                Reserved

  1                Toll Entry

  2                Toll Vehicle Classification

  3                Toll Variable Pricing

  4                Toll System Enroll

  5                Border Trip Identification

  6                Border Clearance Event

  7                Border Lock Notification

  8                Border Lock Status

  9                Border Itinerary Identification

  10               Reserved by IEEE for future use

  11               CMV Screening Clearance Event

  12               Reserved by IEEE for future use

  13               CMV Screening Clearance Event---Expanded

  14               Utility Text String

  15               Utility RSE to Other OBE

  16               Utility Other OBE to RSE

  17               Utility End Of Data

  18..31           Reserved by IEEE for future use
  ---------------- ------------------------------------------------------

The Message Expiration Month field shall specify the point in time after
which the message may be deleted. This field supports a message lifetime
of up to 6 mo. The field shall be interpreted as follows:

-   If the message expiration month is less than or equal to 120 and the
    current month within the decade is greater than the message
    expiration month, then the message shall be deleted.

-   If the message expiration month is greater than 120 and the current
    month within the decade is greater than 6 and less than 114, then
    the message shall be deleted.

-   If the message expiration month is greater than 120 and the current
    date within the decade is less than 7, then the message shall be
    deleted if the message expiration month is less than the current
    month within the decade plus 120.

8.2.2.1 ASN.1 specification

  ------------------ --------- ---------------------- -------------------------
  Dsrcmsg-Header ::=           SEQUENCE               

  {                                                   

  short-message-ID                                    INTEGER (0..31),

  message-month                                       INTEGER (0..4095),

  message-length                                      INTEGER (1..16),

  message-checksum                                    BIT STRING (SIZE(8))

  }                                                   
  ------------------ --------- ---------------------- -------------------------

2.  ASN.1 sample values

  ---------------------- ---------- --------------------- --------------------------
  Dsrcmsg-Header ::=                SEQUENCE              

  {                                                       \-- Begin Short Header

  short-message-ID                                        1,

  short-message-month                                     0,

  short-message-length                                    4,

  message-checksum                                        '00'H

                                                          \-- End Header / Begin
                                                          Body

  }                                                       
  ---------------------- ---------- --------------------- --------------------------

3.  ASN.1 PER encoding

  --------- --------------- -------------------- ---------------------------
  **Bit**   **Bit value**                        **Field definition**

  0         00001                                short-message-ID

  7         000.0000                             short-message-date

  12        0100\.                               short-message-length

  16        xxxxxxxx\.                           message-checksum

  24                                             \-\-\-\-- \[end of Header\]
  --------- --------------- -------------------- ---------------------------

8.3 Message data elements

This subsection describes the data elements used in the body of the
application message. Each data element is accompanied by the
corresponding ASN.1 name. A list of all the data elements and their
ASN.1 attributes is provided in Annex A of IEEE 1455-99.

8.3.1 Common application data elements

The following elements are defined by this specification and were
designed for use across DSRC applications.

8.3.1.1 Timestamp (Dsrc-Time)

DSRC date/time values shall be expressed as a 4 byte integer indicating
the number of seconds since January 1, 1970 GMT.

8.3.1.2 Beacon Identifier (Beacon-Identity)

The roadside beacon shall have a unique identifier consisting of a
16 bit identifier registered to that agency followed by a 16 bit
agency-unique serial number.

8.3.1.3 Transponder Identifier (Transponder-Identity)

The transponder shall have a unique identifier (see 5.2.18) consisting
of 40 bits, which represent the Manu­facturer Identifier and Serial
Number fields (and associated subfields) defined for read-only memory
(see 5.2).

2.  Data elements---application-specific

Application data elements are specified using ASN.1 syntax in Annex A of
IEEE 1455-99.

# Electronic Toll Collection message set

There are no ETC messages required by this specification.

8.5 Commercial Vehicle Operations Border Clearance message set

Table 8.5-1 summarizes the messages that have been defined for the CVO
Border Clearance application. This subclause details the specific
formats, conditions, and uses for each message.

Table 8.5-1 CVO Border Clearance message summary (continued)

  -------------------------- --------------------------------------------
  Message name               Description

  Trip Identification Number Transmits the unique trip load number

  Border Clearance Event     Reports clearance event data to the vehicle

  Electronic Lock            Notifies roadside that the vehicle has
  Notification               electronic locks

  Electronic Lock Status     Provides roadside with status of electronic
                             lock

  Itinerary Verification     Shows percent likelihood that vehicle
                             maintained its itinerary

  Warning/Notification       Indicates special attention for cargo or
                             onboard sensor
  -------------------------- --------------------------------------------

8.5.1 Trip Identification Number message

The Trip Identification Number message contains the unique trip load
number, consisting of the carrier's Dunn & Bradstreet number (DUNS) and
a unique suffix. It is generated by a portable transfer device \[e.g., a
notebook computer or personal digital assistant (PDA)\], stored in the
transponder memory, and received by the beacon at a border clearance
location. See Table 8.5.1-1.

Table 8.5.1-1 Trip Identification Number message

  ------------- ------------------------ -------------------- ----------------
  Field         Data element name        Type                 Constraint

  1             Tripload-DunsNumber      NumericString        Size (9)

  2             Tripload-CarrierSerial   NumericString        Size (6)
  ------------- ------------------------ -------------------- ----------------

8.5.1.1 ASN.1 specification

  ----------------------------- -------------------- ----------------------------
  Trip-Identification-Message   ::=SEQUENCE          

  {                                                  

  header                        Dsrcmsg-Header,      

  duns-number                   NumericString        \-- Tripload-DunsNumber
                                (SIZE(9)),           

  carrier-serial                NumericString        \-- Tripload-CarrierSerial
                                (SIZE(6))            

  }                                                  
  ----------------------------- -------------------- ----------------------------

8..5.1.2 ASN.1 sample values

  ------------------------- ------- --------- ------------ -----------------------------
  Trip-Identification-Mes           ::=       SEQUENCE     
  sage                                                     

  {                                                        \-- Begin Standard Header

  application-ID                              2,           

  message-ID                                  1,           

  message-date                                0,           

  message-length                              8,           

  message-checksum                            '00'H,       

                                                           \-- End Header / Begin Body

  duns-number                                 123456789,   

  carrier-serial                              123456       

  }                                                        
  ------------------------- ------- --------- ------------ -----------------------------

3.  ASN.1 PER encoding

  --------- ----------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                **Field definition**

  0         000001                                       application-ID

  6         00.0001                                      message-ID

  12        0000.00000000.                               message-date

  24        00001000\.                                   message-length

  32        xxxxxxxx\.                                   message-checksum

                                                         \-\-\-\-- \[end of
                                                         Header\]

  40        00010010.00110100.01010110.                  

  64        01111000.1001                                

  76        0001.00100011.01000101.0110                  

  100       xxxx\.                                       

  104                                                    
  --------- ----------------------------- -------------- --------------------------

8.5.2 Border Clearance Event message

The Border Clearance Event message reports border clearance information
to the vehicle. It is generated by the border crossing location DSRC
controller, stored in the transponder memory, and received by the beacon
at another border clearance location. See Table 8.5.2-1.

Table 8.5.2-1 Border Clearance Event message (continued)

  ----------- ---------------------------------- --------------- ------------------
  Field       Data element name                  Type            Constraint

  1           Beacon-Identity                    Bit string      Size (32)

  2           Borderevent-Timestamp              Integer         Dsrc-Time

  3           Borderevent-DriverClearance        Boolean         Go/True -
                                                                 NoGo/False

  4           Borderevent-DriverClearanceFlag    Boolean         Valid/True -
                                                                 Invalid/False

  5           Borderevent-CargoClearance         Boolean         Go/True -
                                                                 NoGo/False

  6           Borderevent-CargoClearanceFlag     Boolean         Valid/True -
                                                                 Invalid/False

  7           Borderevent-TractorClearance       Boolean         Go/True -
                                                                 NoGo/False

  8           Borderevent-TractorClearanceFlag   Boolean         Valid/True -
                                                                 Invalid/False

  9           Borderevent-ReserveClearance       Boolean         Reserved for
                                                                 future use

  10          Borderevent-ReserveFlag            Boolean         Reserved for
                                                                 future use

  11          Transponder-DigitalSignature       Bit string      Size (64)
  ----------- ---------------------------------- --------------- ------------------

8.5.2.1 ASN.1 specification

  ------------------------------------------- ----------------- ----------------------------
  Border-Clearance-Event-Message::=SEQUENCE                     

  {                                                             

  headerDsrcmsg-Header,                                         

  beacon-IDBIT STRING SIZE((32)),                               

  timestampDsrc-Time,                                           

  driver-clearanceBOOLEAN,                                      

  driver-clearance-flagBOOLEAN,                                 

  cargo-clearanceBOOLEAN,                                       

  cargo-clearance-flagBOOLEAN,                                  

  tractor-clearanceBOOLEAN,                                     

  tractor-clearance-flagBOOLEAN,                                

  reserve-clearanceBOOLEAN,                                     

  reserve-flagBOOLEAN,                                          

  digital-signatureBIT STRING (SIZE(64))                        

  }                                                             
  ------------------------------------------- ----------------- ----------------------------

2.  ASN.1 sample values

  ----------------------------------- -------------- ----------- ------------------------------
  Border-Clearance-Event-Message::=                              
  SEQUENCE                                                       

  {                                                              \-- Begin Standard Header

  application-ID                      2,                         \-- CVO Application Identifier

  message-ID                          2,                         \-- Border Clearance Event
                                                                 Message ID

  message-date                        0,                         \-- 1/1/1990

  message-length                      17,                        \-- 17 byte message body

  message-checksum                    '00'H,                     \-- XOR checksum (not
                                                                 calculated)

                                                                 \-- End Header / Begin Body

  beaconID                            '00020100'H,               \-- Agency=2; Serial=256

  timestamp                           0,                         \-- 00:00:00 1/1/1970 GMT

  driver-clearance                    TRUE,                      \-- GO

  driver-clearance-flag               TRUE,                      \-- VALID

  cargo-clearance                     TRUE,                      \-- GO

  cargo-clearance-flag                TRUE,                      \-- VALID

  tractor-clearance                   TRUE,                      \-- GO

  tractor-clearance-flag              TRUE,                      \-- VALID

  reserve-clearance                   FALSE,                     \-- Reserved - NOGO

  reserve-flag                        FALSE,                     \-- Reserved - INVALID

  digital-signature                   0                          \--
                                                                 Transponder-DigitalSignature

  }                                                              
  ----------------------------------- -------------- ----------- ------------------------------

3.  ASN.1 PER encoding

  --------- -------------------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                         **Field definition**

  0         000010                                                application-ID

  6         00.0010                                               message-ID

  12        0000.00000000.                                        message-date

  24        00010001                                              message-length

  32        xxxxxxxx\.                                            message-checksum

                                                                  \-\-\-\-- \[end of
                                                                  Header\]

  40        00000000.00000010.                                    

  56        00000001.00000000.                                    beaconID -- Serial
                                                                  component

  72        00000000.00000000.00000000.00000000.                  

  104       1                                                     

  105       1                                                     driver-clearance-flag

  106       1                                                     cargo-clearance

  107       1                                                     cargo-clearance-flag

  108       1                                                     tractor-clearance

  109       1                                                     tractor-clearance-flag

  110       0                                                     reserve-clearance

  111       0\.                                                   reserve-flag

  112       00000000.00000000.00000000.00000000.                  

  144       00000000.00000000.00000000.00000000.                  

  176                                                             \-\-\-\-- \[end of Body\]
  --------- -------------------------------------- -------------- --------------------------

8.5.3 Electronic Lock Notification message

The Electronic Lock Notification message notifies the roadside that the
vehicle contains electronic locks. It is generated by a portable
transfer device (e.g., a notebook computer or PDA), stored in the
transponder memory, and received by the beacon at a border clearance
location. See Table 8.5.3-1.

Table 8.5.3-1 Electronic Lock Notification message

  ------- ------------------------------ --------- ----------------------------------
  Field   Data element name              Type      Constraint

  1       Lock-Quantity                  Integer   (0 .. 15)

  2       Lock-Identity                  Bit       Size (40); Transponder-Identity;
                                         string    the value of the pre­ceding
                                                   Lock-Quantity field indicates the
                                                   number of occurrences of this
                                                   field

  3       Transponder-DigitalSignature   Bit       Size (64)
                                         string    
  ------- ------------------------------ --------- ----------------------------------

8.5.3.1 ASN.1 specification

  ---------------------------------- ------------------- --------------------------
  Border-Lock-Notification-Message                       
  ::=SEQUENCE                                            

  {                                                      

  headerDsrcmsg-Header,\-- Standard                      
  Header                                                 

  lock-quantityINTEGER (0..15)\--                        
  Lock-Quantity                                          

  lock-IDBIT STRING (SIZE(40)),\--                       
  Lock-Identity (Transponder ID)                         

  digital-signatureBIT STRING                            
  (SIZE(64))\--                                          
  Transponder-DigitalSignature                           

  }                                                      
  ---------------------------------- ------------------- --------------------------

2.  ASN.1 sample values

  ------------------------------------- -------- ------------- ---------------- ------------------------------
  Border-Lock-Notification-Message::=                          SEQUENCE         

  {                                                                             \-- Begin Standard Header

  application-ID                                               2,               

  message-ID                                                   3,               

  message-date                                                 0,               

  message-length                                               14,              

  message-checksum                                             '00'H,           

                                                                                \-- End Header / Begin Body

  lock-quantity                                                1,               

  lock-ID                                                      '0080000040'H,   

  digital-signature                                            0                

  }                                                                             
  ------------------------------------- -------- ------------- ---------------- ------------------------------

3.  ASN.1 PER encoding

  --------- -------------------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                         **Field definition**

  0         000010                                                application-ID

  6         00.0011                                               message-ID

  12        0000.00000000.                                        message-date

  24        00001110                                              message-length

  32        xxxxxxxx\.                                            message-checksum

                                                                  \-\-\-\-- \[end of
                                                                  Header\]

  40        0001                                                  

  44        0000.000010                                           lock-ID Manufacturer =2

  54        00.00000000.00000000.00000100.                        

  80        0000                                                  

  84        0000.00000000.00000000.00000000.0000                  

  116       0000.00000000.00000000.00000000.0000                  

  148       xxxx\.                                                fill

  152                                                             \-\-\-\-- \[end of Body\]
  --------- -------------------------------------- -------------- --------------------------

8.5.4 Border Lock Status message

The Electronic Lock Status message notifies the roadside regarding the
status (e.g., Open, Close, Bad) of an electronic lock. It is generated
by an electronic lock and received by the beacon at a border clearance
loca­tion. See Table 8.5.4-1.

Table 8.5.4-1 Electronic Lock Status message

  ------- ------------------------------ ------------ -----------------------------
  Field   Data element name              Type         Constraint

  1       Lock-Identity                  Bit string   Size (40);
                                                      Transponder-Identity

  2       Borderevent-Timestamp          Integer      Size (32); Dsrc-Time

  3       Lock-CurrentStatus             Integer      (0 .. 7)

  4       Lock-HistoryCount              Integer      (0 .. 15); the value of this
                                                      field indicates the number
                                                      occurrences of Fields 5 and 6

  5       Lock-Status                    Integer      (0 .. 7)\
                                                      0 Open\
                                                      1 Closed\
                                                      2 Bad

  6       Borderevent-Timestamp          Integer      Size (32); Dsrc-Time

  7       Transponder-DigitalSignature   Bit string   Size (64)
  ------- ------------------------------ ------------ -----------------------------

8.5.4.1 ASN.1 specification

  ------------------------------ ------------------- --------------------------
  Border-Lock-Status-Message                         
  ::=SEQUENCE                                        

  {                                                  

  headerDsrcmsg-Header,\--                           
  Standard Header                                    

  lock-IDBIT STRING                                  
  (SIZE(40)),\-- Lock-Identity                       
  (Transponder ID)                                   

  border-timeDsrc-Time\--                            
  Borderevent-Timestamp                              

  lock-statusINTEGER (0..7)\--                       
  Lock-Status                                        

  lock-quantityINTEGER                               
  (0..15)\-- Lock-HistoryCount                       

  lock-status-h1INTEGER                              
  (0..7)\-- Lock-Status                              

  border-time-h1Dsrc-Time\--                         
  Borderevent-Timestamp                              

  digital-signatureBIT STRING                        
  (SIZE(64))\--                                      
  Transponder-DigitalSignature                       

  }                                                  
  ------------------------------ ------------------- --------------------------

2.  ASN.1 sample values

  ------------------------------- ------- ------------ ---------------- ----------------------------
  Border-Lock-Status-Message::=                        SEQUENCE         

  {                                                                     \-- Begin Standard Header

  application-ID                                       2,               

  message-ID                                           4,               

  message-date                                         0,               

  message-length                                       23,              

  message-checksum                                     '00'H,           

                                                                        \-- End Header / Begin Body

  lock-ID                                              '0080000040'H,   

  timestamp                                            0,               

  lock-status                                          0,               

  lock-quantity                                        1                

  lock-status-h1                                       1                

  border-time-h1                                       0                

  digital-signature                                    0                

  }                                                                     
  ------------------------------- ------- ------------ ---------------- ----------------------------

3.  ASN.1 PER encoding

  --------- --------------------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                          **Field definition**

  0         000010                                                 application-ID

  6         00.0100                                                message-ID

  12        0000.00000000.                                         message-date

  24        00001001                                               message-length

  32        xxxxxxxx\.                                             message-checksum

                                                                   \-\-\-\-- \[end of
                                                                   Header\]

  40        0000                                                   

  44        0000.000010                                            lock-ID Manufacturer =2

  54        00.00000000.00000000.00000100.                         

  80        00000000.00000000.00000000.00000000.                   

  112       000                                                    

  115       0001                                                   

  119       0.01                                                   lock-status-h1

  122       000000.00000000.00000000.00000000.00                   

  154       000000.00000000.00000000.00000000.                     

  184       00000000.00000000.00000000.0000000.00                  

  218       xxxxxx\.                                               

  224                                                              
  --------- --------------------------------------- -------------- --------------------------

8.5.5 Itinerary Verification message

The Itinerary Verification message notifies the border clearance
roadside on the percent likelihood that the vehicle maintained its
preplanned itinerary. It is generated by an onboard computer and
received by the bea­con at a border clearance location. See Table
8.5.5-1.

Table 8.5.5-1 Itinerary Verification message

  ------- ------------------------------ ----------- --------------------------------
  Field   Data element name              Type        Constraint

  1       Vehicle-ItineraryQuality       Integer     (0 .. 100); 100 indicates the
                                                     highest confidence that the
                                                     vehicle has followed a specified
                                                     itinerary. 0 indi­cates a high
                                                     confidence that the vehicle has
                                                     signifi­cantly deviated from a
                                                     specified itinerary. Other
                                                     values indicate intermediate
                                                     levels of confidence.

  2       Borderevent-Timestamp          Integer     Size (32); Dsrc-Time

  3       Transponder-DigitalSignature   Bit string  Size (64)
  ------- ------------------------------ ----------- --------------------------------

8.5.5.1 ASN.1 specification

  -------------------------- ------------------- -------------------------------
  Border-Itinerary-Message   ::=SEQUENCE         

  {                                              

  header                     Dsrcmsg-Header,     \-- Standard Header

  itinerary-quality          INTEGER (0..255),   \-- Vehicle-ItineraryQuality;
                                                 Max=100

  border-time                0                   \-- Borderevent-Timestamp

  digital-signature          BIT STRING          \--
                             (SIZE(64))          Transponder-DigitalSignature

  }                                              
  -------------------------- ------------------- -------------------------------

2.  ASN.1 sample values

  -------------------------- ------- ------------ ----------- ----------------------------
  Border-Itinerary-Message           ::=          SEQUENCE    

  {                                                           \-- Begin Standard Header

  application-ID                                  2,          

  message-ID                                      5,          

  message-date                                    0,          

  message-length                                  13,         

  message-checksum                                '00'H,      

                                                              \-- End Header / Begin Body

  itinerary-quality                               64,         

  border-time                                     0,          

  digital-signature                               0,          

  }                                                           
  -------------------------- ------- ------------ ----------- ----------------------------

3.  ASN.1 PER encoding

  --------- -------------------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                         **Field definition**

  0         000010                                                application-ID

  6         00.0101                                               message-ID

  12        0000.00000000.                                        message-date

  24        00001101                                              message-length

  32        xxxxxxxx\.                                            message-checksum

                                                                  \-\-\-\-- \[end of
                                                                  Header\]

  40        01000000                                              

  48        00000000.00000000.00000000.00000000.                  

  80        00000000.00000000.00000000.00000000.                  

  112       00000000.00000000.00000000.00000000.                  

  144                                                             
  --------- -------------------------------------- -------------- --------------------------

8.6 CVO Electronic Screening message set

Table 8.6-1 summarizes the messages that have been defined for the CVO
Electronic Screening (also referred to as Mainline Screening)
application. This subclause details the specific formats, conditions,
and uses for each message.

Table 8.6-1 CVO Electronic Screening message summary

  ------------------------------- ---------------------------------------
  Message name                    Description

  CMV Screening Identification    Sets and sends vehicle and cargo data

  CMV Screening Event             Reports clearance event data to the
                                  vehicle

  CMV Screening Identification    Sets and sends vehicle and cargo data
  Expanded                        

  CMV Screening Event Expanded    Reports clearance event data to the
                                  vehicle
  ------------------------------- ---------------------------------------

8.6.1 CMV Screening Identification message

The CMV Screening Identification message provides the information
necessary to conduct electronic screening of CVs at CV check stations in
North America. It is generated by a portable transfer device (e.g., a
notebook computer or PDA), stored in the transponder memory, and
received by the beacon at a CV check station. It is transferred from the
transponder to the beacon at mainline speeds. See Table 8.6.1-1.

Table 8.6.1-1 CMV Screening Identification message

  -------- ------------------- ------------- --------------------------------
  Field    Data element name   Type          Constraint

  1        Carrier-Identity    IA5string     Size (24); this field may be
                                             repeated up to 3 times

  2        Vehicle-Identity    IA5string     Size (30); VIN

  3        Vehicle-CargoType   IA5string     Size (5); Hazmat Code
  -------- ------------------- ------------- --------------------------------

8.6.1.1 ASN.1 specification

  ----------------------------------- ------------------- -------------------------------
  CMV                                                     SEQUENCE
  -Clearance-Identification-Message                       
  ::=                                                     

  {                                                       

  header                              Dsrcmsg-Header,     \-- Standard Header

  carrier-ID                          IA5String           \-- Carrier-Identity
                                      (SIZE(24)),         

  vin                                 IA5String           \-- Vehicle-Identity
                                      (SIZE(30)),         

  cargo-code                          IA5String (SIZE(5)) \-- Vehicle-CargoType

  }                                                       
  ----------------------------------- ------------------- -------------------------------

2.  ASN.1 sample values

  -------------------------------------- ------- ----------- ---------- ------------------------------
  CMV-Clearance-Identification-Message                                  SEQUENCE
  ::=                                                                   

  {                                                                     \-- Begin Standard Header

  application-ID                                             2,         

  message-ID                                                 6,         

  message-date                                               0,         

  message-length                                             59,        

  message-check sum                                          '00'H,     

                                                                        \-- End Header / Begin Body

  carrier-ID                                                 64,        

  vin                                                        0,         

  cargo-code                                                 0,         

  }                                                                     
  -------------------------------------- ------- ----------- ---------- ------------------------------

3.  ASN.1 PER encoding

  --------- -------------------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                         **Field definition**

  0         000010                                                application-ID

  6         00.0110                                               message-ID

  12        0000.00000000.                                        message-date

  24        00101011                                              message-length

  32        xxxxxxxx\.                                            message-checksum

                                                                  \-\-\-\-- \[end of
                                                                  Header\]

  40        xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  72        xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  104       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  136       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  168       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  200       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  232       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  264       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  296       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  328       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  360       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  392       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  424       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  456       xxxxxxxx.xxxxxxxx                                     

  472       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  504       xxxxxxxx                                              

  512                                                             \-\-\-\-- \[end of Body\]
  --------- -------------------------------------- -------------- --------------------------

8.6.2 CMV Screening Event message

The CMV Screening Event message provides information documenting
critical parameters of the last screening event. It is generated by the
CV check station computer via a DSRC controller, stored in the
tran­sponder memory, and received by the beacon at a CV check station.
See Table 8.6.2-1.

Table 8.6.2-1 CMV Screening Event message

  ------- ------------------------- --------- -----------------------------------
  Field   Data element name         Type      Constraint

  1       Vehicle-GrossWeight       Integer   (0..16383); measured vehicle weight
                                              in 10 kg increments

  2       Scale-Type                Integer   (1 .. 15); see Table 55

  3       Vehicle-AxleNumber        Integer   (2 .. 17); measured number of
                                              vehicle axles

  4       Beacon-Identity           Bit       Size (32)
                                    String    

  5       Mainlineevent-Timestamp   Integer   Size (32); Dsrc-Time

  6       Mainlineevent-Bypass      Boolean   Go/True\
                                              1=Bypass/True, 0=Pullin/False
  ------- ------------------------- --------- -----------------------------------

   

Table 8.6.2-2 Scale types

  ----------------- -----------------------------------------------------
  Values            Definitions

  1                 Jurisdictional weight

  2                 Mainline WIM

  3                 Ramp sorter WIM

  4                 Slow rollover WIM

  5                 Static scale weight

  15                Operator-entered weight
  ----------------- -----------------------------------------------------

8.6.2.1 ASN.1 specification

  ----------------------------- ------------------- -------------------------------
  CMV-Screening-Event-Message                       
  ::=SEQUENCE                                       

  {                                                 

  header                        Dsrcmsg-Header,     \-- Standard Header

  gross-weight                  INTEGER             \-- Vehicle-GrossWeight

  scale-type                    INTEGER             \-- Scale-Type

  axle-number                   INTEGER             \-- Vehicle-AxleNumber

  beacon-ID                     BIT STRING          \-- Beacon-Identity
                                (SIZE(32)),         

  timestamp                     Dsrc-Time           \-- Mainlineevent-Timestamp

  pullin-clearance              BOOLEAN             \--
                                                    Mainlineevent-PullinClearance

  }                                                 
  ----------------------------- ------------------- -------------------------------

8.6.2.2 ASN.1 sample values

  ----------------------------- ------- ----------- -------------- -------------------------------
  CMV-Screening-Event-Message                                      
  ::=SEQUENCE                                                      

  {                                                                \-- Begin Standard Header

  application-ID                                    2,             

  message-ID                                        7,             

  message-date                                      0,             

  message-length                                    12,            

  message-checksum                                  '00'H,         

                                                                   \-- End Header / Begin Body

  gross-weight                                      500,           

  scale-type                                        1,             

  axle-number                                       4              

  beacon-ID                                         '00020100'H,   

  timestamp                                         0,             

  pullin-clearance                                  TRUE           

  }                                                                
  ----------------------------- ------- ----------- -------------- -------------------------------

3.  ASN.1 PER encoding

  --------- -------------------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                         **Field definition**

  0         000010                                                application-ID

  6         00.0111                                               message-ID

  12        0000.00000000.                                        message-date

  24        00001100                                              message-length

  32        xxxxxxxx\.                                            message-checksum

                                                                  \-\-\-\-- \[end of
                                                                  Header\]

  40        00000111.110100                                       

  54        000100                                                

  58        00100                                                 

  64        00000000.00000010.                                    

  80        00000001.00000000.                                    

  96        00000000.00000000.00000000.00000000.                  

  128       1                                                     

  129                                                             

  136                                                             \-\-\-\-- \[end of Body\]
  --------- -------------------------------------- -------------- --------------------------

8.6.3 CMV Screening Expanded Identification message

The CMV Screening Expanded Identification message provides information
that may become necessary to conduct electronic screening of CVs at CV
check stations in North America and is used in conjunction with the CMV
Screening Identification message (see 8.6.1). It is generated by a
portable transfer device (e.g., a notebook computer or PDA), stored in
the transponder memory, and received by the beacon at a CV check
station. It is transferred from the transponder to the beacon at
mainline speeds. See Table 8.6.3-1.

Table 8.6.3-1 CMV Screening Expanded Identification message

  ---------- --------------------------- --------------- ----------------------
  Field      Data element name           Type            Constraint

  1          Vehicle-ComponentIdentity   IA5string       Size (30); VIN

  2          Driver-Identity             IA5string       Size (20)
  ---------- --------------------------- --------------- ----------------------

8.6.3.1 ASN.1 specification

  ------------------------ ------------------ ------------------------------
  CMV-Screening-Expanded                      SEQUENCE
  Identification-Message                      
  ::=                                         

  {                                           

  header                   Dsrcmsg-Header,    \-- Standard Header

  vehicle-component-ID     IA5String          \-- Vehicle-ComponentIdentity
                           (SIZE(30)),        

  driver-ID                IA5String          \-- Driver-Identity
                           (SIZE(20))         

  }                                           
  ------------------------ ------------------ ------------------------------

2.  ASN.1 sample values

  ------------------------ ------- ----------- -------- -------------------------------
  CMV-Screening-Expanded                                ::=SEQUENCE
  Identification-Message                                

  {                                                     \-- Begin Standard Header

  application-ID                               2,       

  message-ID                                   8,       

  message-date                                 0,       

  message-length                               50,      

  message-checksum                             '00'H,   

                                                        \-- End Header / Begin Body

  vehicle-component-ID                                  

  driver-ID                                             

  }                                                     
  ------------------------ ------- ----------- -------- -------------------------------

3.  ASN.1 PER encoding

  --------- -------------------------------------- -------------- --------------------------
  **Bit**   **Bit value**                                         **Field definition**

  0         000010                                                application-ID

  6         00.1000                                               message-ID

  12        0000.00000000.                                        message-date

  24        00001100                                              message-length

  32        xxxxxxxx\.                                            message-checksum

                                                                  \-\-\-\-- \[end of
                                                                  Header\]

  40        xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx                                     

  280       xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

            xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.                  

  440                                                             \-\-\-\-- \[end of Body\]
  --------- -------------------------------------- -------------- --------------------------

8.6.4 CMV Screening Expanded Event message

The CMV Screening Expanded Event message provides information
documenting potentially critical parameters of the last clearance event
and is used in conjunction with the CMV Screening Event message (see
8.6.2). It is generated by the CV check station computer via a DSRC
controller, stored in the transpon­der memory, and received by the beacon
at a CV check station. See Table 8.6.4-1.

Table 8.6.4-1 CMV Screening Expanded Event message

  -------- --------------------- --------- -------------------------------------
  Field    Data element name     Type      Constraint

  1        Vehicle-AxleNumber    Integer   (2 .. 17); measured number of vehicle
                                           axles

  2        Vehicle-AxleWeight    Integer   (0 .. 4536); 10 kg steps; repeated
                                           for each axle

  3        Vehicle-AxleSpacing   Integer   (0 .. 62); distance between axles in
                                           .5 m steps. Last value (for final
                                           axle) shall always be 0. Repeated for
                                           each axle.
  -------- --------------------- --------- -------------------------------------

8.6.4.1 ASN.1 specification

  ------------------------ ------------------ ------------------------------
  CMV-Screening-Expanded                      SEQUENCE
  Event-Message ::=                           

  {                                           

  header                   Dsrcmsg-Header,    \-- Standard Header

  axle-number              INTEGER,           \-- Vehicle-AxleNumber

  axle-weight-1            INTEGER,           \-- Vehicle-AxleWeight

  axle-weight-2            INTEGER,           \-- Vehicle-AxleWeight

  axle-spacing-1           INTEGER,           \-- Vehicle-AxleSpacing

  axle-spacing-2           INTEGER,           \-- Vehicle-AxleSpacing

  }                                           
  ------------------------ ------------------ ------------------------------

2.  ASN.1 sample values

  ------------------------ ------- ----------- -------- -------------------------------
  CMV-Screening-Expanded                                SEQUENCE
  Event-Message ::=                                     

  {                                                     \-- Begin Standard Header

  application-ID                               2,       

  message-ID                                   9,       

  message-date                                 0,       

  message-length                               6,       

  message-checksum                             '00'H,   

                                                        \-- End Header / Begin Body

  axle-number                                  2        

  axle-weight                                  100,     

  axle-weight                                  100,     

  axle-spacing                                 4        

  axle-spacing                                 0        

  }                                                     
  ------------------------ ------- ----------- -------- -------------------------------

3.  ASN.1 PER encoding

  --------- ----------------------- -------------- --------------------------
  **Bit**   **Bit value**                          **Field definition**

  0         000010                                 application-ID

  6         00.1001                                message-ID

  12        0000.00000000.                         message-date

  24        00000110                               message-length

  32        xxxxxxxx\.                             message-checksum

                                                   \-\-\-\-- \[end of
                                                   Header\]

  40        00010                                  

  45        0011.11101000.0                        

  58        0011111.010000                         

  71        00.0100                                

  77        0000.00                                

  83        xxxxxx                                 

  88                                               
  --------- ----------------------- -------------- --------------------------

# 9. Application Layer

## **9.1 Introduction**

The purpose of the Application Layer is to provide communication
services that allow the Resource Manager to communicate with the DSRC
application on the OBE. The specification of the Application Layer is
based on Clause 9 of IEEE 1455-99; however, it has been substantially
modified for the following two reasons. First, a portion of the
application layer functionality has been subsumed by lower layers.
Second, the application layer and its interface to the other layers are
not expected to be exposed and thus they will not be testable.
Therefore, the application layer portion of this specification only
provides limited guidance on the services and lower layer interface.
[Specification compliant DSRC equipment does not need to support the
capability discussed in this section, except formatting related to the
initialization tables as described in section 9.4.]{.underline}

## **9.2 DSRC Application Domain Assumptions**

This specification makes the following assumptions about the domain of
DSRC applications for which the Specification is intended:

-   Point-to-Point Communication: Any session that includes the exchange
    of messages between a DSRC application on the RSE and the
    corresponding application on the OBE transponder is always through a
    single point-to-point communication between the two.

```{=html}
<!-- -->
```
-   Master-Slave: In all RSE-to-OBE point-to-point connections, the
    Resource Manager acts as the master and the OBE transponder
    application is the slave.

## **9.3 Architecture**

### 9.3.1 Lower Layer Service

The Application Layer assumes there is a generic lower layer service.
This lower layer service provides the minimum subset of the
functionality defined by Layers 4 through 1 of the OSI model. Table
9.3.1-1 summarizes the minimum subset of the services, defined by OSI
Layers 4 through 1, that the Application Layer assumes are provided
within the lower layer service.

Table 9.3.1-1 Required Subset of OSI Functionality for the Lower Layer
Service

+---------------------------------+------------------------------------+
| **OSI Layer**                   | **Corresponding Lower Layer        |
|                                 | Service**                          |
+---------------------------------+------------------------------------+
| Layer 4 (transport)             | -   Fragmentation/Defragmentation  |
|                                 |                                    |
|                                 | -   Message sequencing             |
|                                 |                                    |
|                                 | -   Duplicate message handling     |
+---------------------------------+------------------------------------+
| Layer 3 (network)               | > Packet routing                   |
+---------------------------------+------------------------------------+
| Layer 2(data link)              | -   Frame handling                 |
|                                 |                                    |
|                                 | -   Transmission error detection   |
|                                 |                                    |
|                                 | -   Transmission error recovery    |
+---------------------------------+------------------------------------+
| Layer 1 (physical)              | -   Physical information           |
|                                 |     transmission                   |
+---------------------------------+------------------------------------+

The Application Layer requires a service interface to the lower layer
service. This service interface shall provide three basic classes of
service for sending data from the RSE Application Layer and sending
corresponding responses from the OBE Application Layer.

The specific syntax and semantics of the generic lower layer service
implementation may be vendor specific. However, any conformant lower
layer service must provide a lower layer service that corresponds to
each of the required generic lower layer service classes defined in this
section. The specific lower layer service implementation may also
include additional services required for interoperability.

For the purposes of this Specification, the lower layer service classes
are defined using the following generic service identifiers:

1.  DATASEND_RESPOND: This service class sends data from the RSE
    Application Layer and receives a confirmation that the data was
    received by the OBE and response data from the OBE.

2.  DATASEND_NORESPOND: This service class sends data from the RSE
    Application Layer with no subsequent OBE application confirmation
    that the data was received by the OBE.

3.  SEND_BST_RESPOND_REPEAT: This service class sends a BST from the RSE
    Application Layer and receives a confirmation, which includes a
    returned VST, that the BST was received by the OBE.

### 9.3.2 Application Layer Services 

The Application Layer shall consist of an Application Layer kernel whose
services are defined by a set of application kernel elements. An
application kernel element represents a logical component of Application
Layer functionality.

The application kernel shall consist of a transfer kernel element
(T-KE), an initialization kernel element (I-KE), and a broadcast kernel
element (B-KE).

The T-KE shall provide services to transfer information between the
Resource Manager and the application running on the OBE transponder.

The I-KE shall provide services to initialize a session between the
Resource Manager and an application running on the OBE transponder. The
I-KE shall initialize the session by means of a BST. The size of one BST
shall enable the transfer of the BST in one layer service primitive. A
response to an I-KE initialization using a BST shall be in the form of a
VST. The BST and VST are defined in section 9.4.

The B-KE shall provide services to broadcast unacknowledged information
from the Resource Manager to a Broadcast Pool maintained by the OBE
Application Layer as well as services for the OBE transponder
application to access the Broadcast Pool.

**9.4 Initialization Tables**

9.4.1 Beacon Service Table

As part of the initialization of a point-to-point connection between the
RSE and the OBE, the I-KE collects the Resource Manager application
identification number, initial data, and protocol layer parameters
relevant for the communication, and assembles a BST. The BST is
cyclically transmitted by the RSE. Either the Application Layer or the
lower layer service may control this cyclic transmission depending on
the capability of the lower layer service.

The reception of the BST by an OBE transponder is the initiator of the
point-to-point data transfer. The OBE transponder evaluates a received
BST to determine if a connection should be made, and if so, sends back a
corresponding VST. Table 9.4.1-1 describes the individual fields and
their values, which shall comprise the BST.

In order to avoid compatibility problems with a subset of legacy OBEs,
the Logical Link Control bits in the slot used to transmit the BST shall
be set to hex 0100.

Table 9.4.1-1 BST Field Descriptions and Values

+-----------+----------+---------------------+-----+------------------+
| **Field   | **ASN.1  | **Description**     | **S | **Bit Sequence = |
| Name**    | Type**   |                     | ize | Value**          |
|           |          |                     | (b  |                  |
|           |          |                     | its |                  |
|           |          |                     | )** |                  |
+-----------+----------+---------------------+-----+------------------+
| T-APDU    | T-APDUs  | A BST identifier    | 4   | 0-3 = ASN.1      |
|           |          | required for        |     | T-APDUs value    |
|           |          | compliance with the |     | for a choice of  |
|           |          | CEN ASN.1           |     | initia           |
|           |          | definition of a BST |     | lisation.request |
|           |          |                     |     | = hex( 8 )       |
+-----------+----------+---------------------+-----+------------------+
| Options   | BIT      | A bit indicating    | 1   | 4 = 0            |
| Flag      | STRING   | that the optional   |     |                  |
|           | (SIZE    | nonmadatory         |     |                  |
|           | (1) )    | applications list   |     |                  |
|           |          | field is missing;   |     |                  |
|           |          | required for        |     |                  |
|           |          | compliance with the |     |                  |
|           |          | CEN ASN.1           |     |                  |
|           |          | definition of a BST |     |                  |
+-----------+----------+---------------------+-----+------------------+
| beacon    | BeaconID | An identifier       | 43  | 5-20 =           |
|           |          | composed of a       |     | Manufacturer     |
|           |          | Manufacturer        |     | Identifier       |
|           |          | Identifier (a       |     |                  |
|           |          | unique identifier   |     | 21-47 =          |
|           |          | assigned by IEEE)   |     | Individual       |
|           |          | and an Individual   |     | Identifier       |
|           |          | Identifier whose    |     |                  |
|           |          | use is vendor       |     |                  |
|           |          | specific            |     |                  |
+-----------+----------+---------------------+-----+------------------+
| time      | Time     | The number of       | 32  | 48-79 = time     |
|           |          | seconds from        |     |                  |
|           |          | 01/01/1970 GMT      |     |                  |
+-----------+----------+---------------------+-----+------------------+
| profile   | Profile  | The profile that    | 8   | 80-87 = profile  |
|           |          | will be used to     |     |                  |
|           |          | transmit the BST;   |     |                  |
|           |          | profile definitions |     |                  |
|           |          | are specific to the |     |                  |
|           |          | lower layer service |     |                  |
+-----------+----------+---------------------+-----+------------------+
| mandApp   | Applica  | Defines the RSE     | ##  | -   88-95 =      |
| lications | tionList | applications; the   | ### |     number in    |
|           |          | only application    | ##  |     list = hex ( |
|           |          | currently defined   | 136 |     2 )          |
|           |          | by this             |     |                  |
|           |          | Specification is    |     | -   96-103 =     |
|           |          | mailbox             |     |     hex( 0D )    |
|           |          |                     |     |     (mailbox     |
|           |          | The ASN.1 encoding  |     |     AID)         |
|           |          | of the application  |     |                  |
|           |          | list requires that  |     | -   104-111 =    |
|           |          | the first octet     |     |     EID          |
|           |          | defines the number  |     |                  |
|           |          | of elements in the  |     | -   112-119 =    |
|           |          | list which shall    |     |     hex( 4 ) =   |
|           |          | always be hex( 1 )  |     |     tag for      |
|           |          |                     |     |     Octet String |
|           |          | The application     |     |                  |
|           |          | list consists of    |     | -   120-127 =    |
|           |          | the mailbox AID, an |     |     length of    |
|           |          | EID, and a          |     |     data = hex(  |
|           |          | parameter field;    |     |     0C )         |
|           |          | the Parameter field |     |                  |
|           |          | consists of a data  |     | -   128-143 =    |
|           |          | type tag, a data    |     |     1^st^ filter |
|           |          | length octet, and   |     |     identifier   |
|           |          | the data itself.    |     |                  |
|           |          |                     |     | -   144-159 =    |
|           |          | The Parameter Field |     |     2^nd^ filter |
|           |          | data defines two    |     |     identifier   |
|           |          | Page Identifiers    |     |                  |
|           |          | that must be        |     | -   160-175 =    |
|           |          | present on the OBE  |     |     1^st^ return |
|           |          | for the OBE to      |     |     identifier   |
|           |          | respond with a BST  |     |                  |
|           |          |                     |     | -   176-191 =    |
|           |          | The Parameter Field |     |     2^rd^ return |
|           |          | then defines four   |     |     identifier   |
|           |          | Page Identifiers    |     |                  |
|           |          | for which OBE       |     | -   192-207 =    |
|           |          | memory images will  |     |     3^nd^ return |
|           |          | be returned by the  |     |     identifier   |
|           |          | OBE in the VST      |     |                  |
|           |          |                     |     | -   208-223 =    |
|           |          | The Page            |     |     4^th^ return |
|           |          | Identifiers shall   |     |     identifier   |
|           |          | be set to zero if   |     |                  |
|           |          | they are unused     |     |                  |
+-----------+----------+---------------------+-----+------------------+
| pr        | SEQUENCE | A profile, in       | 16  | 224-231 = number |
| ofileList | OF       | addition to the     |     | of profiles in   |
|           | Profile; | profile specified   |     | list = hex( 1 )  |
|           | only one | in the Profile      |     |                  |
|           | Profile  | field, that is      |     | 232-239 = value  |
|           | in the   | supported by the    |     | of profile       |
|           | sequence | RSE lower layer     |     |                  |
|           |          | service; the ASN.1  |     |                  |
|           |          | encoding of         |     |                  |
|           |          | profileList         |     |                  |
|           |          | requires two octets |     |                  |
+-----------+----------+---------------------+-----+------------------+

### 9.4.2 Vehicle Service Table (VST)

The VST is constructed by the I-KE on the OBE transponder in response to
a BST received from the RSE. The VST shall be composed of only the
requested pages; each prefaced by the 40-bit IEEE1455-99 Command
Response header (section 6.5). The Response Command Identifier shall be
set to hex (10). The Response Transaction Identifier shall be set to hex
(00). Page 1 (the Read-only Memory) will be transmitted only when
requested. The \"CEN configuration bits\" will not be transmitted.

**Attachment A Compatibility Philosophy**

Introduction

The primary objective of this document is to specify the characteristics
of Dedicated Short Range Communication (DSRC) equipment that will serve
as a basis for nationwide compatibility for commercial vehicle
operations (CVO). The most significant difference between the equipment
specified by this document (referred to as FHWA equipment) and equipment
previously deployed is the use of the IEEE 1455-99 application layer. It
is anticipated that future FHWA CVO applications will be conducted
exclusively with IEEE 1455 and will require equipment conforming to this
specification. However, this document carries forward the physical layer
and data link layer characteristics of deployed CVO DSRC systems. A goal
of this specification is to allow for compatible operation with deployed
CVO systems such as Advantage CVO, Help Prepass, and border crossing and
to permit a smooth transition from legacy systems to equipment
conforming to this specification. This appendix briefly reviews the
system compatibility philosophy.

Physical Layer

Basic communications compatibility at the physical layer is assured by
adoption of the ASTM PS111-98 physical layer. All active legacy systems
are compatible with the Class A beacon described in PS111-98. The new
Class B downlink frequencies permitted under the ASTM standard, however,
may not be compatible with legacy OBE's. Also, the specification for
Fast Wake-up Time has been eliminated to facilitate the adaptation of
legacy equipment to this specification.

Data Link Layer

Although this document adds new data link layer capabilities, the TDMA
data link structure as defined in "Standard for Dedicated, Short Range,
Two-Way Vehicle to Roadside Communications Equipment, Draft 6," dated 23
February 1996, has been retained. The Draft 6 standard is relaxed in
that only the Wide-Area Frame or "open road" mode is required by this
document. The Lane-Based Frame is not required. To avoid conflicts in
memory usage, both the "internal" and "external" memory commands defined
in the "Draft 6" document have been retained. Internal memory commands
are reserved for legacy operations and IEEE 1455 operations will be
performed using external memory commands.

Legacy Roadside Operations

OBE's developed under this specification are compatible with deployed
systems. Legacy RSE's operating in "open road" mode and using only
internal memory commands will be able to read and write to the internal
memory of FHWA OBE's (consisting of Public ID, Agency Memory, and
General-Use Memory). Because IEEE 1455 operations are isolated in
external memory, legacy RSE's may freely use the internal memory
resources of the FHWA OBE's. The FHWA OBE internal memory has been
reserved for use by legacy systems indefinitely. A FHWA OBE will not
respond to legacy external memory commands.

Legacy On-Board Equipment

Legacy OBE's may be usable by FHWA RSE's. All legacy OBE's will respond
to internal memory commands from FHWA RSE' s using Class A beacons. Some
legacy OBE's, however, may not respond to RSE's using a Class B beacon
because of the higher downlink carrier frequency. Additionally, some
legacy OBE's may suffer an uplink loss because the OBE carrier frequency
is not within the tolerance of this specification. During a transition
period, it is anticipated that sites such as international border
crossings will support both legacy OBE's (with application data in
internal memory) and FHWA OBE's.

[^1]: These commands are supported in broadcast mode.