SP5: Po-Kai Huang, Roaming: 24/1874r1 – Result:
- Do you support to enable the following contexts to be transferred to target AP MLD to preserve the data exchange context for the non-AP MLD?
- Block Ack Parameters and Block Ack Timeout Value indicated by the non-AP MLD for existing BA agreement of a TID
- Next SN to be assigned for DL individually addressed data frame of each TID
- Latest duplicate receiver cache for TID without BA agreement
- latest SN that has been pass up for TID with UL BA agreement
- Starting PN to be assigned for DL individually addressed frame by the target AP MLD
- Initial value to be used by each replay counter of the target AP MLD for UL individually addressed frame
- WinStartO of an existing DL BA agreement so that the target AP MLD does not exceed reordering buffer window of the non-AP MLD
TBD for other contexts
No objections
SP6: Giovanni Chisci, MAP: 24/1220r1, 24/0407r0 – Result:
Do you support to define new actions for Public Action frames for MAPC communications such as discovery and negotiations?
- A new action is defined for MAPC Discovery
- An action is defined for MAPC Negotiation Request
- An action is defined for MAPC Negotiation Response
- Others are TBD
No objection
SP7: Giovanni Chisci, MAP: 24/1220r1 – Result:
Do you support that when an AP use Management frames to discover the capabilities and/or parameters of individual M-AP coordination schemes, the AP shall use the defined MAPC Public Action frame with the following setting:
- The action field is set to MAPC Discovery
No objection
SP8: Giovanni Chisci, MAP: 24/1220r1, 25/0378r0 – Result:
- Do you support that, when an AP (AP1) uses an individually addressed Management frame to initiate a negotiation to establish agreements for M-AP coordination schemes (if enabled by another AP (AP2)), the
AP (AP1) shall use the defined MAPC Public Action frame with the following setting:
- The action field is set to MAPC Negotiation Request
- If new negotiations are disabled by another AP (AP2) the AP (AP1) shall not send a negotiation request the other AP (AP2)
TBD details of ‘new negotiations disabled’
No objection
SP9: Giovanni Chisci, MAP: 24/1220r1 – Result:
- Do you support that when an AP (AP2) receives an individually addressed Management frame that initiates a negotiation to establish agreements for M-AP coordination schemes, the AP (AP2) shall respond by
using the defined MAPC Public Action frame with the following setting, if the negotiations are enabled:
- The action field is set to MAPC Negotiation Response
No objection
SP10: Giovanni Chisci, MAP: 24/1220r1, 23/1887r1, 24/160r1, 24/908r0, 24/0407r0 – Result:
A Co-RTWT Requesting AP, shall include one or more Co-RTWT Parameter Set fields corresponding to each requested R-TWT schedule in the TBD individually addressed Management frame used for the request to the Co-RTWT Responding AP. The Co-RTWT
Parameter Set field includes the following:
- Target Wake Time field, Broadcast TWT ID field, Broadcast TWT Persistence,
- TWT Wake Interval Mantissa, TWT Wake Interval Exponent, Nominal Minimum TWT Wake Duration
TBD other fields
Result: 97Y, 28N, 66A
SP11: Binita Gupta, L4S: – Result:
- Do you agree to define in 11bn an optional mechanism for L4S support on the AP as below?
- Define an MLME primitive that provides congestion notification from the MAC layer to the higher layer at the AP, to enable the upper layer to mark ECN bits on subsequent packets for L4S congestion signaling.
- Enhance the MA-UNITDATA.request primitive to provide an indication whether the MSDU carries the packet of L4S flow
- TBD on whether and how AP’s L4S capability is advertised.
- NOTE 1 - This SP proposal is a further refinement of L4S-related SPs (39.2, 39.3) presented during Nov’24 Vancouver meeting’s TGbn MAC session 1791r1.
- NOTE 2 - The conditions and criteria based on which the MAC layer determines to signal L4S congestion experienced notification to the upper layer is implementation specific and is outside the scope of this
specification.
- NOTE 3 – DCN 25/0459r0 shows a Proposed Draft Text (PDT) corresponding to this SP
Supporting documents: 24/0399, 24/0384, 24/0818, 25/459
Result: 120Y, 45N, 63A
SP 12-16 deferred
SP17: Liwen Chu, Low Latency: 421r0 – Result:
- Do you agree to amend Motion #273 as following?
- TGbn defines or improves an existing mechanism so that a non-AP STA that is a TXOP responder can indicate its buffered low latency
LL traffic needs (for traffic from the TxOP TXOP responder to the TxOP TXOP Holder) in a Multi-STA BA frame. The TXOP holder should consider the indication in determining subsequent actions. Subsequent actions related to this indication are out of the
scope of the standard.
- Note: whether an AP can Indicate indicate its low latency needs is TBD
- The Low Latency Indication is included in the Feedback field of the Feedback Per AID TID Info field (the one that carries control feedback).
- The Feedback Type field (Located in B12 to B15 of the Block Ack Starting Sequence Control) is set to 1
- Note: Feedback Type field set to 0 is used for DUO feedback
- TBD bits in the Feedback field is defined to provide the low latency need.
No objection
SP18: Liwen Chu, Control: 25/425 – Result:
- Do you support that an UHR STA that sets its NAV timer per the BSRP Trigger frame may reset its NAV timer if the following condition is true
- No PHY-RXEARLYSIG.indication or PHYRXSTART.indication primitive is received from the PHY during a NAVTimeout period.
- The NAVTimeout period is equal to (2 × aSIFSTime) + T_PREAMBLE + T_SIGNAL + UL_Length + aRxPHYStartDelay + (2 × aSlotTime).
(see Table 17-5—Timing-related parameters)
Deferred
SP19: Jay Yang, MAP: 24/1693r3, 23/1836r3, 24/1220r2 – Result:
- Do agree that TGbn defines a procedure using pre-association security negotiation (PASN ) to derive the key(s) needed to protect individually addressed management frames exchanged between two APs as part
of the MAPC operation
- •Note – it is TBD whether any extensions will be needed for PASN .
Supporting list: 24/1693r3, 23/1836r3, 24/1220r2
Deferred
SP20: Dmitry Akhmetov, Channel Access: 24/1918 – Result:
Do you support that a UHR STA may use P-EDCA
- If P-EDCA is enabled by the AP to which that STA is associated to
- May transmit up to TBD but no more than 50 transmissions of DS and up to 2.5 ms of total transmission time to start P-EDCA contention over 50ms interval
- Note: ETSI regulation of Short Control Signaling transmission
- Shall not initiate more than TBD number of transmissions of DS to start P-EDCA consecutively.
- Note: consecutive DS transmission are multiple attempts to perform P-EDCA contention w/o falling back to regular EDCA operation
Result: 56Y, 87N, 82A
DSO PDT
Do you support to incorporate the proposed text changes for DSO in 11-25/0454r6 into the latest TGbn draft
No objection
SP21: Binita Gupta, Roaming: 24/0656 – Result:
- For seamless roaming, do you support to allow a non-AP MLD to request preparing more than one candidate target AP MLDs in an SMD during the roaming preparation phase?
- Preparation with multiple AP MLDs is performed using a separate roaming preparation request for each AP MLD
- If successful roaming preparation was performed with multiple candidate target AP MLDs, then the non-AP MLD shall attempt roaming execution with only one of those target AP MLDs at a time.
- Retries with other target AP MLDs are permitted for roaming execution
- TBD on policy indication from the AP on multiple target AP MLDs preparation
SP21: Binita Gupta, Roaming: 24/0656 – Result:
- For seamless roaming, do you support to allow a non-AP MLD to request preparing more than one candidate target AP MLDs in an SMD during the roaming preparation phase?
- Preparation with multiple AP MLDs is performed using a separate roaming preparation request for each AP MLD
- If successful roaming preparation was performed with multiple candidate target AP MLDs, then the non-AP MLD shall attempt roaming execution with only one of those target AP MLDs at a time.
- Retries with other target AP MLDs are permitted for roaming execution
- TBD on policy indication from the AP on multiple target AP MLDs preparation
SPXX: Abhishek
Do you agree that the Co-TDMA sharing AP and the Co-TDMA coordinated AP shall have the same primary 20 MHz channel.
No objection
SPXX+1Binita Gupta 3/13/2025 6:55 AM • SP:
Do you support that for a Seamless Mobility Domain (SMD), the SMD and the 802.1X Authenticator component in the corresponding SMD-ME are uniquely identified by an SMD Identifier?
• The SMD identifier is in the format of a 48-bit MAC address
• The SMD Identifier is used in establishing single PMKSA and PTKSA for a non-AP MLD that associates with the SMD-ME
No objection
• 1) any objections to running the straw poll as presented 2) any objections to answering yes to the straw poll as presented