1. Virtual AP Requirements
January 2005
doc.: IEEE /xxxx
July 2005
Virtual AP Requirements
DATE: July 2005
Author(s)
Name
Company
Address
Phone
Pat R. Calhoun
Cisco Systems, Inc
170 West Tasman Dr.,
San Jose, CA 95134
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 <
Pat R. Calhoun, Cisco
Pat R Calhoun, Airespace

2. January 2005
doc.: IEEE /xxxx
July 2005
Abstract
TGv has identified virtual APs as a possible requirement. This document proposed some requirements that could be adopted by the task group.
Pat R. Calhoun, Cisco
Pat R Calhoun, Airespace

3. Introduction
July 2005
Most enterprise class WLAN devices on the market today support multiple SSIDs. This allows for segmentation of traffic over the air, extending a “VLAN-like” concept over
However, in order to maintain compatibility with stations, these devices have a single BSSID per SSID supported. Consequently, these devices must transmit a beacon for every SSID.
This creates two issues:
Utilizes unnecessary air time
Makes it impossible to distinguish a physical device from a logical device
Pat R. Calhoun, Cisco

4. Terminology
July 2005
Physical AP: An access point advertising a BSSID (base BSSID)
Logical AP: Any additional BSSID being advertised by a physical AP
Generally increments off base BSSID, for instance base BSSID is 00:01:02:03:04:00, while first Logical AP is 00:01:02:03:04:01.
Pat R. Calhoun, Cisco

5. Air Time
July 2005
Imagine a scenario where an AP supports 5 SSIDs, with a beacon period of 100ms (default)
In order to advertise its services, the AP must transmit five beacons every beacon period
Assuming a basic data rate of 1Mbps, and a beacon size of 90 bytes, the average airtime for each beacon would be 800 usecs.
Combining the beacons would eliminate the additional PIFS
Currently, optimizations are done by some vendors to only send a portion of beacons every beacon period, and change the list of SSIDs to ensure every SSID is advertised every n period.
Pat R. Calhoun, Cisco

6. Virtual vs. Physical AP
July 2005
Advertising more than a single SSID (hence BSSID) does not permit a STA (or neighboring AP) to determine whether beacons are generated from a single physical device.
extensions, such as k, could greatly benefit from knowing whether a BSSID is a physical vs. logical entity.
Pat R. Calhoun, Cisco

7. Proposed text Add the following text to the objectives document
July 2005
Add the following text to the objectives document
“TGv will support MAC extensions to improve support of virtual access points, in order to conserve air time as well as enhanced integration with radio measurement extensions, such as TGk.
One example would be to allow a single AP to advertise multiple SSIDs through a single beacon, where each SSID is mapped to a unique BSSID that may have a separate set of policies. Other alternatives to tie a virtual AP to a physical AP would also be acceptable.”
Pat R. Calhoun, Cisco

8. Question?
July 2005
Pat R. Calhoun, Cisco