1. Control Framework for 802.11v
January 2003
IEEE /100r1
Control Framework for v
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
Kwak, Rudolf
Submission

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

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

4. Motivation and Guidelines
The various Radio Resource Management functions that are proposed for v all require signaling
Proposed guidelines for defining v signaling:
Reuse the framework defined in earlier amendments
What was done in h TPC/DFS would be of particular interest to us here
Consider what is being done in current amendments (802.11r and k)
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

5. 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

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

7. Example: Deferral Management
New IE’s and new action frames building on top of what exists in h and k 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

8. 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 , 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 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

9. 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”
“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

10. 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 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

11. Comments and Discussion
Kwak, Rudolf
Submission