| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi, all:Please review the updated revision:Highlight -- leaving the items that need more discussions to later time:1) updated Table 9-299a text.2) removed the p2p bit definitionThanks.ChunyuOn Thu, May 6, 2021 at 1:53 PM Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:Hi Dibakar,I am not sure whether EDCA is relevant for rTWT. I think individual TWT may be more suitable to operate with EDCA.- Can you give an example when you would operate rTWT with EDCA?If a STA wants to use EDCA in rTWT, then are you saying that other devices and OBSS can transmit EDCA on all ACs, but the STA having the rTWT is allowed to transmit traffic on high TIDs only?- What would be the benefit of using rTWT with EDCA?Cheers,JarkkoOn May 6, 2021, at 13:37, Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:Hi Jarkko,If AP sets up a r-TWT SP for a STA with low latency traffic and the STA uses it to txmit mostly non-low latency traffic using EDCA, that would affect AP’s ability to manage the r-TWT SP and balance QoS requirements for other STAs.Regards,DibakarFrom: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 6, 2021 10:20 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi Chunyu, all,Thank you for your discussion on rTWT traffic in the 802.11be call today.I think there were many comments on this text:<image001.png>I am proposing the following text to solve the comments:<image002.png>Main points on new text:- These limitations should be applied only for rTWT traffic. Other traffic should not be limited buy the rTWT traffic limitations.- The QoS violations and traffic scheduling is totally AP’s business for rTWT traffic and other traffic. I believe APs try to schedule only high priority traffic during rTWT SPs, but the scheduling is just very hard to implement in practice.- Clarification for management and control frames delivery.We can continue to improve the text in the coming letter ballots.Cheers,JarkkoHi Jarkko,I have different opinion. However I agree with Patrice’s view in another mail.The rTWT SP should be only used for RTA traffic to keep fairness for every STA, which also make sure that RTA traffic can be guaranteed to be transmitted with priority.The question raised by Patrice, how to avoid abuses of the rTWT SP, I guess this can be made by test cases.BR,XiangxinUnisoc Technologies Co., Ltd.+86 21 20360600 3324From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 6, 2021 11:39 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi,my name was mentioned, so let me clarify.Yes, Chunyu has done good work on rTWT proposal. The current wording is better, but the allowed traffic in rTWT could be written more clearly.The submission is currently missing this principle:1. High TID traffic should be transmitted first in rTWT SP.2. If rTWT SP has time remaining after all high TID traffic is transmitted, then STA and AP could send lower priority traffic in the remainder of the rTWT SP.I would be very happy 😊 if these sentences could be added.I agree that rTWT rules need not be complete in 1.0. We can continue to improve them.Cheers,JarkkoOn May 5, 2021, at 19:32, Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> wrote:Hi Chunyu,I understand you intention. I think it is fine to narrow down the discussion of technical details and focus on what can be done before D1.0 timeline.Since there are some explicit scenarios that have been proposed(Delayed response, Broadcast, data rate fluctuation), you should at least leave some room for next step improvement.RegardsBoyce发件人: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
发送时间: 2021年5月2日 6:35
收件人: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi, Boyce:Thanks for the comments and on/offline discussions.My understanding of the scenario you described is that it seems to be an extended or enhanced usage of the restricted TWT, and is not precluded by the basic setup procedure described in the proposed text.Extending the setup procedure in a broadcast fashion needs more discussion probably. In spirit of converging on the current draft text scope within the D1.0 timeline and making process, I hope to have your agreement and support that we discuss further enhancement at a later time in form of CIDs or technical contributions.Thanks.ChunyuOn Thu, Apr 29, 2021 at 5:04 AM Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> wrote:Hi Dibakar and all,My thinking is that a STA is allowed to negotiate membership 1:1, but sometimes the signaling overhead is a problem(at least two negotiation signaling MMPDUs for each traffic/STA), especially the network is congested. Since bTWT can announce available TWTs in broadcast manner, we can further allow an AP to announce allocation results to multiple traffics/STAs as well(i.e. unicast rTWT requests by non-AP, broadcast rTWT response by AP). It’s useful in a scenario as follows-latency-sensitive traffics arrive when network quality is good (i.e. no need to allocate rTWTs resources)-STAs send QoS requirements(e.g. TWT request without asking for response, TSPEC can be piggybacked) to the AP. By that, The AP can know how many STAs have latency-sensitive traffic and their QoS requirement.-when network quality is getting worse-The AP can allocate rTWTs for multiple STAs with one TWT IE (no need to wait for rTWT request).Of course, one basic assumption is that, the AP should not allocate rTWT resources if network quality is good enough. The reason is1, The channel access time is fragmented. Channel usage is less efficient.2, Latency-sensitive traffic can be sent outside rTWT period, and most of rTWTs will be left unused.RegardsBoyce发件人: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
发送时间: 2021年4月28日 21:23
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi Boyce,Why do you say “signaling overhead of negotiating rTWTs can be reduced by the broadcast feature." ?A STA still negotiates membership in the Broadcast TWT 1:1, right ?Regards,DibakarFrom: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx>
Sent: Wednesday, April 28, 2021 2:32 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi Chunyu,Thanks for the response and updated document.I see your point, unicast. But one important reason why we choose bTWT as a baseline is that the signaling overhead of negotiating rTWTs can be reduced by the broadcast feature. I think we should make full use of that. So I suggest to add AID subfields in Broadcast TWT Parameter Set field, so that an AP can allocate resources for multiple STAs.I also add some comments in your updated doc, please find it in attached.RegardsBoyce发件人: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
发送时间: 2021年4月27日 23:31
收件人: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi, Boyce:Re. your second question, the rTWT is not limited to SU. Each STA can set up an agreement on a schedule with AP. This doesn't prevent AP or STA to use the same schedule for multiple agreements {e.g. AP with STA-A, AP with STA-B}. With the MU tx/rx capabilities, sharing a SP can certainly boost the spectrum/network efficiency and is supported by this signaling.What the draft text describes is that the rTWT Parameter Set field with the Restricted TWT Traffic Info field included is meant for the STA (either non-AP or AP STA) to share their traffic info during the agreement establishment and hence it's a frame exchange between themselves ... hence unicast. Hope that's clear.On your comment of TSPEC or its variant/lite version understand, yes, I think it'll be good to use it during or before the rTWT setup to provide traffic characteristics and qos requirements. To-be-done subclause 35.7.2.2 should cover it.Thanks.ChunyuOn Tue, Apr 27, 2021 at 5:42 AM Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> wrote:Hi Frank,The negotiation procedure is already supported in legacy TWT signaling. I think it’s fine to reuse it. Since TSPEC or TSPEC lite IE proposed in 11be is not for ADDTS/DELTS, those IEs can be piggybacked in TWT Request frames. What do you think about that?RegardsBoyce发件人: Frank Hsu (徐建芳) [mailto:frank.hsu@xxxxxxxxxxxx]
发送时间: 2021年4月27日 14:55
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi, Chunyu,Regarding your response quoted as below, your intention is to decouple the TIDs allowed to transmit during the rTWT SP from the QoS signaling such as TSPEC? With the QoS signaling, AP can know the latency requirements of specific TIDs so that resource, such as rTWT SP, can be arranged accordingly. If we need other TID assignment protocols to negotiate which TIDs can be used during the rTWT SP, in addition to extra overhead and complexity, QoS signaling seems unnecessary. I don’t think it is a right direction.BRs,FrankQuote:One can choose a TID or TIDs not overlapping with these existing typical TID values, and tell AP these "unique" TID(s) that identify latency sensitive traffic. Exact policy and practice is not in 802.11 scope but we provide sufficient tools to do what's needed in order to work in 802.11 MAC context.P.S. there is no upper or lower TIDs per se (in preview some wording in Jarrko's comments) in rTWT context IMO. Either the selected TID(s) are marked as latency sensitive or they are not.From: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Sent: Tuesday, April 27, 2021 12:40 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi, Boyce:It's not clear how fairness issue is related to TID. The way I see how this can work out from MAC protocol support as well as network policy from deployment view is as follows:1) STA or AP based on whatever knowledge it can obtain or instrumented by its upper layer (out of scope of 802.11 L1-2), decide for best of their own interest, the parameters in negotiating a rTWT agreement to be established. The DL/UL TIDs selection is based on their own need of traffic management.E.g. the STA is a laptop device running a video call + browser + email + file transfer. This laptop (based on user configuration and OS support) would like to use rTWT to support the video call while other traffic go through regular EDCA/MU-EDCA (non-rTWT agreement) service. This is, of course, with the well-known constraint or assumption that, if the network has unlimited bandwidth supporting all associated STAs and traffic stream without the need to differentiated QoS treatment the laptop would have no need to differentiate the treatment for its own traffic. Now the laptop knows that if it has to prioritize its own traffic, it needs a way to tell AP what traffic streams it wants to be treated differently. We are proposing to use TID inherently to how 802.11 MAC functions.For the "fairness" argument, I think you already agreed that differentiated QoS is "unfair" but we need to define "fairness" properly (weighted fairness can be also called fair or not fair depending on one's perspective). But this debate, at this point, defeats all the purpose of defining a mechanism to support realtime application that has stringent latency requirement.For the "abuse" point, it's more a network deployment/configuration problem and what we need to do in 802.11 is to provide sufficient tools to allow the network to configure accordingly.E.g. the AP can upbound the network resource, and in the rTWT context, it's the time, allocated to each STA during the setup procedure.Take home environment as one scenario, the homeowner can set, say, 60% time as the total amount of time as upper bound to its home devices for rTWT, and ensure remaining traffic has sufficient bandwidth even one family member is taking a very bandwidth-consuming 3D video call.Take the enterprise environment as another scenario, the IT can configure the network such that each STA can request only up to a certain amount of time and also constraint the total amount of time for rTWT SPs. IT can even get pre-known knowledge, e.g. laptop's MAC address/identification, to combine certain policies (out of 802.11 scope).As one can see, there are various ways to manage the "abuse" problem, and the rTWT and even baseline TWT already supports a negotiation procedure.2) Choosing rTWT to operate at TID level works with overall how 802.11 MAC works in many aspects: the blockack agreement is established at TID level (head of fifo problem is a key element here and I cannot agree it's not "a big deal" as it is a big deal esp. one wants to benefit from aggregation), TSPEC describes traffic at TID level, packet classification as defined in SCS procedure allows packets filtered/mapped to TID level. I don't see why not TID. What would be the alternative.The overall flow it can work IMHO is that, through the QoS management that 802.11 supports (e.g. packet classification, SCS, and/or default DSCP to UP mapping), latency sensitive traffic gets mapped to selected TID(s). On a general computing device like a laptop, one can expect a lot of traffic like the browser etc. are already mapped to certain TID(s). One can choose a TID or TIDs not overlapping with these existing typical TID values, and tell AP these "unique" TID(s) that identify latency sensitive traffic. Exact policy and practice is not in 802.11 scope but we provide sufficient tools to do what's needed in order to work in 802.11 MAC context.P.S. there is no upper or lower TIDs per se (in preview some wording in Jarrko's comments) in rTWT context IMO. Either the selected TID(s) are marked as latency sensitive or they are not.Thanks.ChunyuOn Mon, Apr 26, 2021 at 7:16 PM Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> wrote:Hi Chunyu,Thanks for the response.Some problems come into my mind if TID level is used.1, [fairness and abuse issue] If a STA maps latency-sensitive and non-latency-sensitive traffic to the same TID, the STA is allowed to use rTWTs to transmit non-latency-sensitive traffics as well, due to the fifo block issue you mentioned (although I believe this is not a problem at all, most of designs of TID queues are software-based.). This is not fair to latency-sensitive traffics in other STAs, especially when the data volume of the non-latency-sensitive traffic is huge.For example, a “smart” STA can map buffered video to the same TID with latency-sensitive traffic. So the STA’s buffered video traffic would have higher priority than other STA’s buffered video traffic. The QoS of its own latency-sensitive traffic is not affected as long as the STA is able to handle the so-called “fifo-blocking” problem which is very simple. And latency-sensitive traffics from other STAs have to compete with the non-latency-sensitive traffic.2, [resource allocation issue] The EHT AP has to allocate a lot of resources for the STA, if the data volume of latency-sensitive traffic is small and the data volume of non-latency-sensitive traffic mapping to the same TID is large.So I don’t think we should use TID level just because of head-of-fifo blocking problem(which is not a big deal for most of devices nowadays).RegardsBoyce发件人: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
发送时间: 2021年4月27日 6:13
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseBoyce, Frank,Thanks for sharing your comments. Please see the attached document with some responses.There have been some questions/comments on the traffic requirement etc. and questions on TIDs' role here.We agree that STA may want to share the traffic characteristics and requirements with AP or even wants to change default packet classification (mapping) to TID. Those can be done using existing or extended tool(s) (TSPEC e.g.). I believe Duncan etc. have a contribution on TSPEC variant/lite, and Dibakar etc. have a contribution on SCS change.In this set up procedure, we focus on the general rTWT set up procedure, and that it operates at TID level inline with that the blockack agreement is established at TID level.Please note that there is a subclause 35.7.2.2 traffic classification/requirements are discussed.Thanks.ChunyuOn Mon, Apr 26, 2021 at 12:02 PM Chunyu Hu <chunyuhu07@xxxxxxxxx> wrote:Hi, Jarkko:Since restricted TWT is intended to service latency sensitive traffic, we need a mechanism to provide the identification for such traffic streams. TID is the right level rTWT operates at to avoid problem such as head-of-fifo blocking.So in both DL and UL, the traffic transmitted during rTWT SPs is constrained to the TID(s) that AP/STA agreed on during the rTWT setup.Thanks.ChunyuOn Mon, Apr 26, 2021 at 11:12 AM Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:Hi Chunyu,the R-TWT proposal has DL TID and UL TID bitmaps.I am wondering how these are used?- In DL why would AP limit the TIDs it is allowed to transmits to the STA?- In UL can STA transmit from other TIDs than signaled here?Cheers,Jarkko<image001.png>
Hi, Chunyu,Thanks for the updated contribution. I add my comments after Boyce’s doc.BRs,FrankFrom: Yangbo (Boyce, 2012 NT Lab) [mailto:yangbo59@xxxxxxxxxx]
Sent: Monday, April 26, 2021 11:45 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi Chunyu,Thank for the updated contribution. I have some further comments, please find them in the attached.RegardsBoyce发件人: 顾祥新 (Xiangxin Gu) [mailto:Xiangxin.Gu@xxxxxxxxxx]
发送时间: 2021年4月25日 17:28
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi Chunyu,Thank you for the perfect contribution!I added my comments in the attached file.BR,XiangxinUnisoc Technologies Co., Ltd.+86 21 20360600 3324From: Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Sent: Saturday, April 24, 2021 2:42 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi Chunyu,Thank you so much for this contribution. You have drafted an excellent spec text.In addition to Stephane’s and Rojan’s comments, please find the attached document for my comments on your draft.Have a wonderful weekend!BestRubayetFrom: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Friday, April 23, 2021 7:50 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseThanks all for your feedback. Please see the updated rev1: 11-21/462r1 on server:Stephane, Rojan, please see attached document for responses to your comments inline.Thanks!ChunyuOn Wed, Apr 21, 2021 at 2:04 AM BARON Stephane <Stephane.BARON@xxxxxxxxxxxx> wrote:Hi Chunyu,Thank you for initiating the review on this document.In addition to Rojan’s comments, please in the attached document my comments on this subject.Best regards.Stéphane.From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: mercredi 21 avril 2021 05:53
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi Chunyu,Thanks for preparing the CR. Please see attached for my comments.Regards,RojanFrom: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Wednesday, April 21, 2021 10:48 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclauseHi, all:Will you review and provide your feedback to this draft text that resolves some TBD/CID?Appreciate your input.Thanks.ChunyuTo 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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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<11-21-0462-01-00be-pdt-mac-restricted-twt-tbds-crs-part1-Boyce-Frank.docx>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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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=1To 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