TGu/TGv Ad-hoc Meeting

1. TGu/TGv Ad-hoc Meeting Authors: Date: 2008-04-30 Dorothy Stanley, Aruba Networks

2. Abstract This document contains the agenda and discussion slides for the April 30th, 2008 TGu/TGv ad-hoc, San Jose, CA. Dorothy Stanley, Aruba Networks

3. Agenda • Roll Call • P&Ps and Call for essential patents • Discussion about mSSID and the way forward for TGu/TGv on this issue • Other areas of common interest for TGu/TGv • Agenda items for joint TGu/TGv meeting in Jacksonville • AOB • Adjournment Dorothy Stanley, Aruba Networks

4. Discussion about mSSID and the way forward for TGu/TGv on this issue • “mSSID” issue consists of • Means to instantiate “a lot of networks on one AP device” where “network” is identified by an SSID • Enable efficient network discovery, where “Discovery” is finding the first AP Dorothy Stanley, Aruba Networks

5. Agree on a single mechanism to instantiate “a lot of networks on one device (virtual APs)” • Current Situation: • A Multiple BSSID capability was defined in TGk, as a result ofwanting to make Measurement Pilot frames more efficient when multiple BSSIDs (virtual APs) are present. • TGv Draft 2.0 adds the capability to use a single Beacon Frame to advertize a group of BSSIDs. Maintains single STA-BSSID-AP-BSS--DS structure. • TGu Draft 2.0 adds a multiple SSID per BSSID capability, with a unique group key per SSID. Changes single STA-BSSID-AP-BSS--DS structure. • Proposed way forward: Use Multiple BSSID mechanism • Maintains single STA-BSSID-AP-BSS--DS structure. • Builds on TGk capability • Implication: Multiple SSID mechanism is deleted Dorothy Stanley, Aruba Networks

6. Efficient Network Discovery (Finding the first AP) – Current Mechanisms • Differentiate between “finding the first AP” (Discovery) and “finding the candidate AP(s) when transitioning from the current AP”. • Beacon frames (passive) and Probe Request/Response frames (active) are currently used for “discovery” • Beacon and Probe Request/Response frames are currently used for “finding the candidate AP(s) for transition” • The neighbor report is used for “finding the candidate AP(s) for transition” • Measurement Pilot useful for determining that an AP is present, but does not provide enough information to determine that the AP is the AP with the right characteristics – SSID, security, QOS, etc. .  Dorothy Stanley, Aruba Networks

7. Efficient Network Discovery (Finding the first AP) – TGu mechanisms • 11u adds .21 query access, which enables the AP to determine the required SSID (know which network to use) • TGu takes on the problem of “discovery squared”, in which a lot more information is available about the back-end networks.  • The desire is to keep as much of this new information as possible out of the Beacon frame.  • The mechanism used in TGu for discovery of the new information consists of new frame exchanges (GAS Initial/Comeback Request and Response Frames .4.7.9-7.4.7.12) and new elements (7.3.3).  • The intent is to use native GAS Request and Response frames instead of Probe Request and Response frames for a STA to get this new info • Active scan solution. No passive scan mechanism provided for the new info. • The new frames can carry (encapsulated) 7.3.2 elements, and provide a new discovery mechanism Dorothy Stanley, Aruba Networks

8. Efficient Network Discovery (Finding the first AP) TGu mechanisms - 2 • The new frames can carry (encapsulated) 7.3.2 elements, and provide a new discovery mechanism – should such a new mechanism be added? • Ideal is to have a single query – STA sends one query (containing one or more SSIDs) to one AP/BSSID, gets one frame back with all of the SSIDs and BSSIDs in the multiple BSSID set that serve the queried SSID.    • Could Use Native GAS Request/Response protocol with new element to encapsulate 7.3.2 elements. SSIDC element in (TGu7.3.2.65) would be deleted  and not included in Probe Request and Response frames, native info multiple SSID set element TGu 7.3.3.2) would be renamed, change to include a new element that would carry the 7.3.2. elements that are needed for “discovery”  • No active mechanism for 7.3.3 elements. Is this ok? • Which 7.3.2 elements would be required/allowed/disallowed in the new 7.3.3 element? • Does the encapsulation mechanism overlap with the non-transmitted BSSID profile sub-element? • Could Use Probe Request and Probe Response, would need a mechanism to include the 7.3.3 elements (define as 7.3.2 elements) Dorothy Stanley, Aruba Networks

9. Additional Discussion – Beacon & TGv • The Beacon includes “operational”  information for the BSS, e.g. TIM and “informational” elements •  The Beacon is currently used for both “discovery” and to “find AP(s) at transition”, and provides passive scanning • TGv mechanism introduced to reduce number of Beacons needed to be transmitted when multiple BSSIDs are present; reduces total air-time used by Beacon frames • Non-transmitted BSSID profile, Extend TGk Multiple BSSID Set definition • Non-transmitted BSSIDs “inherit” from the transmitted beacon, and include only elements that differ from the transmitted beacon • No “informational” elements are removed from the Beacon, keep passive discovery capability Dorothy Stanley, Aruba Networks

10. Additional Discussion – Beacon & TGv & TGu • Beacon is used for discovery; want passive discovery to be supported -as much in Beacon as possible, so discovery is easy and passive • Concern about increasing size of the beacon. One approach is to move to active discovery – Probe Request/Response/other new mechanism. • There are tradeoffs. Battery powered devices don’t want to stay awake to receive a long beacon. But if have a lot of stations using active discovery – have probe request/response pollution, and keeping number of frames to a minimum isan advantage (e.g. few APs, lots of devices) • In an AP with u&v support, and both legacy stas & u&v stas, can send Probe Request or GAS request and receive same info. • Fundamental question is: do we want a new mechanism for discovery, and move discovery info out of the beacon? If not, use the existing beacon and probe mechanism. • If put restrictions on what is in the Beacon, need to be all-knowing about the current and future uses of the currently included elements. • There may be ways to minimize what is in the Beacon instead. Dorothy Stanley, Aruba Networks

11. Additional Discussion – Probe Request & TGv • SSID List element added to minimize the number of Probe Request frames sent, can include a list of SSIDs in the request • In the case of a legacy STA and a TGv/TGu capable AP, error case could occur that a STA sends Probe Request,to one of the non-transmitted BSSIDs. AP should not respond, since STA could not remain associated to that AP. • One solution is to have an indication in the Probe Request that the STS supports multiple BSSIDs, and non-transmitted BSSID Probe Response would not be sent to STA without this indication. Dorothy Stanley, Aruba Networks

12. Other areas of common interest for TGu/TGv • Also discuss what parts to keep in TGu vs TGv. Dorothy Stanley, Aruba Networks

13. Agenda items for joint TGu/TGv meeting in Jacksonville • Summary of Ad-hoc discussion • Identify points of agreement • Identify open issues, if any • Next Meeting • AOB • Adjourn Dorothy Stanley, Aruba Networks

14. References Dorothy Stanley, Aruba Networks