Hi Minyoung,
Thanks for your response. I agree that after Beacon-A frame is introduced, the Beacon bloating issue is resolved. But it doesn’t means the signaling overhead is not a issue that
need to be considered. I think it depends on the balance between the effort on the modification and the gain that will get.
I through my two comments are minor, but could get significant benefits, then why not consider them?
1)
The current spec support up to 15 links, although normally there are about 3 links for a AP MLD, it may be more consider that people are considering new spectrum in next
generation. Let’s assume a AP MLD may have 8 links in the future. Once a non-AP STA associated with link 8, we may need 8 bits to indicate one non-AP MLD in MLTI. If the AID offset subfield is add back, we can naturally carry two MLTI in single Beacon-A frame.
E.g. 4 bits per non-AP in one MLTI which include most of the non-AP MLDs, and 8 bits per non-AP MLD in another MLTI for a few non-AP MLDs.
2)
A link bitmap can naturally avoid the indication of some links that doesn’t exist (e.g. after link remove) for each non-AP MLD. Do you have a concern on the link bitmap?
Regards,
Yunbo
发件人: Minyoung Park <mpark.ieee@xxxxxxxxx>
发送时间: 2022年9月24日
2:57
收件人: Liyunbo <liyunbo@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame
Hello all,
Thanks for the feedback on doc 1381r1.
Most of the comments so far are related to further optimization on the size of the MLTI (multi-link traffic indication) element. Although we can spend time and work on optimizing the size of the MLTI element for many
different scenarios, once the MLTI element is moved to a new Beacon-A frame the beacon bloating issue for legacy STAs is resolved and the size of the MLTI element becomes less of a problem. Instead, IMO, simplifying the MLTI element processing might be a more
important aspect to consider. With this in mind, reusing the structure of the Link Recommendation frame that includes the AID Bitmap and the MLTI element seems to be a natural choice.
I've uploaded 1381r2 reflecting the changes on D2.2.
Please see below responses as well:
-
Rojan - although I agree that your proposed approach will reduce overhead of the AID bitmap when there are many zeros in the AID bitmap, this requires using information across TIM in the Beacon and modified AID Bitmap and MLTI elements in
the Beacon-A frame.
-
Vishnu - Since the AID Bitmap element and the MLTI element are in the same frame, whether to have the AID bitmap information in the MLTI element is not a critical part of the design. The Link Recommendation frame includes the AID Bitmap and
the MLTI element so reusing the same structure might be better for simplicity.
-
Xiangxin - The Link Recommendation frame includes the AID Bitmap and the MLTI element so reusing the same structure might be better for simplicity.
-
Shawn - On item1, I revised the resolution for CID 13855. The condition is now updated as "...and the AP MLD has buffered BU(s) (#13855)with TID(s) that are not mapped to all the enabled links for the
non-AP MLD(s)." On item 2, indicating all the links that can be used to retrieve BU with the mapped TID(s) makes more sense to me.
-
Yunbo - Since we resolved the beacon bloating issue with the Beacon-A frame and removed unnecessary overheads (bitmaps associated with legacy STAs or non-AP MLDs with default mapping) from the MLTI element, further optimizing the size of
the MLTI element seems to be not a critical issue.
Hi Minyoung,
Thanks for your presentation. I have below two comments, would you please let me know your opinions.
1)
Do you consider to keep the AID offset subfield? In that case, it will bring several benefits. Firstly, single frame structure of ML traffic indication element can be used in Beacon and Beacon-A
frame. Secondly, multiple ML traffic indication elements can be carried in same Beacon or Beacon-A frame. Think about a use case that AP MLD allocate segment A of AIDs to non-AP MLDs with two links, and allocate segment B of AIDs to non-AP MLDs with three
link. So that the AP could carry two ML traffic indication elements and the bitmap lengths in two element are 2 and 3 respectively. So it could potentially save the overhead.
2)
Link ID offset subfield could help to reduce the signaling overhead, and a link ID bitmap also could achieve same purpose. In some cases that the link IDs are not contiguous, a link ID bitmap
could do better. If a link ID bitmap is used here, we don’t need to force that each AP MLD allocate the link ID contiguous, which may release Abhi’s concern.
Regards,
Yunbo
发件人: Minyoung Park <mpark.ieee@xxxxxxxxx>
发送时间: 2022年9月16日
8:02
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame
Hi all,
I'm starting an email thread on the Beacon-A frame proposal in CR doc 1381r1. Please post your questions in the thread. I answered the questions posted on the
chat and during the meeting.
The following people were in the queue but didn't have chance to ask questions:
-
-
Li-Hsiang Sun
-
Yunbo Li
-
Kiseon Ryu
-
Jay Yang
-
Rojan Chitrakar
-
Shawn Kim
-
Chunyu Hu
-
Guogang Huang
-
Alfred Asterjadhi
-
Vishnu Ratnam
- Q: Is Beacon-A frame transmitted after group addressed frames or before?
- A: Beacon-A frame is transmitted SIFS after a Beacon frame
- Q: Doesn't AID Bitmap element outside of the Multi-link Traffic Indication element defeat the purpose of using Beacon-A frame for future use to solve the Beacon
bloating issue?
- A: AID Bitmap element is replacement of the TIM element in the current text and the TIM element is outside of the Multi-link Traffic Information element so
there is no difference.
- Q: Can we have both methods? In the Beacon and the Beacon-A frame?
- A: It would be better to have one method instead of having two different methods doing the same function.
- Q: does this new way occupy more air time?
- A: it may if the overhead of AID bitmap element is larger than the overhead of unnecessary Per-link bitmap information of non-AP MLDs or STAs indicated in the
TIM element. But, this proposal solves the beacon bloating problem and legacy STAs are not affected due to Multi-link Traffic Indication element.
- Q: How a STA tell whether there is pending multicast frame other than this frame?
- A: I think it can just follow the existing rule (DTIM Count =0 and Traffic Indicator=1)
- Q: Would this frame makes AP to set the multicast bit in TIM to 1?
- A: I don't think it needs to since the Beacon-A Present Flag subfield in the Cap. Info field=1 will indicate presence of the Beacon-A frame.
Regards,
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
|