In 9.22.4.2.1 General Proposed resolution: Revised. At 1552.34, change “The request may be sent for ACs for which the ACM subfield is 0”. to: “The ADDTS Request frame may be sent for ACs regardless of the ACs’ ACM settings.”. CID Page Clause Resn Status Comment Proposed Change Ad-hoc 5214 This paragraph does not acknowledge that the times at which the AP transmits during an unscheduled SP may be additionally constrained by the coexistence mechanism. Add a statement to this para somewhere: "The times at which an AP may transmit during an unscheduled SP might be constrained by the Coexistence mechanism (see 10.2.2.5.2)." MAC Discussion Cited text: Agree with commenter that adding a statement might be helpful. Proposed resolution: Revised. At the end of cited paragraph, add "The times at which an AP may transmit during an unscheduled SP might be constrained by the U-APSD coexistence mechanism (see 10.2.2.5.2)." CID Page Clause Comment Proposed Change Resolution Owning Ad-hoc 5218 1560.62 10.2.2.10 This subclause acknowledge the coexistence mechanism, which has a whole raft of rules about receive operation. Add a sentence, "For receive operation using the U-APSD coexistence mechanism, also see 10.2.2.5.2." MAC APSD
12. Spatial multiplexing power save I encourage the WG to create additional power-saving mechanisms. Discussion Proposed resolution: Rejected. The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be determined. Comment Proposed Change Owning Ad-hoc To be consistent with the DTI components, add "BHI" in the leftmost column covering the first three non-header rows. Ditto at 1581.07 As in the comment. MAC Discussion Cited text: Agree with comenter. BHI comprises BTI, A-BFI, and ATI. Proposed resolution: Accepted. CID Page Clause Comment Proposed Change Owning Ad-hoc 10.2.6.2.2 There is a layer of meaning in this state machine that is obscure. The leftmost top bubble "expands" to the state machine below it. But the rightmost bubble expands to one of the two state machines below it with transitions that are not shown. Redraw the state machine so that all states are shown and all transitions identified clearly. Make matching changes at 1585.02. MAC Discussion It is not how to redraw it. A submission is required for review. Suggest assigning to the commenter. I
"10.2.2 Power management in a non-DMG infrastructure network" contains vast amounts of detail. "10.2.6 Power management in a PBSS and DMG infrastructure BSS" is much thinner. Is it really the case that the latter is complete for DMG infrastructure BSSes (e.g. it doesn't include any stuff)? Add any missing stuff for PBSSes and DMG ABSSes MAC Discussion The comment to identify a specific issue to be addressed. Proposed resolution: Rejected The comment fails to identify a specific issue to be addressed. It fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be determined. Comment Proposed Change Owning Ad-hoc Are FTM frames bufferable? This subclause suggests they are Either state that a non-AP STA doing FTM needs to be in active mode during burst instances, or state that FTM frames are not bufferable MAC Discussion Have talked to some FTM folks, here is the feedback: Non-AP STA doing FTM needs to be in Active mode. This, though not explicitly stated, is implicit in the protocol specification. Not sure what value it adds by stating it explicitly. Need more work. Will be discussed in PM1 Wed in Nov. Proposed resolution: TBD Rejected. Non-AP STA doing FTM needs to be in Active mode. This, though not explicitly stated, is implicit in the protocol specification and is clear if you read the entire protocol specification. Comment Proposed Change Owning Ad-hoc "For a STA using U-APSD, the AP transmits one BU destined for the STA from any AC that is not After the first sentence cited add "The AP should MAC
If TDLS is used without QoS, the dot11TDLSPeerUAPSDBufferSTAActivated CANNOT be set to true. I think the first sentence of the cited clause is sufficient. Proposed resolution: Revised. At 1564.42, after the first sentence, add: “A non-QoS STA shall set dot11TDLSPeerUAPSDBufferSTAActivated to false.” CID Page Clause Comment Proposed Change Owning Ad-hoc 10.2.2 1557.51: "An AP may delete buffered BUs for implementation dependent reasons, including the use of an aging function [...] The AP may base the aging function on the Listen Interval". 1561.9: "Any AP aging function shall not cause the buffered BU to be discarded after any period that is shorter than the ListenInterval of the STA for which the BUs are buffered". Well, which is it? Is the AP required to honour the ListenInterval or not? Change 10.2.2.6.k to have some kind of "subject to 10.2.2.12" MAC Discussion The cited text at 1557.51 is in 10.2.2.6 AP Operation during the CP The cited text at 1561.9 is in 10.2.2.12 AP aging fnction Agree with the comment’s suggestion. AP is required to honour the ListenInterval. Proposed resolution: Revised. At 1557.52, change “…implementation dependent reasons, ” To “…implementation dependent reasons (subject to 10.2.2.12),”.
CID Page Clause Comment Proposed Change Owning Ad-hoc 10.2.2.17 What is the value of the "Overridden" status code in the TIM Broadcast Response element? Add a NOTE to say this is treated exactly the same as Accept by the recipient, e.g. "NOTE---A Status field indicating Overridden can be treated exactly the same as one indicating Accept." MAC Discussion Cited text at 1569.57: The the value of the “Overriden” is defined in Table 8-200: The behaviour of the STA receiving “Overridden” is different from the behaviour of receiving “Accept”. According to 1570.1: However, when the STA receives “Overridden”, it cannot ignore the TIM Broadcast Interval. The TIM Broadcast Interval specified in the TIM Broadcast Resposne element shall be used by the STA. Proposed resolution: Rejected. The behaviour of the STA receiving “Overridden” might be different from the behaviour of the STA receiving “Accept”, see 1570.1 CID Page Clause Comment Proposed Change Owning Ad-hoc 10.2 "A STA that has transmitted a frame to an AP with which it is not associated and from which it expects a response shall remain in the awake state until such a response is received or until the procedure has timed out." -- equivalent statements need to be made for cases Add similar statements for IBSS, PBSS and perhaps also MBSS MAC Discussion In IBSS, there is no “associated” concept. Therefore, similar statement won’t apply. The basic approach of power management in IBSS is described in 10.2.3. There is no need to add a similar sentence for IBSS. For MBSS, s similar description is already covered in 13.14.8.3 Operation in deep sleep mode for nonpeer mesh STAs: A PBSS is similar to an infrastructure BSS, a similar statement can be added. Proposed resolution: