1. IEEE DSRC Application Services (P1609)
Date:
Authors:
Name
Company
Address
Phone
Tom Kurihara
TKstds
Management
3800 N Fairfax Dr, #207
Arlington, VA
22203

2. Notice: This document has been prepared to assist IEEE 802. 11
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at

3. PROGRAM OF WORK WAVE - Resource Manager (P1609.1)
IEEE Standard TM-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 p, 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

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

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

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

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

8. MULTI-CHANNEL OPERATIONS (P1609.4)
SCOPE
“…describes multi-channel wireless radio operations, that uses the IEEE p, 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 WAVE mode that describes how to support a multi-channel system with the IEEE 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 , IEEE , IEEE , and IEEE p.
1.2 Purpose
This standard provides enhancements to the IEEE 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

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

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

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

12. Proposals for Addition to Program of Work (tentative project titles)
P 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)

13. SCHEDULE
October 3-5, 2006, WG meeting, NY State Thruway Authority, Albany, NY
November 2006-June 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

14. 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 p Task Group
Omni-Air Consortium
R. Roebuck
IEEE Standards Department
M. Ceglia
WAVE in North America (IEEE p Amendment to IEEE Standard )
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 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 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 to 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.