[Federal Register Volume 64, Number 250 (Thursday, December 30, 1999)]
[Proposed Rules]
[Pages 73674-73742]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 99-33406]


-----------------------------------------------------------------------

DEPARTMENT OF TRANSPORTATION

Federal Highway Administration

23 CFR Part 945

[FHWA Docket No. FHWA 99-5844]
RIN 2125-AE63


Dedicated Short Range Communications In Intelligent 
Transportation Systems (ITS) Commercial Vehicle Operations

AGENCY: Federal Highway Administration (FHWA), DOT.

ACTION: Notice of proposed rulemaking (NPRM); request for comments.

-----------------------------------------------------------------------

SUMMARY: The FHWA proposes to amend its regulations to require use of 
the FHWA Specification for ``Dedicated Short Range Communications 
(DSRC) for Commercial Vehicles'' as a provisional standard for 
Intelligent Transportation Systems (ITS) commercial vehicle projects 
using highway trust funds. The DSRC systems use microwave 
communications over very short distances to allow moving vehicles to 
communicate with roadside locations. In commercial vehicle 
applications, the DSRC devices provide identification of vehicles which 
allows electronic screening of the vehicle, for safety, regulatory 
compliance, and credentials at weigh stations, ports of entry, and 
international border crossings. The use of DSRC standards would promote 
interoperability among, and enable integration of the ITS systems for 
North American commercial vehicle applications. Interoperability 
provided by this provisional standard would also encourage business 
interoperability and cooperation.

DATES: Comments must be received on or before February 28, 2000.

ADDRESSES: Submit written, signed comments to the docket number that 
appears in the heading of this document to the Docket Clerk, U.S. DOT 
Dockets, Room PL-401, 400 Seventh Street, SW., Washington, DC 20590-
0001. All comments received will be available for examination at the 
above address from 9 a.m. to 5 p.m., e.t., Monday through Friday, 
except Federal holidays. Those desiring notification of receipt of 
comments must include a self-addressed, stamped envelope or postcard.

FOR FURTHER INFORMATION CONTACT: Mr. William S. Jones, ITS Joint 
Program Office (JPO), (202) 366-2128, e-mail address 
<[email protected]>; or Mr. Wilbert Baccus, Office of the 
Chief Counsel, (HCC-32) (202) 366-0780, e-mail address 
<[email protected]>, Federal Highway Administration, 400 
Seventh Street, SW., Washington, DC 20590. Office hours are from 7:30 
a.m. to 4 p.m., e.t., Monday through Friday, except Federal holidays.

SUPPLEMENTARY INFORMATION:

Electronic Access

    Internet users may access all comments received by the U.S. DOT 
Dockets, Room PL-401, by using the universal resource locator (URL): 
http://dms.dot.gov. It is available 24 hours each day, 365 days each 
year. Please follow the instructions online for more information and 
help.
    An electronic copy of this document may be downloaded using a 
computer with a modem and suitable communications software from the

[[Page 73675]]

Government Printing Office's Electronic Bulletin Board Service at (202) 
512-1661. Internet users may reach the Office of the Federal Register's 
home page at: http://www.nara.gov/fedreg and the Government Printing 
Office's web page at http://www.access.gpo.gov/nara. The ITS critical 
standards are available online at http://www.its.dot.gov.

Background

    In section 6053(b) of the Intermodal Surface Transportation 
Efficiency Act of 1991 (ISTEA), Public Law 102-240, 105 Stat. 1914, at 
2190, the Congress directed the Secretary of Transportation (Secretary) 
to develop and implement standards and protocols to promote widespread 
use of ITS technology as a component of the Nation's ground 
transportation systems.
    In the Transportation Equity Act for the 21st Century (TEA-21), 
section 5206 of Public Law 105-178, 112 Stat. 107, at 457 (23 U.S.C. 
502 Note), the Congress requires the Department to ``ensure the 
national interoperability'' of ITS services through standards. To carry 
out this mandate, the Congress stated that the Secretary could use the 
services of existing standards-setting organizations, as appropriate. 
The statutory provisions also provide that use of approved standards 
shall be established as a prerequisite for use of highway trust funds 
on certain ITS projects. In addition, the Congress required the 
department to identify all standards that were critical to national 
interoperability. This report was submitted to Congress, and made 
available in July 1999.
    Recently, approved standards issued by the American Society for 
Testing and Materials (ASTM) and the Institute of Electrical and 
Electronics Engineers (IEEE) apply to DSRC systems and devices using 
microwave communications in the 902-928 megahertz (MHz) frequency band. 
The DSRC systems use microwave communications over very short distances 
to allow moving vehicles to communicate with roadside locations. They 
are currently in use for applications, such as, electronic tolling, 
electronic clearance of commercial vehicles at weigh stations.
    As transportation agencies with responsibility for commercial 
vehicle administration and toll collection have procured systems and 
other devices based on the DSRC, they have had to cope with proprietary 
interfaces, which are the interface designs held as industrial secrets 
by equipment suppliers. Selection of a manufacturer by an agency has 
often made that agency a captive market of that manufacturer for 
procurement of future system upgrades and expansions. These agencies 
could only use devices from the initial manufacturer, since only that 
manufacturer would have the correct proprietary interfaces. When 
agencies procure different proprietary DSRC systems, this precludes 
interoperability among these agencies. This limits the usefulness of 
this technology for vehicles that cross jurisdictional boundaries, such 
as, State lines and international borders. Even within States, there 
can be interoperability issues if different agencies purchase from 
different suppliers.
    In TEA-21, the Congress has given the U.S. DOT the responsibility 
to ``ensure national interoperability'' of ITS technologies through the 
development and promulgation of standards. Further, the Congress 
authorized the Secretary to issue ``provisional standards'' when the 
normal consensus standard development process was unsuccessful in 
reaching agreement on a standard.
    There is a clear need for interoperability in at least two 
applications of DSRC technology within the ITS program as follows:
    1. Interstate trucks that participate in the Commercial Vehicle 
Operations (CVO) program, which, for example, will allow vehicles to be 
electronically cleared for operation without stopping at State ports of 
entry or weigh/inspection stations, require national interoperability.
    2. All vehicles, including passenger cars and trucks, in a common 
multitoll environment within a single State or multistate metropolitan 
area, require regional interoperability.
    This rulemaking only addresses the national interoperability 
requirement for commercial vehicle applications of DSRC technology. For 
the CVO program to be successful, it is essential that these vehicles 
be able to travel from State to State, and within a State, using DSRC 
technology for processing at automated inspection stations and to be 
able to bypass State ports of entry if they meet the criteria for 
safety and weight, and possess the appropriate credentials. The only 
way to achieve this fundamental objective is to have a set of DSRC 
standards that all States utilize for their ITS CVO implementations. 
Thus, this application clearly falls within the TEA-21 definition of 
standards ``critical to national interoperability.'' The critical 
standards list defined by the ITS Joint Program Office (JPO), in 
response to TEA-21, includes CVO related standards.
    With the imminent expansion of the CVO program, it is essential 
that the FHWA provide guidance to States that will meet the 
requirements of the law and achieve the minimum objectives of the 
statute. To implement the requirements of TEA-21, and to address the 
current applications of DSRC technology, the FHWA's objective is to 
achieve national interoperability for the ITS CVO applications and 
border crossing functions through the use of a ``Provisional Standard'' 
as defined in TEA-21.
    When using DSRC, vehicles employ devices called tags, or 
transponders to communicate with readers, or roadside units. The 
operation of these devices can be specified with a standards profile 
consisting of three layers: the Physical Layer, the Data Link Layer and 
the Application Layer. (Per the Open Systems Interconnection Reference 
Model.)
    The Physical Layer describes the transmission of data over the 
communications channel, for example, the media, the modulation format, 
the required transmission power and the physical configuration of the 
transmitter and receiver.
    The Data Link Layer describes how the data is reliably and 
efficiently sent over the communications link, which includes framing 
and timing of the data, error control and flow control.
    The Application Layer incorporates the specific user program, which 
in this case, refers to the definition of the various messages that 
must be communicated, such as those pertaining to commercial vehicle 
electronic clearance and international border clearance. This layer 
also potentially permits many other functions to be performed.
    The DSRC systems can achieve interoperability if they conform to 
the same profile, and incorporate the same options within each standard 
that comprise the profile.
    Current DSRC systems employ two different methods at the physical 
layer: backscatter and active. Backscatter systems use tags known as 
passive tags, which do not contain their own transmitter and power 
source. They use the energy received from the reader to generate a 
response. Active tags contain their own power source and transmitter to 
respond to the roadside unit.
    Current DSRC systems also employ two different methods at the data 
link layer: asynchronous and synchronous. In asynchronous transmission, 
normally used in backscatter systems, tags respond to the reader when 
queried, without specific timing established between the tag and the 
reader for the response. In synchronous transmission, normally used on 
active systems, a specific timing is established for a tag to respond 
to a reader. It is the disparity

[[Page 73676]]

in these four options that preclude the interoperability of DSRC 
systems.
    Under the auspices of the ASTM, the industry tried to generate a 
set of standards for DSRC for about eight years. However, because of 
the fundamental differences in implementing the technologies, the 
standards process deadlocked with no agreement attainable until late 
1996, when the DOT became more active in the process.
    The DOT recognized a need to have a standards-based DSRC for use by 
ITS Commercial Vehicle Operation program. This will enable commercial 
vehicles to use a common tag to be electronically processed while in 
motion at weight and inspection stations and at international borders.
    In 1996, the CVO program was expanding due to the model deployments 
and the international border crossing programs. It was essential, 
therefore, that a standard be established. Thus, the DOT urged the 
community to come together and agree on a standard, or the DOT would 
mandate a provisional standard for CVO and border crossing 
applications.
    The work of developing DSRC standards and building consensus among 
the stakeholders has been led by various standards development 
organizations (SDOs) with guidance and partial funding by the 
Department. The new standards development is being led by the ASTM and 
IEEE. The breadth of participation in this development approach has 
ensured the widest possible consensus base for the emerging standards, 
thus ensuring the ready acceptance of the application of these 
standards. This new activity started in 1996. These SDOs have worked 
under a cooperative agreement, with partial funding from the FHWA along 
with voluntary donations of time and travel expenses from committee 
participants, to develop very broad ranging direct user inputs to the 
standards development process in striving for broad consensus on 
requirements.
    In an early attempt to break the standards deadlock, and to respond 
to the needs of the CVO community, Hughes Aircraft (Hughes), now 
Raytheon Systems Company, made public its proprietary protocol. 
Further, many of the CVO sites had already chosen the Hughes protocol 
for their applications. Mark IV Industries agreed to build tags to the 
Hughes protocol, which produced competition among suppliers for a 
single configuration of a tag for the first time. This version was 
submitted to the ASTM standards organization as a candidate standard, 
and was called ``ASTM Version 6.''
    The Version 6 configuration was never approved by the committee. 
However, since the Hughes ``Version 6'' tag was employed in all CVO and 
international border crossing deployments, and it was the only device 
where there were two suppliers to compete in the CVO market, the ASTM 
Version 6 tag was chosen by the DOT as the interim device that would be 
used on all CVO applications until standards were formally adopted by 
the community.
    There appears to be general agreement among the industry and the 
SDOs on the latest version of the application and Physical Layer 
standards, with the Physical Layer now approved by the ASTM, and the 
Application Layer standard (IEEE 1455) approved by the IEEE.
    The Application Layer standard (IEEE P1455) is of particular 
importance. This standard is designed to allow a wide variety of 
applications to be implemented using a single device. Whereas, today, 
virtually all tags are customized to a particular application, e.g., 
tolls or CVO, and it is not easy to add applications. The IEEE standard 
facilitates the use of a single device for multiple applications.
    The DSRC Physical Layer standard allows either active or passive 
technologies, or both, to be used.
    Since all three tag types can be produced, it is likely that 
multiple tag configurations, that are not interoperable, will exist. 
The best way to afford the opportunity for interoperability is for DOT 
to specify a single configuration for a particular application when 
interoperability is required. Because the CVO community already has a 
large installed base, all using the active configuration, the DOT has 
selected the active configuration.
    It is the Data Link Layer where the current standards process is 
stalemated. The current version of this standard allows the two 
fundamentally incompatible protocols, synchronous and asynchronous, to 
exist. Since there is no clear industry agreement on this protocol, 
interoperability can best be achieved by continuing to use the Data 
Link Layer functions found in the legacy systems that conform to ASTM 
Version 6.
    Therefore, the recommended profile is to use a provisional standard 
that consists of the new ASTM Physical Layer in the active mode, the 
existing ASTM Version 6 Data Link layer in the synchronous mode, and 
the IEEE 1455 Application Layer. In addition, this provisional standard 
will be designed to ensure interoperability with the existing legacy 
equipment used in CVO that conforms to ASTM Version 6. This DSRC 
provisional standard is described in the FHWA Specification, 
``Dedicated Short Range Communications for Commercial Vehicles.''

Purpose of this Rulemaking

    In this NPRM, the FHWA proposes to amend its regulations to 
establish rules to ensure application of DSRC standards for CVO 
projects implemented with highway trust funds. The proposed regulations 
would apply DSRC standards to relevant systems, subsystems, devices, 
equipment and software to be acquired as part of those projects.
    This rule covers the DSRC provisional standard defined in the FHWA 
specification for Dedicated Short Range Communications for Commercial 
Vehicles which incorporates the following protocols from existing 
standards efforts:
    (1) ASTM PS 111-98, Standard Specification for Dedicated Short 
Range Communications Physical Layer Using Microwave in the 902-928 MHz 
Band (Active Mode Option),
    (2) ASTM Version 6 data link layer functions, and
    (3) IEEE P1455, Standard for Message Sets for Vehicle/Roadside 
Communication.
    This configuration will be compatible and interoperable with ASTM 
Version 6 legacy CVO installations.

Costs and Benefits of the DSRC Interface Standards

    The DSRC provisional standard includes some of the first protocols 
for wide use in the United States surface transportation industry 
providing for interoperability between products that have typically 
used proprietary interfaces even to the present day. Manufacturers will 
have some costs for developing and incorporating compliant interfaces. 
Only a small part of each of these devices will be affected, so the 
costs will be minimal. Many of these manufacturers have also been 
involved in development of the DSRC standards, thus ensuring that they 
are prepared to provide products that are in conformance.
    On the benefits side, this provisional standard eliminates the need 
to purchase equipment with proprietary interfaces, thus freeing 
agencies of long-term commitments to specific vendors and their systems 
with proprietary interfaces. This standard also enables operation with 
reduced mutual interference, so that co-site and inter-site frequency 
coordination is greatly

[[Page 73677]]

simplified. The application layer portion of the provisional standard 
also makes possible the use of the device for applications other than 
CVO.
    Interoperability will ensure that DSRC-based systems for CVO will 
become interchangeable for identical functions by having identical 
interfaces. This will allow States and carriers to rely on multiple 
manufacturers as sources of interoperable equipment, which would 
provide for increased competitiveness among manufacturers of ITS 
systems and devices. The competitiveness will in turn, encourage 
suppliers to strive for improved quality, functionality, reliability, 
and maintainability at lower cost. The agency specifically requests 
comment on the potential costs and benefits of this proposal.

Interface Compatibility

    The FHWA would establish regulations that require conformance to 
the DSRC provisional standard, which is defined in the FHWA 
specification, ``Dedicated Short Range Communications for Commercial 
Vehicles,'' in CVO systems, subsystems, devices, equipment and software 
being procured in ITS projects using highway trust funds. In this 
proposed action, the interface standards would apply to procurements of 
new equipment, or major upgrades of existing equipment, that occur 
after January 1, 2001.
    There is no intent to require the replacement of, or the 
retrofitting of changes to existing equipment solely to be compatible 
with the DSRC provisional standard. Incorporation of the DSRC 
provisional standard should be an orderly process during the normal 
cycle of replacement of the equipment. This replacement process will be 
at the discretion of the transportation agency. The new DSRC 
provisional standard compliant equipment and the existing DSRC 
equipment used in CVO will operate on the same communications 
facilities.
    This regulation would require that all new or updated equipment, 
for which this standard applies, procured after January 1, 2001, shall 
conform with the FHWA specification, ``Dedicated Short Range 
Communication for Commercial Vehicles.'' This is interpreted as 
applying to any equipment which meets either of the following criteria:
    (1) The specifications for the equipment are still in preparation 
on January 1, 2001 (i.e., specifications have not been approved and 
released to procurement and contracting prior to January 1, 2001).
    (2) The equipment is the subject of an upgrade which is being 
procured after January 1, 2001. This means the specifications for the 
upgrade are still in preparation on January 1, 2001 (i.e., have not 
been approved and released to procurement and contracting prior to 
January 1, 2001).
    There are various potential approaches to achieving DSRC conformity 
that could be utilized. It is the FHWA's objective to eventually have 
all DSRC equipment used for CVO applications conforming with the 
provisional standard. However, the exact path to that objective would 
be at the discretion of the implementing agency.
    To facilitate the compliance process, the FHWA will conduct a 
testing program that will verify that the DSRC provisional standard, as 
embodied in the DSRC specification, performs the required functions and 
is backward compatible with the existing design of CVO DSRC equipment. 
There are no new Federal review processes required for complying with 
this proposed regulation. The specification of applicable standards is 
part of the existing processes which depend on the nature and scope of 
the project.
    The FHWA believes that a federally established process for 
certifying manufacturer product conformance with DSRC standards is not 
necessary, and is left to the States and local agencies procuring the 
technology and their suppliers to determine.

Exemptions From the FHWA DSRC Standards Profile Specification

    As the life cycle of newer ITS non-conforming devices nears an end 
and the transition to the DSRC provisional standard nears completion, 
the regulations would require open systems interfaces to the exclusion 
of proprietary interfaces in ITS systems, subsystems, devices, 
equipment and software implemented with the use of highway trust funds. 
In the specific case of this NPRM, open systems interfaces would be 
interpreted as including interfaces conforming with the FHWA DSRC 
specification. Note that the DSRC provisional standard is a small 
subset of the ITS standards that are soon to become available. Specific 
exemptions to be allowed, or disallowed, regarding the DSRC standards 
conformance requirements proposed in this NPRM are as follows:
    1. Legacy System Exemptions. This policy would allow continued use 
of legacy (existing) devices having proprietary interfaces through 
their useful operating life during this transition to DSRC provisional 
standard conforming interfaces, and until such time as new products 
conforming to the DSRC provisional standard become available as 
commercial off-the-shelf items.
    2. Grandfathered Interface Exemptions. Exemption of proprietary 
interfaces from DSRC provisional standard conformance in any legacy 
device applied to a CVO system would be limited to the useful operating 
life of the device and would not be construed as extending into the 
life of any replacement, upgrade, enhancement, or expansion of the 
legacy device.

Summation

    The DSRC provisional standard is defined in the FHWA specification, 
``Dedicated Short Range Communications for Commercial Vehicles.'' This 
action proposes to implement this specification, which describes the 
Physical Layer standard using the active tag option, the Data Link 
Layer standard in the synchronous option, the Application Layer (IEEE 
1455) standard and backward compatibility with existing ASTM Version 6 
equipment as a prerequisite for highway trust funding of CVO projects. 
Rules are proposed for implementation of this standard, and 
supplementary information is provided to lay this rulemaking open for 
review and comment. In this regulatory process, some choices and 
decisions must be made. Listed below are topics on which the FHWA would 
like inputs, suggestions, or recommendations in order to benefit from 
the experience and knowledge of State and local agencies, system 
operators, carriers, and in the vendor community.
    (1) The FHWA requests comments on when the rules described in this 
NPRM should become effective and the reasons for that recommendation.
    (2) The FHWA requests recommendations on how to achieve compliance 
with the described rules by the State and/or local agencies involved in 
commercial vehicle operations.
    (3) The FHWA requests recommendations on whether or how to verify 
compliance with the described rules by the manufacturers.
    (4) The FHWA requests recommendations on how to address the 
problems of products that are represented as conforming to the DSRC 
standards, but do not prove to be interoperable when they are operated 
with legacy equipment or other DSRC equipment. The FHWA seeks to 
establish interoperability and to avoid litigation to resolve issues.
    (5) Assumptions have been made in the Regulatory Evaluation 
contained in the regulatory analysis for Executive Order 12866, 
Regulatory Planning and

[[Page 73678]]

Review. The FHWA would like to receive comments on the validity of 
those assumptions, along with reasoning and explanations for them.
    (6) The FHWA seeks comments on a possible limitation period for 
completion of the transition from the proprietary interfaces with 
legacy devices to interfaces that fully conform with the DSRC 
provisional standard.
    (7) The FHWA seeks comments from the manufacturers concerning the 
costs, both to the manufacturer and their customers, of complying with 
the rules described in this NPRM. Information concerning costs of both 
a one-time nature as well as potential recurring costs are sought.

Rulemaking Analyses and Notices

    All comments received before the close of business on the comment 
closing date indicated above will be considered and will be available 
for examination in the docket at the above address. Comments received 
after the comment closing date will be filed in the docket and will be 
considered to the extent practicable, but the FHWA may issue a rule at 
any time after the close of the comment period. In addition to late 
comments, the FHWA will also continue to file in the docket, relevant 
information that becomes available after the comment period closing 
date. Interested persons should continue to examine the docket for new 
material.

Executive Order 12866 (Regulatory Planning and Review) and DOT 
Regulatory Policies and Procedures

    The FHWA has determined that this action is not a significant 
regulatory action within the meaning of Executive Order 12866 or 
significant within the meaning of Department of Transportation 
regulatory policies and procedures. It is anticipated that the economic 
impact of this rulemaking will be minimal, therefore, a full regulatory 
evaluation is not required. The implementation of these standards will 
not alter the functionality of the DSRC equipment, both the reader on 
the roadside and the tag on the vehicle. The recurring cost of these 
devices should be virtually the same as State governments are now 
paying for existing equipment. We do not anticipate any significant 
economic impact of the regulation proposed in this rulemaking document. 
Nevertheless, the FHWA solicits comments, information, and data on this 
issue.

Regulatory Flexibility Act

    In compliance with the Regulatory Flexibility Act (5 U.S.C. 601-
612), the FHWA has evaluated the effects of this rule on small 
entities. Based on that evaluation, the FHWA hereby certifies that this 
action will not have a significant economic impact on a substantial 
number of small entities. Any impact to small entities would likely be 
a positive one, due to the resulting ability of these entities to 
compete in the open market for ITS system integration work and other 
engineering services and to develop and market DSRC standards 
conforming devices useful in CVO deployment. Large corporations, 
through sales of their proprietary products and proprietary interfaces 
have previously dominated this market. Previously, large corporations 
that owned the proprietary interface designs were the only 
organizations able to manufacture, install, integrate, and service 
equipment with the proprietary interfaces. Although the large 
corporations may experience a small loss of engineering services 
business, this will be more than compensated for by the increased 
marketability of their DSRC standards profile-conforming products in 
the growing national ITS industry.

Unfunded Mandates Reform Act of 1995

    This proposed rule would not impose a Federal mandate resulting in 
the expenditure by State, local, and tribal governments, in the 
aggregate, or by the private sector, of $100 million or more in any one 
year (2 U.S.C. 1531 et seq.).

Executive Order 13132 (Federalism)

    This action has been analyzed in accordance with the principles and 
criteria contained in Executive Order 13132 dated August 4, 1999, and 
it has been determined this action does not have a substantial direct 
effect or sufficient federalism implications on States that would limit 
the policymaking discretion of the States. Nothing in this document 
directly preempts any State law or regulation.

Executive Order 12988 (Civil Justice Reform)

    This action meets applicable standards in sections 3(a) and 3(b)(2) 
of Executive Order 12988, Civil Justice Reform, to minimize litigation, 
eliminate ambiguity, and reduce burden.

Executive Order 13045 (Protection of Children)

    We have analyzed this action under Executive Order 13045, 
Protection of Children from Environmental Health Risks and Safety 
Risks. This rule is not an economically significant rule and does not 
concern an environmental risk to health or safety that may 
disproportionately affect children.

Executive Order 12630 (Taking of Private Property)

    This rule will not effect a taking of private property or otherwise 
have taking implications under Executive Order 12630, Governmental 
Actions and Interference with Constitutionally Protected Property 
Rights.

Executive Order 12372 (Intergovernmental Review)

    Catalog of Federal Domestic Assistance Program Number 20.205, 
Highway Planning and Construction. The regulations implementing 
Executive Order 12372 and amendments thereto regarding 
intergovernmental consultation on Federal programs and activities apply 
to this program. Those regulations stipulate that Federal agencies 
shall provide opportunities for consultation by elected officials of 
State and local governments that would provide non-Federal funds for, 
or that would be directly affected by, proposed Federal assistance or 
direct Federal development. The regulations further state that the 
Federal agencies must communicate with the appropriate State and local 
officials as early in the program planning cycle as is reasonably 
feasible to explain specific plans and actions.
    Since members of the ASTM, the IEEE, and the DSRC industry 
participated in establishing the need for the DSRC standards, in 
defining the requirements for the DSRC standards, and in development 
and approval of the DSRC standards, it is clear that requirements of 
the intergovernmental review regulations have been satisfied. In 
addition, the FHWA and ITS America have made information about the 
standards program and the standards widely and publicly available. 
Furthermore, publication of this action with request for comments 
further coordinates the action and opens the action to review and 
comment.

Paperwork Reduction Act

    Under the Paperwork Reduction Act of 1995 (PRA) [44 U.S.C. 3501-
3520], Federal agencies must determine whether requirements contained 
in proposed rulemaking are subject to the information collection 
provisions of the PRA. The FHWA has determined that this proposed 
regulation does not constitute an information collection within the 
scope or meaning of the PRA. Implementation of this proposal would 
impose no paperwork burden on the States or private entities. The 
proposal merely sets forth the DSRC

[[Page 73679]]

interoperability standards for devices that collect the vehicle data 
that is already being transmitted either electronically, visually, or 
otherwise. As for the States assuring that vendors of the devices 
comply with these standards, the FHWA is not imposing any formal 
certification process on them. The States may accomplish assurances of 
vendor compliance as part of their usual and customary processes that 
they would adopt to implement the requirements of any Federal 
regulation.

United States International Trade Policy

    The agency has analyzed the impact of this rulemaking on United 
States trade in accordance with Executive Order 12661 and finds no 
significant detrimental impacts on United States international trade 
policy.

National Environmental Policy Act

    The agency has analyzed this action for the purpose of the National 
Environmental Policy Act of 1969 (42 U.S.C. 4321 et seq.) and has 
determined that this action would not have any effect on the quality of 
the environment.

Regulation Identification Number

    A regulation identification number (RIN) is assigned to each 
regulatory action listed in the Unified Agenda of Federal Regulations. 
The Regulatory Information Service Center publishes the Unified Agenda 
in April and October of each year. The RIN contained in the heading of 
this document can be used to cross reference this action with the 
Unified Agenda.

List of Subjects in 23 CFR Part 945

    Communications, Highways and roads, Radio, Transportation-
intelligent systems.

    Issued on: December 15, 1999.
Kenneth R. Wykle,
Federal Highway Administrator.
    In consideration of the foregoing, the FHWA proposes to amend 23 
CFR chapter I by establishing a new subchapter K consisting of part 945 
as follows:

SUBCHAPTER K--TRANSPORTATION OPERATIONS AND MANAGEMENT

PART 945--DEDICATED SHORT RANGE COMMUNICATIONS (DSRC) FOR 
COMMERCIAL VEHICLES

Sec.
945.1  Purpose.
945.3  Applicability and scope.
945.5  Definitions.
945.7  Policy.
945.9  Exemptions from the provisional standard.
Appendix A to Part 945--Specification for Dedicated Short Range 
Communications for Commercial Vehicles.

    Authority: 23 U.S.C.315, and 502 note; sec. 6053(b), Pub. L. 
102-240, 105 Stat. 1914, at 2190; sec. 5206(e), Pub. L. 105-178, 112 
Stat. 107, at 457; and 49 CFR 1.48.


Sec. 945.1  Purpose.

    The purpose of this part is to define the provisional standard that 
will be utilized to ensure national interoperability of all commercial 
vehicle operation (CVO) projects that incorporate Dedicated Short Range 
Communications (DSRC) technology.


Sec. 945.3  Applicability and scope.

    (a) The specification ``Dedicated Short Range Communications for 
Commercial Vehicles'' shall be used on all commercial vehicle projects 
and international border crossing projects utilizing DSRC that are 
procured after January 1, 2001, and utilize funds from the highway 
trust fund.
    (b) Procurement funds are for new equipment, whether it be 
replacement of existing equipment or new installations.
    (c) This part does not require the retrofitting or replacement of 
existing equipment to be compliant with the provisional standard.
    (d) This provisional standard does not apply to other applications 
of DSRC technology, such as electronic toll collection.


Sec. 945.5  Definitions.

    (a) The terms used in this part are consistent with those commonly 
used in the standards community as defined by the Institute of 
Transportation Engineers (ITE).
    (b) The terms that are unique to Intelligent Transportation Systems 
(ITS) are defined as follows:
    Commercial Vehicle Operations (CVO) means any ITS project that 
includes all the operations associated with moving goods and passengers 
via commercial vehicles over the North American highway system and the 
activities necessary to regulate these operations.
    Dedicated Short Range Communications (DSRC) means a technology 
employing microwave communications over very short distances to allow 
moving vehicles to communicate with fixed roadside locations.
    Provisional standard means a specification prescribed by the U.S. 
DOT. In this instance the specification is ``Dedicated Short Range 
Communications for Commercial Vehicles.''


Sec. 945.7  Policy.

    It is the policy of the Federal Highway Administration (FHWA) to 
identify the standards that are critical to ensure national 
interoperability. Commercial vehicle applications that enable 
electronic screening, including checking safety status, and other 
credentials associated with the licencing and regulation of commercial 
carriers shall use equipment that conforms to the FHWA specification 
for Dedicated Short Range Communications for Commercial Vehicles, as 
provided in the appendix to this part.


Sec. 945.9  Exemptions from the provisional standard.

    The specification, ``Dedicated Short Range Communications for 
Commercial Vehicles'' does not apply to future implementations of, or 
the current standard effort operating in the 5.8 gigahertz frequency 
band.

[[Page 73680]]

Appendix A to Part 945 Specification for Dedicated Short Range 
Communications (DSRC) for Commercial Vehicles--November 1999

Ver  0.0.1

Federal Highway Administration

United States Department of Transportation, Federal Highway 
Administration, Intelligent Transportation Systems Joint Program Office

Contents

1  Overview
2  Background Information
3  Physical Layer
4  Data Link Layer
5  Transponder Resources
6  Transponder Commands and Memory Access
7  Resource Manager
8  ITS Application Messages
9  Application Layer
Attachment A  Compatibility Philosophy

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.

[[Page 73681]]

    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.

[[Page 73682]]

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

------------------------------------------------------------------------
                        Frequency Deviation (+/-
                                   )                   Attenuation
------------------------------------------------------------------------
Class A:                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:                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.

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

------------------------------------------------------------------------
             Parameter                              Value
------------------------------------------------------------------------
Class A&B:
    Maximum `off' carrier to        0.103
     minimum `on' carrier ratio.

[[Page 73683]]

 
    Maximum `on' carrier to         1.14
     minimum `on' carrier ratio.
    \1/2\ 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.
     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 deg. to 
+75 deg. C continuous and up to +85 deg. 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: 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.

[[Page 73684]]

    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'         0.103
                               carrier to minimum
                               `on' carrier ratio.
                              Maximum `on' carrier  1.14
                               to minimum `on'
                               carrier ratio.
                              \1/2\ of bit period.  1 microsecond
                              Allowed time          165 nanoseconds
                               variance.
------------------------------------------------------------------------

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 
simulta

[[Page 73685]]

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

BILLING CODE 4910-22-P

[[Page 73686]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.028



BILLING CODE 4910-22-C

[[Page 73687]]

    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 facilitate 
the transfer of large data files (see section 4.8.5).

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 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 Originated Slot Data 
Message (SDM) or Acknowledgement--40sec
 Preceding each Transponder-Originated SDM or Acknowledgement--
100sec
4.6.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:


[[Page 73688]]


 Prior to the FCM--375 bits
 Prior to each Reader-Originated Acknowledgement Message--30 
bits
 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.

------------------------------------------------------------------------
                                                                Binary
               Field definition                   No. bits      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            -
                                               -------------
    Total bits................................          272
------------------------------------------------------------------------

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

------------------------------------------------------------------------
                                                                Binary
               Field definition                   No. bits      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            -
                                               -------------
    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. 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
                                          -------------
    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

[[Page 73689]]

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. 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
                                          -------------
    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. bits     Binary value
------------------------------------------------------------------------
Header Code:
    Selsyn...............................            8  01010101
    Flag.................................            8  10001101
Transponder Type.........................            4  ................
Message Type.............................            4  0010
Transponder ID...........................           32  ................
CRC......................................           16
                                          -------------
    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:

----------------------------------------------------------------------------------------------------------------
                                                                                                      Activation
                                                                                                     probability
                                                Code                                                     (in
                                                                                                       percent)
----------------------------------------------------------------------------------------------------------------
00                                                                                                           100
01                                                                                                            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''.
4.8.3  Frame Control
    This 4-bit field identifies the type of beacon protocol and 
activation control.

------------------------------------------------------------------------
                 Bit                     Code          Definition
------------------------------------------------------------------------
3....................................        1  Wide Area Frame
                                             0  Lane-Based Frame (not
                                                 used under CVO
                                                 protocol)
2....................................        1  Transponder Activation
                                                 Inhibited
                                             0  Transponder Activation
                                                 Enabled
1....................................        1  External Activation
                                                 Inhibited
                                             0  External Activation
                                                 Enabled

[[Page 73690]]

 
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.
4.8.3.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.8.3.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.
4.8.3.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.
4.8.3.6  Normal TDMA Framing--If Bit 0 = 0, then remaining Frame 
Control field bits define normal protocol operation as shown in Figure 
A-1.
4.8.3.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.
4.8.4  Message Type
    This 4-bit field identifies the specific type of DSRC message. The 
bits are coded as follows:

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

[[Page 73691]]

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 Kbytes 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 Number                      7                   6                   5                   4                   3                   2                   1                   0
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
First Byte......................  FC................  S.................  C/R...............  F.................  A.................  Frag10............  Frag9.............  Frag8
Second Byte.....................  Frag7.............  Frag6.............  Frag5.............  Frag4.............  Frag3.............  Frag2.............  Frag1.............  Frag0
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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              Bit             Coding
------------------------------------------------------------------------
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                                          Code            Definition
----------------------------------------------------------------------------------------------------------------
7........................................................................  1............  Transmit Message to
                                                                                           Beacon
                                                                           0............  Receiver Message from
                                                                                           Beacon
6........................................................................  1............  Acknowledge Message
                                                                           0............  Unacknowledged Message
5........................................................................  1............  Last Frame of
                                                                                           Transaction
                                                                           0............  Transaction Not
                                                                                           Complete
4........................................................................  1............  Internal Memory/
                                                                                           Application

[[Page 73692]]

 
                                                                           0............  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                              Definition
------------------------------------------------------------------------
00...........................  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.

[[Page 73693]]

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                                          Code            Definition
----------------------------------------------------------------------------------------------------------------
3........................................................................  1............  Open-Road Frame
                                                                                           capable
                                                                           0............  Open-Road or Lane-
                                                                                           Based capable
2........................................................................  1............  Anonymous Link Entry
                                                                                           (Use Random ID for
                                                                                           Transponder ID)
                                                                           0............  Public Link Entry (Use
                                                                                           Public ID for
                                                                                           Transponder ID)
1,0......................................................................  00...........  Extended Protocol
                                                                                           Capable \1\
                                                                           01...........  Internal Read-Only
                                                                           10...........  Internal Read/Write
                                                                           11...........  Internal and External
                                                                                           Read/Write
----------------------------------------------------------------------------------------------------------------
\1\ 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.

4.9.1.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.
4.9.1.2  Protocol flowcharts are shown in Figures 4.9.1.2-1 through 
4.9.1.2-4.
BILLING CODE 4910-22-P 

[[Page 73694]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.029

 

[[Page 73695]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.030

 

[[Page 73696]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.031

 

[[Page 73697]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.032



[[Page 73698]]

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

[[Page 73699]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.033



[[Page 73700]]

    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.
4.9.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.
4.9.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.
4.9.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 size
               Field definition                    (bits)     Bit mumber
------------------------------------------------------------------------
Public ID.....................................           32      480-511
All Zeros.....................................           32      448-479
Agency Memory Contents........................          192      256-447
General-Use Memory Contents...................          256        0-255
------------------------------------------------------------------------

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

[[Page 73701]]

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

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

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

[[Page 73702]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.034



BILLING CODE 4910-22-C
5.1.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.
5.1.2  Controller
    The controller shall interpret and implement commands (listed in 
Section 6) when received across the wireless 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.
5.1.3  External interface
    Compliant transponders may provide an external interface. The 
availability and characteristics of this interface shall be indicated 
in the read-only memory (as defined in 5.2). If implemented, this 
interface shall provide other pieces of OBE with access to the 
transponder's resources and through those resources provide 
communications with the roadside.

[[Page 73703]]

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.
5.1.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, 
commands 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 transponder, 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.
------------------------------------------------------------------------

5.1.5  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 commands 
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 
memory 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

[[Page 73704]]

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 Configuration 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 identifier             OBE address       Message length     Error detect code     Message 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                   Field name            Type              Length               Values
----------------------------------------------------------------------------------------------------------------
1..............................  Message Identifer  Integer..........  8 bits...........  hex 01, other values
                                                                                           are reserved for
                                                                                           future use.
2..............................  OBE Address......  Bit String.......  32 bits..........  Vehicle bus address,
                                                                                           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 Code  Bit String.......  8 bits...........  XOR Checksum of the
                                                                                           Message Body.
5..............................  Message Body.....  Octet String.....  1 to 65636 bytes.  binary data.
----------------------------------------------------------------------------------------------------------------

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

[[Page 73705]]

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 Interface command specified in 6.4.6. Character readout
    Compliant transponders may provide a digital readout. The 
availability of a digital readout shall be as indicated in the read-
only memory, as defined in 5.2. The digital readout is controlled using 
the Set User Interface 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 (bits)       Length (bits)        Specification and description
----------------------------------------------------------------------------------------------------------------
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 Applications...........  16-23...............  8..................  Number of applications in the
                                                                               applications list = hex (1).
Application Identifier (AID).....  24-31...............  8..................  Mailbox AID = hex (D).
EID/Revision Level...............  32-39...............  8..................  EID; shall be used for the IEEE
                                                                               Std 1455-1999 revision level.
Container Tag....................  40-47...............  8..................  Octet string tag = hex (4); used
                                                                               to encapsulate the VST parameter.
Octet String Length..............  48-55...............  8..................  The actual length (in octets) of
                                                                               the subsequent data in the octet
                                                                               string.
Octet String Data................  ....................  Includes following   An octet string used for ASN.1
                                                          fields.              compliance, which comprises the
                                                                               subsequent fields defined in this
                                                                               table.
Returned Pages Flag..............  56-57...............  2..................  Bits that correspond to the two
                                                                               memory images returned, as
                                                                               specified in the BST.
Reserved 1.......................  58-60...............  3..................  Reserved by IEEE for future use.
Memory Configuration.............  61-63...............  3..................  Defines the availability of
                                                                               various memory regions.
Transponder Configuration........  64-71...............  8..................  Defines the availability of
                                                                               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 Type...............  88-91...............  4..................  Indicates how the serial number
                                                                               and manufacturer identifier
                                                                               should be interpreted.
Manufacturer Identifier..........  92-107..............  16.................  Identifies the manufacturer of 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 A of 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.

[[Page 73706]]



               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 purpose 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 transponder and, therefore, 
which memory pages are being returned as part of the VST. This field 
shall be interpreted 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).
5.2.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.

[[Page 73707]]



      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 (sample 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 Number
                                          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 Manufacturer Identifier field 
value. The method of assigning values to this field shall be entirely 
controlled by the manufacturer.

[[Page 73708]]

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 Number 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 implemented 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 messages. 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 transaction
         Command identifier                identifier            Command length      Access control length      Access control       Command parameter
--------------------------------------------------------------------------------------------------------------------------------------------------------
1 byte.............................  1 byte................  2 bytes...............  1 byte...............  1 to 32 bytes........  Variable.
--------------------------------------------------------------------------------------------------------------------------------------------------------

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 credentials 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 credentials          Meaning             OBE command support
----------------------------------------------------------------------------------------------------------------
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.

[[Page 73709]]

 
Hex (11)...........................  Hex (91)..............  Write Memory Page.....  Optional \1\ (required if
                                                                                      read/write memory is
                                                                                      present).
Hex (12)...........................  Hex (92)..............  Append Message........  Optional \1\ (required if
                                                                                      read/write memory is
                                                                                      present).
Hex (13)...........................  Hex (93)..............  Initialize Circular     Optional (required for
                                                              Queue.                  circular queues).
Hex (14)...........................  Hex (94)..............  Write Circular Queue..  Optional * (required for
                                                                                      circular queues).
Hex (15) .. (1F)...................  Hex (95) .. (9F)......  Reserved..............  ...........................
Hex (20)...........................  Hex (A0)..............  Set User Interface....  Optional * (required if OBE
                                                                                      has UI).
Hex (21)...........................  Hex (A1)..............  Map User Interface....  Optional.
Hex (22 .. 2F).....................  Hex (A2 .. AF)........  Reserved..............  ...........................
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 (required if
                                                              Configuration.          Reserve Memory Page
                                                                                      command is implemented).
Hex (43)...........................  Hex (C3)..............  Reserve Memory          Optional.
                                                              Partition.
Hex (44) Hex (C4)..................  Release Memory          Optional..............
                                      Partition.
                                     xlD                     (required if Reserve
                                                              Memory Partition
                                                              command is
                                                              implemented).
Hex (45 .. 6F).....................  Hex (C5 .. EF)........  Reserved..............  ...........................
Hex (70 .. 7F).....................  Hex (F0 .. FF)........  Available for           Optional--shall not be used
                                                              manufacturer-specific   in production units
                                                              testing.                deployed in the field.
----------------------------------------------------------------------------------------------------------------
\1\ These commands are supported in broadcast mode.

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.

[[Page 73710]]

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.

6.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 
appropriate 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 RegisterApplicationBeacon service in the 
application layer. This registration causes the RSE application layer 
to construct a BST and initiate communication with potential OBE 
transponders.
    (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 command 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 information flow 
shall be observed:
    (a) The resource manager may use the BroadcastData.request service 
of the RSE application layer to broadcast to the OBE.
    (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 multiple transponders are within the 
communications zone at the time of transmission. The OBE transponder 
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.
6.4.1.1  Command set definition
    The Read Memory Page command shall consist of the fields shown in 
Table 6.4.1.1-1.

[[Page 73711]]



                                Table 6.4.1.1-1.--Read Memory Page Command Fields
----------------------------------------------------------------------------------------------------------------
          Field name               Location (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  hex (10) / Hex (90).
Command transaction Identifier  1.....................  1.....................  Identifies an instance of a
                                                                                 command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes. A nonzero
                                                                                 value indicates that the Page
                                                                                 Identifier field will be offset
                                                                                 by the indicated number of
                                                                                 bytes (max. 32).
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  2.....................  Identifies referenced memory
                                Control field + 1.....                           page (as per specification in
                                                                                 Table E.2).
Page identifier...............  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 (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (11) / Hex (91).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  2.....................  Identifies referenced memory
                                Control field + 1.....                           page (as per specification in
                                                                                 Table E.2).
Page identifier...............  End of Access.........                          ................................
                                Control field + 2 xl..
Memory image..................  End of Access.........  ......................  The information that shall
                                ......................                           consist of sequenced messages
                                Control field + 3 .. n                           followed by zero-fill bytes or
                                                                                 an End Of Data message
                                                                                 identifier. The length of this
                                                                                 image is only constrained by
                                                                                 the maximum command 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 referenced agency memory page.

[[Page 73712]]

    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 previously 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 (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (12) / Hex (92).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional). Number of access
                                                                                 credential bytes.
Access Control................  5 .. n................  0/1 .. 32.............  (Optional). Access credentials.
Command parameter.............  End of Access.........  2.....................  Identifies referenced memory
                                Control field + 1.....                           page (as per specification in
                                                                                 Table E.2).
Page identifier...............  End of Access.........                          ................................
                                Control field + 2.....
Message Image.................  End of Access.........  ......................  The information that shall be
                                Control field + 3 .. n                           appended to the specified
                                                                                 memory page.
----------------------------------------------------------------------------------------------------------------

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 specified 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
6.4.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
----------------------------------------------------------------------------------------------------------------
          Field name               Location (bytes)         Length (bytes)        Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (13) / Hex (93).

[[Page 73713]]

 
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  2.....................  Identifies referenced memory
                                Control field + 1.....                           page (as per specification in
                                                                                 Table E.2).
Page identifier...............  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
----------------------------------------------------------------------------------------------------------------
          Field name               Location (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (14) / Hex (94).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  2.....................  Identifies referenced memory
                                Control field + 1.....                           page (as per specification in
                                                                                 Table E.2).
Page identifier...............  End of Access.........                          ................................
                                Control field + 2.....
Message image.................  End of Access.........  ......................  The information that shall be
                                Control field 3 .. n..                           written to the end of the
                                                                                 circular queue in the specified
                                                                                 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 circular 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.

[[Page 73714]]

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 I11The 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
----------------------------------------------------------------------------------------------------------------
          Field name               Location (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (20) / Hex (A0).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
Command length................  2 .. 3................  2.....................  Defines the total (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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  2.....................  Each command will affect only
                                Control field + 1.....                           the addressed elements defined
                                                                                 as follows:
User interface element........  End of Access.........  ......................  Bit 0: Red lamp.
                                Control field + 2.....                          Bit 1: Yellow lamp.
                                                                                Bit 2: Green lamp.
                                                                                Bit 3: Enunciator.
                                                                                Bit 4: Character display.
                                                                                Bits 5-15: Additional UI
                                                                                 elements.
Type (ObeUICmdType)...........  End of Access.........  1.....................  AbsoluteOff (0),
                                Control field + 3.....                          AbsoluteOn (1),
                                                                                TimedCommand (2),
                                                                                Flashing Command (3),
                                                                                Reserved (4 .. 255).
Attributes:...................  End of Access.........  0.....................  (Unused for Absolute Command).
                                Control field + 4 .. n
Absolute command (0 bytes)....  Control field + 4 .. n  2.....................  Time period in 125 ms
                                                                                 increments.
Timed command (2 bytes).......                          4.....................  Cycle state bitmap, 125 ms per
                                                                                 bit.
Flashing Command (5 bytes)....                          1.....................  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. Turns the addressed UI element off. State 
is maintained until changed by a subsequent command.
    --Absolute On command. Turns the addressed UI element on. State is 
maintained until changed by a subsequent command.
    --Timed command. Turns the addressed UI element on for a specified 
period of time. The time period is specified in 125 ms increments.
    --Flashing command. 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

[[Page 73715]]

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 command 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 component. This reservation shall include 
the establishment of access control procedures. Mapping a page of 
memory 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.
6.4.7.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 (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (21) / Hex (A1).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credentials bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  1.....................  Defines the UI element to be
                                Control field + 1.....                           mapped.
User interface element........  ......................  ......................  0: Keypad.
                                                                                1: Character Display.
                                                                                2: Enunciator voice 1.
                                                                                3-255: Reserved for additional
                                                                                 UI elements.
Page identifier...............  End of Access.........  2.....................  Identifies referenced memory
                                Control field + 2.....                           page (as per specification in
                                                                                 Table 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 element. 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.

[[Page 73716]]



                          Table 6.4.8.1-1 Sleep Transponder Command Fields (continued)
----------------------------------------------------------------------------------------------------------------
          Field name               Location (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (30) / Hex (B0).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter:............  End of Access.........  2.....................  Sleep time duration in 125 ms
                                Control field + 1.....                           increments.
Sleep duration................  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 (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (40) / Hex (C0).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Partition identifier..........  End of Access.........  2.....................  Specifies the partition
                                Control field + 1.....                           identifier in which the memory
                                End of Access.........                           shall be allocated (as per
                                Control field + 2.....                           specification in Table E.1). A
                                                                                 value of 0 implies that the
                                                                                 page shall be allocated within
                                                                                 unpartitioned memory.
Command parameter.............  End of Access.........  2.....................  Length (in bytes) of the memory
                                Control field + 3.....                           page that is requested.
Page size.....................  End of Access.........                          ................................
                                Control field + 4.....
Page identifier...............  End of Access.........  2.....................  Specifies the page identifier
                                Control field + 5.....                           that will be associated with
                                End of Access.........                           the allocated memory (as per
                                Control field + 6.....                           specification in Table E.2).

[[Page 73717]]

 
Page access credential type     (End of Page..........  0/1...................  (Optional.) Bits 0 .. 1 indicate
 and length.                    Identifier field + 1).                           the access credential scope:
                                                                                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 credentials.......  (End of Access          0/1 .. 32.............  (Optional.) Access credentials
                                 Credential Type and                             that shall be applied to
                                 Length + 1 .. n).                               reserved page.
----------------------------------------------------------------------------------------------------------------

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 available 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 (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (41) / Hex (C1).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credentials bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  2.....................  Identifies referenced memory
                                Control field + 1.....                           page (as per specification in
                                                                                 Table E.2).
Page identifier...............  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 returning 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.
6.4.10.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 73718]]

--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 memory 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 (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (42) / Hex (C2).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  (4)...................  0/1...................  (Optional.) Number of access
                                                                                 credentials 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
----------------------------------------------------------------------------------------------------------------
          Field Name               Location (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (43) / Hex (C3).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credential bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter:............  End of Access.........  2.....................  Length (in bytes) of the memory
                                Control field + 1.....                           partition that is requested.
Partition size................  End of Access.........                          ................................
                                Control field + 2.....

[[Page 73719]]

 
Partition identifier..........  End of Access.........  2.....................  Identifies the partition
                                Control field + 3.....                           identifier that will be
                                End of Access Control                            associated with this request;
                                 field + 4.                                      Table 1 defines the valid range
                                                                                 of values for partition
                                                                                 identifiers.
Partition access credential     (End of Partition       0/1...................  (Optional.) Number of access
 length.                         Identifier field + 3                            credential bytes that shall be
                                 ).                                              applied to this partition; max
                                                                                 value = 32.
Partition access credentials..  (End of Partition       0/1 .. 32.............  (Optional.) Access credentials
                                 Access Credential                               that shall be required when
                                 Type field + 1.. n ).                           reserving memory pages within
                                                                                 this partition.
----------------------------------------------------------------------------------------------------------------

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 partition 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 previously 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 (bytes)             Length            Specification and description
----------------------------------------------------------------------------------------------------------------
Command identifier............  0.....................  1.....................  Hex (44) / Hex (C4).
Command transaction identifier  1.....................  1.....................  Uniquely identifies an instance
                                                                                 of a command.
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 length.........  4.....................  0/1...................  (Optional.) Number of access
                                                                                 credentials bytes.
Access control................  5 .. n................  0/1 .. 32.............  (Optional.) Access credentials.
Command parameter.............  End of Access.........  2.....................  Identifies the partition
                                Control field + 1.....                           identifier that will be
                                                                                 associated with this request;
                                                                                 Table E.1 defines the valid
                                                                                 range of values for partition
                                                                                 identifiers.
Partition identifier..........  End of Access.........                          ................................
                                Control 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

[[Page 73720]]

--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 command identifier        transaction          Response          Response data       Response data
                                      identifier          identifier            length
----------------------------------------------------------------------------------------------------------------
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 Command Success. All other values indicate failure conditions.

              Table 6.5.3.4-1.--Response Identifier Values
------------------------------------------------------------------------
                                                      Specification and
        Response name                 Value              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 Recognized......  hex (3).............  The command was
                                                     invalid or
                                                     unsupported by the
                                                     OBE. This response
                                                     is used if the RSE
                                                     references a UI
                                                     element that is not
                                                     present on a
                                                     transponder.
Access Control Error........  hex (4).............  Access credentials
                                                     may not have been
                                                     supplied in a
                                                     required situation
                                                     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.

[[Page 73721]]

 
Partition Not Defined.......  hex (6).............  The partition
                                                     identifier does not
                                                     match an existing
                                                     partition in the
                                                     OBE.
Device Error................  hex (7).............  A malfunction has
                                                     occurred in the OBE
                                                     hardware or
                                                     software.
Memory Access Error.........  hex (8).............  The requested memory
                                                     is faulty.
Page Length Mismatch........  hex (9).............  The length of the
                                                     memory image is
                                                     greater than the
                                                     length of the
                                                     referenced memory
                                                     page, or command
                                                     execution would
                                                     require crossing a
                                                     page boundary.
Insufficient Memory.........  hex (A).............  Available free
                                                     memory is
                                                     insufficient in the
                                                     referenced page to
                                                     perform the
                                                     command.
Previously Reserved.........  hex (B).............  The specified page
                                                     or partition
                                                     identifier has
                                                     already been
                                                     reserved by a
                                                     previous Reserve
                                                     command.
Reserved....................  hex (C .. EF).......  Reserved.
Vendor Area.................  hex (F0 .. FF)......  Available for vendor-
                                                     specific failure
                                                     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 configuration 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.
    (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.

[[Page 73722]]

    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. Interoperable 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.
6.7.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.
    (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 
manager shall be the initiator of all commands to the OBE controller, 
acting as the master in a master-slave relationship. The functional 
relationships are illustrated in Figure 7-1.


[[Page 73723]]

[GRAPHIC] [TIFF OMITTED] TP30DE99.035



BILLING CODE 4910-22-C
    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. Compliant 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.
    (b) The resource manager shall then communicate with the connected 
beacons to configure each beacon'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 transponder. 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 information contained within the memory 
images to the BOAs that have registered for it.

[[Page 73724]]

    (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 memory 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 manipulated. 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 information type            Description and usage
------------------------------------------------------------------------
Unique Identifiers of Interest....  Specifies a set of transponders that
                                     are of interest to the registering
                                     application; data reports shall be
                                     made to the BOA only for
                                     transponders with included unique
                                     identifiers.
Unique Identifiers Not of Interest  Specifies a set of transponders that
                                     are not of interest to the
                                     registering application; data
                                     reports shall never be made to the
                                     BOA for transponders with included
                                     unique identifiers.
Service Agencies of Interest......  Specifies a set of service agencies
                                     that are of interest to the
                                     registering application; data
                                     reports shall be made to the BOA
                                     only for transponders with included
                                     service agencies.
Service Agencies Not of Interest..  Specifies a set of service agencies
                                     that are not of interest to the
                                     registering application; data
                                     reports shall never be made to the
                                     BOA for transponders with included
                                     service agencies.
Beacon Identifiers................  Specifies a set of beacon
                                     identifiers that are of 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 Identifiers...............  Specifies a set of message
                                     identifiers that are of interest to
                                     the registering application; only
                                     those messages identifiers
                                     registered by the BOA shall be
                                     reported to the BOA when a
                                     transponder communicates with a
                                     beacon.
Transponder Resources.............  Specifies a set of transponder
                                     resources, such as 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 Identifiers...........  Specifies a set of transponder
                                     memory pages that are 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

[[Page 73725]]

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 reformatted 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.
    (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 accomplish 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 communicating transponder, the BOA may choose 
to manipulate the transponder's UI. The resource manager shall provide 
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 accomplish 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 during 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, configuration files, or custom 
software that implements the required sequences of actions. If this 
capability is provided, 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 controller to communicate with the beacon to control the beacon 
configuration, elicit information from each transponder 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 control 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 constrain the period of time during which 
the beacon may communicate with a transponder. The physical 
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 modified 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:


[[Page 73726]]


    --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 identifier 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 modified 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 determined by comparing the message 
expiration date stored within the specified message to the date at 
which the analysis is performed.
    (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 designated 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 arbitration 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 positive identification of 
vehicles, containers, chassis, etc. Each application area, such as 
Electronic Toll Collection 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).
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 encoding. Within

[[Page 73727]]

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
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                               Message expiration
       Application identifier          Message identifier             date               Message length       Error detect code         Message body
--------------------------------------------------------------------------------------------------------------------------------------------------------
Bits 0 .. 5........................  Bits 6 .. 11..........  Bits 12 .. 23.........  Bits 24 .. 31........  Bits 32 .. 39........  Variable
--------------------------------------------------------------------------------------------------------------------------------------------------------


                                       Table 8.2-2.--Short Message Format
----------------------------------------------------------------------------------------------------------------
                                  Message expiration
       Message identifier                date           Message length     Error detect code     Message body
----------------------------------------------------------------------------------------------------------------
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 Identifier  Integer...............  6 bits................  See Table 34
2...............  Message Identifier....  Integer...............  6 bits................  See Tables 35 through
                                                                                           38
3...............  Message Expiration      Integer...............  12 bits...............  (0 .. 4095); Days
                   Date.                                                                   since 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 string............  8 bits................  XOR Checksum of the
                                                                                           message 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
------------------------------------------------------------------------


[[Page 73728]]


          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),                      --Dsrcmsg-ApplicationIdentity
                     message-ID                    INTEGER (0..63),                      --Dsrcmsg-MessageIdentifier
                     message-date                  INTEGER (0..4095),                    --Dsrcmsg-Date
                     message-length                INTEGER (0..255),                     --Dsrcmsg-Length
                     message-checksum              BIT STRING (SIZE(8))                  --Dsrcmsg-ErrorDetect
                     }
 

8.2.1.2  ASN.1 sample values

                     Dsrcmsg-Header ::=            SEQUENCE
                     {                                                                   --Begin Standard Header
                     application-ID                1,                                    --ETTM Application Identifier
                     message-ID                    1,                                    --Toll Entry Message Identifier
                     message-date                  0,                                    --1/1/1990
                     message-length                0,                                    --0 byte message body
                     message-checksum              `00'H                                 --XOR checksum (not calculated)
                                                                                         --End Header/Begin Body
                     }
 

8.2.1.3  ASN.1 PER encoding

------------------------------------------------------------------------
              Bit                     Bit value         Field definition
------------------------------------------------------------------------
0.............................  000001...............  application-ID
6.............................  00.0001..............  message-ID

[[Page 73729]]

 
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 message identifier. Table 
8.2.2-1 lists the fields and the permissible field values for the short 
message header. Messages 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 Identifier...  Integer..............  5 bits...............  See Table 40
2..............  Message Expiration     Integer..............  7 bits...............  (0 .. 127); Months since
                  Month.                                                               last decade. A value of
                                                                                       127 indicates that a
                                                                                       message never expires.
3..............  Message Length.......  Integer..............  4 bits...............  (1 .. 15); Length of
                                                                                       message body in byte
                                                                                       pairs (does not include
                                                                                       header)
4..............  Error Detect Code....  Bit string...........  8 bits...............  XOR checksum of the
                                                                                       message body
----------------------------------------------------------------------------------------------------------------

    Short message headers shall use the short message identifier 
instead of the application identifier and message 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),                      --Dsrcmsg-ShortMessageIdentity
                     message-month                 INTEGER (0..4095),                    --Dsrcmsg-ShortDate
                     message-length                INTEGER (1..16),                      --Dsrcmsg-ShortLength
                     message-checksum              BIT STRING (SIZE(8))                  --Dsrcmsg-ErrorDetect
                     }
 

8.2.2.2  ASN.1 sample values

                     Dsrcmsg-Header ::=            SEQUENCE
                     {                                                                   --Begin Short Header
                     short-message-ID              1,                                    --Toll Entry Message Identifier

[[Page 73730]]

 
                     short-message-month           0,                                    --1/1/1990
                     short-message-length          4,                                    --5 byte pair message body
                     message-checksum              `00'H                                 --XOR checksum (not calculated)
                                                                                         --End Header / Begin Body
                     }                             ....................................  ...........................................
 

8.2.2.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 Manufacturer Identifier and 
Serial Number fields (and associated subfields) defined for read-only 
memory (see 5.2).
8.3.2  Data elements--application-specific
    Application data elements are specified using ASN.1 syntax in Annex 
A of IEEE 1455-99.

8.4 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 Notification...........  Notifies roadside that the
                                          vehicle has 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)

[[Page 73731]]

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

8.5.1.1  ASN.1 specification

                                                        Trip-Identification-           SEQUENCE
                                                         Message::=
                                                        {
                                                        header                         Dsrcmsg-Header
                                                        duns-number                    NumericString (SIZE(9)),               --Tripload-DunsNumber
                                                        carrier-serial                 NumericString (SIZE(6))                --Tripload-CarrierSerial
                                                        }
 

8.5.1.2  ASN.1 sample values

                     Trip-Identification-          SEQUENCE
                      Message::=
                     {                                                                   --Begin Standard Header
                     application-ID                2,                                    --CVO Application Identifier
                     message-ID                    1,                                    --Trip Identification Message Identifier
                     message-date                  0,                                    --1/1/1990
                     message-length                8,                                    --8 byte message body
                     message-checksum              `00'H,                                --XOR checksum (not calculated)
                                                                                         --End Header/Begin Body
                     duns-number                   123456789,
                     carrier-serial                123456
                     }
 

8.5.1.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..  duns-number
64...............  01111000.1001...............
76...............  0001.00100011.01000101.0110.  carrier-serial
100..............  xxxx........................  octet alignment pad
104..............                                --[end of Body]
------------------------------------------------------------------------

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-                Boolean..............  Go/True--NoGo/False.
                                     DriverClearance.
4.................................  Borderevent-                Boolean..............  Valid/True--Invalid/
                                     DriverClearanceFlag.                               False.
5.................................  Borderevent-CargoClearance  Boolean..............  Go/True--NoGo/False.
6.................................  Borderevent-                Boolean..............  Valid/True--Invalid/
                                     CargoClearanceFlag.                                False.
7.................................  Borderevent-                Boolean..............  Go/True--NoGo/False.
                                     TractorClearance.
8.................................  Borderevent-                Boolean..............  Valid/True--Invalid/
                                     TractorClearanceFlag.                              False.
9.................................  Borderevent-                Boolean..............  Reserved for future use.
                                     ReserveClearance.
10................................  Borderevent-ReserveFlag...  Boolean..............  Reserved for future use.
11................................  Transponder-                Bit string...........  Size (64).
                                     DigitalSignature.
----------------------------------------------------------------------------------------------------------------

8.5.2.1  ASN.1 specification

                      Border-Clearance-Event-Message::=SEQUENCE
                      {
                      headerDsrcmsg-Header,                                   --Standard Header.

[[Page 73732]]

 
                      beacon-IDBIT STRING SIZE((32)),                         --Beacon-Identity.
                      timestampDsrc-Time,                                     --Borderevent-Timestamp.
                      driver-clearanceBOOLEAN,                                --Borderevent-DriverClearance.
                      driver-clearance-flagBOOLEAN,                           --Borderevent-DriverClearanceFlag.
                      cargo-clearanceBOOLEAN,                                 --Borderevent-CargoClearance.
                      cargo-clearance-flagBOOLEAN,                            --Borderevent-CargoClearanceFlag.
                      tractor-clearanceBOOLEAN,                               --Borderevent-TractorClearance.
                      tractor-clearance-flagBOOLEAN,                          --Borderevent-TractorClearanceFlag.
                      reserve-clearanceBOOLEAN,                               --reserved field.
                      reserve-flagBOOLEAN,                                    --reserved field.
                      digital-signatureBIT STRING (SIZE(64))                  --Transponder-DigitalSignature.
                      }
 

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

8.5.2.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..........  beaconID--Agency
                                               component.
56.............  00000001.00000000..........  beaconID--Serial
                                               component.
72.............  00000000.00000000.00000000.  timestamp.
                  00000000.
104............  1..........................  driver-clearance.
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.  digital-signature.
                  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).

[[Page 73733]]

 
2..................................  Lock-Identity.........  Bit string............  Size (40); Transponder-
                                                                                      Identity; the value of the
                                                                                      preceding Lock-Quantity
                                                                                      field indicates the number
                                                                                      of occurrences of this
                                                                                      field.
3..................................  Transponder-            Bit string............  Size (64).
                                      DigitalSignature.
----------------------------------------------------------------------------------------------------------------

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

8.5.3.2  ASN.1 sample values

                                                       Border-Lock-Notification-Message::=SEQUENCE
                          {                                                                                                      ----Begin Standard
                                                                                                                                  Header
                          application-ID                             2,                                                          ----CVO Application
                                                                                                                                  Identifier
                          message-ID                                 3,                                                          ----Electronic Lock
                                                                                                                                  Status Message ID
                          message-date                               0,                                                          ----1/1/1990
                          message-length                             14,                                                         ----14 byte message
                                                                                                                                  body
                          message-checksum                           `00'H,                                                      ----XOR checksum (not
                                                                                                                                  calculated)
                                                                                                                                 ----End Header/Begin
                                                                                                                                  Body
                          lock-quantity                              1,                                                          ----Number of locks
                          lock-ID                                    `0080000040'H,                                              ----Lock-Identity
                                                                                                                                  Man=2; Serial=4
                          digital-signature                          0                                                           ----Transponder-
                                                                                                                                  DigitalSignature
                          }
 

8.5.3.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........................  lock-quantity
44...............  0000.000010.................  lock-ID Manufacturer=2
54...............  00.00000000.00000000.0000010  lock-ID Serial=4
                    0..
80...............  0000........................  lock-ID Reserved
84...............  0000.00000000.00000000.00000  digital-signature
                    000.0000.
116..............  0000.00000000.00000000.00000
                    000.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 location. 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

[[Page 73734]]

 
6.................................  Borderevent-Timestamp.....  Integer..............  Size (32); Dsrc-Time
7.................................  Transponder-                Bit string...........  Size (64)
                                     DigitalSignature.
----------------------------------------------------------------------------------------------------------------

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

8.5.4.2  ASN.1 sample values

                      Border-Lock-Status-Message::=SEQUENCE
                      {                                                                            --Begin Standard Header
                      application-ID                                          2,                   --CVO Application Identifier
                      message-ID                                              4,                   --Electronic Lock Status Message ID
                      message-date                                            0,                   --1/1/1990
                      message-length                                          23,                  --23 byte message body
                      message-checksum                                        `00'H,               --XOR checksum (not calculated)
                                                                                                   --End Header/Begin Body
                      lock-ID                                                 `0080000040'H,       --Lock-Identity Man=2; Serial=4
                      timestamp                                               0,                   --00:00:00 1/1/1970 GMT
                      lock-status                                             0,                   --Lock-Status=0; Open
                      lock-quantity                                           1                    --Lock-HistoryCount=1
                      lock-status-h1                                          1                    --Lock Status=1; Close
                      border-time-h1                                          0                    --Borderevent-Timestamp
                      digital-signature                                       0                    --Transponder-DigitalSignature
                      }
 

8.5.4.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........................  lock-ID Reserved
44..........  0000.000010.................  lock-ID Manufacturer = 2
54..........  00.00000000.00000000.0000010  lock-ID Serial = 4
               0.
80..........  00000000.00000000.00000000.0  timestamp
               0000000.
112.........  000.........................  lock-status
115.........  0001........................  lock-count
119.........  0.01........................  lock-status-hl
122.........  000000.00000000.00000000.000  border-time-hl
               00000.00.
154.........  000000.00000000.00000000.000  digital-signature
               00000.
184.........  00000000.00000000.00000000.0
               000000.00.
218.........  xxxxxx......................  fill
224.........                                ---- [end of Body]
------------------------------------------------------------------------

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 beacon at a border clearance location. See Table 8.5.5-
1.

[[Page 73735]]



                                 Table 8.5.5-1.--Itinerary Verification Message
----------------------------------------------------------------------------------------------------------------
               Field                    Data element name             Type                    Constraint
----------------------------------------------------------------------------------------------------------------
1..................................  Vehicle-                Integer...............  (0 .. 100); 100 indicates
                                      ItineraryQuality.                               the highest confidence
                                                                                      that the vehicle has
                                                                                      followed a specified
                                                                                      itinerary. 0 indicates a
                                                                                      high confidence that the
                                                                                      vehicle has significantly
                                                                                      deviated from a specified
                                                                                      itinerary. Other values
                                                                                      indicate intermediate
                                                                                      levels of confidence.
2..................................  Borderevent-Timestamp.  Integer...............  Size (32); Dsrc-Time.
3..................................  Transponder-            Bit string............  Size (64).
                                      DigitalSignature.
----------------------------------------------------------------------------------------------------------------

8.5.5.1  ASN.1 specification

 
 
 
                                    Border-Itinerary-Message ::=SEQUENCE
                     {
                     header                        Dsrcmsg-Header,                       --Standard Header
                     itinerary-quality             INTEGER (0..255),                     --Vehicle-Itinerary Quality; Max=100
                     border-time                   0                                     --Borderevent-Timestamp
                     digital-signature             BIT STRING (SIZE(64))                 --Transponder-DigitalSignature
                     }
 

8.5.5.2  ASN.1 sample values

 
 
 
                                    Border-Itinerary-Message ::= SEQUENCE
                     {                             ....................................  --Begin Standard Header
                     application-ID                2,                                    --CVO Application Identifier
                     message-ID                    5,                                    --Border Itinerary Message ID
                     message-date                  0,                                    --1/1/1990
                     message-length                13,                                   --13 byte message body
                     message-checksum              `00'H,                                --XOR checksum (not calculated)
                                                                                         --End Header / Begin Body
                     itinerary-quality             64,                                   --Itinerary Quality = 64%
                     border-time                   0,                                    --Borderevent-Timestamp
                     digital-signature             0,                                    --Digital Signature = 0
                     }
 

8.5.5.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....................  itinerary-quality
48...............  00000000.00000000.00000000.0  border-time
                    0000000..
80...............  00000000.00000000.00000000.0  digital-signature
                    0000000..
112..............  00000000.00000000.00000000.0
                    0000000..
144..............                                -----[end of Body]
------------------------------------------------------------------------

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 Expanded..  Sets and sends vehicle and
                                          cargo data.
CMV Screening Event Expanded...........  Reports clearance event data to
                                          the vehicle.
------------------------------------------------------------------------


[[Page 73736]]

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-Clearance-Identification-Message ::= SEQUENCE
                     {
                     header                        Dsrcmsg-Header,                       -- Standard Header
                     carrier-ID                    IA5String (SIZE(24)),                 -- Carrier-Identity
                     vin                           IA5String (SIZE(30)),                 -- Vehicle-Identity
                     cargo-code                    IA5String (SIZE(5))                   -- Vehicle-CargoType
                     }
 

8.6.1.2  ASN.1 sample values

                     CMV-Clearance-Identification-
                      Message ::=SEQUENCE
                     {                                                                   -- Begin Standard Header
                     application-ID                2,                                    -- CVO Application Identifier
                     message-ID                    6,                                    -- Clearance ID Message Identifier
                     message-date                  0,                                    -- 1/1/1990
                     message-length                59,                                   -- 59 byte message body
                     message-check sum             `00'H,                                -- XOR checksum (not calculated)
                                                                                         -- End Header/Begin Body
                     carrier-ID                    64,                                   --
                     vin                           0,                                    --
                     cargo-code                    0,                                    --
                     }
 

8.6.1.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.                             carrier-identity
                                    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.                             vehicle-identity
                                    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.                             vehicle-cargo-type
                                    504                    xxxxxxxx
                                    512                    ...............................................................  ---- [end of Body]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


[[Page 73737]]

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 
transponder 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 String.........  Size (32)
5................................  Mainlineevent-        Integer............  Size (32); Dsrc-Time
                                    Timestamp.
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

                                     Screening-Event-Message ::=SEQUENCE
                     {
                     header                        Dsrcmsg-Header,                       -- Standard Header
                     gross-weight                  INTEGER                               -- Vehicle-Gross Weight
                     scale-type                    INTEGER                               -- Scale-Type
                     axle-number                   INTEGER                               -- Vehicle-Axle Number
                     beacon-ID                     BIT STRING (SIZE(32)),                -- Beacon-Identity
                     timestamp                     Dsrc-Time                             -- Mainline event-Timestamp
                     pullin-clearance              BOOLEAN                               -- Mainline event-Pullin Clearance
                     }
 

8.6.2.2  ASN.1 sample values

                                   CMV-Screening-Event-Message ::=SEQUENCE
                     {                                                                   -- Begin Standard Header
                     application-ID                2,                                    -- CVO Application Identifier
                     message-ID                    7,                                    -- Screening Event
                                                                                         Message Identifier
                     message-date                  0,                                    -- 1/1/1990
                     message-length                12,                                   -- 12 byte message body
                     message-checksum              `00'H,                                -- XOR checksum
                                                                                         (not calculated)
                                                                                         -- End Header/Begin Body
                     gross-weight                  500,                                  -- 5000 Kg
                     scale-type                    1,                                    -- Jurisdictional weight
                     axle-number                   4                                     -- Vehicle-Axle Number
                     beacon-ID                     `00020100'H,                          -- Agency=2; Serial=256
                     timestamp                     0,                                    -- 00:00:00 1/1/1970 GMT
                     pullin-clearance              TRUE                                  -- Go
                     }
 

8.6.2.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............  gross-weight
54.............  000100.....................  scale-type
58.............  00100......................  axle-number

[[Page 73738]]

 
64.............  00000000.00000010..........  beacon-ID--Agency
                                               component
80.............  00000001.00000000..........  beacon-ID--Serial
                                               component
96.............  00000000.00000000.00000000.  timestamp
                  00000000..
128............  1..........................  pullin-clearance
129............  xxxxxxx -Fill
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-Component Identity  IA5string............  Size (30); VIN
2.................................  Driver-Identity...........  IA5string............  Size (20)
----------------------------------------------------------------------------------------------------------------

8.6.3.1  ASN.1 specification

                         CMV-Screening-Expanded Identification-Message ::= SEQUENCE
                     {
 
                     header                        Dsrcmsg-Header,                       -- Standard Header
                     vehicle-component-ID          IA5String (SIZE(30)),                 -- Vehicle-Component Identity
                     driver-ID                     IA5String (SIZE(20))                  -- Driver-Identity
                     }
 

8.6.3.2  ASN.1 sample values

                         CMV-Screening-Expanded Identification-Message ::= SEQUENCE
                     {                                                                   -- Begin Standard Header
                     application-ID                2,                                    -- CVO Application Identifier
                     message-ID                    8,                                    -- Screening Event
                                                                                         Message Identifier
                     message-date                  0,                                    -- 1/1/1990
                     message-length                50,                                   -- 50 byte message body
                     message-checksum              `00'H,                                -- XOR checksum
                                                                                         (not calculated)
                                                                                         -- End Header / Begin Body
                     vehicle-component-ID                                                --
                     driver-ID                                                           --
                     }
 

8.6.3.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.  vehicle-component-ID
                  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.  driver-ID
                  xxxxxxxx..
                 xxxxxxxx.xxxxxxxx.xxxxxxxx.
                  xxxxxxxx..
                 xxxxxxxx.xxxxxxxx.xxxxxxxx.
                  xxxxxxxx..
                 xxxxxxxx.xxxxxxxx.xxxxxxxx.
                  xxxxxxxx..
                 xxxxxxxx.xxxxxxxx.xxxxxxxx.
                  xxxxxxxx..
440............                               --[end of Body]
------------------------------------------------------------------------


[[Page 73739]]

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 transponder 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 Event- ....................................  ...........................................
                      Message ::= SEQUENCE
                     {                             ....................................  ...........................................
                     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
                     }                             ....................................  ...........................................
 

8.6.4.2  ASN.1 Sample Values

                     CMV-Screening-Expanded Event- ....................................  ...........................................
                      Message ::= SEQUENCE
                     {                             -- Begin Standard Header
                     application-ID                2,                                    -- CVO Application Identifier
                     message-ID                    9,                                    -- Screening Event Message Identifier
                     message-date                  0,                                    -- 1/1/1990
                     message-length                6,                                    -- 6 byte message body
                     message-checksum              '00'H,                                -- XOR checksum (not calculated)
                                                   -- End Header / Begin Body
                     axle-number                   2                                     -- Vehicle-AxlesNumber
                     axle-weight                   100,                                  -- 1000 kg
                     axle-weight                   100,                                  -- 1000 kg
                     axle-spacing                  4                                     -- 4 meters
                     axle-spacing                  0                                     -- terminal axle
                     }                             ....................................  ...........................................
 

8.6.4.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......................  axle-number
45.............  0011.11101000.0............  axle-weight
58.............  0011111.010000.............  axle-weight
71.............  00.0100....................  axle-spacing
77.............  0000.00....................  axle-spacing
83.............  xxxxxx.....................  octet alignment pad
88.............                               --[end of Body]
------------------------------------------------------------------------


[[Page 73740]]

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.

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.
     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
------------------------------------------------------------------------
                                            Corresponding lower layer
               OSI 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.

[[Page 73741]]

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 Name                       ASN.1 Type                       Description                  Size (bits)        Bit Sequence = Value
--------------------------------------------------------------------------------------------------------------------------------------------------------
T-APDU................................  T-APDUs.................  A BST identifier required for                         4  0-3 = ASN.1 T-APDUs value for
                                                                   compliance with the CEN ASN.1                            a choice of
                                                                   definition of a BST.                                     initialisation.request =
                                                                                                                            hex( 8 )
Options Flag..........................  BIT STRING (SIZE (1))...  A bit indicating that the optional                    1  4 = 0
                                                                   nonmadatory applications list field is
                                                                   missing; required for compliance with
                                                                   the CEN ASN.1 definition of a BST.
beacon................................  BeaconID................  An identifier composed of a                          43  5-20 = Manufacturer
                                                                   Manufacturer Identifier (a unique                        Identifier 21-47 =
                                                                   identifier assigned by IEEE) and an                      Individual Identifier
                                                                   Individual Identifier whose use is
                                                                   vendor specific.
time..................................  Time....................  The number of seconds from 01/01/1970                32  48-79 = time
                                                                   GMT.
profile...............................  Profile.................  The profile that will be used to                      8  80-87 = profile
                                                                   transmit the BST; profile definitions
                                                                   are specific to the lower layer
                                                                   service.
mandApplications......................  ApplicationList.........  Defines the RSE applications; the only              136   88-95 = number in
                                                                   application currently defined by this                    list = hex  ( 2 )
                                                                   Specification is mailbox The ASN.1                       96-103 = hex( 0D )
                                                                   encoding of the application list                         (mailbox AID)
                                                                   requires that the first octet defines                    104-111 = EID
                                                                   the number of elements in the list                       112-119 = hex( 4 ) =
                                                                   which shall always be hex( 1 ) The                       tag for Octet String
                                                                   application list consists of the                         120-127 = length of
                                                                   mailbox AID, an EID, and a parameter                     data = hex( 0C )
                                                                   field; the Parameter field consists of                   128-143 = 1st filter
                                                                   a data type tag, a data length octet,                    identifier
                                                                   and the data itself.                                     144-159 = 2nd filter
                                                                  The Parameter Field data defines two                      identifier
                                                                   Page Identifiers that must be present                    160-175 = 1st return
                                                                   on the OBE for the OBE to respond with                   identifier
                                                                   a BST The Parameter Field then defines                   176-191 = 2nd return
                                                                   four Page Identifiers for which OBE                      identifier
                                                                   memory images will be returned by the                    192-207 = 3rd return
                                                                   OBE in the VST The Page Identifiers                      identifier
                                                                   shall be set to zero if they are                         208-223 = 4th return
                                                                   unused.                                                  identifier
profileList...........................  SEQUENCE OF Profile;      A profile, in addition to the profile                16  224-231 = number of profiles
                                         only one Profile in the   specified in the Profile field, that                     in list = hex( 1 )
                                         sequence.                 is supported by the RSE lower layer                     232-239 = value of profile
                                                                   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

[[Page 73742]]

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.

[FR Doc. 99-33406 Filed 12-29-99; 8:45 am]
BILLING CODE 4910-22-P