[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