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

Re: [STDS-802-11-TGBE] Further discussion on 11-22/1201

Dear all,

 

In the interest of making progress, based on offline discussions, I have resolved the first comment from the below email in the latest revision. The latest revision of the CR document can be found below, and the changes are highlighted in blue.

16-Jan-2023 ET

2022

1201

5

TGbe

ML traffic indication using A-control

Vishnu Ratnam (Samsung)

16-Jan-2023 02:01:27 ET

Download

The main change is as follows:

  • The LI control subfield has been assigned the Control ID of 9 (which was previously assigned to AAR). AAR has been added as a subtype of LI control subfield.

I would be happy to address any further questions or comments on the document.

 

Regards,

Vishnu

 

From: Vishnu Vardhan Ratnam
Sent: Thursday, January 12, 2023 2:12 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Further discussion on 11-22/1201

 

Dear all,

 

Thank you for the discussion on the document 11-22/1201r4 in 1/11/2023 PM1 session, and sharing your thoughts. I think this is a useful feature for WiFi-7 that can help a non-AP MLD to save power by using only one link for TX/RX in low traffic condition and also have good performance by waking-up other STAs when required, as recommended by the AP MLD. Since the straw poll was some-what positive (17y 11n), I would like to initiate a discussion here to try and see if we can get more support. The main questions raised on the call were as follows:

 

Alfred:

  1. The text needs rewording since it is not clear if the wakeup request is only meant for STAs in doze state or even for STAs that are in active state. STAs in active state can also use such information for bandwidth expansion etc.
  2. The LI-Control field should be combined with the AAR A-control field since they have a similar format and application.

Vishnu:

  1. The indication in the proposal is meant for other STAs that are currently in doze state. If the other STAs are already in active state, the corresponding AP can directly transmit the PPDUs to those STAs, or can provide the indication for bandwidth expansion directly to those other STAs (other proposals are exploring this direction by sending an MU-RTS). So the need for the cross-link indication for STAs in active state isn't be clear.
  2. As I mentioned, yes the final intention is to consider adding AAR A-control as a subtype of the LI A-control. This is also why the format has been kept compatible. But proposing a new A-control, and a new subtype (Wake-up request) and also merging AAR as another subtype is a very big task to accomplish in one proposal. It is better to do the merging in a separate proposal. Apart from that I agree with your point.

 

Minyoung:

  1. I have concern on the AP MLD telling the non-AP MLD where it should receive the remaining BUs. The non-AP MLD may have restrictions on which STAs it wants to wake up.
  2. There is already the multi-link traffic indication element and the link recommendation frame that are providing link recommendation for a non-AP MLD. Why do we need a 3rd mechanism? I don't think ML traffic indication element is an inefficient solution for such indication.

Vishnu:

  1. The indication by the AP MLD is only a recommendation for the non-AP MLD, to help it determine how many STAs should be transitioned to active state based on the amount of downlink BUs buffered (to optimize its performance). It is not binding, so the non-AP MLD may refrain from transitioning to active state on the other link for implementation dependent reasons. The AP will still deliver the remaining BU(s) on the first link, although now it may take longer for the buffer for the non-AP MLD to be cleared.
  2. Although the ML traffic indication element can be used for link recommendation, it is to suggest options of links for receiving the BUs. The goal is mainly for load balancing. To elaborate, please note that the spec says:

"Any non-AP STA affiliated with the non-AP MLD that operates on the link(s) indicated as 1 in the Per-Link Traffic Indication Bitmap subfield may issue a PS-Poll frame, or a U-APSD trigger frame..., to retrieve buffered BU(s) from the AP MLD."

In other words, if two bits are set to 1 in the Per-link Traffic Indication List Bitmap corresponding to a non-AP MLD, the AP MLD is indicating that any one of the two STAs affiliated with the non-AP MLD can retrieve the BUs. It doesn’t indicate that the AP MLD is recommending STAs on both links to transition to awake state. So ML traffic indication element doesn’t achieve the desired behavior considered in this proposal. In addition, there are several other issues with using ML traffic indication element in its current form, as also described in the discussion section of the proposal 1201r4. Link Recommendation frame is also meant for long-term recommendations of links to retrieve BUs in UL/DL. In other words , it is like a soft T2LM and is for load balancing. It doesn’t achieve the desired behavior of this proposal. If you think ML traffic indication or Link recommendation frame can achieve the desired goal, kindly do share.

 

I hope these answer the questions raised on the call. I would be happy to answer any further questions.

 

Regards,

Vishnu

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