Download - Winot Overview Proposal Tgu Network Selection Requirements Cluster

January 2006

Stefano M. Faccin, NokiaSlide 1

doc.: IEEE 802.11-06/00112r0

Submission

WiNOT Consortium: Proposal For TGu Network Selection Requirements Cluster

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 <[email protected]> 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 <[email protected]>.

Date: 2006-01-15

Name Company Address Phone email Stefano M. Faccin

Nokia Dallas, TX USA +1 972 894 5000 [email protected]

Jari Jokela Nokia Tampere, Finland +358 718060445 [email protected]

Jon Edney Nokia Cambridge, UK +44 1353648567 [email protected]

Authors:

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

WiNOT consortium

• This presentation is made on behalf of the WiNOT (Wireless NetwOrking Technology), comprising:– Intel

– Nokia

– Siemens

– Panasonic

– STMicroeletronics

– Cingular

– BenQ

– T-Mobile

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Proposal Overview

• Optimized Discovery of Network Features and Roaming Rights, support of multiple SSPNs, identification of interworking services– Passive information discovery

• ESSID• Optimized Information Delivery

– Active information discovery:• Optimized Power Saving Querying Mechanism

– Optimized Information Delivery• Layered Beacons• Content Differentiation And Adaptive Advertising

• Advertisement of usage charges– Based on above solution, with simplified alternative provided

• Addresses N1, N3, N4 and N5

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Requirement N3

• Define functionality to support authentication with multiple SSPNs through a single AP.

• There are two issue with this requirement1. Advertising the availability of the SSPNs

2. Directing authentication and subsequent data to the correct SSPN

• Issue (1) requires a scalable mechanism to provide information to the STA prior to connection

• Issue (2) requires additional state information connected to STA association so that messages can be directed to the appropriate SSPN

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Advertising capabilities

• Most schemes require modification to beacons

• There are lots of problems with SSID apart from inability to advertise SSPN (see 11-05-0971 “Redefining SSID”)

• If we are to add the capability to meet N3 requirement then there is the opportunity to improve the operation of SSID in general

• Therefore we propose to meet the N3 requirement through the definition of ESSID as previously presented to TGu

Requirement N3

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Advertising SSPN through ESSID

• In the ESSID proposal the SSPN supported is identified by a 16 bit Path Selector

• The Path selector value can be computed by hashing the public name of the SSPN with the ESSID value– the purpose of the Path Selector is to enable the STA to identify a

particular service provided by the AP and ESS

– Now the AP can advertise a reasonable number of services efficiently

• Thus STA can compute the target hash and (with high confidence) whether the AP supports the required SSPN simply by observing the Path Selector in the beacon

• STA will confirm full name SSPN in SSID field during association.

Requirement N3

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

New ESS-ID Element

• New ESS-ID element to be carried in beacon and probe requests.

• ESS-ID element to be included also in 802.11r to provide post-authentication verification that it was not modified or forged.

ESS Address ESS NamePath Selector

CountPath

Selectors

6 Octets 0 – 32 Octets 1 Octet

ENLn*

2

* EN Ln: length of ESS Name, 0 = ESS Name not present

Variable

Additional SSPNs (optional)

1 Octet

Requirement N3

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Passive versus Active Discovery

• Thanks to the additional (optional) SSPN/services IE, the STA knows whether the whole list of services is advertised in the beacon or not

• In case the STA does not discover the desired service advertised in the beacon (passive discovery), it can perform an active discovery (e.g. through a query).

• Active discovery in following slides for support of requirement N1• Passive discovery when the ESSID and path selectors are used is also

described in the support for N1 • Passive discovery is also applicable to TGr when deciding where to

perform the fast transition– When STA wants to transition to different AP is scans for AP which:

• have the same SSID• have the same ESSID-Value• ESSID includes the same path selector as currently in use

– This gives assurance that the AP will support connectivity to SSPN upon transition.

Requirement N3

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Security analysis based on G2

• If a rogue AP copies the ESSID from a genuine AP it will appear to be valid

• However rogue AP cannot simply accept any and all SSPN requests - it must advertise a limited set

• Full name of SSPN must be submitted at association

• Real Authentication occurs using EAPOL as currently defined in the standard

Requirement N3

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Addressing N3 Requirement

• This approach provides solution for N3– Mechanism provided for the AP to advertise the SSPN compatible

with requirement N1

– Connection procedure allows STA to confirm required SSPN

– AP filters traffic to SSPN according to local policy

• Use of ESSID provides a mechanism to efficiently advertise and specify SSPN

• Use of ESSID enabled assurance the transition target AP will support required SSPN

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

N1: Optimized Discovery of Network Features and Roaming Rights

• N1: Define functionality by which a STA can determine whether its subscription to an SSPN would allow it to access a particular 802.11AN before actually joining a BSS within that 802.11 AN. Proposals must describe their consideration of scalability. – It’s not acceptable for a STA to be required to attempt IEEE

802.1X authentication with all available networks until it finds one that works. Equally a solution is not practical if it requires every possible credential supplier to be listed in a beacon (due to scalability problems).

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Analysis of Issues

• Issues are twofold– Need a mechanism to enable an STA to discover in an optimized

manner whether it has roaming rights, and potentially information related to the network

– Need an optimized way for network to provide information to stations

• Proposal has two components:– Part I: Optimized Discovery for STA– Part II: Optimized Information Delivery– Support or either Part I or Part II or both is advertised to the

stations, e.g. in beacons and possibly in Neighbor Reports (2 bits are sufficient)

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Part I: Optimized Discovery for STA

• Currently the burden is on the STAs to know information on the network a-priori (e.g. list of all SSIDs for which the STA has a roaming agreement) in order to identify whether the STA has roaming in a given network and therefore perform network selection

• Idea is to shift burden from the station to the network and enable optimized discovery for the STA

Requirement N1: Part I

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Optimized Discovery for STA: Active Discovery

• Approach is similar to doc. 11-05/0870r0 “802.11 TGu Initial Network Selection Concept ”

• However, the approach is modified as follows– The Probe Response is extended to return one or more SSIDs that the STA can

use for access while roaming using the credentials/identifier provided in the query.

• Considering the solution for N3, also the ESSID and Path Selector values should be returned.

– The Probe Response is extended to return additional IEs related to the SSID or list of SSIDs, in case the AP is configured to return such information to the STA e.g. to facilitate the decision of the specific SSID to use, or to provide additional information to enable the STA to connect to the network

• A different management frame can be defined for the active discovery to avoid “overloading” the semantic of Probe messages


January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Optimized Discovery for STA: Passive Discovery

This is the passive discovery described in the ESSID description for support of N3


January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Part II: Optimized Information Delivery

• Network information is currently provided to STA through beacons, Probe Response and Neighbor Reports

• The beacon serves two functions:1) Maintaining the timing for the network and signaling to associated stations2) Advertising to stations that are in discovery mode

• Two of the drivers for requirement N1 are:– the beacon does not contain all the information required to enable an STA

to make an “educated” decision– The beacon cannot be extended by adding a large amount of information:

several past attempts to add new information to the beacon failed due to the impact of beacon size and frequency on e.g. the system capacity modifications to existing beacon size and frequency should be kept at a minimum

• Proposal: layering of beacons and content differentiation

Requirement N1: Part II

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Layered Beacons

• Idea: split overall set of information to be sent to STA into two message types: – the “Network Maintenance Beacon," that can be short and regular

– while the “Network Discovery Beacon," that can be sent at a lower frequency by the AP

• Network Maintenance Beacon (NMB) = ‘legacy’ beacon

• Network Discovery Beacon (NDB) = Network Maintenance Beacon + new 802.11u IEs


January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Options for Proposal

• NDB and/or NMB are broadcasted at “self-adjusting” regular interval– Depending on the system load either NDB or NMB is sent– The NDB can in particularly be sent seldom (e.g., DTIM or x DTIMs) and/or NMB

more often. Three scenarios can be defined:• Light load: NDB sent in every TBTT• High load: Only reduced beacons sent

– Thresholds may need to be signalled or timed to next NDB. This is needed because STA need to understand in which mode the AP currently is. Without this info the STA may wait for the NDB even if the load is high and AP is not sending the NDB.

– Likely some hysteresis is needed in order to avoid continuous switching between the modes.

• Neighbor Reports can be used to deliver information– Can be made (more) extendable similarly to probe responses, i.e., STA can ask

what info it wants.• Currently 7 bits free in Neighbor Report Request


January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Content Differentiation And Adaptive Advertising

• “Adaptive advertising”: – if an STA missed the NMB or NDB, it uses Probe

request/Response as described in Part I for querying the network

– The network can optionally monitor such requests and may decide, based on management algorithms, to change the type of information sent and the frequency, i.e. crating an adaptive "advertising" of information

– Adaptive advertising here refers only to the set of IEs being provided in NDB, not the frequency

• Also, the network can add the information to Neighbor reports in an adaptive fashion


January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Analysis of proposal for N1 based on G1

• G1: All proposals (whichever requirements they address) shall describe how they minimize battery consumption for mobile devices.

• Optimized Information Delivery: no impact on battery consumption– NMB sent exactly as today

– NDB sent with a variable frequency; if STA does not receives it, it can use active discovery to retrieve the information

• Cont.d

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission


• Part I: active discovery for information can have impact on power saving– Proposal addresses these concerns through the “optimized power

saving querying mechanism” described in the following slides.– Issues:

• Requiring a STA to wait indefinitely for a response to a query impacts considerably the power consumption

• for practical implementations, WFA has e.g. indicated that the Probe Response shall be returned within 5ms from the receipt of the Probe Request in order to support power saving

• Also, timing out (e.g. after MaxChannelTime) is not a realistic solution, since it may take considerably more time for the AP to retrieve the information and create a reply, therefore most queries would automatically time out

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Optimized Power Saving Querying Mechanism

• Assumptions:– The AP receiving a query from a station can determine whether the information is

available or not– If not available, the AP has the ability to retrieve such information

• Mechanism is out of scope

• Basic concept:– the mechanism enables an AP receiving a query from a station and not having the

information readily available to reply to the station that the AP is capable to provide the information requested, but that such AP cannot provide it right away

– The mechanism enables the AP to indicate to the station that the station needs to query again for the information

– Specifically, the AP may optionally return a query identifier QueryID (whose value is unique for the AP) to be used by the station to query such AP again without the need for indicating again the information elements required (this may be useful when more than one IEs are requested and are not available instantaneously at the AP, and performing a new query by providing again the list of IEs would imply a waste of radio resources), and by the AP to correlate the queries.

– The AP may optionally return also a time value ComeBackDelay determined by the AP and indicating how long the station shall wait before querying the AP again.

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Optimized Power Saving Querying Mechanism (cont.d)

STA APBacken

d

Probe Request (IE1, IE2, …, IEn)

“Come-back” Probe Request ([QueryID])

Probe Response (IEj1, IEjm,)

“Come-back” Probe Response ([QueryID], [ComeBackDelay])AP cannot provide IEj, IEk

Retrieve IEj1, …, IEjm

IEj1, …, IEjm

Typically

>>

5ms

< 5ms

< 5ms

Delay = ComeBackDelay

[X] : optional IE

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Optimized Power Saving Querying Mechanism (cont.d)

• The STA does not need to remain active while waiting to send the “come-back” Probe Request, therefore enabling power saving

• In case the STA is connected to an AP1 and is actively exchanging data frames with AP1, but wants to retrieve information from a target AP2, the STA does not need to remain on the AP2 channel while waiting to send the “come-back” Probe Request

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission


• G2: All proposals (whichever requirements they address) shall describe the security

• Security for Optimized Discovery for STA– Completely securing Part I (both active and passive discovery) implies securing

management frame exchange before the STA is authenticated and associated– This is not really in the scope of current TGw work– A foolproof solution is not realistic, unless solutions based on PKI are adopted

(scalability becomes then an issue, and DoS attacks on the AP can be carried out by rogue stations by forcing the AP to compute a large number of signatures)

– Proposal for Optimized Discovery for STA addresses some of the security threats• Security experts raised concerns that solutions that just reply “yes” or “no” to “roaming

queries” • Proposal enables a minimal level of security by requiring the AP to assert a set of

information (i.e. the list of SSIDs to be used for accessing the network), instead of simply reply “yes” or “no.” In this way, it is more complicate to implement an STA trap

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Analysis of proposal based on G2 (cont.d)

• Security for Optimized Information Delivery:– Security for NMB and/or NDB: this implies securing the content

of the beacon

– Securing neighbor reports: this is feasible, since the neighbor report is obtained from the AP the STA is associated with

Requirement N1

January 2006


doc.: IEEE 802.11-06/00112r0

Submission

Summary for Network Selection Cluster

• Proposal addresses N1, N3, N4 and N5, capitalizing on common concepts used to solve the various requirements

• Security and power saving implications of the proposal have been analyzed