Re: [STDS-802-11-TGBE] CR doc 1381r1

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

Hi Minyoung and all,

In addition to the comment mentioned by Minyoung at the start of this discussion, I have another as follows:

The AID Bitmap element introduced is not reasonable. First, in many cases the element itself costs more bits than the saved bits from ML traffic indication element. Please have in mind that it is in a periodic broadcast frame. Second, it brings much more complexity in parsing the information.

I suggest to consider to piggyback a new AID on TID-To-Link Mapping element to make it easier. An non-AP MLD is updated with a new AID along with updating TID-To-Link Mapping from default mapping to non-default mapping back and forth. Through this the AP MLD can make the ML traffic indication element in small size. Piggybacking a new AID on TID-To-Link Mapping element is very small resource consuming. Someone may think that the solution brings a burden to the AP MLD. Managing AID is a piece of cake for the AP MLD, comparing to much more complex tasks such as MU scheduling.

Thanks!

BR,

Xiangxin Gu

Communication Standards Devision

From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Friday, September 16, 2022 2:35 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

Hi Minyoung,

I beg to disagree with your response to my comment that: “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.” Firstly, your proposal is to have a new beacon-A frame that can have many new elements to be populated in future. If each such element is meant for a subset of AIDs, it should be self-contained, i.e., the indication of the AIDs that it corresponds to should be inside the element as a field. Having a separate AID Bitmap element before each new element of the Beacon-A frame would be a very poor design in my opinion. It is also not correct to draw comparison to TIM element. Firstly, TIM element was already present in the beacons in legacy spec, so it couldn’t be touched. This is the reason why it is kept outside the ML traffic indication element. Such constraints do not apply here, so we should make a clean design choice when creating such a new frame. I think it is a much better design choice to have the bitmap as a field of the ML traffic indication element.

I also agree with Rojan regarding the fact that the size of the AID bitmap can be further reduced significantly by only corresponding to the AIDs set to 1 in the TIM element. I don’t think there is any significant increase in complexity due to this.

Regards,

Vishnu

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Thursday, September 15, 2022 3:00 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

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 Minyoung,

Thanks for initiating the thread. Am supportive of the direction but I believe we have scope for further overhead reduction:

While the text doesn’t clearly explain how the bits in the AID Bitmap are populated, based on the below example, it appears that it is the same as the Tim Bitmap, except that the bits corresponding to non-EHT STAs are set to 0. I don’t see why that has to be the case, the AID bitmap could be much smaller if it only carries the bits that are set to 1 in the TIM bitmap (highlighted in red below). Only STAs whose bits are set to 1 in the TIM Bitmap need to parse the AID bitmap and they can figure out their bit position in the AID bitmap based on their position in the TIM Bitmap. In case of sparse TIM bitmap where many bits are set to 0, this will greatly reduce the size of the AID bitmap. For your consideration.

Regards,

Rojan

From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, September 16, 2022 8:02 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 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.

Xiangxin Gu

- 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.

Ming Gan

- 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.

Yong Liu

- 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,

Minyoung

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