November 2007

Doug Kavner, Raytheon

Slide 1

doc.: IEEE 802.11-07/2901r06

Submission

Use of BSSID in WAVEDate: 2007-12-06

Name Affiliations Address Phone email Doug Kavner Raytheon 1801 Hughes Drive,

Fullerton, CA 92834 714-446-2276 dkavner@raytheon.com

Authors:

November 2007

Doug Kavner, Raytheon

Slide 2

doc.: IEEE 802.11-07/2901r06

Submission

Abstract

A solution is proposed to permit simultaneous reception of BSS data frames and non-BSS data frames on the same channel by the same STA.

November 2007

Doug Kavner, Raytheon

Slide 3

doc.: IEEE 802.11-07/2901r06

Submission

Desired Functionality

• WAVE mode permits transmission of data frames without an established WAVE BSS using a wildcard BSSID

• It may be desirable now or in the future to permit this in conjunction with data frames within an established WAVE BSS from the same STA– 802.11p does not explicitly exclude this operation currently

– Note: BSSID for a WAVE BSS is the MAC address of the WAVE BSS Initiator

November 2007

Doug Kavner, Raytheon

Slide 4

doc.: IEEE 802.11-07/2901r06

Submission

The Problem

• There is no way to set the BSSID in a data frame to the wildcard BSSID while joined to a BSS

• The BSSID in transmitted data frames is the currently joined BSSID– BSSID is not currently specified on a frame-by-frame basis from

higher layers

– See IEEE Std 802.11-2007, clause 6.2.1.1.2

November 2007

Doug Kavner, Raytheon

Slide 5

doc.: IEEE 802.11-07/2901r06

Submission

Recommended Solution

• Add an optional parameter to MA-UNITDATA.request to specify a specific BSSID for the frame

• Add an optional parameter to MA-UNITDATA.indication to report a received BSSID other than the currently joined BSSID

• Use of the new parameters is not restricted to WAVE mode

November 2007

Doug Kavner, Raytheon

Slide 6

doc.: IEEE 802.11-07/2901r06

Submission

Implications of the Solution

• Received BSS data frames are still subject to traditional filtering

• Received non-BSS data frames are filtered on the non-BSSID criteria– 802.11p already contains the exception to allow reception of data

frames with a wildcard BSSID

• Higher layers must know when to set a specific BSSID– In WAVE, non-BSS data frames are for WSMP only

– WSMP can be enhanced to have knowledge of the new parameter

November 2007

Doug Kavner, Raytheon

Slide 7

doc.: IEEE 802.11-07/2901r06

Submission

Rejected Solutions (1)

• Using a non-wildcard WAVE BSSID for non-BSS data frames is problematic– Assume two nearby WAVE BSSs with BSSID=3 and BSSID=4

– STAs on BSSID 3 will filter all data frames from BSSID 4

– Non-BSS data frames sent from a STA on BSSID 4 will also be filtered by STAs on BSSID 3

– Running in promiscuous mode would circumvent the primary purpose of multiple BSSIDs, which is to permit filtering of broadcast/multicast data frames• See IEEE Std 802.11-2007, p. 78 first sentence

November 2007

Doug Kavner, Raytheon

Slide 8

doc.: IEEE 802.11-07/2901r06

Submission

Rejected Solutions (2)

• Resetting the MAC to change the BSSID is not feasible– Loss of MAC state and queued packets

– Latency

• Creating a MLME-SET-BSSID.request to change the BSSID without resetting the MAC would require tight coupling and synchronization of management and data planes

November 2007

Doug Kavner, Raytheon

Slide 9

doc.: IEEE 802.11-07/2901r06

Submission

Rejected Solutions (3)

• Set BSSID in the MAC Header to the wildcard BSSID when:– DA/RA is a locally administered multicast address with the non_bss_multicast_bit

= 1 (non_bss_multicast_bit is an arbitrary value to be selected by the editor)– Broadcast MAC address (FF FF FF FF FF FF) qualifies as a locally administered

multicast address with non_bss_multicast_bit = 1

• Implications to filtering of WAVE BSS Data Frames– Unicast Data Frames: None

• Filtering is already based on the RA alone

– Broadcast Data Frames: Filtering not supported• Use a specific multicast address instead

– Multicast Data Frames: Filtered if non_bss_multicast_bit = 0– Case of non_bss_multicast_bit = 0 when not joined to a WAVE BSS is undefined

• Note that to/from DS data frames are sent unicast• While this solution could work, after a long discussion in the November

2007 TGp sessions, the opinion of the group was that it is too clumsy

November 2007

Doug Kavner, Raytheon

Slide 10

doc.: IEEE 802.11-07/2901r06

Submission

Rejected Solutions (4)

• Add new MA-UNITDATA-NON-BSS.request/confirm/indication primitives to support transmission of data frames outside of a BSS– Parameters same as for MA-UNITDATA.request/confirm/indication

– BSSID in MAC Header always set to wildcard BSSID

– Permits a non-wildcard BSSID to be used for data frames sent with current MA-UNITDATA.request

• On receive, MAC would invoke MA-UNITDATA-NON-BSS.indication if the BSSID is the wildcard BSSID

• Splitting MA-UNITDATA creates confusion in the architecture and is not supportable in the long-term if other parameters need to be added

November 2007

Doug Kavner, Raytheon

Slide 11

doc.: IEEE 802.11-07/2901r06

Submission

Motion

• Move to accept the recommended solution and instruct the editor to make updates to the draft

• Moved:

• Second:

• For:

• Against:

• Abstain: