Initial Network Selection Concept January 2006 IEEE 802.11-06/0072r1 January 2006 Initial Network Selection Concept Date: 2006-01-16 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Eleanor Hepworth, Siemens Roke Manor Eleanor Hepworth, Siemens Roke Manor

January 2006 IEEE 802.11-06/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

January 2006 IEEE 802.11-06/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

January 2006 IEEE 802.11-06/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

January 2006 IEEE 802.11-06/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

Passive Advertisement January 2006 IEEE 802.11-06/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

January 2006 IEEE 802.11-06/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

Information Format January 2006 IEEE 802.11-06/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

January 2006 IEEE 802.11-06/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

Overview of Operation January 2006 IEEE 802.11-06/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

New Information Elements January 2006 IEEE 802.11-06/0072r1 January 2006 New Information Elements NAI can be limited to “@realm” NAI in Probe Request NAI plus ack/nack flag in Probe Request Eleanor Hepworth, Siemens Roke Manor Eleanor Hepworth, Siemens Roke Manor

Requirements Conformance (Self Evaluation) January 2006 IEEE 802.11-06/0072r1 January 2006 Requirements Conformance (Self Evaluation) Addresses all of the requirements in the Network Selection Cluster of IEEE 802.11-05/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