TGu/TGv Joint Meeting

1. TGu/TGv Joint Meeting Authors: Date: 2008-05-11 Dorothy Stanley, Aruba Networks

2. Abstract This document contains the agenda and discussion slides for the May 13th Joint TGu/TGv Jacksonville session, and reference material from 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 • Ad-hoc meeting recommendation on mSSID, mBSSID and the way forward for TGu/TGv on this issue • AOB • Adjourn Dorothy Stanley, Aruba Networks

4. Discussion about mSSID/mBSSID and the way forward for TGu/TGv on this issue • “mSSID/mBSSID” 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 element 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 will be deleted from TGu, references to multiple SSID deleted from TGv • Each TG resolves LB comments based on the agreed direction Dorothy Stanley, Aruba Networks

6. Agree on way forward to “Enable efficient network discovery” • Current Situation: • Beacon frames (passive) and Probe Request/Response frames (active) are currently used for “discovery” • TGu Draft 2.0 introduces GAS protocol mechanisms to enable Beacon discovery “offload”, active only • Proposed way forward: remove Beacon discovery “offload” from TGu • Deal with “Beacon Bloat” as a separate WG effort, possibly a new SG/TG • The issue is thought to be a difficult one in which to gain consensus among WG members and, if included, would unnecessarily delay TGu’s schedule • Implication: SSID Container element & Multiple SSID set elements deleted from TGu • Each TG resolves LB comments based on the agreed direction Dorothy Stanley, Aruba Networks

7. Motion The ad-hoc recommendation on the proposed way forward, as described in slides 5 & 6 of this document should be used by TGu and TGv to amend their drafts. • Yes • No • Abstain Dorothy Stanley, Aruba Networks

8. Reference slides from April 30th ad-hoc Dorothy Stanley, Aruba Networks

9. 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

10. 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 will be deleted from TGu, references to multiple SSID deleted from TGv • Each TG resolves LB comments based on the agreed direction Dorothy Stanley, Aruba Networks

11. 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”, not used for “finding the first AP” • 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

12. 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 7.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 GAS Request/Response frames can carry 7.3.2 elements (encapsulated in new 7.3.3 elements), and provide a new discovery mechanism Dorothy Stanley, Aruba Networks

13. 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

14. 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

15. 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

16. 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

17. Other areas of common interest for TGu/TGv • Location capability indication • Supported, as per prior TGu request • Location data exchange • Supported in multiple IETF standard data formats • Location/E-911 often required for regulatory reasons • TGu assumed that there was a MAC level location data exchange, as provided in TGk, TGv, required for providing E911 service • TGu Generic Advertisement • Enables exchange of additional discovery data Dorothy Stanley, Aruba Networks

18. References Dorothy Stanley, Aruba Networks