Hi Alfred,
Could you kindly queue the following document to the MAC queue which resolves 1 CID (11587)? Changes have been made based on offline feedback. I am also forwarding herewith
the offline discussions on the topic for everyone’s reference.
|
17-Oct-2022 ET |
2022 |
1201 |
3 |
TGbe |
ML traffic indication using A-control |
Vishnu Ratnam (Samsung) |
17-Oct-2022 18:40:15 ET |
Regards,
Vishnu
From: Vishnu Vardhan Ratnam
Sent: Monday, October 17, 2022 4:32 PM
To: 'huangguogang' <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: 董贤东 <dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>;
Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein
<arik.klein@xxxxxxxxxx>
Subject: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Guogang,
Thank you for the response. However I am not entirely convinced about the need to violate the downlink T2LM. If T2LM violation is allowed, probably just delivering all the
BUs on the currently active link might be the best option in terms of power saving. Also, allowing AP to violate the T2LM in downlink has repercussions on uplink channel access by the non-AP MLDs. If we allow it, nothing prevents an AP MLD from always violating
downlink T2LM, so the purpose of T2LM is negated. One might as well not negotiate the downlink T2LM in that case. I think there is no clear solution to this issue, and it depends more on what is the majority opinion of the group. So I would like to queue the
current version (please find attached) of the doc to a MAC call.
@all: Please find attached the latest revision where I have incorporated the other changes suggested by everyone. Kindly let me know if you have any concerns regarding this
that hasn’t been discussed yet.
Regards,
Vishnu
From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Thursday, October 13, 2022 9:50 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>;
Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: 董贤东 <dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>;
asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat
Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>;
Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>;
luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: 答复: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Vishnu,
Please find my response inline.
Regards
Guogang Huang
发件人:
Vishnu Ratnam [mailto:vishnu.r@xxxxxxxxxxx]
发送时间: 2022年10月14日 2:31
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>;
Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
抄送: 董贤东 <dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>;
asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat
Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>;
Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>;
luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
主题: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Guogang,
At a high level there are two arguments here that you are making I think:
- The A-control should allow violation of T2LM for traffic delivery:
It is not clear to me why a non-AP MLD would negotiate a T2LM for downlink and then agree to violate it. I agree with your point that non-default T2LM for DL may have some disadvantages for power save etc. But in that case the non-AP MLD will just not negotiate
it right?
[Guogang Huang] Generally, the T2L mapping is negotiated for a
long-term period to improve the QoS. But the wakeup Request is designed in a
short-term period. The AP MLD may want to change the links for transmission for a specific STA due to the current load balancing, link quality and so on. I think it has a similar motivation to the Link Recommendation frame. When an affiliated STA operates
in PS mode and is waked up by the AP MLD, it can transition to the doze state if the More Data subfield is set to 0. Hence, the wakeup request has clear start time and end time.
For the second question, it is possible that the DL T2L mapping is negotiated due to some reason. In this
case, I still don’t want to add the T2L mapping constraint to the Wakeup Request.
- For non-default mapping, wake-up request is better than traffic indication:
In “principle”, traffic indication indicates what all STAs a non-AP MLD can use to fetch the BUs from, and the non-AP MLD can chose which of them to transition to awake state. In principle, wake-up request allows the AP to dictate which STA to transition to
awake, without indicating what are the other possible STA options for the non-AP MLD to do so. I think both have their separate benefits.
That being said, I do agree that there is a deficiency of the traffic indication method used in MLTI element currently for non-default mapping. In current method, the bit for a link is set to 1 if there is at least one BU that is mapped to that link.
So, if a non-AP MLD finds that the bits corresponding to two of its links are set to 1, a non-AP MLD cannot decide if it needs to wake up both or it is sufficient to wake up just 1 of them to fetch the BUs. The same deficiency is also admittedly passed on
to the proposed MLTI A-control in its current form. So in that sense, I am open to your suggestion for recommending a link for non-default mapping case, albeit without violating the T2LM. I am also open to other suggestions, if any? Only alternative is
@Abhishek Patil’s suggestion to use a TID bitmap to indicate what all TIDs the BUs belong to (so that non-AP MLD can pick the STAs accordingly).
[Guogang Huang]For this candidate resolution, it cannot indicate the link-specific MMPDU without carrying
MLO Link Information element. Furthermore, it cannot address the following cases, e.g. the AP MLD may want to change the link for transmission if the current link is kind of congested or unreachable due to the mobility.
But it will make things too cumbersome considering we are trying to make the A-control field a generic “link indication”
field that can be used for multiple use-cases involving a link bitmap.
@Park,
Minyoung
@Yongho Seok do you have any comments on the second bullet above?
Regards,
Vishnu
From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Tuesday, October 11, 2022 8:50 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>
Cc: 董贤东
<dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat
Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>;
Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>;
luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: 答复: Offline discussion on MLTI-variant A-control
(doc-1201)
Hi Vishnu,
Personally, I don’t prefer this version. I still think it should decouple with the T2L mapping, regardless of the default or no-default
T2L mapping.
So I can support 1201r1, rather than 1201r2.
Regards
Guogang Huang
发件人:
Vishnu Ratnam [mailto:vishnu.r@xxxxxxxxxxx]
发送时间: 2022年10月12日 2:42
收件人: Park, Minyoung <minyoung.park@xxxxxxxxx>;
huangguogang <huangguogang1@xxxxxxxxxx>;
Yongho Seok <yongho.seok@xxxxxxxxx>
抄送: 董贤东 <dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx;
Liyunbo <liyunbo@xxxxxxxxxx>;
Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
asterjadhi@xxxxxxxxx;
Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>;
Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>;
Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>;
Kiseon Ryu <kiseon.ryu@xxxxxxx>;
Serhat Erkucuk <serkucuk@xxxxxxxxxx>;
Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>;
Rakesh.Taori@xxxxxxxxxxxx;
Morteza Mehrnoush <mmehrnoush@xxxxxx>;
Rubayet Shafin <r.shafin@xxxxxxxxxxx>;
luliuming@xxxxxxxx;
Arik Klein <arik.klein@xxxxxxxxxx>
主题: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Minyoung,
In my current proposal, the “wake-up request” type behavior is only for default TID-to-link mapping, and it is only a recommendation. In other words,
in a frame exchange with a STA of a non-AP MLD, the AP can also request another STA to transition to awake state to receive the traffic. It is only a recommendation similar to link recommendation in ML traffic indication element. So I do not see why it will
disrupt the non-AP MLD’s operation since it can disregard it if required.
The reason I called it a “wake-up request” type behavior is to differentiate it from the operation of the link recommendation frame which is very
different. Link recommendation frame works more like a long-term soft TID-to-link mapping. This is also why I argue that existence of “Link recommendation frame” and T2LM feature
does not solve the same problems as the proposed MLTI A-control, and that there is no redundancy. It can be, for example, verified that none of the suggested scenarios in the discussion can be solved by either of these two features. The only similar
feature to the proposed MLTI A-control is the MLTI element. In other words, MLTI A-control is like an individually addressed version of the MLTI-element.
@Yongho: Thank you for sharing your opinion on the scope of comment resolution. I would like to argue that what is being proposed is to solve the
same issue as that raised in the comment by me. Only for default mapping where its benefit doesn’t exist, an alternative interpretation of the A-control is used. Even this interpretation has been used before in MLTI element so my opinion is that its not like
the comment is being used to push something different. That being said, as you suggested, I would indeed like to know opinion from others regarding this and then we can take a call whether to defer the operation for default mapping to future revisions or not.
Regarding why we need the feature when we already have MLTI element, T2LM and LR frame, please see my discussion above.
Regards,
Vishnu
From: Park, Minyoung <minyoung.park@xxxxxxxxx>
Sent: Tuesday, October 11, 2022 11:20 AM
To: huangguogang <huangguogang1@xxxxxxxxxx>;
Yongho Seok <yongho.seok@xxxxxxxxx>;
Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>
Cc: 董贤东
<dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx;
Liyunbo <liyunbo@xxxxxxxxxx>;
Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
asterjadhi@xxxxxxxxx;
Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>;
Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>;
Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>;
Kiseon Ryu <kiseon.ryu@xxxxxxx>;
Serhat Erkucuk <serkucuk@xxxxxxxxxx>;
Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>;
Rakesh.Taori@xxxxxxxxxxxx;
Morteza Mehrnoush <mmehrnoush@xxxxxx>;
Rubayet Shafin <r.shafin@xxxxxxxxxxx>;
luliuming@xxxxxxxx;
Arik Klein <arik.klein@xxxxxxxxxx>
Subject: RE: Offline discussion on MLTI-variant A-control (doc-1201)
My opinion is, in general, an AP MLD controlling power states of STAs affiliated with a non-AP MLD can disrupt the non-AP MLD’s operation since the
non-AP MLD has other operations that it needs to perform (e.g. P2P, scanning, coexistence with other radios, etc.). Thus, wakeup request kind of operation is not preferred.
Regards,
Minyoung
From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Tuesday, October 11, 2022 2:36 AM
To: Yongho Seok <yongho.seok@xxxxxxxxx>;
Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Cc: Park, Minyoung <minyoung.park@xxxxxxxxx>;
董贤东
<dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx;
Liyunbo <liyunbo@xxxxxxxxxx>;
Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
asterjadhi@xxxxxxxxx;
Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>;
Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>;
Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>;
Kiseon Ryu <kiseon.ryu@xxxxxxx>;
Serhat Erkucuk <serkucuk@xxxxxxxxxx>;
Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>;
Rakesh.Taori@xxxxxxxxxxxx;
Morteza Mehrnoush <mmehrnoush@xxxxxx>;
Rubayet Shafin <r.shafin@xxxxxxxxxxx>;
luliuming@xxxxxxxx;
Arik Klein <arik.klein@xxxxxxxxxx>
Subject: 答复:
Offline discussion on MLTI-variant A-control (doc-1201)
Hi Yongho Seok,
Sorry to jump into the discussion.
For the wakeup Request A-control, I do see some benefits. I can add some use cases:
Use case 1. When the link quality of the current link is getting poor, the AP MLD can wake up other links for reception. For example,
assuming that 2.4 GHz link is in PS mode and 6 GHz link is in active mode. Due to the non-AP MLD’s mobility, the link quality of the 2.4 GHz link is getting poor, then the AP MLD can send a individually addressed frame with a Wakeup Request A-control to wake
up 6 GHz link for reception.
Use case 2. To achieve a good trade-off between power saving and the delay performance, a non-AP MLD can let only one link operate
in active mode. When there are a larger volume of traffic to be delivery, the AP MLD can wake up other link s to enhance the throughput and reduce the delay.
Use case 3. Considering the Beacon bloating and legacy STA’s compatibility issue resulting from including a MLTI element within the
Beacon frame, maybe we can define a wakeup request as an alternative to allow the AP MLD not to include a MLTI element within the Beacon frame. When the corresponding bit in the TIM element is set to 1, then any STA affiliated with this non-AP MLD can issue
a PS-Poll. After that, the AP MLD may dynamically reschedule the downlink delivery based on the traffic loads on all links by using the Wakeup Request A-control.
In addition, for the current text on the MLTI element, I don’t think it’s good to couple it with
DL T2L mapping. This design is not good to the non-AP MLD’s power saving. If we define a wakeup Request A-control, I don’t see the benefit to negotiate the T2L mapping for the downlink. Because the
AP MLD can dynamically schedule the downlink delivery based on the traffic loads on all links by using the Wakeup Request A-control.
Based on the current condition to include a MLTI element within the Beacon frame, if there is a link-level MMPDU, the MLTI element
may be not included within the Beacon frame. In this case, a wakeup request also can be used.
Regards
Guogang Huang
发件人:
Yongho Seok [mailto:yongho.seok@xxxxxxxxx]
发送时间: 2022年10月11日 14:05
收件人: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
抄送: Park, Minyoung <minyoung.park@xxxxxxxxx>;
huangguogang <huangguogang1@xxxxxxxxxx>;
董贤东 <dongxiandong@xxxxxxxxxx>;
montemurro.michael@xxxxxxxxx;
Liyunbo <liyunbo@xxxxxxxxxx>;
Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
asterjadhi@xxxxxxxxx;
Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>;
Cariou, Laurent <laurent.cariou@xxxxxxxxx>;
Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>;
Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>;
Kiseon Ryu <kiseon.ryu@xxxxxxx>;
Serhat Erkucuk <serkucuk@xxxxxxxxxx>;
Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>;
Rakesh.Taori@xxxxxxxxxxxx;
Morteza Mehrnoush <mmehrnoush@xxxxxx>;
Rubayet Shafin <r.shafin@xxxxxxxxxxx>;
luliuming@xxxxxxxx;
Arik Klein <arik.klein@xxxxxxxxxx>
主题: Re: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Vishnu,
Please see my response inline.
Thanks,
Yongho
2022년 10월
10일 (월)
오후 1:40, Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>님이
작성:
Hi Yongho,
Although the goal of the comment (which was made by me) indeed is for cross-link BU indication, such indication is not particularly useful when a device has default mapping. So for default mapping at least, an alternative use-case should be provided. So I proposed to use the same approach as in the MLTI-element, i.e., for non-default mapping provide BU indication, and for default mapping provide link recommendation. I do not see any reason why the proposal should only be restricted to BU indication even for default T2LM, considering a precedent already exists in MLTI element transmitted in beacons.
[YH: This is a recommendation of the comment resolution (11-13/0230).
"The proposed change should relate to the comment directly, not be an excuse to fix something else."
It seems the link recommendation and wake-up request are something else.
In the default mapping, we already have several mechanisms, the link recommendation in the MLTI in the Beacon frame, the Link Recommendation action frame, the T2LM load balancing (11-22/1509). I
don't know why we need another one.
BTW, this is just my personal opinion, although I am against on this proposal, it may be interesting to see how many members support this direction.
]
Kindly also note that this link recommendation is equivalent to a “wake-up request” and is very different from the purpose of the link recommendation frame (which is similar to a soft T2LM). So a individually addressed link recommendation frame cannot achieve the same goals as the proposed MLTI A-control and vice versa. In my opinion, the confusion is due to use of the phrase “link recommendation” to imply multiple things in the spec.
I also went through your proposal on cross-link PM and EOSP indication for U-APSD (CR 085r1) in detail, and in my opinion they are very different proposals from the proposed MLTI A-control. I do not see why they should be tied to the current proposal whose focus is on for cross link traffic indication, or why they need to be co-designed. That being said, as per your and Minyoung’s suggestion, I have in the revised document and generalized the A-control to “Link Indication” with a subtype field. One sub-type can be MLTI for cross-link traffic indication. Others can be used for other goals like the cross-link power management, more data, EOSP that you mention.
@all: Kindly let me know if there are any comments on the revised proposal attached herewith.
Regards,
Vishnu
From: Yongho Seok <yongho.seok@xxxxxxxxx>
Sent: Thursday, September 15, 2022 4:23 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>
Cc: Park, Minyoung <minyoung.park@xxxxxxxxx>; huangguogang <huangguogang1@xxxxxxxxxx>; 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: Re: Offline discussion on MLTI-variant A-control (doc-1201)
"When there are no remaining BUs for a nonAP MLD that mapped to the current link, the AP MLD sets the "More Data" subfield to 0 in a downlink PPDU, or transmits a QoS null data frame in response to a PS poll. The spec should provide a mechanism for the AP to also indicate, in the response frame, presence of pending traffic for the non-AP MLD that is mapped to other links. The AP should also utilize such a mechanism to indicate a need to check the beacon for critical update."
Basically, the comment is asking for a BU indication of another link.
But, some members are commenting on a different scenario like a link recommendation in default mapping scenario. It is not out of scope.
And, your all Options are assuming that we support the link recommendation. I disagree with that.
First, we should focus on the comment itself, and design an unified approach to support the cross-link PM, MD, ESOP, etc.
Thanks,
Yongho
2022년 9월 15일 (목) 오후 12:57, Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>님이 작성:
Hi Minyoung and all,
I agree that there are two aspects here:
- Traffic indication (same as more data in my opinion)
- Link recommendation (same as power management or wake up request)
Please let me know if there are more to consider.
The question is whether we want to achieve both goals with the transmission of one A-control field or we want to send separate A-control fields for both.
Option 1: Follow the same approach as in ML traffic indication element, i.e., provide traffic indication for default T2LM and link recommendation for non-default T2LM. The A-control format can be like:
| Control ID | Subtype | Link bitmap | Padding |
4 4 16 6
Subtype=0: ML Traffic indication
Subtype=1: AAR
Subtype>1: Reserved
Option 2: Separate A-control subtypes for both features, where the A-control format can be like:
| Control ID | Subtype | Link bitmap | Padding |
4 4 16 6
Subtype=0: Traffic indication/More data
Subtype=1: Link recommendation/Wakeup request
Subtype=2: AAR
Subtype>2: Reserved
Option 3: An alternative is on slide 9 of my ppt, which can simultaneously perform both traffic indication (using a 16bit TID bitmap) and can recommend one link to wake up (using a 4bit link ID field) using just one transmission of the A-control.
| Control ID | TID bitmap | Link ID | Padding |
4 16 4 6
In my opinion option 2 (although most generalizable), makes it unclear when the AP should send subtype0 and when it should send subtype1. Sending both will require two transmissions of A-controls in two data frames. So option 1 and option 3 may be simpler since it is more clear when to include them. Thoughts?
Regards,
Vishnu
From: Park, Minyoung <minyoung.park@xxxxxxxxx>
Sent: Thursday, September 15, 2022 7:36 AM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; huangguogang <huangguogang1@xxxxxxxxxx>; 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Vishnu,
I would suggest to give some more thoughts on a unified approach on this related to power save and traffic indication across multiple links (PM, More Data, EOSP, traffic indication, etc.). Resolving just one aspect of the ML operation using the A-control field seems not complete.
Regards,
Minyoung
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Wednesday, September 14, 2022 12:05 PM
To: Park, Minyoung <minyoung.park@xxxxxxxxx>; huangguogang <huangguogang1@xxxxxxxxxx>; 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Dear all,
Based on offline discussion, there are 3 potential options for cross link traffic indication/link recommendations. Please find the same in the attached ppt slides 7-9. I have also listed the benefits and disadvantages of all the three options there. Based on the comments received so far, it seems option 1 is the most preferrable option. Please let me know if you feel otherwise (in particular for option 3 since this wasn’t discussed before).
Main concerns raised for option 1 and my responses:
- Does not give non-AP MLD flexibility to pick the link to transition to awake state.
[VR] The indication is only a recommendation. A non-AP MLD can always ignore it and try to fetch the BUs on other links, so flexibility is maintained. The benefit of following the recommendation is faster channel access, more power save by enabling “temporary” violation of T2LM, faster packet delivery etc.
- There are already two link recommendation features: ML traffic indication element and Link Recommendation frame. Why do we need a third for individually addressed case.
[VR] The link recommendation provided in MLTI-variant A-control is an individually addressed version of the link recommendation and traffic indication provided in ML traffic indication element. I would like to reiterate that this is very different from the link recommendation frame feature which is a long term indication and for both uplink downlink (it is more similar to a soft T2LM). It will be very wasteful to use the existing link recommendation frame for temporary indication the links to fetch BUs in individually addressed frames. Firstly it is much larger in size, secondly since it is long term, it has to be disabled as well after the BUs are fetched. Thirdly, link recommendation frame is not equipped to provide traffic indication, for e.g., it can’t indicate that no further traffic is pending for the non-AP MLD (see scenario 2 on slide 4 and also the discussion below).
Copying scenario 2 here to further justify why MLTI-variant A-control can’t be replaced by link recommendation frame:
The current spec on multi-link traffic indication element says: “When the Per-Link Traffic Indication Bitmap subfield corresponds to a non-AP MLD that has successfully negotiated TID-to-link mapping and not all TIDs are mapped to all the enabled links, a value of 1 in the bit position i in the bitmap that corresponds to a link on which a STA affiliated with a non-AP MLD is operating indicates that there is buffered BU(s) with TID(s) mapped to the link with the link ID equal to i or MMPDU(s); a value of 0 in a bit position in the bitmap indicates that there is no buffered BU(s) with TID(s) mapped to the corresponding link nor MMPDU(s).”
So for one BU mapped to multiple links, the bit corresponding to all such link IDs can be set to 1 in multi-link traffic indication element. In such case all of those STAs may transition to awake state. Then it is essential to provide cross-link traffic indication so that once the BU is delivered on one link, the other STAs don’t need to waste power contending for channel access. [See scenario 2 on slide 4]. We similarly also have the other benefits as in scenario 1-4.
Regards,
Vishnu
From: Park, Minyoung <minyoung.park@xxxxxxxxx>
Sent: Tuesday, September 6, 2022 2:05 PM
To: huangguogang <huangguogang1@xxxxxxxxxx>; Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Vishnu,
As I mentioned during the call, I would like to see a unified cross-link design that can also indicate the power management mode of other link(s) through a frame that includes the A-Control field that is transmitted on one of the enabled links.
The A-control field format can include a subtype field (3-4 bits? For 8-16 different subtypes) to differentiate different signalings
- e.g. PM indication can have a subtype value = 1.
- The bitmap (16bit) can indicate Link ID and when it is set to 0, the STA on that link is action, when it is set to 1, the link is in PS mode.
- The current link on which the frame with the A-control field is being transmitted can be excluded, i.e. the PM indication of the current link follows the baseline rules.
Regards,
Minyoung
From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Monday, September 5, 2022 11:37 PM
To: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>; 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: 答复: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Vishnu,
Thanks for your response.
Besides the indicated link ID in MLTI-variant A-control doesn’t need to comply with the T2L mapping, I want to emphasize another use case I mentioned in the last email.
For the MLTI A-control proposed by Vishnu, I can add another use case. Assuming that a non-AP MLD has negotiated a default T2L mapping with the AP MLD, the non-AP MLD may let only one affiliated STA operate in the active mode and let the remaining affiliated STAs operate in PS mode to save power.
When a larger volume of downlink traffic is arrived, the AP MLD is allowed to wake up other affiliated STAs to enhance the downlink throughput or improve the latency. This operation is very useful to make a good trade-off between power consumption and throughput/latency. Note that in this case, the AP MLD cannot use the MLTI signaling through the Multi-link Traffic Indication element to recommend link. Because according to the below text, the AP MLD is not allowed to set the bit in the partial virtual bitmap of the TIM element to 1.
In the above use case, we can see the proposed MLTI-variant A-control may have no relationship with the MLTI signaling through the Multi-link Traffic Indication element.
Regards
Guogang Huang
发件人: Vishnu Ratnam [mailto:vishnu.r@xxxxxxxxxxx]
发送时间: 2022年9月6日 13:31
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
主题: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Guogang,
Thanks for the suggestion. Yes as per the current draft, the indicated link ID in MLTI-variant A-control doesn’t need to comply with the T2L mapping. This is to minimize the number of STAs that need to wake up to fetch all the BUs, thus saving power. This also partly addresses Yongho’s question on the distinction from the link recommendation in Multi-link traffic indication element.
Regarding the name, I am open to determining a name after we have consensus on the functionality of the A-control field.
Regards,
Vishnu
From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Sunday, September 4, 2022 9:10 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: 答复: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Vishnu,
In my understanding, your proposed MLTI-variant A-control is a little different from the one signaled through a Multi-link Traffic Indication element. For example, the proposed MLTI-variant A-control doesn’t need to comply with the T2L mapping agreement, right?
If yes, I suggest to use a new name to differentiate these two mechanisms. Maybe we can name it as Wakeup Request. When a STA affiliated with a non-AP MLD receives a Wakeup Request, then the corresponding affiliated STA should wake up on the indicated links to retrieve buffered BUs.
Regards
Guogang Huang
发件人: Vishnu Ratnam [mailto:vishnu.r@xxxxxxxxxxx]
发送时间: 2022年9月5日 0:58
收件人: 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; huangguogang <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; luliuming@xxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
主题: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Adding Arik to the thread.
@all: a gentle reminder to kindly share any comments you may have on this topic. I have summarized and added the replies to Mike, Yunbo and Abhi’s comments below.
Regards,
Vishnu
From: Vishnu Vardhan Ratnam
Sent: Tuesday, August 30, 2022 10:51 PM
To: '董贤东' <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; huangguogang <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>; 'luliuming@xxxxxxxx' <luliuming@xxxxxxxx>
Subject: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Adding Liuming to the thread.
From: 董贤东 <dongxiandong@xxxxxxxxxx>
Sent: Tuesday, August 30, 2022 10:01 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; montemurro.michael@xxxxxxxxx; huangguogang <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Subject: 答复: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Vishnu,
Your response makes sense to me.
Best regards
Xiandong
发件人: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
发送时间: 2022年8月31日 10:52
收件人: 董贤东 <dongxiandong@xxxxxxxxxx>; montemurro.michael@xxxxxxxxx; huangguogang <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>
主题: RE: Offline discussion on MLTI-variant A-control (doc-1201)
Hi Xiandong,
Could you elaborate what you mean by “wake up scheduling which is already completed”? If you are referring to any per-link traffic indication received in a multi-link traffic indication element that was previously transmitted by the AP MLD, then yes the indication in the MLTI-variant A-control will replace that indication. If you are referring to something like r-TWT wake-up schedules etc., those will still apply and will not be replaced. The corresponding text I copy paste below:
(#11587)When a STA of a non-AP MLD with dot11MLTIOptionImplemented set to true receives a frame from the AP with the MLTI control subfield present in the HE-variant HT control field, then the following applies:
- The STAs of the non-AP MLD operating on the link(s) indicated as 1 in the Traffic Indication Link ID bitmap subfield of the MLTI control subfield, should issue a PS-Poll frame, or a U-APSD trigger frame if the STA is using U-APSD and all ACs are delivery enabled, to retrieve buffered BU(s) from the AP MLD.
- The STAs of the non-AP MLD operating on the link(s) indicated as 0 in the Traffic Indication Link ID bitmap subfield of the MLTI control subfield do not need to issue a PS-poll or a U-APSD trigger frame, if recommended to do so by a multi-link traffic indication element previously transmitted by the AP MLD.
Regards,
Vishnu
From: 董贤东 <dongxiandong@xxxxxxxxxx>
Sent: Tuesday, August 30, 2022 8:59 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; montemurro.michael@xxxxxxxxx; huangguogang <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Subject: 答复: Offline discussion on MLTI-variant A-control (doc-1201)
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 Vishnu,
Thanks for initiating this E-mail tread, it seems that you proposed an “early indication for wakeup” mechanism, my clarification question is that if the mechanism is used for early wakeup of a STA affiliated with a non-AP MLD to retrieve the BUs, should the STA still follow the wake up scheduling which is already completed with the AP affiliated an AP MLD.
Best regards
Xiandong
发件人: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
发送时间: 2022年8月31日 6:02
收件人: montemurro.michael@xxxxxxxxx; huangguogang <huangguogang1@xxxxxxxxxx>; Park, Minyoung <minyoung.park@xxxxxxxxx>; Liyunbo <liyunbo@xxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx; 董贤东 <dongxiandong@xxxxxxxxxx>; Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; Yongho Seok <yongho.seok@xxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; Guoyuchen (Jason Yuchen Guo) <guoyuchen@xxxxxxxxxx>; Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; Kiseon Ryu <kiseon.ryu@xxxxxxx>; Serhat Erkucuk <serkucuk@xxxxxxxxxx>; Rajat PUSHKARNA <rajat.pushkarna@xxxxxxxxxxxxxxxx>; Rakesh.Taori@xxxxxxxxxxxx; Morteza Mehrnoush <mmehrnoush@xxxxxx>; Rubayet Shafin <r.shafin@xxxxxxxxxxx>
主题: Offline discussion on MLTI-variant A-control (doc-1201)
Dear all,
Thank you for sharing your comments on my proposal 1201r2 today. Due to lack of time unfortunately, I couldn’t get feedback from everyone so I would like to use this thread to get further feedback from everyone who commented on the topic. I also summarize below the questions raised on call, kindly correct me if my understanding of your question is incorrect or if you have more feedback.
Summary of proposal: A mechanism for an AP affiliated with an AP MLD indicate in an existing individually-addressed frame sequence with a STA affiliated with a non-AP MLD if it has BU(s) that are mapped to or are recommended to be retrieved on other links of the non-AP MLD. Several use cases are possible as described in the discussion.
Mike--Is the use-case assumption here that TID-to-Link mapping is non-default? From vendor side, it may be preferred for non-AP MLD to make the decision to wake up STA. If there is non-default mapping, why not leverage the additional features of U-APSD to determine where to send the U-APSD trigger?
VR: There are use cases even for default TID-to-link mapping. The proposed indication is similar to link recommendation in multi-link traffic indication element, except that this is individually addressed and is sent in an on-going frame exchange sequence. So similar to link recommendation, the decision of whether to wake up another STA or not is still with the non-AP MLD. The indication just facilitates providing the recommendation by the AP MLD. I actually did not follow your commend regarding U-APSD completely (my knowledge of U-APSD is limited). Could you kindly elaborate?
Minyoung—Create a generalized A-control, say Link Indication control field, that has similar structure but with 2 or 3 bits indicating “subtype”. AAR and MLTI can be two sub-types of Link Indication control field.
VR: Agree with this suggestion, in case we reach consensus to use the current format for the MLTI-variant and agree to merge it with AAR-variant.
Yunbo--There is no issue in the operation of more data field. The intention here is to enable additional benefit by indicating traffic for other links. Is this correct understanding? But it is hard for the non-AP MLD in default mapping to know whether it is efficient for it to wake up another STA or not based on the recommendation.
VR: Yes, there is no issue with current operation of more data subfield. It is expected that the AP MLD will indicate an alternate link in the MLTI A-control field only in the case that the current TXOP is not sufficient to deliver all the BU(s) addressed to the non-AP MLD, or if some BU(s) are not mapped to the current link. So in my opinion the trade-off of whether to follow the recommendation is quite similar to when receiving a link recommendation in multi-link traffic indication element. When one STA of a non-AP MLD that is in awake state receives the multi-link traffic indication element with another STA of the non-AP MLD as the recommended link, there is a similar trade-off, i.e., transmit PS poll on the active STA or on the recommended STA. So in my opinion, the proposal does not add any additional dilemma, and a non-AP MLD capable of making a decision based on link recommendation in multi-link traffic indication element can also do so for the proposed MLTI-variant A-control. Finally note that the indication is only a recommendation by the AP MLD, and a non-AP MLD can decide whether to conform or not (similar to the recommendation in multi-link traffic indication element).
Abhi—It is much more beneficial to indicate a TID bitmap (instead of a link recommendation bitmap) to indicate if there is at least one BU corresponding to each TID. This can enable a non-AP MLD to determine which STAs to transition to awake. Also, support indication for MLTI may not be necessary (can make mandatory).
VR: Indeed the suggestion is interesting but it realizes a slightly different goal.
Benefit of indicating TIDs:
- Gives flexibility for non-AP MLD to pick which additional links to wake up.
Benefits when AP indicates link IDs:
- AP MLD has an idea of the network load at the current time and so accordingly it can recommend appropriate STAs of non-AP MLD to wake up (so that there are not too many PS polls on one link).
- The number of STAs that are asked to wake up can be based on the amount of BUs for the non-AP MLD.
- Can offload some link recommendations from the multi-link traffic indication element (which is inefficient in signaling).
I personally am of the opinion that benefits of the latter are better, but I am open to suggestions on this.
Others?
Regards,
Vishnu
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
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