IEEE DSRC Application Services (P1609) Date: 2006-09-16 Authors: Name Company Address Phone email Tom Kurihara TKstds Management 3800 N Fairfax Dr, #207 Arlington, VA 22203 +1 703-516-9650 tkstds@mindspring.com

Notice: This document has been prepared to assist IEEE 802. 11 Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.

PROGRAM OF WORK WAVE - Resource Manager (P1609.1) IEEE Standard 1609.2TM-2006, WAVE - Security Services for Applications and Management Messages WAVE - Networking Services (P1609.3) WAVE - Multi-channel Operations (P1609.4) Reaffirmation of IEEE Standard 1455TM-1999, IEEE Standard for Message Sets for Vehicle/Roadside Communications Note: P1609 family of standards are intended to operate with IEEE 802.11p, Wireless Access in Vehicular Environment (WAVE) and supports the U. S. Department of Transportation Intelligent Transportation Systems (ITS) Program and the Vehicle and Infrastructure Integration (VII] Program

WAVE DEVICE UPPER IEEE 1609.1, LAYERS et al WAVE NETWORK SECURITY SERVICES NETWORK LAYER IEEE 1609.2 IEEE 1609.3 LOWER LAYERS IEEE 1609.4 IEEE 802.11p Note: The figure from IEEE P1609.3D20 is shown to Illustrate the notional relationship among the IEEE 1609 and IEEE 802.11 standards MEDIUM Reference: IEEE P1609.3D20, page 9, Figure 1, WAVE Standards, July 2006

RESOURCE MANAGER (P1609.1) SCOPE STATUS “…describe the services and interfaces, including security and privacy protection mechanisms, associated with the DSRC Resource Manager operating at 5.9GHz band authorized by the Federal Communications Commission (FCC) and to satisfy the Intelligent Transportation System (ITS) wireless communications requirements.” STATUS Draft P1609.1D12 Sponsor Ballot closed January 7, 2006, with 90.7% Affirmative, 6.2% abstain, with 522 comments Completed recirculations without change in approval percentage Submitted to IEEE Review Committee for approval on August 4, 2006 (Approved September 14, 2006) 1.1 Scope To specify the services and interfaces of the Resource Manager Application, including protective mechanisms for security and privacy, applicable and available to all users of DSRC and WAVE mode operations in the 5.9 GHz band authorized by the Federal Communication Commission for Intelligent Transportation System (ITS). 1.2 Purpose The purpose of this standard is to enable complete inter-operability of applications using WAVE in a manner that simplifies the on-board vehicle systems, reducing cost and improving performance. Effective use of the memory pages by applications can also minimize configuration management issues over the life of a system. This standard is intended to enable a wide range of applications to be supported by an OBU of the lowest possible cost. The low cost is enabled by removing the need for the OBU to interpret application messages. There is no OBU software representing applications using Resource Manager, thus the processing, memory, and configuration management requirements are removed from the OBU. Instead of putting such processing requirements on the OBU, they are placed on the RSU or BOA. The only processing requirement is that of interpreting the specific commands and message headers defined herein, which is application independent. The OBU merely serves as a mobile mailbox to carry application messages and data from one RSU to another or as a common interface point to transfer data to other on-board systems. By allowing memory to be assigned to an application at any time during the life of the OBU, future applications can be developed and deployed without on-board hardware or software modification. For applications using RM as a mobile mailbox, with no on-board use of the data stored in memory, there are significant security advantages. By having the OBU treat each application's messages as a bit-stream to be saved and later retrieved from memory, such data can be encrypted in a manner that is not known to the OBU. There is no need for the OBU to support the encryption scheme used by these applications and such security schemes can be under the total and absolute control of this application.

Security Services for Applications and Management Messages (P1609.2) SCOPE (same as IEEE P1556 withdrawn December 2005) defines secure message formats and processing of secure messages, within the DSRC/WAVE system defines methods for securing WAVE management messages and application messages, with the exception of anonymity-preserving vehicle safety messages describes administrative functions necessary to support the core security function STATUS Approved, June 6, 2006, IEEE Trial-Use Standard for WAVE Applications and Management Messages, IEEE Standard 1609.2-2006 Trial-use period through December 2007 Corrigenda planned to include revised ACID field, etc. Plan to develop revised draft including additional requirements and changes required to be consistent with the other three documents 1.2 Scope The scope of this standard is to define secure message formats, and the processing of those secure messages, within the WAVE system. The standard covers methods for securing WAVE management messages and application messages, with the exception of vehicle-originating safety messages. It also describes administrative functions necessary to support the core security functions. 1.3 Purpose The safety-critical nature of many WAVE applications makes it vital that services be specified that can be used to protect messages from attacks such as eavesdropping, spoofing, alteration and replay. Additionally, the fact that the wireless technology will be deployed in personal vehicles, whose owners have a right to privacy, means that in as much as possible the security services must be designed to respect that right and not leak personal, identifying, or linkable information to unauthorized parties. This standard describes security services for WAVE management messages and application messages, with the exception of 30 vehicle-originating safety messages, to meet these requirements. It is anticipated that vehicle-originating safety messages will be added in an amendment to this standard.

NETWORKING SERVICES (P1609.3) SCOPE “…define services, operating at the network and transport layers, in support of wireless connectivity among vehicle-based devices, and between fixed roadside devices and vehicle-based devices using the 5.9 GHz DSRC/WAVE mode.” STATUS Sponsor Ballot Results: in ballot group = 104; returns 75.0%; approval = 94.7%; abstentions =  2.6%; with 503 comments Addressing comments and preparing for recirculation to start on or about September 12, 2006 Projected approval December 2006 1.1 Scope The scope of the standard is to define services, operating at the network and transport layers, in support of wireless connectivity among vehicle-based devices, and between fixed devices and vehicle-based devices. 1.2 Purpose The purpose of this standard is to provide connectivity in support of in-vehicle applications offering safety and convenience to their users, while at the same time offering a level of confidentiality and data security to those users. Standard network layer functions, such as addressing and routing, are supported, as are multiple upper layer protocols to provide different types of service to the users.

MULTI-CHANNEL OPERATIONS (P1609.4) SCOPE “…describes multi-channel wireless radio operations, that uses the IEEE 802.11p, WAVE mode, medium access control and physical layers, including the operation of control channel and service channel interval timers, parameters for priority access, channel switching and routing, management services, and primitives designed for multi-channel operations.” STATUS Sponsor Ballot Results in ballot group = 100; returns 77.0%; approval = 91.9%; abstentions =   3.9%; with 286 comments Addressed comments, completed two recirculations Changes to ACID field to be made before third recirculation Projected approval December 2006 1.1 Scope The scope of the standard is to describe 1. An extension to the IEEE 802.11 WAVE mode that describes how to support a multi-channel system with the IEEE 802.11 medium access control and physical layers via a Control Channel and multiple Service Channels. Specifically, the multi-channel operation (channel coordination) provides mechanisms for prioritized access, channel routing and coordination, and data transmission. 2. The management activities and primitives for the multi-channel coordination. This specifies the functionality of one layer in the overall WAVE architecture, which also includes IEEE 1609.1, IEEE 1609.2, IEEE 1609.3, and IEEE 802.11p. 1.2 Purpose This standard provides enhancements to the IEEE 802.11 MAC to enable it to support WAVE operations. These enhancements collectively handle WAVE safety and private applications over the Control Channel and Service Channels.1

Change in Standard Category PARs were approved and drafts were approved for sponsor ballot as “full-use” Whether “full-use” or “trial-use” category was discussed in WG meeting before going to sponsor ballot and no change was made (March 2006) Negative position ballots were submitted to change the category to “trial-use” WG resolved to accept “trial-use” category Change will be made to the drafts as required by the IEEE Style Guide and recirculated as “trial-use” with appropriate explanatory text Change in category does not affect sponsor ballot status or schedule for recirculation

USE CASES AND LIAISON WG consolidating and verifying user requirements and use cases for DSRC/WAVE Conducting extended proto-type equipment tests using IEEE 1609 drafts Coordinating activities with: SAE Technical Committee, Project J2735, DSRC Data Dictionary and Message Sets Vehicle Infrastructure Integration Consortium (VIIC) DSRC Industry Consortium (DIC) ISO TC204 WG16, CALM Omni-Air Consortium and SwRI, certification and test guide for WAVE/DSRC Devices

Application Class Identifier (ACID) Registration Discussion with IEEE Registration Authority Committee (RAC) for the IEEE Registration Authority (RA) to administer the assignment of the ACID RAC agreed (September 2006), provided that the WG agree to change from a one-byte ACID to a flat, four-byte ACID WG presented with proposal, no substantive disagreement, however, changes to ACID field length will be made before forwarding for approval Approach to detailed changes affecting all four volumes to be discussed during WG meeting in October 2006 WG to develop policies and procedures for applying for, assigning, and administering the ACID with the assistance of the IEEE RAC Administrator

Proposals for Addition to Program of Work (tentative project titles) P1609.0 - WAVE - Architecture Guide for WAVE Security Services Guide for WAVE/DSRC Application Services Guide for WAVE Application Services Certification and Test Procedures for applying and assigning Application Class Identifier (ACID)

SCHEDULE October 3-5, 2006, WG meeting, NY State Thruway Authority, Albany, NY November 2006-June 2007 - Bi-monthly meetings and teleconferences planned with venues TBD Purposes to develop proposal for essential new projects to develop identified requirements from this phase to address feedback from trial-use and proto-type testing to respond to request for formal interpretations

LIAISON CONTACTS The following are either confirmed or pending liaisons with other standards setting organizations SAE Technical Committee, DSRC Message Sets D. Kavner DSRC Industry Consortium VII Consortium S. Andrews ISO TC204 WG16, CALM R. Roy ASTM Committee E17.51 L. Armstrong IEEE 802.11p Task Group Omni-Air Consortium R. Roebuck IEEE Standards Department M. Ceglia WAVE in North America (IEEE 802.11p Amendment to IEEE Standard 802.11) K.1 Introduction This Annex provides additional descriptions and requirements for implementing WAVE for stations in North America. The primary purpose of the WAVE mode in North America is to provide wireless communications between RSUs and OBUs at highway speeds. The FCC in the US and the CRTC in Canada are the regulatory authorities governing the 5.850-5.925 GHz band (5.9 GHz Band) use of spectrum for non-federal government users. In North America the FCC and CRTC provide oversight in the operations of stations including the Band Plan, Power Limits, Emission Limits, Antenna height, and Control Channel-Service Channel Usage (see CFR Title 47) . An RSU shall be restricted to the geographic region where it is licensed to operate. Portable or hand-held RSUs are permitted to operate on the Control Channel and Service Channels where they do not interfere with another RSU according to its site registration. K.2 WAVE Channelization Clause 20.3.8.3.3 defines the WAVE Band and Channels of operation in North America. Stations can communicate on seven 10 MHz channels in a special band for which DSRC is a primary user and unlicensed operation is prohibited. In the 5.850 to 5.925 GHz band only the WAVE mode shall be used. K.3 Priority Communications for Public Safety The FCC categorizes WAVE applications into safety of life, public safety, and private. Two channels, Channel 172 and Channel 184, are reserved for communications of public safety applications Only User priorities 4, 5, 6, and 7 defined in IEEE P802.11e™, Clause 6.1.1, shall be used for public safety applications. K.4 WAVE Channel priority screening The SME shall implement a mechanism to screen messages that are created with high priorities and are intended to be transmitted on Channels 172 and 184. If a packet is destined for Channel 172 or 184 it must have a priority level of 4, 5, 6, or 7. If it does not the packet 1 will be rejected and a response will be sent to indicate that this process has failed.