Dear Alfred,
Would you please add updated HIP EDCA SP to the MAC queue
Do you agree to define HIP EDCA in UHR where a STA with Low Latency traffic may be allowed, based on TBD conditions, to send a Defer Signal (e.g. CTS frame or RTS) to start a protected short contention for pending LL data
- Conditions to be allowed to send a Defer Signal is TBD
- STA in HiP EDCA always use RTS/CTS as initial frame exchange and retry.
- Duration of protected short contention is TBD.
- Access parameters (AIFSN, CW and the expansion rules) used to transmit the Defer Signal are TBD. The retry count where the Defer Signal is allowed to be sent is TBD
- Contention parameters for the protected short contention are TBD. The STAs that transmitted a Defer Signal but did not win the protected short contention will initiate a new retry.
- Low Latency traffic is treated as AC_VO traffic. Other cases are TBD.
- The solution would provide control on the degree of collisions that may occur while using it and, allows for autonomous randomness or/and controlled by the AP
- No new
mandatory synchronization requirement on STA side
- HIP EDCA is used by the STAs in a BSS only when this feature is enabled by the AP
Supporting doc: 24/1144r1
Thank you
Dmitry
From: Sherief Helwa <00002dded7ae4daf-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, January 13, 2025 6:42 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] TGbn MAC SPs Request
Hi Alfred,
Please see the following updated SP text.
- Do you agree with the following:
Green: allowed
Orange: disallowed
|
Allowed ICF to be transmitted by a non-AP STA?
|
|
eMLSR
|
AP DPS
|
DUO
|
NPCA
|
Unsolicited Coex
|
C-TDMA (ICF)
|
Co-BF/Co-SR
|
RTS
|
N/A
|
Yes
|
N/A*
|
No
|
No
|
N/A
|
MU RTS
|
No
|
No
|
No
|
BSRP Trigger
|
No
|
No
|
No
|
BSRP GI3
|
Yes
|
Yes
|
Yes
|
|
RTS solicits CTS frame; BSRP GI3 Trigger frame solicits an M-BA that is contained in a non-HT (dup) PPDU.
C-TDMA, C-BF, CSR transmission is to other APs. No expectations for non-AP STAs, unless due to other functionalities already enabled/supported by non-AP STA.
* Here N/A means that the Coex Mode (DUO) cannot be enabled by an AP, and as such the AP cannot send an M-BA that contains unavailability feedback in response to ICFs (BSRP GI3 to be more specific) sent by the STA.
Acronyms:
- DPS: Dynamic Power Save
- DUO: Dynamic Unavailability Operation
- Unsolicited CoEx: Reporting unavailability in ICF
- Co-BF: Coordinated beamforming
- Co-SR: Coordinated Spatial Reuse
- BSRP GI3: BSRP Trigger frame soliciting a non-HT (dup) response
|
Supporting list: [24/1558, 24/1221, 24/1225, 24/1563]
- Do you agree with the following:
Green: allowed
Yellow: TBD
Orange: disallowed
Allowed ICF to be transmitted by an AP
|
ICF
|
eMLSR
|
DPS
|
DUO
|
NPCA
|
C-TDMA (ICF/announcement frame)
|
Co-BF/Co-SR
|
RTS
|
No
|
Yes
|
No
|
No
|
No
|
No
|
MU RTS
|
Yes
|
Yes
|
No
|
Yes
|
No
|
TBD
|
BSRP Trigger
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
TBD
|
BSRP GI3
|
TBD
|
TBD
|
Yes
|
TBD
|
Yes
|
TBD
|
RTS solicits CTS frame; MU RTS Trigger solicits CTS frame; BSRP Trigger solicits a TB PPDU that contains QoS Null(s) if STA is not in Coex mode and STA is allowed to aggregated M-BA if STA is in Coex mode; BSRP GI3 Trigger frame solicits
an M-BA that is contained in a non-HT (dup) PPDU.
Allocation frame for C-TDMA is MU-RTS TXS
Acronyms:
- DPS: Dynamic Power Save
- DUO: Dynamic Unavailability Operation
- Co-BF: Coordinated beamforming
- Co-SR: Coordinated Spatial Reuse
- BSRP GI3: BSRP Trigger frame soliciting a non-HT (dup) response
|
Supporting list: [24/1558, 24/1221, 24/1225, 24/1563]
Regards,
Sherief
Hi Alfred,
A couple more SPs to add to the MAC queue please. These two SPs are from
@Liwen Chu and me.
- Do you agree with the following:
Green: allowed
Orange: disallowed
|
Allowed ICF to be transmitted by a non-AP STA?
|
|
eMLSR
|
AP DPS
|
solicited Coex
|
DSO
|
NPCA
|
Unsolicited Coex
|
CFP
|
C-TDMA (ICF)
|
C-BF/CSR
|
RTS
|
N/A
|
Yes
|
N/A*
|
N/A
|
No
|
No
|
No
|
N/A
|
MU RTS
|
No
|
No
|
No
|
No
|
BSRP
|
No
|
No
|
No
|
No
|
BSRP GI3
|
Yes
|
Yes
|
Yes
|
Yes
|
|
C-TDMA, C-BF, CSR transmission is to other APs. No expectations for non-AP STAs, unless due to other functionalities already enabled/supported by non-AP STA.
* Here N/A means that the Coex Mode cannot be enabled by an AP, and as such the AP cannot send an M-BA that contains unavailability feedback in response to ICFs (BSRP GI3 to be more specific) sent by the STA.
|
Supporting list: [24/1558, 24/1221, 24/1225, 24/1564, 24/1563]
- Do you agree with the following:
Green: allowed
Yellow: TBD
Orange: disallowed
Allowed ICF to be transmitted by an AP
|
ICF
|
eMLSR
|
DPS
|
DUO
|
DSO
|
NPCA
|
CFP
|
C-TDMA (ICF/announcement frame)
|
C-BF/CSR
|
RTS
|
No
|
Yes
|
No
|
No
|
No
|
No
|
No
|
No
|
MU RTS
|
Yes
|
Yes
|
No
|
No
|
Yes
|
No
|
No
|
TBD
|
BSRP
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
TBD
|
BSRP GI3
|
TBD
|
TBD
|
Yes
|
No
|
TBD
|
Yes
|
Yes
|
TBD
|
C-TDMA, C-BF, CSR transmission is to other APs. No expectations for non-AP STAs, unless due to other functionalities already enabled/supported by non-AP STA.
|
RTS solicits CTS frame; MU RTS Trigger solicits CTS frame; BSRP Trigger solicits a TB PPDU that contains QoS Null(s) if STA is not in Coex mode and STA is allowed to aggregated M-BA if STA is in Coex mode; BSRP GI3 Trigger frame solicits
an M-BA that is contained in a non-HT (dup) PPDU. More details in other tables.
Allocation frame for C-TDMA is MU-RTS TXS
|
Supporting list: [24/1558, 24/1221, 24/1225, 24/1564, 24/1563]
Regards,
Sherief
Hi Alfred,
Can you please add the following SPs to the MAC queue?
- Do you agree with the following for UHR-variant trigger frame:
- Responding PPDU format is non-HT (Dup) PPDU format: reuse entry value 3 in GI and HE/EHT LTF type in UHR-variant common info field
- Other values are used for UHR TB PPDU format
Supporting list: [11-24/1558]
- Do you agree to include the CoEx unavailability information in a new “Special User Info” field with AID12 set to 2008 of the BSRP Trigger frame when used as an ICF to report CoEx
unavailability information
- A Feedback Type field (4 bits field – B12 to B15 of the “Special User Info” field) which is set to 0 to indicate that the “Special User Info” field is carrying CoEx unavailability information
- CoEx unavailability information includes two parameters: Unavailability Target Start Time and Unavailability Duration (these fields are already defined)
Supporting list: [11-24/1558]
- Do you support to define a special Feedback Per AID TID Info field (name TBD) that carries control feedback in the M-BA frame?
- The control feedback (i.e. unavailability indication) is carried instead of the BlockAck Bitmap in that Feedback Per AID TID Info field
- The Ack Type subfield of the Per AID TID Info field is set to 0 and the TID subfield of the Per AID TID Info field is set to the value 13
- The AID11 subfield of this Per AID TID Info field is set to 2008 value if the control feedback is addressed to all STAs or to the AID11 that identifies the intended recipient STA
- The Starting Sequence Number field of this Per AID TID Info field is reserved
Supporting list: [11-24/543, 11-24/1558]
Regards,
Sherief
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1