Using Beacon Frames for WAVE Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Using Beacon Frames for WAVE Date: 2007-03-13 Authors: 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@ok-brit.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>. Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Abstract This presentation includes discussion materials for migrating from the “WAVE announcement” action frame to a “quick beacon” management frame in order to further synergize TGp with the base 802.11 standard. The corresponding changes, if accepted, will address almost all comments on clause 7 (211 total), 6 comments on clause 9, and many related comments on clause 10. Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Overview of the Recommended Changes Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Overview of the Recommended Changes Create a new management frame called a “quick beacon” Quick beacon features: Transmitted on demand, not periodically Subject to back-off (transmitted after DIFS + random back-off) Handles larger information elements (IEs) Use frame type 00 (management), subtype 0111 (currently reserved) The proposed changes will result in merely 2 ½ bytes of changes to the frame currently used (WAVE Announcement) to start a WAVE BSS Changes the frame subtype (½ byte), and eliminates action frame fields category and value (2 bytes) Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

The Need for Quick or “On-Demand” Beacons Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 The Need for Quick or “On-Demand” Beacons In the vehicular environment, vehicles and roadside stations will be transmitting simple, non-IP data messages (typically broadcast) in the absence of a BSS The on-demand/quick beacon allows an application or upper layer to request the transmission of one or more beacons to establish a BSS as needed rather than unnecessarily congesting the medium with periodic beacons (e.g. every 100 ms) from vehicles or stations mounted along the roadside The current ad hoc networking mechanism is not scalable to support rapid movement and rapidly increasing/decreasing numbers of stations within range of each other (this has been well documented) Using a separate management frame (different subtype than the standard beacon) avoids affecting the organization of the base document and corresponding beacon processing mechanism descriptions (the quick beacon can be processed independently of the traditional beacon if desired) Note: The extended length WAVE Service Information Element present in the quick beacon permits inclusion of application and/or upper layer specific information that is outside the scope of Layer 2 Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Current WAVE Announcement Contents Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Current WAVE Announcement Contents Order Information Element 1 Timestamp 2 Capability 3 SSID 4 Supported Rates 5 EDCA Parameter Set 6 WAVE Service Information (WSI) Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Current Beacon Contents (REVma – D9.0) (items in red currently used in WAVE Announcement) Order Information Element 1 Timestamp 2 Capability 3 SSID 4 Supported Rates … 23 EDCA Parameter Set 24 QoS Capability Last Vendor Specific Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Quick Beacon Contents (items in red mandatory for WAVE) Month Year doc.: IEEE 802.11-yy/xxxxr0 Quick Beacon Contents (items in red mandatory for WAVE) March 2007 Order Information Element 1 Timestamp 2 Capability 3 SSID 4 Supported Rates … 23 EDCA Parameter Set 24 QoS Capability 25 WSI (has a 2-byte length field) Last Vendor Specific Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Quick Beacon Benefits The Quick beacon allows all fields used in a traditional beacon to be used in WAVE systems Introduces the capability to utilize additional information elements typically found in a beacon, such as spectrum management and additional QoS controls (congestion management mechanisms) Resolves regulatory concerns by ISO/CALM and other domains to the extent TGp can address them Allows beacon processing architecture to be used in implementations Maintains ability to include larger information elements (different management frame subtype) without affecting the structure of the current beacon frame Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Changes required Basic changes required to the wording in clauses 5, 9 & 11 Changes to frame formats in clause 7 required Changes are straight forward, requires small amount of reorganization Changes to service primitives in clause 10 required Change MLME-WAVEANNOUNCEMENT.xxx to MLME-QUICKBEACON.xxx Changes are straight forward Minor changes to Annex D (MIB) Request use of currently reserved management frame subtype from IEEE ANA Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2007 Recommendation McNew to prepare a motion for Thursday TGp session to accept “quick beacon” approach Justin McNew – TechnoCom, Dick Roy – SRA John Doe, Some Company