1. WAVE without beacons Date: 2007-05-14 Authors: May 2007 Month Year
doc.: IEEE yy/xxxxr0
May 2007
WAVE without beacons
Date:
Authors:
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
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

2. Month Year
doc.: IEEE yy/xxxxr0
May 2007
Abstract
This presentation contains a proposal for an approach to WAVE that does not require changing or using beacons, which will address almost all comments on clause 7 (211 total), 6 comments on clause 9, and many related comments on clause 10.
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

3. Month Year
doc.: IEEE yy/xxxxr0
May 2007
Background
We are designing a communication system for vehicular environments (WAVE)
In WAVE environments, there is insufficient time for the standard BSS establishment process – WAVE requires an immediate communications establishment that is not supported by traditional beaconing, authentication and association mechanisms
See document p from March plenary, which addresses the reasons for not being able to use beacons (e.g. ad hoc beacon mechanism scalability)
While ITS systems based on WAVE are not expected to use traditional beacons, there is no reason to obviate the standard BSS/IBSS features as they may prove useful in limited instances
Facilities for higher layer synchronization must be included to provide maximum flexibility in PHY channelization configurations for supporting multiple regulatory domains
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

4. Month Year
doc.: IEEE yy/xxxxr0
May 2007
Basic Approach
Leave current beaconing and joining mechanisms unchanged and limit WAVE changes to requiring data communications in the absence of beaconing, authentication and association (data exchange in the absence of a BSS)
Remove WBSS and provider/user concepts from current p draft
Add a new management frame for WAVE:
WAVE management frame (Type: 11 Subtype <ANA>)
STAs for which dot11WAVEServicesImplemented is true will process both beacons and WAVE management frames
If dot11WAVEServicesEnabled is true beaconing, authentication and association are not used
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

5. WAVE Management Frame Contents
Month Year
doc.: IEEE yy/xxxxr0
May 2007
WAVE Management Frame
Contents
MAC header is the same as for current management frames
Allows inclusion of standard information elements present in the current beacon
Transmitted only as needed (rarely) for the purpose of indicating synchronization timing, regulatory domain information and changes to the EDCA parameter set (the WSI is no longer included)
Beacon interval is not included
Include a “Time Reference Information” field that indicates the source and accuracy of the local Timestamp with respect to an external time reference (fixed 8-octet field – see chart 7)
Supported by the MLME-SET/GET/INC/DECTSFTIMER.request/confirm/indication primitives included in current p draft
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

6. WAVE Management Frame Contents (items in red mandatory for WAVE)
Month Year
doc.: IEEE yy/xxxxr0
May 2007
WAVE Management Frame Contents (items in red mandatory for WAVE)
Order
Information Element 1
Timestamp 2
Time Reference Information (new) 3
Capability 4
SSID 5
Supported Rates …
… (other optional fields – see probe response frame from REVma D9) N
EDCA Parameter Set
N+1
QoS Capability
Last
Vendor Specific
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

7. Time Reference Information Format
Month Year
doc.: IEEE yy/xxxxr0
May 2007
Time Reference Information Format
Contents:
Time Source indicates the external source of the time reference
Local or external sources (e.g. common time reference based on UTC)
TSF Timer Error is the estimate of the offset of the Timestamp from the external time source
Set to 0 if the time source is local
Standard Deviation is the estimate of the standard deviation of the TSF Timer Error in the WAVE device’s estimate of the external time source
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

8. Overall WAVE Management Frame
Month Year
doc.: IEEE yy/xxxxr0
May 2007
Overall WAVE Management Frame
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

9. Month Year
doc.: IEEE yy/xxxxr0
May 2007
Additional Benefits
WAVE Management frame allows inclusion of existing information elements that support operation in multiple regulatory domains
Need to harmonize with CALM TC204
Need to change the regulatory classes to include various possible (frequency) channelization schemes
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

10. Inclusion of Additional Channelization Schemes
Month Year
doc.: IEEE yy/xxxxr0
May 2007
Inclusion of Additional Channelization Schemes
Regulatory
Class
Channel
Starting
Frequency
(GHz) BW
(MHz)
Channel set
Transmit
Power limit
(mW)
Emissions
Limits set
Behavior
<ANA>
5.000 40
174 – 181
6 – 10
11, 12 20
172 – 183 10 5
TBD
xxx-255
Reserved
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

11. Month Year
doc.: IEEE yy/xxxxr0
May 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-WAVEMGMT.xxx
Changes are straight forward
Minor changes to Annex D (MIB)
Request use of currently reserved management frame subtype from IEEE ANA
Request use of currently reserved regulatory classes from IEEE ANA
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC

12. Summary WAVE Management frame approach Addresses many comments
Month Year
doc.: IEEE yy/xxxxr0
May 2007
Summary
WAVE Management frame approach Addresses many comments
Replaces “Quick Beacon” proposal and WAVE Announcement Action Frame and preserves traditional beaconing mechanisms
Requires moving WSI to a higher layer data frame (MSDU)
Supports additional regulatory domains (i.e. supports ISO TC204 requirements)
J. McNew – TechnoCom, R. Roy – SRA, F. Simon – ARINC