1. Initial Network Selection Concept
January 2006
IEEE /0072r1
January 2006
Initial Network Selection Concept
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
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

2. January 2006
IEEE /0072r1
January 2006
Abstract
This document addresses the network selection requirements cluster R8N1, R8N2, R8N3, R8N4.
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

3. January 2006
IEEE /0072r1
January 2006
WiNOT consortium
This presentation is made on behalf of the WiNOT (Wireless NetwOrking Technology), comprising:
Intel
Nokia
Siemens
Panasonic
Cingular
STMicroeletronics
BenQ
T-Mobile
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

4. January 2006
IEEE /0072r1
January 2006
Technical Approaches
There are three main technical approaches that can be considered
Virtual APs
Passive advertisement via Beacons/Probe Responses
Active discovery through Request/Response exchanges
The approaches are not mutually exclusive, they can be used in combination to provide the best solution for the type of network being deployed.
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

5. January 2006
IEEE /0072r1
January 2006
Virtual APs
Current solutions are not scalable or implemented consistently
Proposals exist to fix these problems, but there will still be limits to the amount of information that can be included.
Can be used to support scenarios where multiple operators share infrastructure
But does not allow these different operators to indicate valid roaming relationships
Are VAP proposals something we wish to consider within this group?
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

6. Passive Advertisement
January 2006
IEEE /0072r1
January 2006
Passive Advertisement
Provides a scalable approach to including roamed operator information in the beacon/probe response.
The information advertised may reflect the most commonly requested SSPNs (based on some sort of selection algorithm)
This list of SSPNs may be statically configured in the network, or updated dynamically depending on the capabilities of the infrastructure.
Used in combination with an “additional SSPNs available” bit to indicate that other SSPNs can be roamed to that have not been advertised.
Other SSPN information can be queried via an explicit request (see next section)
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

7. January 2006
IEEE /0072r1
January 2006
Overview of Operation
Realm strings (identifying SSPNs) may be quite long
Therefore, a hash of the string is used instead.
On receipt, the STA checks the hashes of the realms it has credentials for against the hashes in the message.
Shorter hashes are good from a size point of view but may result in hash collisions
A hash collision may result in an STA attempting an authentication that can never succeed
However, this is no worse than the current situation anyway
Longer hashes reduce the possibility of collisions, but require more space
Solution: hash length can be altered adaptively
E.g. this could be chosen based on the number of realms being advertised or the network loading
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

8. Information Format January 2006
IEEE /0072r1
January 2006
Information Format
Initially, three flag bits are defined:
Bits B0 and B1 indicate the hash length that is being used:
00 = 1 octet
01 = 2 octets
10 = 3 octets
11 = 4 octets
B2 indicates whether additional realms are available that are not included in the list of hashed realms in this IE.
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

9. January 2006
IEEE /0072r1
January 2006
Active Discovery
Supports a directed query as to whether one or more SSPNs are accessible
could you wildcard for a complete list?
Messages could be exchanged using:
Probe request/response
Comments have been raised as to whether this is practical, probe messages use a lot of available air time already – would this exacerbate the problem?
Management (action) frames
Class 1 data frames
This choice needs to be considered further
i.e. we ran out of time on this point – TBC later…!
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

10. Overview of Operation January 2006
IEEE /0072r1
January 2006
Overview of Operation
Currently based on the Probe mechanism, but information formats could equally apply to other transport options
NAI given in Probe Request
Probe Response indicates whether the AAA infrastructure can authenticate the user
The querying of AAA infrastructure could be implemented as anything from inspecting a local configuration file through to dynamically probing the AAA infrastructure
The latter option is not currently supported by RADIUS operation
Most likely situation will be statically configured information in the local RADIUS proxy; assumes that enough information is available here?
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

11. New Information Elements
January 2006
IEEE /0072r1
January 2006
New Information Elements
NAI can be limited to
NAI in Probe Request
NAI plus ack/nack flag in Probe Request
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor

12. Requirements Conformance (Self Evaluation)
January 2006
IEEE /0072r1
January 2006
Requirements Conformance (Self Evaluation)
Addresses all of the requirements in the Network Selection Cluster of IEEE /0822r0 with a classification of ‘Required’
R8N1, R8N2, R8N3, R8N4
It does not attempt to satisfy the optional requirement R8N5 or the out-of-scope requirements R8N6 and R8N7.
Scalability issues considered
Directed messages
‘NAI Probe’ mechanism scales O(1) with number of SSPNs
Assuming probe is for a single SSPN only
Eleanor Hepworth, Siemens Roke Manor
Eleanor Hepworth, Siemens Roke Manor