Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBE] 答复: [EXT] [STDS-802-11-TGBE] 答复: Discussion on More Data Ack (11-22/1043r4)



Hi Kiseon,

 

In that case, the AP can send a BSRP trigger frame to get a BSR report if an ACK/BA frame with the More Data subfield is set to 1 is received. After that, the AP can allocate UL resource for the UL transmission.

 

And I assume you had noticed that I use the word ‘may’ to describe the AP’s behavior when an ACK/BA frame with the More Data subfield is set to 1 is received.

 

If you have further question/comment, please let me know.

 

 

Regards

Guogang Huang

发件人: Kiseon Ryu [mailto:kiseon.ryu@xxxxxxx]
发送时间: 2022829 22:28
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; huangguogang <huangguogang1@xxxxxxxxxx>
主题: Re: [EXT] [STDS-802-11-TGBE] 答复: Discussion on More Data Ack (11-22/1043r4)

 

Hi Guogang,

 

Thank you for your discussion. In my opinion, one bit More Data Ack indication seems not a sufficient information for an AP to determine whether it allocates the UL resource by a Trigger frame or the remaining TXOP time by a MU-RTS TXS Trigger frame or an RDG/More PPDU subfield in the CAS Control subfield, etc. It looks better for a non-AP STA to send a BSR frame along with a BA frame in response to the received PPDU in order to provide the AP with its buffer status information exactly.

 

Thank you,

Kiseon


From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, August 26, 2022 11:20 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: [EXT] [STDS-802-11-TGBE]
答复: Discussion on More Data Ack (11-22/1043r4)

 

Caution: EXT Email

Hi all,

 

I’m planning to run a SP on 1043r4 in the next week if there is no further comment/question.

 

 

Regards

Guogang Huang

发件人: huangguogang
发送时间: 2022818 12:34
收件人: 'Peshal Nayak' <p.nayak@xxxxxxxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; Duncan Ho <dho@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Jarkko Kneckt <calendarserver01+261100ee-e7b0-4521-8ebc-2c607c41b63b@xxxxxxxxx>; Chunyu Hu <chunyuhu@xxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: 答复: Discussion on More Data Ack (11-22/1043r4)

 

Hi Peshal,

 

Please find my response inline.

 

 

Regards

Guogang Huang

 

发件人: Peshal Nayak [mailto:p.nayak@xxxxxxxxxxx]
发送时间: 2022818 4:23
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; Duncan Ho <dho@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Jarkko Kneckt <calendarserver01+261100ee-e7b0-4521-8ebc-2c607c41b63b@xxxxxxxxx>; Chunyu Hu <chunyuhu@xxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: Discussion on More Data Ack (11-22/1043r4)

 

Thanks Guogang for your responses. Please see some more comments inline below.

 

Thanks.

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Tuesday, August 16, 2022 9:07 PM
To: Peshal Nayak <p.nayak@xxxxxxxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; Duncan Ho <dho@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Jarkko Kneckt <calendarserver01+261100ee-e7b0-4521-8ebc-2c607c41b63b@xxxxxxxxx>; Chunyu Hu <chunyuhu@xxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject:
答复: Discussion on More Data Ack (11-22/1043r4)

 

Hi Peshal,

 

Thanks for your questions. Please find my response inline.

 

 

Regards

Guogang Huang

 

发件人: Peshal Nayak [mailto:p.nayak@xxxxxxxxxxx]
发送时间: 2022817 5:25
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; Duncan Ho <dho@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Jarkko Kneckt <calendarserver01+261100ee-e7b0-4521-8ebc-2c607c41b63b@xxxxxxxxx>; Chunyu Hu <chunyuhu@xxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: Discussion on More Data Ack (11-22/1043r4)

 

Thanks Guogang for your hard work and for triggering this discussion thread.

 

As I mentioned in yesterday’s call, I have two main concerns with the procedure:

 

1.       To leverage the procedure, the STA needs to have downlink traffic. Further, the downlink traffic load will also come into play. STAs that have a high downlink traffic load can have more frequent downlink transmissions and thus more opportunities for making the indication in the BA.

[Guogang Huang] The proposed scheme is just a complement to the current protocol. The AP still can still use other methods to collect the buffer report info, e.g. NFRP Trigger frame.

[Peshal] Thanks. The point I was trying to make is that the current proposed scheme seems to have a flaw due to its dependence on availability of downlink traffic for the signaling to work.

              [Guogang Huang]I don’t agree it is a flaw. This is just the scenario for the proposed scheme.

2.       The procedure will create an unfair bias for STAs that have downlink traffic. Such STAs may not necessarily have latency sensitive traffic.

[Guogang Huang] I don’t understand why it will create an unfair bias. The proposed scheme just exploits the existing procedure. There is no any new procedure. If such STAs have no latency sensitive traffic, then the More Data subfield is set to 0.

[Peshal] Here is an example to explain the unfair bias point. Let us say that there are two STAs ? STA1 (affiliated with non-AP MLD1) and STA2 (affiliated with non-AP MLD2). STA1 has latency sensitive traffic for uplink. STA2 has delay tolerant traffic for uplink. AP has downlink traffic for STA2 but no downlink traffic for STA1. As per your scheme, when AP transmits to STA2, it can make this indication in BA and get medium time via TXOP sharing. STA1 will not be able to get medium time. So it is unfair for STA1.  

             [Guogang Huang]I don’t agree this is unfair for STA 1. It’s the AP choice. The AP also can make the scheduling decision after collecting the buffer report of STA 2 and other STAs. Let me ask you a question, do you    think  it is fair if the AP sends the downlink traffic to STA 2 and immediately trigger the STA 2’s uplink transmission? This is allowed in the current spec.

3.       The main goal of the procedure is to reduce the delay as indicated in the comment. Could you provide some analysis on how this kind of a procedure will reduce delay? Intuitively, it feels this will reduce delay for STAs that have downlink traffic only which may not be so much beneficial if they don’t have latency sensitive traffic.

[Gugang Huang]This indication can tell the AP when to trigger the STA’s uplink transmission. Considering the proposed scheme reuse the current More Data subfield, there is no signaling overhead. And you may note that, although I mentioned this scheme may be more useful to reduce the delay of the latency-sensitive traffic, I don’t emphasize it in the draft text. I just say one or more pending frames.

[Peshal] Thanks. I think there is some misunderstanding. Due to the dependency on downlink traffic pointed out in question 1, it is unclear what scenarios will benefit from this scheme. What I meant in my question was that do you have any theoretical analysis or simulation results that for a general scenario this scheme will reduce delay? If it cannot do so for all scenarios, what is the target use case for this proposed scheme?

             [Guogang Huang]The scenario is, when the AP is sending downlink traffic to STA 2 and STA 2 also has pending UL traffic, the AP can trigger STA 2’s UL link transmission if the More Data subfield is set to 1. I don’t know why you hope one scheme can apply to all scenario, let alone there is no extra overhead.  

 

An EHT STA optionally sets the More Data subfield in individually addressed Ack and BlockAck frames to 1 to indicate that it has one or more pending frames for an EHT AP that is the intended recipient of the Ack or BlockAck.

 

 

 

Thanks.

Peshal

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Monday, August 15, 2022 8:13 PM
To: Rubayet Shafin <
r.shafin@xxxxxxxxxxx>; Peshal Nayak <p.nayak@xxxxxxxxxxx>; Duncan Ho <dho@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Jarkko Kneckt <calendarserver01+261100ee-e7b0-4521-8ebc-2c607c41b63b@xxxxxxxxx>; Chunyu Hu <chunyuhu@xxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Discussion on More Data Ack (11-22/1043r4)

 

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi all,

 

I’d like to initiate this thread to discuss the CR document (11-22/1043r4) which is presented in today’s TGbe MAC call.

 

Please let me know your comments/questions.

 

 

Regards

Guogang Huang

 

 

 


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1