Layered Beacons, Content Differentiation and Adaptive Advertising Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Layered Beacons, Content Differentiation and Adaptive Advertising Date: 2006-03-08 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>. Stefano M. Faccin, Nokia John Doe, Some Company

March 2006 Abstract This document contains a partial proposal for TGu network selection requirements cluster, focusing on requirement N1 The slides refer to document 06/0286r1 The solution proposed is based on document 06/0073r0 Stefano M. Faccin, Nokia

N1: Optimized Discovery of Network Features and Roaming Rights March 2006 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). Stefano M. Faccin, Nokia

Analysis of Issues Issues are twofold March 2006 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 addresses Optimized Information Delivery Stefano M. Faccin, Nokia

Optimized Information Delivery March 2006 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 stations 2) 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 + content differentiation/adaptive advertising Stefano M. Faccin, Nokia

March 2006 Layered Beacons Concept summary: 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 Stefano M. Faccin, Nokia

March 2006 Options for Proposal NDB and/or NMB are broadcasted at “self-adjusting” regular interval Neighbor Reports can be used to deliver information Stefano M. Faccin, Nokia

Broadcasting at “self-adjusting” regular interval March 2006 Broadcasting at “self-adjusting” regular interval NDB and/or NMB are broadcasted with “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: Load AP operation Under ‘light load threshold’ NDB sent in every TBTT. Time to next NDB is set to 1. Between ‘light load threshold’ and ‘high load threshold’ Every n:th Beacon is NDB. Otherwise NMB is sent. Time to next NDB indicates when NDB ís sent next. Over ‘high load threshold’ NMB is sent in every TBTT. Time to next NDB is set to 31. ‘011’-‘111’ Reserved Stefano M. Faccin, Nokia

Broadcasting at “self-adjusting” regular interval (cont.d) March 2006 Broadcasting at “self-adjusting” regular interval (cont.d) 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. If the AP supports either .11e or .11k, then it is measuring the load anyway  determining whether to send NDB or NMB beacon is easy Threshold may be number of associated STAs, channel utilization or available admission capacity or combination of these Algorithm to select frequency is outside the scope of TGu Stefano M. Faccin, Nokia

Neighbor Reports Currently sent only if requested March 2006 Neighbor Reports Currently sent only if requested Overhead concerns not as bad as in case if broadcasted regularly regular broadcast always implies overhead in request/response the overhead is there only in case of real need assumption is that the STA will not request Neighbor Reports periodically => overhead is smaller 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 SSID filtering is possible Stefano M. Faccin, Nokia

Content Differentiation And Adaptive Advertising March 2006 Content Differentiation And Adaptive Advertising “Adaptive advertising”: if an STA missed the NMB or NDB, it uses Probe request/Response or other management frame defined for network selection to query 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 Stefano M. Faccin, Nokia

Analysis of proposal for N1 based on G1 March 2006 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 Stefano M. Faccin, Nokia

Analysis of proposal for N1 based on G2 March 2006 Analysis of proposal for N1 based on G2 G2: All proposals (whichever requirements they address) shall describe the security Security for NMB and/or NDB: this implies securing the content of the beacon See Jesse Walker’s presentation Securing neighbor reports: this is feasible, since the neighbor report is obtained from the AP the STA is associated with Stefano M. Faccin, Nokia

Analysis of proposal for N1 based on G3 March 2006 Analysis of proposal for N1 based on G3 G3: 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 are supported in that APs still continue to issue beacons containing the current information, so any STA not supporting the additional information can discard such information. An STA attempting to join a legacy AP will simply revert to current mechanism to perform network selection, i.e. based the selection on the SSID. Stefano M. Faccin, Nokia