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

Re: [STDS-802-11-TGBE] [PHY] SU SIG contents, 11-20/285



Thanks Jinsoo.

 

From: Jinsoo Choi [mailto:js.choi@xxxxxxx]
Sent: Thursday, March 26, 2020 7:37 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] [PHY] SU SIG contents, 11-20/285

 

Hi Wookbong,

 

Thanks for your answer. I think your opinion is very aligned with what I’m thinking from better resource utilization aspect and this is the reason why I asked below question since your text looked me as forcing the indication of its own 80MHz segment at all time (different interpretation with ‘at least’), but if your intention still allows flexible allocation then it’s fine for me.

 

Best regards,

Jinsoo

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 27, 2020 12:11 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] SU SIG contents, 11-20/285

 

Hi Jinsoo,

 

Thanks for question.

First question.

Would it mean excluding the case that for 160MHz capable STA, U-SIG in a certain 80MHz segment indicates the information of other 80MHz segment that isn’t overlapped with the 80MHz segment that SIG decoding happens for example, while larger RU like 2x996 can be indicated since it encompass its own 80MHz segment?  

Answer is no.

First of all, SP says “at least”, so BW/punc info in U-SIG can indicate puncturing pattern in other 80MHz segment, e.g. all bandwidth. But it is for further discussion.

Second, resource allocation information (at least for OFDMA) is carried in EHT-SIG. The SP only talks about U-SIG, especially puncturing information.

 

Even though this is different topic, I would like to express my opinion on your question. Maybe your question is more related to Jianhan’s contribution/SP.

In case of 160MHz capable STA, I believe 11be shall allow indication of resource in other than primary 80MHz channel.

If BSS BW is 160MHz, then the 160MHz capable STA does not need to camp on a certain 80MHz (even if 11be supports 80MHz SST type of operation).

In this case, allowing resource allocation in other than primary 80MHz will provide more flexibility to AP.

Also, 11ax SST is with TWT. If STAs didn’t setup TWT, then there will be resource utilization issue if we are not allowing this.

 

Hope this answers your question.

 

For your question on multi-RU, I will response in other e-mail thread. J

 

Best regards,

Wook Bong Lee

 

 

From: Jinsoo Choi [mailto:js.choi@xxxxxxx]
Sent: Wednesday, March 25, 2020 10:46 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] [PHY] SU SIG contents, 11-20/285

 

Hi Wookbong,

 

Thank you so much for your effort on harmonization. Let me ask a question for clarification on below SP regarding 80MHz segment;

Would it mean excluding the case that for 160MHz capable STA, U-SIG in a certain 80MHz segment indicates the information of other 80MHz segment that isn’t overlapped with the 80MHz segment that SIG decoding happens for example, while larger RU like 2x996 can be indicated since it encompass its own 80MHz segment?  

 

One more question on another SP for RU allocation in MU; (sorry for bringing up different contribution 373 here)

SP: Do you agree to use RU allocation subfield defined in 11ax to indicate RU to be assigned to each STA for MU PDDU when only one RU per a STA is assigned and the number of multiplexed users in each RU is up to 8?  

In 11ax, you know there is a case that the multiplexed users in a RU is not supported up to 8, when only two 106-RUs are assigned (with middle 26-RU hole) that the users in each RU are limited as 4. Would you intend to change this case up to 8 which requires the modification of current RU signaling table and not aligned with your current text I guess?

 

Best regards,

Jinsoo

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Tuesday, March 24, 2020 8:37 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [PHY] SU SIG contents, 11-20/285

 

Hi Dongguk,

 

I saw your e-mail to Alfred regarding 11-20-0524-00-00be-signaling-of-preamble-puncturing-in-su-transmission.(Dongguk Lim, LG Electronics), EHT-SIG.

 

Do you want me to defer following SP after your presentation?

       Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted?

       Note1: Each STA needs to decode U-SIG in only one 80MHz segment

       Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz

       Whether BW/Puncturing info can be different for different 80MHz is TBD

       Whether BW and puncturing info bits in U-SIG are carried as a combined or a separate field is TBD

I think all of your options can support above high level concept.

 

Please let me know your preference.

 

Best regards,
Wook Bong Lee

 

From: Oded Redlich (TRC) [mailto:oded.redlich@xxxxxxxxxx]
Sent: Friday, March 20, 2020 12:27 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] : [PHY] SU SIG contents, 11-20/285

 

Thanks Wookbong,

 

My contribution is #483

 

BR,

 

Oded

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 20, 2020 7:12 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Hi Oded,

 

No problem.

I can run this SP after your contribution. Please let me know your contribution number.

 

Best regards,

Wook Bong Lee

 

From: Oded Redlich (TRC) [mailto:oded.redlich@xxxxxxxxxx]
Sent: Friday, March 20, 2020 9:49 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] : [PHY] SU SIG contents, 11-20/285

 

Hi Wookbong,

 

By pointing out the 1x1x structure I was actually referring to the case where one of the content channel is missing  (assuming 2 CC will be supported of course) . In this case limiting the reception of pre-EHT to 80MHz will degrade the channel utilization for devices that support BW>80MHz.

I do have a contribution on that so I would appreciate if you defer the relevant SPs as you suggested.

 

Thanks,

 

Oded

 

 

From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx]
Sent: Friday, March 20, 2020 6:33 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Wookbong.

I do not have any plan for a counter proposal yet. It is your SP and if you want to run, go ahead.

I already requested further discusdion on this topic, and if you insist on running your SP. I cannot support you at this moment.

Regards

--------------------------------------------------
Junghoon Suh
Mobile: +1-6137005790
Email: Junghoon.Suh@xxxxxxxxxx

From:Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>

To:STDS-802-11-TGBE <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>

Date:2020-03-20 12:25:15

Subject:Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Hi Oded,

 

Thanks for your response/comment.

First of all, currently [1 x 1 x] is not agreed in 11be. During last conference call, Eunsung run SP to have [1 x 1 x] (SP#4), but it failed.

 

I would like to repeat my response to Junghoon in here.

If your intention is to have different requirement than 80MHz preamble processing, I am fine with waiting for your presentation before run this SP. I deferred these SPs once, but I can further wait if it depends on other presentation/contribution.

Please let us know your plan for this.

 

Best regards,

Wook Bong Lee

 

 

From: Oded Redlich (TRC) [mailto:oded.redlich@xxxxxxxxxx]
Sent: Friday, March 20, 2020 9:13 AM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] : [PHY] SU SIG contents, 11-20/285

 

Hi, Wookbong

 

I would also like to thank you for trying to harmonize the SPs via the e-mail reflector.

 

Regarding the 1st bullet, I think that if we insist on limiting any device to receiving the pre-EHT field on 80MHz we preserve a con of 802.11ax. There is a special case where the puncturing structure is 1x1x, where the BW is reduced to 20MHz even if there are available channels in other S80s. So although it is a non-issue for the 80MHz devices, what about devices that support higher BWs? These devices should not “suffer” from such limitation. Therefore I think we should not restrict the ability to receive pre-EHT on BW>80MHz.

I know that there are concerns about power consumption but there should not be a problem with that due to the use of power-save mechanism (PS-Poll, TWT)

Anyway, I think that further discussion about this issue is required.

 

BR,

 

Oded

 

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 20, 2020 6:11 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Hi Junghoon,

 

First of all, I don’t know how to make progress if we don’t respect passed SP at this moment. As far as I know, we don’t have any means to run any motion. 

 

If your intention is to have different requirement than 80MHz preamble processing, I am fine with waiting for your presentation before run this SP. I deferred these SPs once, but I can further wait if it depends on other presentation/contribution.

Please let us know your plan for this.

 

Finally, as I recommended to Dongguk, since we are using e-mail reflector, we can always get feedback from our MAC colleagues.

If there is a concern on particular SP text from your MAC colleague, please feel free to inform us.

I am more than happy to address the issue and move forward.

 

Thank you.

Best regards,

Wook Bong Lee

 

From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx]
Sent: Friday, March 20, 2020 8:30 AM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] : [PHY] SU SIG contents, 11-20/285

 

For, the 1st bullet, we only saw the presentation 1st time in the last CC, and there were lots of abstains. We do not want to run any SP based on any other SP (without being fixed into the SFD).

For how to decode, I do not see why it should be limited to 80 MHz clearly. Why not 40 MHz then. All I am saying is more time needed. We only saw this proposal once.

It is not just PHY issue, as you commented in the last CC. We need to think further for any other issue which may take place by this proposal.

 

The 2nd and 3rd bullet are dependent on the 1st bullet.

 

Regards

Junghoon

 

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 20, 2020 11:21 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Hi Junghoo,

 

Thanks for your response.

 

First of all, in my opinion, first two notes are purely PHY issue.

Note 1 is saying nothing but non-AP STA to decode only 80MHz segment. If there is no such requirement, then non-AP STA needs to decode all BW or more than one 80MHz segment? If I recall correctly, Sameer already ran text in note 1, and result was more than 75% yes.

Note 2 is same 11ax. I don’t see other way to do this. Please let me know if you have better idea.

 

For the third bullet, as I respond to Ross, we can make it TBD for now.

       Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted?

       Note1: Each STA needs to decode U-SIG in only one 80MHz segment

       Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz

       Whether BW/Puncturing info can be different for different 80MHz is TBD

       Whether BW and puncturing info bits in U-SIG are carried as a combined or a separate field is TBD

Hope you are fine with modified SP above.

 

Regarding second SP, yes, please let us know if you have a comment. Your support will be great. J

 

Best regards,

Wook Bong Lee

 

 

From: Junghoon Suh [mailto:Junghoon.Suh@xxxxxxxxxx]
Sent: Friday, March 20, 2020 7:56 AM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] : [PHY] SU SIG contents, 11-20/285

 

Hi, Wookbong

I echo with Ross.

 

For SP1, especially for sub-bullet 1~3, I think we need more discussion in the Joint session, even though we ran a SP on this in the last CC, we have not run any motion about the 80MHz segment based processing,yet, and it is not in the SFD. We do not want to run any SP based on something we have not agreed in SFD.

 

For SP2, I am also feeling the need to have the STA-ID info in the PHY  header for SU-PPDU in the different perspective from your explanation, but I need more investigation.

 

Regards

Junghoon

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: March 20, 2020 12:01 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Thanks Dongguk.

Best regards,

Wook Bong Lee

 

From: Dongguk Lim [mailto:dongguk.lim@xxxxxxx]
Sent: Thursday, March 19, 2020 8:23 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] : [PHY] SU SIG contents, 11-20/285

 

Hi Wookbong,

 

Thanks for the reply.

Okay. I will also discuss these issues with our Mac people.

 

Best regards,

Dongguk

 

From: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
Sent: Friday, March 20, 2020 11:46 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Hi Dongguk,

 

Thanks for response.

 

Since we are anyway using e-mail reflector now, can you ask this to your MAC colleagues?

If they have some concern, we can try to resolve that in here first.

If we can’t reach a consensus, then certainly we can ask for slot to discuss it in joint session.

 

Best regards,

Wook Bong Lee

 

From: Dongguk Lim [mailto:dongguk.lim@xxxxxxx]
Sent: Thursday, March 19, 2020 7:42 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Cc: hg.cho@xxxxxxx; js.choi@xxxxxxx; esung.park@xxxxxxx
Subject: RE: [STDS-802-11-TGBE] : [PHY] SU SIG contents, 11-20/285

 

Hi Wookbong,

 

Thanks for suggesting of harmonized SPs for the efficient processing.

 

As you mentioned in the PHY CC, the operation in 80MHz which is not primary channel and the using of STA-ID of SU-PPDU in Multi link transmission are related with Mac operation.

And, some issues related to above topic still being discussed or not discussed yet.  

Thus, I think that we need to discuss this topic with Mac guys in the joint session to avoid unnecessary arguments.

 

Best regards,

Dongguk

 

From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
Sent: Friday, March 20, 2020 10:30 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [PHY] SU SIG contents, 11-20/285

 

Hi Wookbong,

 

Thanks for the replies and considering my suggestion. And your example is a good one.

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
发送时间: 2020320 9:03
收件人: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [PHY] SU SIG contents, 11-20/285

 

Hi Ross,

 

Thanks for question.

For SP1, do you want to put something like “whether BW/Puncturing info can be different for different 80MHz is TBD?”

We can run SP after Jianhan’s contribution.

 

For second SP, whether we will have SU PPDU or not is TBD as Sameer mentioned. Personally I prefer having SU PPDU, but (partial) STA-ID in the EHT-SIG.

(Please refer 11-20/285, especially slide 8)

Rational for including STA-ID in PPDU is for non-STR MLD STA. Please find more explanation in below. I copied from contribution.

 

cid:image001.jpg@01D5FEB1.C9FDD620

       For certain conditions, non-STR STA resumes countdown on link B during busy state on link A

       Similar to 802.11ax SRP-based spatial reuse backoff procedure

       Inter-BSS PPDU (e.g. BSS Color)

o   Backoff countdown can be resumed as frame not for non-STR STA

       Intra-BSS Uplink PPDU

o   Backoff countdown can be resumed, similar to above

o   UL/DL bit in HE-SIG-A for HE SU PPDU/ER SU PPDU

o   UL MU identified by HE TB PPDU

       Intra-BSS Downlink PPDU

o   Backoff countdown can be resumed if PPDU identified to be not destined to itself

o   STA ID in HE-SIG-B for HE MU PPDU or unable to decode HE-SIG-B of HE MU PPDU

o   No STA ID info in PHY preamble for SU PPDU and MAC header decoding can take long

o   Proposal: STA ID info in EHT PHY preamble for SU PPDU

 

Please let me know if this is still not clear.

 

Thank you.

Best regards,

Wook Bong Lee

 

From: Yujian (Ross Yu) [mailto:ross.yujian@xxxxxxxxxx]
Sent: Thursday, March 19, 2020 5:47 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: : [PHY] SU SIG contents, 11-20/285

 

Hi Wookbong,

 

Thanks for using the email reflectorJ and trying to harmonize the SPs to make the CC more efficient.

 

For SP1, regarding the 3rd subbullet, BW/Puncturing info can be different for different 80MHz. I think this mechanism still needs to be fully discussed from both MAC/PHY point of view before we run the SP. Meantime, Jianhan’s contribution is still in the queue.

 

For SP2, could you or people in the group share more info about the benefits of carrying STA ID for SU transmission? I don’t find a clear answer myself. The question actually also applies to using HE MU PPDU format for SU transmission back in 11ax.

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
发送时间: 2020320 8:36
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [PHY] SU SIG contents, 11-20/285

 

Hi Sameer,

 

Thanks for quick response and suggestions.

 

I am fine with all of your suggestion.

I will update SPs accordingly.

Will wait for more discussion before upload revision 3.

 

SP#1

       Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted?

       Note1: Each STA needs to decode U-SIG in only one 80MHz segment

       Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz

       BW/Puncturing info can be different for different 80MHz

       Whether BW and puncturing info bits in U-SIG are carried as a combined or a separate field is TBD

SP#2

       Do you agree to have STA-ID related information in an EHT PPDU sent to a single user?

 

Best regards,

Wook Bong Lee

 

From: Sameer Vermani [mailto:svverman@xxxxxxxxxxxxxxxx]
Sent: Thursday, March 19, 2020 5:18 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [PHY] SU SIG contents, 11-20/285

 

Thanks Wook Bong for this harmonization attempt.  I overall agree with the ideas in your straw-polls.  I have two minor comments which you might want to consider:

 

  1. To aid clarity, maybe you can change the TBD bullet in SP1 to: “Whether BW and puncturing info bits in U-SIG are carried as a combined or a separate field is TBD”
  2. In SP2, since we have not decided if there will be an SU PPDU (which is separate from MU PPDU), maybe you can word it as follows: “Do you agree to have STA-ID related information in an EHT PPDU sent to a single user?”

 

Regards,

Sameer

 

 

From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Sent: Thursday, March 19, 2020 4:33 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] [PHY] SU SIG contents, 11-20/285

 

CAUTION: This email originated from outside of the organization.

Hi PHY fans,

 

This is an email to discuss straw poll for SU SIG contents in 11-20/285.

During 3/18 conference call, there was a request to discuss straw poll using e-mail reflector.

If you are not interested in this topic, sorry for this e-mail.

 

    • 285r1 SU PPDU SIG Contents Consideration (Wook Bong Lee)

First, Eunsung asked to defer the straw poll since he has some more puncturing pattern to propose, and it may impact the signaling design.

Eunsung’s contribution was discussed 3/18 call, and there was no agreement to add more puncturing pattern.

Second, after I review following two contributions,

    • 380r0 U-SIG Structure and Preamble Processing (Sameer Vermani)
    • 439r0 Efficient EHT Preamble Design (Jianhan Liu)

I agreed with some of ideas in those contributions, i.e. allowing a STA to know exact what is puncturing pattern for the 80MHz.

I believe this is useful not only for a different STA to camp different 80MHz (note this feature itself needs more discussion in MAC Adhoc or in Joint group) but also for a non-associated STA to decode FILS or Unsolicited Probe Response frame in MU PPDU which is supported in 11ax for 6GHz operation.

So, I modified SP accordingly.

 

In addition to that, we want to propose to include STA-ID related information in SU PPDU as well to aid non-STR STA for MLD operation. Please refer 11-20/285 or 11-19/1405r7, “Multi-link Channel Access Discussion” for more discussion.

 

These are proposed SPs in 11-20/285r2. Uploaded revision 2 in the server.

SP#1

       Do you support that U-SIG in each 80MHz shall carry puncturing channel info for at-least the specific 80MHz where it is transmitted?

       Note1: Each STA needs to decode U-SIG in only one 80MHz segment

       Note2: Within each 80MHz segment, U-SIG is duplicated in every non-punctured 20MHz

       BW/Puncturing info can be different for different 80MHz

       TBD: separate BW and puncturing info bits in U-SIG

SP#2

       Do you agree to have STA-ID related information for SU PPDU in EHT-SIG?

 

If you have any question or any suggested modification, please let us know.

 

Best regards,

Wook Bong Lee

 

 

 


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


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