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

Re: [STDS-802-11-TGBE] [EXT] Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

Hi all,

Thanks for the feedback. Since there are differences in opinions, I'll ask an agenda time for a SP to gauge which direction the group wants to go.

Regards,
Minyoung   



On Fri, Sep 30, 2022 at 9:52 AM Jarkko Kneckt <jkneckt@xxxxxxxxx> wrote:
Hi,I wanted to provide my 2c.

In general Beacons contain too many information elements and we should try to shorten Beacon frames sizes. 
I do not see much benefits on Beacon A-frame. It allows AP to add even more elements to the beacon frame(s). 
Beacon A-frame consumes more airtime due to additional SIFS, preamble and MAC header. 

I think, the longest Beacon frame sizes are in the 6 GHz band due to use of Multiple BSSID Beacons. Luckily, we already have features to reduce the Beacon PPDU sizes caused by the non-transmitted BSSs. 

Cheers,
Jarkko   

On Sep 30, 2022, at 9:38 AM, Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:

Hi Yunbo,

Thanks for your comment. 
Sure, we can consider keeping the AID offset subfield if that helps for consensus.

Regards,
Minyoung

On Thu, Sep 29, 2022 at 5:13 PM Liyunbo <liyunbo@xxxxxxxxxx> wrote:

Hi Minyoung and Liwen,

 

For the 2nd point from Liwen, I had a similar request in my previous email. Below is the sentence I copied from previous email. Please consider whether it is a good way to solve this problem.

 

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.

 

Regards,

Yunbo

 

发件人: Minyoung Park <mpark.ieee@xxxxxxxxx>
发送时间: 2022年9月29日 13:37
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [EXT] Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

 

Hi Liwen,

 

Thanks for sharing your thoughts.

 

Based on a  number of members who shared their experiences on this problem, the Beacon frame size above 1.5-2 kbytes causes a problem to legacy STAs so solving this problem in TGbe seems to be a right thing to do.

 

On your 1st point, in the current proposal, there is a bit in the Capability Information element being used to indicate the presence of the Beacon-A frame so this part is covered.

 

On your 2nd point, I think the overhead due to the Beacon-A frame seems to be not that large but we can consider your suggestion and if this could be a good compromise I'm open to this idea.

 

Regards,

Minyoung 

 

On Tue, Sep 27, 2022 at 12:36 PM Liwen Chu <liwen.chu@xxxxxxx> wrote:

If this is the problem, 11be should address it. One possible method could be the basic beacon + extended beacon where the basic Beacon in Beacon frame  indicates that an extended beacon follows the basic beacon. Believe or not, the Beacon frame carries some useless information in some deployment, 802.11 should address it.  

 

I did see some issue with a separate broadcast frame that carries critical information:

1, 802.11 allows a power save STA ignore the broadcast frame. In order for every associated STA to correctly receive the broadcast critical information that follows a Beacon, the Beacon frame should carry an explicit indication to let the STA to receive the broadcast critical information after the Beacon.

2, the additional broadcast frame increases the used medium time compared with carrying the information in the Beacon frame. With the additional broadcast frame, the medium time will be PHY header (at least 20us) + MAC header and FCS (>= 28 octets). If after including the broadcasting critical information, the Beacon frame is less than 1508 octets, the better way is to carry the information in the Beacon frame. If after including the broadcasting critical information, the Beacon frame is more than a threshold, the separate broadcast frame should be used.

 

Best Regards,

Liwen  

 

From: Pooya Monajemi <00000ef0b9e0aff7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 27, 2022 11:50 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

 

Caution: EXT Email

Agreed with Gaurav. It is actually a problem in the field.

 

Regards

Pooya  

 

On Tuesday, September 27, 2022 at 10:26:46 AM PDT, Gaurav Patwardhan <gauravpatwardhan1@xxxxxxxxx> wrote:

 

 

Hi Jay,

We encounter wireless clients from different vendors in the field that expect the Beacon frame to be less than a certain size (thresholds vary from 1508 bytes to ~1800 bytes and some having 2300 bytes). It is not a problem with just a single implementation, but is a pretty widespread issue. If you see the transmitted Beacon size from 802.11ax capable tri-band (2.4/5/6) APs and with MBSSID + RNR enabled for few Virtual-APs per band, we quickly start to run into these thresholds. Now add to this 802.11be with its MLE, per-STA profiles, ML Traffic Indication, etc. and the problem with Beacon size is pretty glaring.

 

We need a solution which not only fixes this problem now, but also is a flexible enough framework to be extended in the future amendments. I understand that this should not have been the problem in the first place, but we are here, and now we have to fix it without affecting legacy clients. To that end, I think we should move forward with the direction proposed by Minyoung.

With Regards,
Gaurav Patwardhan
(Hewlett Packard Enterprise)

 

On Tue, Sep 27, 2022 at 1:22 AM Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> wrote:

Hi Abhi,

 

I consulted some STA vendors, but I don’t hear any vendor mentioned the Beacon parsing issue. I’m not sure whether it’s a general issue in WIFI industry or a corner issue in some specific vendor’s product.

As you mentioned, it’s a legacy STA issue. Suppose such product is already in the market. Could you provide more evidence on this, like product list and test data? Why has such special design, due to no enough buffer for the Beacon frame?

Anyway, hope you can provide more information on this so that I can support you.

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: 2022年9月27日 15:14
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

 

 

Hi Jay,

 

As Minyoung explained, there are legacy STAs from various vendors out in the field that expect the Beacon frame to be within a certain size. These devices fail to parse the Beacon frame if the size of the frame exceeds a certain value (the exact value varies from 1.5k bytes to 2k bytes depending on the vendor and the product). The contents of the frame doesn’t matter, it is the overall size. When a legacy device fails to correctly parse the Beacon frame, it starts misbehaving and that brings down the overall system performance. This is an industry wide issue and is affecting Wi-Fi interop.

 

As we all are aware, the size of ML Traffic IE can become very large and will easily lead to the size of the Beacon frame exceeding the threshold for many legacy devices. Let’s not hold a short term view of the problem by addressing it with a patchwork solution. Moving ML Traffic IE out of the beacon is the right direction for the Wi-Fi industry.

 

Regards,
Abhi

 

 

From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Monday, September 26, 2022 7:16 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Jay,

 

Maybe George, Abhi, and Brian who submitted comments can elaborate more on the issue. 

 

My understanding is that when a beacon frame becomes too big, legacy STAs have a problem processing that large beacon frame.

 

WM usage will be similar (maybe additional SIFS and MAC header).

 

Regards,

Minyoung

 

On Mon, Sep 26, 2022 at 12:27 AM Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> wrote:

Hi Minyoung,

 

Your explanation makes me confused.

The legacy STA can’t decode the MLTI  element and will discard it naturally, why you thought it’s a problem?

And your proposal will cause extra channel resource wasting issue, seems you don’t object with this point.

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: 2022年9月26日 14:25
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] CR doc 1381r1 - Beacon-A frame

 

Hi Jay,

 

Please see the following comment. The beacon bloating issue is a problem that a legacy STA having a problem with dealing with a large beacon frame and not necessarily a beacon overhead issue.

10386

GEORGE CHERIAN

9.4.2.315

0.00

Remove the Multi-Link Traffic Indication element from the beacon, since it can cause beacon bloating, that can affect legacy clients

 

On the second question, the Beacon-A frame is also a group addressed frame.

 

Regards,

Minyoung

 

On Sun, Sep 25, 2022 at 10:52 PM Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> wrote:

Hi Minyoung,

 

I have a general question on your proposal. When we talk the Beacon bloating issue, it equals to the big size of Beacon frame cost too much channel resource. I wonder how to save the channel resource based on your proposal that splits one Beacon to two Beacons?

Let’s assume TXOP (beacon) = beacon/ data rate; your proposal looks like: TXOP(beacon-1)/data rate + SIFS + TXOP(A-beacon)/data rate.  Am I right?

 

Second, the group addressed BU shall be sent after DTIM beacon immediately according to the baseline rule, and your proposal makes such rule changed, how to compatible with legacy STA? e.g. Legacy STAs may see the AID0 is set in the partial Bit map in the DTIM beacon, and plan to receive the group addressed BU. But they see a unknown A-Beacon follows the DTIM beacon, the legacy STA will be confused.

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: 2022年9月24日 2:57
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 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.

 

Thanks,

Minyoung

 

  

 

On Wed, Sep 21, 2022 at 9:58 PM Liyunbo <liyunbo@xxxxxxxxxx> wrote:

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.

  • 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

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

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

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

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