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

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 802.11ae capable AP and 802.11ae capable STA respectively

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 11-10-0365-03-00ae-proposal-for-prioritization-of-management-frames.doc 11-10-0295-01-00ae-tech-proposals.doc 11-10-0093-05-00ae-tgae-requirements-and-use-cases.doc

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 802.11ae 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 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 11-10-0097-02-00ae-management-frame-analysis.xls)

Management Frame 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 management frame policy between STAs This IE is sent in Beacons, (Re)Association Request/Response and Probe Request/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 defined in the IE List of Priority Definition fields contains one or more Priority Definition fields

Priority Definition Field (PrDf) Design guiding principles: 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

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 and Length_PrDf subfields. This can support maximum of 15 octets. TID subfield is 4 bits in length and is defined in 7.1.3.5.1. 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

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 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 Var 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

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) = 0000 0011, 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

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

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

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 11-10-0097-02-00ae-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 Provides some level of grouping/aggregation. Logically, priorities would be changed for contiguous set of Action values 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 11-10-0097-02-00ae-management-frame-analysis.xls) 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 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 octet 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 = 10 - 7x1 = 7 octets All Low (0 octet Action Value bitmap) Categories = 2, 12, 126, 127 - 3x4 = 12 octets

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. 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: Type_PrDf U M Length_ PrDf TID Subtype_ PrDf Category Value 1 3 13 10 Octets: Action Value Bitmap

Management Policy Exchange action Table 7-24—Category values Code Meaning See Subclause Robust <ANA> Management Policy Exchange (MPE) ? Table X -- MPE Action field values Action field value Description Policy Query 1 Policy Response 2 Policy Config Request 3 Policy Config Response 4 Policy Config Delete The management policy can be exchanged and changed using the above action frames

Policy Query Category Action Dialog Token Octets: 1 Policy Request frame body format This frame is used to request policy from an STA to another The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Request, as specified in Table X The Dialog Token field is set to a nonzero value chosen by the STA sending the policy request to identify the request/report transaction.

Policy Response Category Action Dialog Token Management Frame Policy element Octets: 1 variable Policy Report frame body format This frame is used to indicate the policy when a policy request is received from an STA The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Report, as specified in Table X The Dialog Token field is set to the nonzero value of the corresponding Policy Request frame. If the Policy Report frame is being transmitted other than in response to an Policy Request frame, then the Dialog token is set to zero –not required, any reason why this will be needed?

Policy Config Request Category Action Dialog Token Management Frame Policy element Octets: 1 variable Policy Change Request frame body format This frame is used to request change in management frame policy configuration The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Change Request, as specified in Table X The Dialog Token field is set to a nonzero value chosen by the STA sending the policy request to identify the request/response transaction. The Management Frame Policy element is as define earlier. When sent by an associated STA, this frame will indicate the new management frame policy requested by the STA Management frames not indicated in this request are sent at policy advertised by associated AP Only unicast allowed When sent by an AP, this frame will indicate the new management frame policy that STAs 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

Policy Config Response Month Year doc.: IEEE 802.11-yy/xxxxr0 Policy Config Response Category Action Dialog Token Status Code Octets: 1 Policy Change Response frame body format This frame is used to respond to a policy config change request The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Change Response, as specified in Table X The Dialog Token field is set to the nonzero value of the corresponding Policy Change Request frame. The Status Code field contains status code in response to Policy Change 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

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

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

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 unicast management frames to the AP (by unassociated STAs) shall be sent at the policy advertised in AP beacon Multicast management frames? Frames to other APs? Default priority? 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 ? 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 As default action drop the packet when received at incorrect priority? 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 11-10-0097-02-00ae-management-frame-analysis.xls)