1. Multiple SSID Support Authors: January 2007 Date: 2007-01-15
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Multiple SSID Support
Date:
Authors:
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
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
January 2007
Abstract
This proposal describes an idea which facilitates multiple SSPNs to be represented on one AP and is called multi-SSID.
Each SSPN may be bound to an SSID and multiple SSIDs are bound to a single BSSID.
This facilitates scaling of hotspot APs to support multiple SSPNs.
Corresponding normative text is in r0.
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

3. Month Year
doc.: IEEE yy/xxxxr0
January 2007
Proposal update:
Update GAS native protocol to better accommodate addition future information
Addition of Emergency Networks Query and List which was needed for ESO and Emergency Services Realm features to support mSSID operation.
Text updated from 11-06/1473r1 shown in blue font
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

4. Month Year
doc.: IEEE yy/xxxxr0
January 2007
Overview
Each directly-connected SSPN may be assigned to a VLAN in the DS
APs are configured to support multiple SSIDs in a BSSID
Frames on a particular VLAN are bridged to/from corresponding SSID per AP’s configuration
Transmissions on SSIDs (which share a common BSSID) are cryptographically separated using different GTKs thereby keeping VLAN broadcast domains separated
Each SSID may have its own security settings (i.e., per-SSPN security configuration)
STAs discover supported SSIDs via Advertising (aka Action) frames
Based on GAS (Generic Advertising Service) as defined in u-D0.02
This proposal defines a Native Query Protocol which runs over GAS
Avoids beacon bloat which would otherwise occur due to length of SSID and related IEs.
4-way handshake used to deliver to STA the GTK and GTK ID corresponding to SSID with which it’s associated
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

5. Example Message Sequence Chart
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Example Message Sequence Chart
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

6. GAS Native Query Protocol
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Native Query Protocol
Advertisement Protocol IE {GAS Native Protocol}
Element ID
Length
Delivery Method
Advertisement Protocol ID
Octets: 1
Values:
x+2 2
0x3
GAS Native Query protocol:
Used to deliver L2 or higher layer information to STAs
Provided on a request basis so the information is not included in Beacons, thereby avoiding beacon bloat
Uses either multicast or unicast delivery method
Is intended to be handled locally by AP (not by server in DS)
GAS Capability IE includes Advertisement Protocol IE {GAS Native Protocol}
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

7. Advertisement Protocol IE
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Request IE
Element ID
Length
Advertisement Protocol IE
Query
Octets: 1
variable
GAS Request IE copied from u-D0.02 for reference purposes
GAS Native Query Protocol ID in Advertisement Protocol IE
GAS Native Query in Query field
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

8. Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Native Query IE
Element ID
(0)
Length
Native Query Info
Octets: 1
Variable
Query Info
Info ID
Capability List
mSSID List 1
Emergency Networks List 2
Reserved
3-255
Native query is a variable length list of 1-octet values which request desired information from AP
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

9. Advertisement Protocol IE
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Response IE
Element ID
Length
Advertisement Protocol IE
Response Info
Octets: 1
variable
GAS Response IE copied from P802.11u-D0.02 for reference purposes
GAS Native Query Protocol ID in Advertisement Protocol IE
GAS Native Query Response in Response Info field
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

10. GAS Native Query Response
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Native Query Response
Element ID
(1)
Length
Native Info IE #1
Native Info IE #2 (optional) …
Native Info IE #N (optional)
Octets: 1 2
variable
There is one Native Info included in the Native Query Response for each Native Query Info ID
This proposal supports three Native Info IEs: Capabilities List, mSSID List and Emergency Networks List (defined on next slides)
In order to keep native protocol simple, fragmentation of Query Responses is not supported
A response to a single query (i.e., Native Query Info length is 1 octet) by design will fit MSDU limit
If Query Response is larger than MSDU size, then error status code is returned. Status code is in the GAS Initial Response action frame which is not shown on this slide.
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

11. GAS Native Info: Capabilities List
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Native Info: Capabilities List
Info ID (0)
Length
Status Code
Info ID #1 (0)
Info ID #2 (optional) …
Info ID #N (optional)
Octets: 1 2
The Capabilities List defines a list of Info IDs which have been configured in this ESSID. Info ID(0) is always in the list by default.
The status code has the following values defined and shall be used in all Native Info responses defined. The following are the status codes and their associated meanings:
Status code = 0, requested information is present in response
Status code = 58, requested information corresponding to the Info ID of the query is not configured in this BSS
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

12. GAS Native Info: mSSID List
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Native Info: mSSID List
Info ID (1)
Length
Status Code
SSIDC IE #1 (optional)
SSIDC IE #2 (optional) …
SSID IE #N (optional)
Octets: 1 2
variable
Maximum number of SSIDCs (SSID Containers) is limited by the maximum MSDU size of the frame
SSIDC IE #1 is shown as optional since a query for this element, when not configured, would return only a failure status code and zero SSIDC IEs.
Goal is to support up to 32 SSIDs per BSSID (which is also the number of GTK IDs required—see subsequent slides)
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

13. GAS Native Info: Emergency Networks List
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Native Info: Emergency Networks List
Info ID (2)
Length
Status Code
ESO
Capability
SSID IE (conditionally optional)
Default Emergency Services Realm IE
(optional)
SSID IE
(conditionally optional)
Octets: 1 2
variable
With a single Native GAS query, STA can obtain all configured information relating to emergency networks (i.e., wireless networks which provide emergency service)
ESO bit and Default Emergency Services Realm IE are currently defined in u-D0.02
ESO bit in Interworking Capability IE is now also in ESO capability field (defined on subsequent slide)
ESO bit and Default Emergency Services Realm, as currently defined in u-D0.02 are defined for an SSID, so with mSSID feature and without this modification, binding of emergency network information to SSID could be ambiguous.
Note: the Default Emergency Services Realm IE and ESO capability could instead have been put into the SSIDC, but then STA seeking emergency network information would need to search the mSSID List.
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

14. GAS Native Info: Emergency Networks List (cont.)
Month Year
doc.: IEEE yy/xxxxr0
January 2007
GAS Native Info: Emergency Networks List (cont.)
The SSID IE immediately following the ESO capability is present only if the ESO network is defined; if present the SSID IE may contain either the default SSID or an SSID from the mSSID List.
The Default Emergency Services Realm IE is only present if this information has been configured on the AP
The SSID IE immediately following the Default Emergency Services Realm IE is present only if Default Emergency Services Realm IE is present; if present the SSID IE may contain either the default SSID or an SSID from the mSSID List.
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

15. Month Year
doc.: IEEE yy/xxxxr0
January 2007
SSIDC IE
Element ID
Length
SSID IE
RSN IE (optional)
Octets: 1
variable
RSN IE
If RSN IE is not included, then RSN IE contained in beacon applies to this SSID/ESSID pair
If RSN IE is included, then the RSN parameters MUST be the same for all APs in the ESS (as defined by the ESSID); this is helpful to support fast transition as mSSID List is not included in beacon frames
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

16. Emergency Services Only
Month Year
doc.: IEEE yy/xxxxr0
January 2007
ESO Capability field B0
B1 B7
Emergency Services Only
Reserved
Bits: 1 7
Emergency Services Only (ESO) bit defined in u-D0.02
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

17. Month Year
doc.: IEEE yy/xxxxr0
January 2007
Operational Comments
When AP receives a Probe Request from a legacy STA with wildcard SSID, it responds with default SSID (the one in the beacon).
When AP receives a Probe Request from legacy STA with non-default SSID in the mSSID list, it does not respond to Probe Request
To provide backwards compatibility with legacy STAs, TGu-capable non-AP STAs shall transmit Probe Requests and APs shall transmit Probe Responses in accordance with the “Use SSIDC in Probes” bit (see subsequent slides)
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

18. Use of SSIDC in Probe Requests
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Use of SSIDC in Probe Requests B0 B1 B2 B3 B4
B15
QoS Map
EBR
ESO
Use SSIDC IE in Probes
Reserved
Bits: 1 12
“Use SSIDC in Probes” bit is included for operation with legacy (non-TGu capable) STAs
If legacy STAs are associated or are actively scanning a BSS, B3 shall be set to 1
If no legacy STAs are associated and no legacy STAs have been actively scanning, then an AP may set B3 to 0.
If B3 is set to 0 and an AP receives a Probe Request from a legacy STA, the AP must set B3 to 1 within 1s for a minimum of 60s.
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

19. Use of SSIDC in Probe Requests (cont.)
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Use of SSIDC in Probe Requests (cont.)
If B3 is set to 1
TGu-capable non-AP STAs shall use the default SSID in Probe Requests and include an SSIDC IE containing the SSID which is being actively scanned; if the desired SSID is the default SSID, then TGu-capable STAs shall not include an SSIDC IE in Probe Requests.
APs receiving Probe Requests with an SSIDC IE shall use the default SSID and include an SSIDC IE containing the requested SSID and optional RSN IE in Probe Responses
APs receiving a Probe Request without an SSIDC IE shall not include an SSIDC IE in the Probe Response.
If B3 is set to 0
TGu-capable non-AP STAs shall not include the SSIDC ID in Probe Requests; rather they shall include the SSID IE specifying the desired SSID to actively scan whether or not that SSID is in the mSSID List.
APs shall not include an SSIDC IE in a Probe Response.
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

20. Extended GTK for Supporting Multiple SSIDs
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Extended GTK for Supporting Multiple SSIDs
Current limitations
Only one (+1 for rollover) GTK per AP currently supported
Current key ID only 2 bits
Number of SSIDs can easily exceed this
If identifiers are reused then STA does not know which key to use for which packet or even if it should decrypt the packet
Enhancements
Allow for multiple broadcast and multicast keys
Longer key ID allows for flexible key management
Reduces STA “guessing” and associated errors
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

21. Multiple GTK Hierarchies
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Multiple GTK Hierarchies
On the AP, each SSID may have its own GMK used to derive GTKs for each SSID
GTK[s] = PRF-X(GMK[s],“Group key expansion”,AA||GNonce)
Each GTK has its own ID
GTKID[s] is determined by the AP
Must support 64 IDs (32 SSIDs x 2 for rollover)
Minimum 6-bit ID is necessary
Proposal makes used of reserved key ID bits in CCMP header (protected header)
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

22. MPDU Format with Extended GTK
Month Year
doc.: IEEE yy/xxxxr0
January 2007
MPDU Format with Extended GTK
Frame Header
CCMP Header
(8 bytes)
Data
MIC
PN0
PN1
Rsvd
Ext Key ID
Ext IV
Key ID
PN2
PN3
PN4
PN5 b0 b4 b5 b6 b7
Key ID Byte
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

23. Month Year
doc.: IEEE yy/xxxxr0
January 2007
Extended Key ID
Extended key ID uses 5 reserved bits in the CCMP header key ID field
Combined with existing key ID this provides 7 bits
Enough room for 32 keys plus rollover
Existing implementations should work as today
Ignore reserved bits so will not be able to determine correct key
If key matches then decryption succeeds, else decrypt error
Implementations may be done in software as only multicast traffic is considered
New implementations avoid decrypt error
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

24. Extended GTK Key Management
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Extended GTK Key Management
GTK is established during 4-way handshake and/or group key handshake of using a GTK KDE
Extend existing GTK KDE format by using 5 reserved bits
Alternatively a new GTK KDE could be defined
Existing key ID could be used for key roll-over
Key ID Tx
Ext ID
Rsvd
GTK
Bits 0-1
Bit 2
Bits 3-7
1 byte
Length – 6 bytes
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

25. Comparison to TGv’s mBSSID
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Comparison to TGv’s mBSSID
Benefits of TGv’s mBSSID method
Provides greater flexibility of configuring an ESS than mSSID
Assuming each SSPN has its own BSSID, then QBSS Load indicates utilization of each SSPN
AAC field indicates remaining admission control capacity for SSPN
Benefits of TGu’s mSSID method
Does not require allocation of additional MAC addresses for AP
If MAC addresses installed on AP during manufacturing are used up (as in TGv method), mSSID feature still allows more SSPNs to be added to AP. In addition to better scalability, it provides better backward compatibility with existing AP HW.
Smaller beacon size
mBSSID adds up to 42N octets to beacon where N is number of SSIDs supported; SSID element adds up to 34 octets dependent on number of octets in SSID
If ESS supports 32 SSPNs, this could add up to 1344 octets to beacon
Assuming 1:1 correspondence of SSPN to mSSID, then QBSS Load identifies BSS utilization for multiple SSPNs
AAC indicates remaining capacity for all SSPNs on BSS
Provides more efficient resource utilization as STAs will interpret AAC for as collective BSS resources (i.e., better trunking efficiency)
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

26. Comparison to TGv’s mBSSID (cont.)
Month Year
doc.: IEEE yy/xxxxr0
January 2007
Comparison to TGv’s mBSSID (cont.)
mSSID and mBSSID have complementary benefits and coexistence is not mutually exclusive
Standardizing both methods gives operators the most flexibility in hotspot AP deployment
mSSID used when hotspot can be otherwise configured using IEs present in a single Beacon
mBSSID and mSSID when hotspot must support multiple configurations which are not possible using a single Beacon
Conceptually, this keeps mSSID simpler
No need for extra IEs to be included (per feedback from Melbourne meeting)
Eliminate ESSID from mSSID proposal (use mBSSID feature when necessary to configure two or more ESSIDs in a hotspot)
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

27. Month Year
doc.: IEEE yy/xxxxr0
January 2007
Benefits of Proposal
Directly-connected SSPNs can have their presence advertised via SSID at hotspots
Allows greater flexibility in mapping SSPNs to SSIDs
Each SSID may have its own RSN configuration
Each SSID has its own GTK thereby keeping SSPNs’ broadcast domains separated
Introduction of GTK ID facilitates STAs to differentiate bc/mc frames corresponding to the SSID with which they’re associated
Building this capability upon GAS Native Query (introduced herein) avoids beacon bloat
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

28. Month Year
doc.: IEEE yy/xxxxr0
January 2007
G1 Analysis
All proposals (whichever requirements they address) shall describe how they minimize battery consumption for mobile devices.
This proposal has possible effect on battery consumption
TIM bit in Beacon signals AP’s intention to commence transmission of broadcast and/or multicast frames
STAs in SSID(s) within corresponding BSSID share this bit
STA in one SSID will wake up and receive broadcast/multicast frames intended for STA in another SSID; frames will be filtered, but battery energy consumed
Battery life will be no worse than that using operation per baseline standard
Battery life impact of broadcast/multicast traffic has been addressed in TGv with FBMS (Flexible Broadcast/Multicast Service); FBMS was voted into TGv draft amendment
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

29. Month Year
doc.: IEEE yy/xxxxr0
January 2007
G2 Analysis
All proposals (whichever requirements they address) shall describe the security impact of the functions they propose.
This proposal improves security of overall solution
Minimizes crypto error by explicitly allowing cryptographic separation of the VLANs
Minimizes the potential for information leakage across SSIDs by providing cryptographic separation of broadcast traffic between SSIDs so that only authorized parties have the correct GTK for decryption
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

30. Month Year
doc.: IEEE yy/xxxxr0
January 2007
G3 Analysis
All proposals must allow APs to serve legacy STAs in addition to STAs that have been upgraded to 11u. Proposals must describe how this is achieved.
Legacy STAs may not be capable of associating to SSIDs other than the SSID carried in the beacon—same situation for both mBSSID and mSSID.
De-crypt errors on bc/mc frames for some legacy STAs may cause undesired behavior (e.g., roaming); many legacy STAs already tolerant of decrypt errors.
Any undesirable effects can be mitigated by:
Having legacy STAs associate to default SSID/BSSID
Having legacy STAs associate to VAP (not the TGv type of VAP) or 2nd AP in hotspot configured without mSSID capability.
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company

31. Month Year
doc.: IEEE yy/xxxxr0
January 2007
Motion
Move to instruct the Technical Editor to include normative text from document 11-06/1935r0 for Multi-SSID feature into the TGu draft amendment.
Moved: Dave Stephenson
Second:
Yes = , No = , Abstain = .
Dave Stephenson et al, Cisco Systems, Inc.
John Doe, Some Company