Control Framework for 802.11v January 2003 IEEE 802.11-03/100r1 Control Framework for 802.11v Authors: 2005-07-21 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>. Kwak, Rudolf Submission

January 2003 Joe Kwak, Marian Rudolf (InterDigital) IEEE 802.11-03/100r1 July 2005 doc: IEEE 802.11-05/0500r1 Control framework in 802.11v Joe Kwak, Marian Rudolf (InterDigital) Submission Kwak, Rudolf

Outline of Observations and Suggestions Motivation and proposed guidelines for control framework with 802.11v Examples Dynamic Channel Selection Network-controlled Load Balancing Deferral management (e.g. Power/EDT control) Management Control Interface Options Kwak, Rudolf Submission

Motivation and Guidelines The various Radio Resource Management functions that are proposed for 802.11v all require signaling Proposed guidelines for defining 802.11v signaling: Reuse the framework defined in earlier amendments What was done in 802.11h TPC/DFS would be of particular interest to us here Consider what is being done in current amendments (802.11r and 802.11k) Make it simple and easy to implement The following are representative examples using three different radio resource management work areas: Seamless channel switching (e.g. dynamic channel selection) Network-controlled load balancing Deferral management (e.g. Power/EDT control) Kwak, Rudolf Submission

Example: Seamless channel switching 802.11h already tackled this problem: DFS “Channel Switch Announcement” IE can be attached to the Beacon or Probe response frame or sent in a dedicated action frame Modified channel switch intention element format Add a transaction ID to be able to pair with response Possibility of appending measurements or reason code Element ID Length Channel switch mode New channel number Channel switch count Element ID Length Channel switch mode New channel number Channel switch count Transaction ID Measurements Reason Kwak, Rudolf Submission

Example: Network-controlled Load Balancing Load balancing can be split into decision phase and execution phase Let 802.11v focus on decision and rely on 802.11r for the execution Kwak, Rudolf Submission

Example: Deferral Management New IE’s and new action frames building on top of what exists in 802.11h and 802.11k with minimal modifications New Deferral management IE’s Deferral management capability Supported CCA modes, Max/Min Tx power, Max/Min EDT Deferral management reports and requests CCA mode, EDT, Tx Power operational settings (or range) (some of these already proposed in TGk statistics) Deferral management set command Single IE could be used for both direct and indirect control modes New Deferral management action frames Deferral management request + reports Kwak, Rudolf Submission

Summary of what needs to be done For each functionality, decide which management frames are needed: Action frames (section 7.4) Other management frames (section 7.2.3) Add required new information fields in non-action management frames Section 7.2.3 Add new category in the action field for Radio Management Section 7.3.1.11, Table 19a Add new action frames (section 7.4.x) Add new Radio Management Information Elements Section 7.4.x for IEs strictly used by action frames Section 7.2.3 for IEs if used by frames other than action frames For the three examples mentioned before we estimate the need for ~3-4 new 2-way, management action frame exchanges total ~10 information fields or elements total Kwak, Rudolf Submission

Thoughts on 11v Management Control Interface Primarily, use MIB’s as baseline management interface for AP and STA MIBs has always been the de-facto standard for IEEE 802 Admitted, MIB’s have several major shortcomings Admitted, many people are notoriously unhappy with SNMP… But there is no clear-cut attractive alternative in sight today (XML ?) TGv has defined work area to investigate this further. For now, continue to assume MIB’s as simple baseline working assumption for 11v (too much work to rip apart the concrete now) 11v should consider simple alternatives such as MAC/SME management “API” or “SAP”? In this context, must study what is currently proposed by other 802 groups: 802.1 “Media Independent RF Management of Wireless 802 Networks” 802.21 “Media Independent Handover” Trial this new approach with a selected set of few (3-4) key RF settings and RF performance metrics for setting/reporting through a new MAC/SME API/SAP in APs with 11v Set Operating channel, Tx power/EDT/CCA, Network name, Disassociate MAC-address#N Report Link quality, Throughput/Load, Inst. Data rate Kwak, Rudolf Submission

MAC/SME API/SAP Management Server or Application BLUE: can be proprietary, may be standardized RED: standardized Management Management Management Agent Agent Agent MAC API/SAP MAC API/SAP MAC API/SAP MIB MIB MIB SME SME SME MAC PHY MAC PHY MAC PHY AP1 AP2 AP3 MAC API/SAP could be a quick and easy alternative to MIB’s for simple yet essential RF management tasks in 802.11 WLANs Nothing needs to be standardized above L2 and for the DS Removes the need to modify in SME itself, management agents (SNMP etc.) could be external Kwak, Rudolf Submission

Comments and Discussion Kwak, Rudolf Submission