1. TGu/TGv Joint Meeting Date: 2008-05-11 Authors: May 2008 Month Year
doc.: IEEE yy/xxxxr0
May 2008
TGu/TGv Joint Meeting
Date:
Authors:
Dorothy Stanley, Aruba Networks
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
May 2008
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
John Doe, Some Company

3. Agenda Roll Call P&Ps and Call for essential patents
May 2008
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. May 2008
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. May 2008
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 of wanting 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”
May 2008
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. May 2008
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
May 2008
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
May 2008
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. May 2008
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 of wanting 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. May 2008
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
Month Year
doc.: IEEE yy/xxxxr0
May 2008
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 ) 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 elements (encapsulated in new elements), and provide a new discovery mechanism
Dorothy Stanley, Aruba Networks
John Doe, Some Company

13. Efficient Network Discovery (Finding the first AP) TGu mechanisms - 2
May 2008
Efficient Network Discovery (Finding the first AP) TGu mechanisms - 2
The new frames can carry (encapsulated) 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 elements. SSIDC element in (TGu ) would be deleted  and not included in Probe Request and Response frames, native info multiple SSID set element TGu ) would be renamed, change to include a new element that would carry the elements that are needed for “discovery” 
No active mechanism for elements. Is this ok?
Which elements would be required/allowed/disallowed in the new 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 elements (define as elements)
Dorothy Stanley, Aruba Networks

14. Additional Discussion – Beacon & TGv
May 2008
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
May 2008
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 is an 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
May 2008
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
May 2008
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. May 2008
References
Dorothy Stanley, Aruba Networks