| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Yunbo, Thank you again for this constructive discussion. As you are ok with both solutions, hopefully we can move forward with current SP text, and discuss further on how to have the TID/link indication as a next step. Best regards, Young Hoon From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Young Hoon, Thanks for your explanation. After the discussion I don’t have a strong preference of the two types of indication I mentioned in previous e-mails. I withdraw
my suggestion of SP text. Further comments as below: I think they their own pros can cons. From signaling point of view, when the MLD has a small percentage (others are legacy or single link MLD), Type 1 is better.
While the percentage increase, Type 2 which you propose is better. I don’t think multiple AIDs for a MLD will makes other MAC procedure very complex. A simple way is only use the first AID and ignore others for other MAC frames.
But I agree it may need some clarification or restriction in the spec. Thanks again for your discussion. Regards, Yunbo 发件人:
Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Yunbo, Thanks for your follow up explanation. If an AID is given to each TID (or a set of TIDs) for a non-AP MLD, say n1 bits are assigned to the non-AP MLD, then it occupies n1 times more AID space for a single non-AP
MLD, therefore even if there’s no DL buffered BU assigned for the non-AP MLD, these n1 bits needs to be included in the TIM element. But, in case AID is assigned per MLD, we only need one bit per MLD in TIM element, and because the number of STAs that AP has buffered BU is much smaller than the number of
associated STAs, having a separate element for indicating which link to use gives meaningful overhead reduction. Also, AID is used not only for TIM indication but also for other purposes. For example, AID is used for a STA-ID in PHY header and quite a lot of MAC frames. So, in case an
AP transmits a multi-TID A-MPDU for a non-AP MLD, if different AID is mapped to different TID, we need additional rule to clarify which AID to be used and how to handle all the exceptional cases etc, which requires each non-AP MLD to further check and compare
multiple AIDs if the indicated AID in a frame is for the non-AP MLD or not each time the non-AP MLD receives the frame. So, I don’t think having AID per TID is a clean solution. One more thing to say is that I didn’t include the link indication part in my SP as I also agree with the group that there can be more discussion needed for the link indication. So, we can further consider both TID indication and link indication and make a final conclusion in later phase. Thanks, Young Hoon From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Young Hoon, Yes, in Type 1, an AID will be assigned for one TID (or one set of TIDs to save overhead) for a non-AP MLD.
I think we still have some different understandings. Let me try to further explain my opinions. I think it doesn’t matter TID-to-link mapping or default mapping is used, TID indication instead of link indication is a very important information will help
non-AP MLD to decide wakeup on which links. Frequently update TID-to-link mapping doesn’t have any affection of Type 1 indication, only affect the decision of wake up links for non-AP MLD, which is implementation
issue. Because non-AP MLD only need to wake up some or all of mapped links. Regards, Yunbo 发件人:
Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Yunbo, Thank you very much for your suggestion. Not sure if I understand your suggestion correctly, but it looks you want to allow assigning AID per each TID for a non-AP MLD. But in my opinion, the most frequent and meaningful usage case is that all TIDs are mapped to all links, which even doesn’t require any TID to link mapping indication at all.
Also, TID to link mapping can happen more frequently during a non-AP MLD’s association with an AP MLD.
So, I’m not quite convinced of having many AIDs for a non-AP MLD for this purpose. Thanks, Young Hoon From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Yong Hoon, Thanks for the reply. I have several further comments/questions: For your design, when a TID is mapping to multiple links, how does the AP MLD choose which links to set to 1? If AP set all mapped links to 1, then STA MLD needs
to wake up all mapped links every time (because STA MLD doesn’t know the TID information). It may not efficient to save power for STA MLD. As I understanding, currently there are two types of indication. Type 1 is assign a AID for one TID, and TID grouping can further
reduce the overhead. Type 2 is assign a AID for STA MLD, and then indicate link or TID for the STA MLD. Type 2 is what you proposed. For me, Type 1 also has its advantages:
1)
it doesn’t need to introduce new LMB field (or elements),
2)
different STA MLD can has different number of signaling bits, based on the number of TIDs it supports. So for a STA MLD it only needs n1 bits for signaling
in Type1, n1=the number of TIDs it support. While a STA MLD needs (1+n2) bits for signaling in Type 2, n2 is the maximum number of TIDs that all associated STA MLD supports. So for signaling overhead point of view, which type is more efficient will depends
on scenarios. So if you want to run SP in next MAC meeting, can I suggest to change one AID for a STA MLD to “one or more AID(s) for a STA MLD” in straw poll before fully discussed? Regards, Yunbo 发件人:
Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Yunbo, Thank you very much for your comments. Please see my answers in line below. BR, Young Hoon From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Young Hoon, Thanks for sharing the presentation 0066. Since we didn’t have time to fully discussion, I use this e-mail thread to continue the discussion. I have two questions,
would you please clarify, thanks.
1)
In side 3, you mentioned “The AP MLD needs to indicate which link the AP MLD has buffered BU to transmit, especially when different TIDs are mapped
to different links”. In MLD, when the BU of one TID is mapping to multiple links, how AP decide which links to indicated in LMB? When the STA MLD receive the signaling, it still doesn’t know what TID the BU belongs to, so how the STA MLD decide to wake up
on which links? I think may be a better way is to indicate the TID, so the STA MLD can clearly know it should wakeup on which links (base on the Traffic requirement, battery level, and other internal conditions). Because power save is an issue for at STA MLD
side, not at AP MLD side, so it may be better to STA MLD to do the decision. During the teleconference, many people asked the similar questions in the chat window. [YKWON] As I mentioned during the call, indicating TID instead of link can also be another option. But, the issue is that overhead.
Due to overhead limit I would expect that one bit indication for each TID is too much, and thus, a set of TIDs may need to be grouped together for the indication. In this case, as there’s still uncertainty which TID to be used, similar issues are still there.
We can certainly have further discussion on how to indicate TID/link when we first agree on the first step of having per-MLD level AID.
2)
In your design, each legacy STA also needs to use 3 bit in LMB subfield. So in a scenario that only a small percent of STAs are EHT MLD, AP needs to
still need to allocate 3 bits for each legacy STA in LMB subfield. It will be a large overhead. It has similar issue for STA MLD that only mapping on one or two links. [YKWON] The way I showed in this slides deck is just an example of doing TID to link mapping, and there’s other ways of improving/optimizing the overall
performance on link indication side. For example, an AP MLD can assign AIDs greater than a threshold for non-AP MLDs (AID for legacy STAs can be assigned to be less than the threshold in this case), and the AP MLD indicate the LMB only for those STAs that
AID is greater than the threshold. I didn’t elaborate on the link mapping side a lot as we think at least in R1 the most common operation scenario is the case that all TIDs are mapped to all links. Regards, Yunbo 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 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 |