1. Management Frame Policy Definition
Month Year
Month Year
doc.: IEEE yy/xxxxr0
doc.: IEEE yy/xxxxr0
Management Frame Policy Definition
Date:
Authors:
Slide 1
Santosh Pandey, Cisco Systems
Page 1
John Doe, Some Company
John Doe, Some Company

2. Outline Requirements addressed
High level exchange – Association enterprise exchange
Policy advertisement
Policy request/report
Policy change request/response
Pre-association/Roaming policy
Legacy STA
IBSS – Exchange
Unless specified otherwise, all references to AP and STA in this presentation imply ae capable AP and ae capable STA respectively

3. Requirements to be addressed
Management policy definition and advertisement
Allow application of policy to groups of management frames
Advertise management frames’ priorities in beacons concisely
Pre-association policy advertisement and implementation
Post-association policy advertisement and implementation
STAs can exchange policies on demand
STAs can request change in policy
Details
ae-proposal-for-prioritization-of-management-frames.doc
ae-tech-proposals.doc
ae-tgae-requirements-and-use-cases.doc

4. High level exchange – Association enterprise exchange
Default policy is to send all management frames at highest priority (AC_VO)
Pre-association
Extended Capabilities IE bit will be set to indicate STA is ae capable. This IE is included in Beacons, Association Request/Response, Reassociation Request/Response and Probe Request/Response
The pre-association policy advertisement and adoption is described later
Association
AP shall include the entire management frame policy in (Re)Association Response
STA shall adopt this policy post-association to send all management frames
Post-Association policy
STA shall request associated AP for changing priority of any management frame if needed
AP shall respond will accept/reject response. The reject response shall include a reason code to indicate if the STA may or may not retry later
Any management frames whose priority is not modified by Management Frame QoS (MFQ) Policy is sent at AC_VO.
Sending entire policy in the beacon may get excessive
11 subtype frames (association etc)
2 Action/Action no ack which have category/action values
22 Categories defined (including 11s – <ANA>)
24 Action values (max) in WNM (categorty 10)
Out of 140 management frames, 79 management frames were identified to be sent at low or medium priority (Only high, low, medium considered in ae-management-frame-analysis.xls)

5. Management Frame QoS Policy IE
Element ID
Length
Priority Definition Count
Priority definition field #1
Priority definition field #2 (optional) …
Priority Definition field #n (optional)
Octets: 1
variable
This IE will be used to advertise and exchange MFQ policy between STAs
This IE is sent in Beacons, (Re)Association Response and Probe Response
Contents of IE in beacon frame should only be for frames which can only be transmitted in state 1 and 2. Pre-association details in later slides.
It will also be used in a new policy report frame and policy change request/response frame describe later
Priority Definition Count field indicates the number of Priorities Definition field included in the IE
List of Priority Definition fields contains one or more Priority Definition fields

6. Priority Definition Field (PrDf)
This field indicates a group of management frames and their corresponding priority
Guiding principles for this field:
To indicate priority of all management frames efficiently
Allow grouping of management frames having the same priority
Future proof – no change needed when future amendments add new management frames
This is an ordered list as explained in slide 14

7. Priority Definition Field: Type_PrDf=0
Bits: B0 B1 B2 B3 B4 B7 B0 B3 B4 B7 B0 Bn
Priority Definitio n Field Type
0 0 U M
Priority Definition Field Length
TID
Mgmt Frame Subtype
Category Value (optional)
Action Value Bitmap (optional)
Octets: 1
variable
Priority Definition Field Type (Type_PrDf) subfield is 2 bits in length and defines the structure of the Priority Definition field.
Unicast bit (U) is set if the management frames priorities defined in PrDf is applicable to unicast management frames
Multicast bit (M) is set if the management frames priorities defined in PrDf is applicable to multicast management frames
Priority Definition Field Length (Length_PrDf) subfield is 4 bits in length and defines the length in octets of the Priority Definition field, excluding the 1 octet used for Type_PrDf , U, M and Length_PrDf subfields. This can support maximum of 15 octets.
TID subfield is 4 bits in length and is defined in The management frames indicated in this priority definition field are sent at priority defined by this TID.
Management Frame Subtype (Subtype_PrDf) subfield is 4 bits in length. The values are defined in Table 7-1 for management frame type. For example,
a value of 0000 indicates Association Request management frame
a value of 1101 indicates Action management frame
Category Value (CV_PrDf) subfield is 1 octet in length and is included only for frames of subtype Action and Action No Ack
For example, a Category Value of 10 will indicate WNM category action frame when Subtype_PrDf = Action subtype
Action Value Bitmap (AVB_PrDf) subfield length is variable and it indicates the corresponding Action values
For example, setting Bit 0 and Bit 1 will indicate Event Request/Response when Subtype_PrDf = Action subtype and CV_PrDf = WNM Category
In all for any given category, a maximum of 104 action value frames can be supported in this format
This subfield is zero padded to complete any incomplete octet

8. Priority Definition Field: Type_PrDf=0
Action Value Bitmap subfield may be included for frames of subtype Action and Action No Ack and when the Category subfield is included
Each bit in the Action Value Bitmap subfield is mapped to the corresponding action value.
Multiple Action frames are indicated by setting multiple bits
This subfield is zero padded to complete any incomplete octet
Length_PrDf (octet(s))
Subtype_PrDf
CV_PrDf
AVB_PrDf
Description 1  
Policy to be applied to all management frames of the corresponding subtype 2
Policy to be applied to all action frames of corresponding category value belonging to the management subtype frames
>= 3
Policy to be applied to only Action frames indicated via the action value bitmap for corresponding category value and management subtype frames
Table: Valid combination of optional fields to be included in Priority Definition Field

9. Example 1 For example, above frame
Type_PrDf U M
Length_ PrDf
TID
Subtype_ PrDf
Category Value 1 3 13
Octets:
Action Value Bitmap B0 B1 B2 B3 B4 B5 B6 B7
Priority Definition Field
For example, above frame
TID = 1 (AC_BK)
Subtype = 13 (Action)
Category Value = 0 (Spectrum management)
Action Value Bitmap subfield (B7-B0) = , indicates frames with Action value = 0 and 1 (i.e. Measurement Request/Response respectively)
This indicates that the Measurement Request/Response of Spectrum Measurement Category will be sent at AC_BK priority

10. Example 2 For example, above frame
Type_PrDf U M
Length_ PrDf
TID
Subtype_ PrDf
Category Value 1 2 13 11
Octets:
Priority Definition Field
For example, above frame
TID = 0 (AC_BE)
Subtype = 13 (Action)
Category Value = 11 (unprotected WNM)
This indicates that all unprotected WNM Action frames will be sent at AC_BE priority

11. Example 3: Mgmt Frame Policy IE with 3 priority definitions
Element ID
<ANA>
Length 8
Priority Definition Count 2
Octets: 1
Type_PrDf U M
Length_ PrDf
TID
Subtype_ PrDf
Category Value 1 3 13
Octets:
Action Value Bitmap
Type_PrDf U M
Length_ PrDf
TID
Subtype_ PrDf
Category Value 1 2 13 11
Octets:
The above defines complete management policy IE which includes different priorities defined in examples 1-2 in previous slides

12. Considering trade offs for priority definition
Brute force – specifying subtype, category, action value for each management frame priority
Pros
Future proof – no change needed for any future amendments
Cons
Requires minimum 3 bytes for each management frame (TID, Subtype, Category, Action)
No grouping possible, each frame has to be individually specified
Very large size (237 octets) considering that 79 of the 140 management frames priority may need to be changed to low priority (from ae-management-frame-analysis.xls)
Lookup Table – have a table of bitmap for all the management frames
Can specify all the management frame for a given priority in a single Priority Definition field
Selectively define management frames in the table (implicitly club request/response to a single priority)
Size can be limited (with current management frames) to 19 octets
Requires table which needs to be updated for every amendment which introduces management frames
Table may grow too large for future
Extra lookup overheads in STA
Proposed scheme
Continued next slide …
Brute force 237 octets
79 x 3 = 237
Table lookup
140 management type = 1 octet TID + 18 octets map = 19 octets
Proposed scheme
52 octets for our size - Used only Field Type field = 00,
Default high –
1 M subtype (ATIM) – 2 octets
Some Low (1 octet Action Value bitmap) Categories = 0, 1, 5, 7, mesh – 4x5 = 20 octets
Some Low (2 octet Action Value bitmap) Categories = 4, Protected dual – 5x2 = 10 octets
Some Low (4 octet Action Value bitmap) Categories = x1 = 7 octets
All Low (0 octet Action Value bitmap) Categories = 2, 12, 126, x4 = 12 octets

13. Considering trade offs for priority definition
Proposed scheme
Pros
Provides some level of grouping/aggregation. Logically, priorities would be changed for contiguous set of Action values
Future proof – no change needed for any future amendments
All frame subtypes or categories can be aggregated
Requires minimum 2 octets and maximum 7 octets for all current subtype-category pairs. 52 octets will be required to change priorities of 79 of the 140 management frames (from ae-management-frame-analysis.xls)
Cons
A Priority Definition field can support only a single subtype-category pair of management frames. Multiple Priority Definition field is required for unique subtype-category pairs to be defined
Length of the IE may range from 3 to 255.
The priority of all management frames from the doc 10/097 to a single lower priority is 52 bytes
As there are only 3 AC other than AC_VO (the default priority), a maximum of 156 bytes (note we are counting same frames multiple times for this upper bound calculation) may be required for defining all management frame priorities
Brute force 237 octets
79 x 3 = 237
Table lookup
140 management type = 1 octet TID + 18 octets map = 19 octets
Proposed scheme
52 octets for our size - Used only Field Type field = 00,
Default high –
1 M subtype (ATIM) – 2 octets
Some Low (1 octet Action Value bitmap) Categories = 0, 1, 5, 7, mesh – 4x5 = 20 octets
Some Low (2 octet Action Value bitmap) Categories = 4, Protected dual – 5x2 = 10 octets
Some Low (4 octet Action Value bitmap) Categories = x1 = 7 octets
All Low (0 octet Action Value bitmap) Categories = 2, 12, 126, x4 = 12 octets

14. Optimizations: Policy Definition IE
Month Year
doc.: IEEE yy/xxxxr0
Optimizations: Policy Definition IE
Contents of IE in beacon frame should only be for frames which can only be transmitted in state 1 or 2 – partial management frame policy
There is an assumption that the number of subtypes that would be specified by priority would be small – from the excel sheet (doc 10/097) it will be 10 bytes.
The complete policy shall be sent to STA in (Re)Association Response
If same management frame is indicated in multiple Priority Definition fields, the management frame is sent at the priority defined in the last Priority Definition field
This can be used to set the priority of the entire category and change only specific action frames
For example, to set the entire WNM category (10) at AC_BE priority with the exception of Event Request/Report (Action value = 0,1), which are to be sent at AC_BK, the following sequence of Priority Definition fields can be used in the Management Frame Policy IE
Type_PrDf U M
Length_ PrDf
TID
Subtype_ PrDf
Category Value 1 2 13 10
Octets:
There could be an optimization to add an Action value index field – similar to a partial virtual bitmap. The best case scenario would save about 2 bytes
In the beacons only action frames allowed are public action frames
Set some at low priority = 5 bytes
-Other class 1 and 2 frames priorities are not changed except ATIM = 2 bytes
IE overhead = 3 bytes
Total = 10 bytes
Type_PrDf U M
Length_ PrDf
TID
Subtype_ PrDf
Category Value 1 3 13 10
Octets:
Action Value Bitmap
John Doe, Some Company

15. Management Frame QoS Policy action
Table 7-24—Category values
Code
Meaning
<ANA>
Management Frame QoS policy
Table X -- MPE Action field values
Action field value
Description
MFQ Policy Query Request 1
MFQ Policy Query Response 2
MFQ Policy Config Request 3
MFQ Policy Config Response 4
MFQ Policy Config Delete
The MFQ policy can be exchanged and changed using the above action frames

16. MFQ Policy Query Request
Category
Action
Dialog Token
Octets: 1
MFQ Policy Query Request frame body format
This frame is used to request policy from an STA to another
This is not used in infrastructure BSS network
Only used in IBSS (or mesh and 11p cases)
The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in
The Action field is set to the value indicating MFQ Policy Query Request, as specified in Table X
The Dialog Token field is set to a nonzero value chosen by the STA sending the MFQ Policy Query Request to identify the request/response transaction.

17. MFQ Policy Query Response
Category
Action
Dialog Token
Management Frame QoS Policy element
Octets: 1
variable
MFQ Policy Query Response frame body format
This frame is used to indicate the MFQ policy when a MFQ Policy Query Request is received from an STA in an IBSS case
The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in
The Action field is set to the value indicating MFQ Policy Query Response, as specified in Table X
The Dialog Token field is set to the nonzero value of the corresponding MFQ Policy Query Request frame.
MFQ policy element defines the complete MFQ policy

18. MFQ Policy Config Request
Category
Action
Dialog Token
Management Frame QoS Policy element
Octets: 1
variable
MFQ Policy Config Request frame body format
This frame is used to request change in MFQ policy configuration
The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in
The Action field is set to the value indicating MFQ Policy Config Request, as specified in Table X
The Dialog Token field is set to a nonzero value chosen by the STA sending the MFQ Policy Config Request to identify the request/response transaction.
The MFQ Policy element is as define earlier.
When sent by an associated STA, this frame will indicate the new MFQ policy requested by the STA
Management frames not indicated in this request are sent at policy advertised by associated AP – only the delta change of policy is sent in this request
Only unicast allowed
When sent by an AP, this frame will indicate the new MFQ policy that STA associated to this AP shall adopt
Only unicast allowed. Multicast is discussed later
This will be used to set policy by AP post-association to some or all associated STA

19. MFQ Policy Config Response
Month Year
doc.: IEEE yy/xxxxr0
MFQ Policy Config Response
Category
Action
Dialog Token
Status Code
Octets: 1
MFQ Policy Config Response frame body format
This frame is used to respond to a MFQ Policy Config Request
The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in
The Action field is set to the value indicating MFQ Policy Config Response, as specified in Table X
The Dialog Token field is set to the nonzero value of the corresponding MFQ Policy Config Request frame.
The Status Code field contains status code in response to MFQ Policy Config Request frame as defined in adjacent Table.
Only unicast frames allowed
Status Code Definitions
Status Code
Status code description
Accept 1
Reject – don’t retry 2
Reject – may retry
May add partial accept later
John Doe, Some Company

20. High level management policy exchange
MFQ Policy Config Request
Requestor
Responder
Action
MFQ Policy Config Response
Unicast AP
STA
STA adopts policy
Sends response
AP may or may not allow STA to change policy
(Re)Association Request/Response will be used to exchange complete MFQ during association
MFQ Policy Query Request/Response can only be unicast
Multicast may lead to response storm in network
MFQ Policy Config Request/Response actions are governed by the adjacent table
Policy Config Request/Response combinations for BSS case
MFQ Policy Config Request
Requestor
Responder
Action
MFQ Policy Config Response
Unicast
Non-AP STA
STA may or may not adopt policy
Sends response
Policy Config Request/Response combinations for
IBSS (11p and mesh) case

21. MFQ Policy Config Delete
Category
Action
Octets: 1
MFQ Policy Config Delete frame body format
This frame is used to delete the change previously requested in management frame policy configuration using MFQ Policy Config Request
The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in
The Action field is set to the value indicating MFQ Policy Config Delete, as specified in Table X
The Dialog Token field is set to the dialog token value used in the MFQ Policy Config Request
This will be used to set policy by AP post-association to some or all associated STA

22. Other cases and open issues
Pre-association
In AP beacons, only the policy for pre-association management frames to be sent at non-default priority will be included
All management frames to the AP (by unassociated STAs) shall be sent at the policy advertised in AP beacon
AP may configure priority of STA post-association
Policy Config Request frames will be used
Multicast may induce unreliability – no certainty that the STA received the policy definition or not, which may lead to sequence number issues. So should we only allow unicast configuration? Is there a group address response – can 11aa help?
Roaming
Associated STA shall follow the associated AP management policy to send management frames (e.g. Probe Request) to other APs in the same ESS
If the target AP is in different ESS?
If associated AP is a legacy AP, then should the STA adopt the policy of the target AP if it received the management frame policy in the target AP beacon ?
This will follow the pre-association policy with respect to the destination BSS
Legacy STA
An 11ae capable STA shall associate in 11ae mode to an 11ae capable AP.
An 11ae capable STA shall associate in legacy mode to a non 11ae capable AP.
A non-11ae capable STA shall associate in legacy mode to an 11ae capable AP.
An 11ae capable STA shall adhere to the policy advertised by the 11ae capable AP.
Any management frame not defined in the policy defaults to the AC_VO
Policy exchange in IBSS shall be carried out using Management Policy Exchange Action frames
What action should be taken when a packet is received at incorrect priority?

23. Meeting discussions Pre-association
STA shall use MFQ policy from AP Beacon frame (if received) to transmit packet to that AP . If AP Beacon frame is not received then STA shall transmit the management frames at AC_VO priority
Using multicast MFQ Policy Config Request by an AP to change the policy of associated STA may be a problem
Consider a counter to be used by AP to advertise policy and indicate MFQ policy change
STA may drop frames that are not in policy
Group-addressed frames should have consistent policy across the ESS
STA may not be able to detect the transmit priority of the received MFQ management frame
The group discussed default priorities and decided on AC_VO as
It is the legacy priority for management frame so will not cause unfairness for 11ae STAs
Default priority are very deployment specific and may change with each deployment
Using the mechanism outlined in this presentation, the priority of all management frames can be changed efficiently
Just after MFQ policy is changed, there may be management frames in the transmit queue which may be out of policy and dropped at the receiver
This was discussed and the group concluded that this will have low impact