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
P1609.0, WAVE – Architecture (PAR approved December 2006)
IEEE Trial-use Standard TM-2006, WAVE - Resource Manager
IEEE Trial-use Standard TM-2006, WAVE - Security Services for Applications and Management Messages
P1609.3D21, WAVE - Networking Services
IEEE Trial-use Standard TM-2006, WAVE - Multi-channel Operations
IEEE Standard 1455TM-1999(2006), 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.3D21 is shown to illustrate
the relationship among the IEEE
1609 and IEEE standards
MEDIUM
Reference: IEEE P1609.3D20, page 9, Figure 1, WAVE Standards, July 2006

5. Architecture (P1609.0) SCOPE STATUS
“This standard describes the Wireless Access in Vehicular Environments (WAVE/DSRC) architecture and services necessary for multi-channel DSRC/WAVE devices to communicate in a mobile vehicular environment.”
STATUS
PAR APPROVED, December 2006
Preliminary draft circulated to WG, October 2006
Revised outline and content draft expected to be available mid-January 2007 for review at next P1609 WG meeting
Projected approval planned in CY2008

6. 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
Approved for trial-use September 14, Trial-use period through August 2008, or less.
Revisions planned based on feedback from trial-use and additional requirements during CY2007
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.

7. 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 for trial-use, June 6, 2006, Trial-use period through December 2007
Corrigenda planned to include changes to ACID field (now PSID)
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.

8. 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
Comments addressed, changes in progress based on changes to PSID and PSC (a.k.a., ACID and ACM) and prepared for recirculation that started November 21 and closed December 2 with 94 comments of which two negatives must be resolved
Preparing tutorial for IEEE Registration Authority Committee review and approval for PSID registration to be administered by the IEEE Registration Authority upon approval of the standard
Projected approval as Trial-use standard: March 2007
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.

9. 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
Approved November 2006 for Trial-use
Revisions planned based on feedback from trial-use and additional requirements during CY2007 and 2008
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

10. 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 schedules for recirculation
Trial-use period for evaluation is expected to be two years or less

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

12. Provider Service Identifier (PSID) Registration
Discussion with IEEE Registration Authority Committee (RAC) for the IEEE Registration Authority (RA) to administer the assignment of the Application Class Identifier (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
Agreed to 4-byte field and to change name at working group meeting in October 2006.
Changed ACID to Provider Service Identifier (PSID) and ACM to Provider Service Context (PSC)
WG to develop policies and procedures for applying for, assigning, and administering the PSID with the assistance of the IEEE RAC Administrator before March 2007

13. Proposals for Addition to Program of Work (tentative project titles)
Guide for WAVE Security Services
First draft circulated, second draft scheduled for circulation in October 2006 has been delayed
Guide for WAVE/DSRC Application Services
Guide for WAVE Application Services Certification and Test
In Progress, by Omni-Air Consortium and SwRI
Procedures (tutorial for posting to IEEE Registration Authority web site) for applying and assigning Provider Service Identifier (PSID) [formerly ACID]
To gain consensus by Working Group before March 2007
WAVE/DSRC Requirements update
On-going in working group

14. SCHEDULE February 6-8, 2007, SwRI, San Antonio, TX (confirmed)
March - December Bi-monthly meetings and teleconferences planned with venues and agenda TBD
Purposes
to develop proposal for essential new projects
to develop identified requirements from this phase
to address feedback from trial-use and prototype testing
to respond to request for formal interpretations

15. LIAISON CONTACTS
The following are either confirmed or pending liaisons to 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.