Transportation operations and management: Dedicated short range communications in intelligent transportation systems commercial vehicle operations,

[Federal Register: December 30, 1999 (Volume 64, Number 250)]

[Proposed Rules]

[Page 73674-73742]

From the Federal Register Online via GPO Access [wais.access.gpo.gov]

[DOCID:fr30de99-43]

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 ‹william.s.jones@fhwa.dot.gov›; or Mr. Wilbert Baccus, Office of the Chief Counsel, (HCC-32) (202) 366-0780, e-mail address ‹wilbert.baccus@fhwa.dot.gov›, 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 filedin 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-99OBE 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-99does 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-99standard. 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‹SUP›-6‹/SUP› 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‹SUP›-5‹/SUP›, 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‹SUP›-5‹/SUP›.

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

‹bullet› Maximum Signal Strength: Downlink BER of 10‹SUP›-5‹/SUP› at 9377 millivolts/meter (+3dBm with 0 dBi antenna) horizontal signal strength. Fast Wake-up: Minimum signal strength: Downlink BER of 10‹SUP›-5‹/SUP› at 450 millivolts/meter minimum (-23dBm with 0 dBi antenna). (Fast Wake-up is not required for compliance with this specification.)

‹bullet› Required Signal Strength: Downlink BER of 10‹SUP›-5‹/SUP› 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).

‹bullet› 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‹SUP›-6‹/SUP› 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‹SUP›-5‹/SUP›, 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-99Table 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:

‹bullet› Following each Activation Phase--250‹greek-m›sec +10%,-0% ‹bullet› Following each Transponder ID Msg--8‹greek-m›sec ‹bullet› Preceding the Extended Header of each Originated Slot Data Message (SDM) or Acknowledgement--40‹greek-m›sec ‹bullet› Preceding each Transponder-Originated SDM or Acknowledgement-- 100‹greek-m›sec 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]]

‹bullet› Prior to the FCM--375 bits ‹bullet› Prior to each Reader-Originated Acknowledgement Message--30 bits ‹bullet› 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 filedshall be coded as shown. Otherwise, Message Type filedshall 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:

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

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

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

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

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

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

   ‹bullet› Single packet per vehicle, one to four vehicles simultaneously each frame

   ‹bullet› Multiple packets per vehicle per frame.

   ‹bullet› Multiple packets per vehicle in multiple frames.

   ‹bullet› 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-99user 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-99with 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:

   ‹bullet› The minimum memory page size shall be 128 bits.

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

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

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

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

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

   ‹bullet› 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.

   ‹bullet› 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:

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

   ‹bullet› 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-99provides 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-99ITS 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-99defines 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-99defines 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-99may 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-99with 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:

   ‹bullet› 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.

   ‹bullet› 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.

   ‹bullet› 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:

   ‹bullet› 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.

   ‹bullet› 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).................... ‹bullet› Fragmentation/ Defragmentation. ‹bullet› Message sequencing. ‹bullet› Duplicate message handling. Layer 3 (network)...................... Packet routing. Layer 2(data link)..................... ‹bullet› Frame handling. ‹bullet› Transmission error detection. ‹bullet› Transmission error recovery. Layer 1 (physical)..................... ‹bullet› 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 ‹bullet› 88-95 = number in application currently defined by this

   list = hex ( 2 ) Specification is mailbox The ASN.1

   ‹bullet› 96-103 = hex( 0D ) encoding of the application list

   (mailbox AID) requires that the first octet defines

   ‹bullet› 104-111 = EID the number of elements in the list

   ‹bullet› 112-119 = hex( 4 ) = which shall always be hex( 1 ) The

   tag for Octet String application list consists of the

   ‹bullet› 120-127 = length of mailbox AID, an EID, and a parameter

   data = hex( 0C ) field; the Parameter field consists of

   ‹bullet› 128-143 = 1st filter a data type tag, a data length octet,

   identifier and the data itself.

   ‹bullet› 144-159 = 2nd filter The Parameter Field data defines two

   identifier Page Identifiers that must be present

   ‹bullet› 160-175 = 1st return on the OBE for the OBE to respond with

   identifier a BST The Parameter Field then defines

   ‹bullet› 176-191 = 2nd return four Page Identifiers for which OBE

   identifier memory images will be returned by the

   ‹bullet› 192-207 = 3rd return OBE in the VST The Page Identifiers

   identifier shall be set to zero if they are

   ‹bullet› 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-33406Filed12-29-99; 8:45 am]

   BILLING CODE 4910-22-P