Guogang,
I never really got to back to you, sorry.
- Your comment on Page 3, in this sentence, “However, each affiliated AP provides legacy upper MAC operations to associated legacy non-AP STAs, through an independent MLD upper MAC sublayer.” You commented that the word “MLD” near the end of the sentence could be legacy, perhaps? I guess I’m missing your point. Yes, this is for “legacy” operation (hence the “non-AP STAs” that are associating) but we have a naming challenge. First, we can’t use the word “legacy” in the Standard, because no one will know “legacy to what?” 10 years from now. Second, we have agreement (I think) that this is an “upper MAC sublayer” equivalent to the one in the MLD. But, due to confusion with people that implement a “split MAC” (some in the AP and some in a controller, for example), when we first stared using the term “upper MAC” we got a lot of complaining. So, we added the “MLD” to qualify exactly what sort of “upper MAC” we meant. Hence, we have “MLD upper MAC” as a concept for the AP MLD. So, for the affiliated AP, I have been trying to stick to “affiliated AP’s upper MAC sublayer” or something similar. Is that okay? (I agree, this particular usage on page 3 is confusing by using “MLD” for the affiliated AP – luckily it is only Discussion, so at this point we can ignore it.)
- I see your changes to Figure 4-30c and 4-30d. I think that only adds the MAC-SAPs (and changes the ovals for data frames into arrows to the new MAC-SAPs), right? I agree with what you are showing, and would have no problem adding that. Will you submit a comment on the LB (or should I)? As for the details you mention about MAC address usage, I agree with that also, and I’ll note that while I agree with your reference that these are normatively defined/required on P381, this is also already mentioned in this document and in clause 4, in the 3rd and 4th paragraphs of 4.9.5 (just about 10 paragraphs before your comment). So, I think/hope we’ve said this pretty clearly in this context in clause 4, also.
Thanks again for your help on this! Mark
From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 10:40 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Mark,
I have some comments. Please find attached.
Regards
Guogang Huang
发件人: Duncan Ho [mailto:dho@xxxxxxxxxxxxxxxx]
发送时间: 2022年5月13日 7:46
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Mark,
No problem. How about putting an asterisk inside the PS deferred queuing box, then add a legend to explain the asterisk as part of the diagram?
Thanks,
Duncan
From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, May 12, 2022 3:36 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-21/1111 further discussion
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi, Duncan,
Of course, we just crossed emails. I’ve already posted the updated document (as it was). I am happy to consider this, if you can provide a specific change (not sure how to cram that much information in a note in the box), that we can take as part of the straw poll to proceed.
Mark
From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 4:32 PM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Mark,
I think one quick clarification could be to keep all the boxes the same as you have them but add a note in the “PS deferred queueing box” saying that the queuing also takes into account the TID-to-link mapping.
Thanks,
Duncan
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, May 12, 2022 2:02 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
All,
- If PS Defer Queuing is below T2LM, it would be confused as T2LM is matching with Merging. It would be better to keep same order which aligns with the existing 802.11 spec.
- in MLD case we want to avoid the PS queuing as much as possible
Just picking on the couple of comments above, but to generalize, I am concerned that we are making this decision without consideration for what is truly required to get the logic correct, technically. There are real requirements that will dictate the way these blocks can/must flow. I’m not sure we have identified all those requirements clearly, yet, to make sure any decision we make about how these blocks stack up (and which are upper or lower, or shared/independent (in MLD or affiliated AP) or are per-link (in a lower MAC sublayer) is being made with all the constraints met.
I think this needs more study, in the next ballot round.
Mark
From: Yonggang Fang <00001a2738812321-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 2:54 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Abhi, and all,
Thanks for your comment. If PS Defer Queuing is below T2LM, it would be confused as T2LM is matching with Merging. It would be better to keep same order which aligns with the existing 802.11 spec.
Best Regards
Yonggang
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 11:54 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Mike, Mark, All,
The buffering would occur at the MLD level. Let me try to explain: if all the STAs of the non-AP MLD, that are operating on the link to which a certain TID is mapped to, are in PS mode, then the AP MLD would need to buffer the MPDUs belonging to that TID. The traffic indication on all the links reflect the buffer status at the MLD. Therefore the TIM bit in the beacons on all the links will indicate BUs for that non-AP MLD (this is covered in the current spec).
I propose moving the PS Queuing block below the T2LM block (as shown below). This can address some of the concerns expressed in previous emails. Operation wise, the transmit side would decide to buffer after T2LM block if all the link to which the TID is mapped to are in doze state. If any link wakes-up, the packets belonging to that TID are flushed on that link.
Please let me know your thoughts.
Regards,
Abhi
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, May 12, 2022 10:22 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Thanks Arik,
So Mark,
So based on Arik's comment, I'm wondering whether we should move the PS Deferral Queuing to the lower MAC, but I think it's important to add some text to describe that PS state transitions and link selection is managed in the upper MAC, but queuing is done in the lower MAC (or something like that).
At this point, I suspect the PS discussion will continue into the next round of comment resolution.
Cheers,
Mike
On Thu, May 12, 2022 at 1:04 PM Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Mark,
Thanks for your respond.
Please see my inline further comments.
Regards,
Arik
From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: יום ה 12 מאי 2022 17:55
To: Arik Klein <arik.klein@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-21/1111 further discussion
Arik, Stephen, and all,
I believe the current architecture view (in D1.5) was derived to support the ability to retry frames on any link. That is, an MPDU is prepared for transmission (SN assignment, PN assignment, and encryption) in the upper MAC sublayer, so that the resulting frame can be “moved” between links if a transmission on one link fails and an alternate link is selected for the retry. Further, the upper MLD sublayer is the holder of the PTKSA, which also puts the encryption block into the upper MAC sublayer, and therefore the SN and PN assignment (which are before encryption) are in the upper MAC sublayer.
Any disagreement on this point?
If we are good with that, then the question remaining is about where the PS queuing can happen. Since different links (with the same peer MLD) can change power save state independently, and the MLD is expected to send (individually addressed) MPDUs over any link that is not in PS mode, don’t we have to have the PS queuing happen at the MLD level (and only happens when all links to the given peer MLD are in PS mode)?
[Arik Klein] This is not the only case of PS queuing. Please note that the TID-To-Link mapping function can also impose limitation to send an MPDU on specific link which is not in PS mode, so in this case you also have to buffer that MPDU (For Instance: AP MLD has 2 links. The non-AP STA affiliated with non-AP MLD and operating on link 1 is in PS mode and according to TID-TO-Link mapping TID1-TID6 are mapped only to Link 1. That means that an MPDU corresponding to TID1-TID6 can’t be sent to this non-AP MLD as long as the non-AP STA operating on link 1 is in PS mode and hence these MPDUs shall be buffered).
Anyway – this decision must happen after the TID-To-Link mapping block which simply means that it is done per link, once the Transmitting side has decided that the MPDUs can’t be sent on any other link than the current link.
An aside: traditionally (since at least 2007) we have described PS queuing as happening before (above in the stack) SN and PN assignment and encryption – I believe there is some case where the SN or PN will get out of order if we don’t do that, but I’ve lost track of the details on this discussion (from 15 years ago!). Does anyone remember?
[Arik Klein] When you have a single link – this is correct, but in MLD case we want to avoid the PS queuing as much as possible – by sending the MPDU through any of the link as long as it is possible (one of the main benefits of MLO feature!!). So, there is distinction in functionality between upper MAC layer and lower MAC layer and in this case the consideration should be different.
As to your concern of SN/PN order – please note that this issue already exists in MLD case even if none of the affiliated non-AP STAs is in PS mode and the Transmitter sends subsequent MPDUs on different links - the order of their reception on each link is independent in the order they were transmitted…..I see no big issue in the PS queuing in that sense.
Mark
From: Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 4:41 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Mark,
Thanks for sharing the doc and for this further discussion.
Several comments for further discussion:
- I agree with Duncan argument that “ML BACK Scoreboarding” term in the upper MAC layer is misleading. I would suggest to designate it as “Optional: Block ACK Scoreboarding (merging)”. Are you OK with that?
- The “Merging” functional block in the “MSDU flow Receiving side” is vague/unclear. I would suggest to use “Link Merging” term that better explains what is merged here (as opposed to the TID-To-Link mapping functionality on the “MSDU flow Transmitting side”)
- I echo Stephen’s comment regarding the “PS Defer Queuing” functionality - I think that this should be placed only in the lower MAC layer (i.e. per each link).
Furthermore – I do not see any problem with assigning an SN to the individually addressed MPDU (in the upper MAC layer) and then queuing it in a specific buffer (per the link it is going to be sent) only if both conditions occur: (1)the non-AP STA affiliated with the associated non-AP MLD and operating on that link is in PS (2) and due to TID-To-Link mapping the MPDU can’t be transmitted on any other link. Otherwise – there is no PS queuing for that MPDU….- According to Figure 4-30c, the upper MAC layer of the affiliated AP handles the group addressed MLD traffic. I think this is incorrect, since upper MAC layer of the AP MLD receives all the MLD data frames (from the DS) to include both those that will be sent as individually addressed MPDUs and those that will be sent as group addressed MPDUs. Then, once the upper MAC layer processes the group addressed frames it delivers them to the lower MAC layer of each link (to be authenticated with GTK/IGTK/BIGTK per that link) and then these MPDUs are further processed and passed to the PHY (per link) to be sent following transmission of DTIM Beacon frames.
(Note: this also applicable to MMPDUs sent as group addressed frames)
Consequently, the upper MAC layer of the affiliated AP processes only the individually addressed frames sent to the non-MLD non-AP STAs associated with that affiliated APs (and these frames are delivered from the DS to the affiliated AP directly).
Please revise the Figure 4-30c.- Does the NSTR mobile AP MLD architecture follow the Figure 4-30c or that of Figure 4-30d?
Could you add a note to clarify that point in the corresponding figure?
Thanks for your cooperation.
Regards,
Arik
From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: יום ה 12 מאי 2022 12:36
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Mark,
Thanks for this discussion. Regarding the "PS Defer buffering", what does this have to do with SN/PN assignment? If an MPDU is deferred for PS reasons, this implies that the MPDU is assigned to a link in the upper MAC and is then buffered until the PS state of that link is ok to transmit the MPDU. This seems to break the MLO concept?
Kind regards
Stephen
On Thu, 12 May 2022 at 03:44, Tomo Adachi <tomo.adachi@xxxxxxxxxxxxx> wrote:
Hi Mark,
I echo Duncan and Po-Kai’s comment on the scoreboarding terminology.
Full state is to keep all the statuses within the reception window from an initiator, while the record can be temporal in partial state.
Best regards,
tomo
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, May 12, 2022 7:51 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi, Alfred,
If we can have just a few minutes (5-10) to discuss these topics on the morning call, I can get the document updated with any agreement, for consideration at a future call.
Thanks. Mark
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 4:36 PM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: TGBE <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
[re-sending from gmail account]
Thanks Mark, and all for working on these resolutions.
I scheduled the doc for SP/discussion tomorrow evening (MAC call) however if the preference is to have the discussion on the morning call we can try to find some time on that call.
Let me know.
Regards,
Alfred
On Wed, May 11, 2022 at 3:31 PM Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
All,
As there does not appear to be consensus on how to describe the Block Ack blocks (based on the comments on the call this morning, and now these comments on my proposed update), can I suggest that we have a quick discussion on this on the call tomorrow morning (U.S. time).
Also, I am having a hard time figuring out how to sequence the SN and PN assignment versus PS queueing, for group addressed frames. In particular, we have existing text in D1.5 that says the AP MLD’s upper MAC sublayer will do the SN assignment, and then pass the frame to the affiliated AP(s) to be buffered and then do further processing/transmission. I think that causes issues with SN and PN ordering. Has this been covered in some other power save presentations/agreements (that perhaps I missed)? Does anyone have a clear view of how this is planned to work and/or is there agreement in the group? (I don’t think this is a significant change to my document, but there are details discussing this that need to be aligned to the correct operation). Perhaps this can be discussed quickly tomorrow morning, also?
@Alfred Asterjadhi, I’ll look to your direction on how to proceed most efficiently for the group’s time.
Thanks. Mark
From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 2:28 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi all,
I agree with Duncan that we do not need to create term like ML BA Scoreboarding and we also do not need say lower MAC is always partial state.
Partial and full is just about whether your record is temporary or not, which is an implementation choice.
The following text also seems to be enough, so do we really need to add more?
· The MLD Upper MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Lower MAC sublayer). Optionally, the MLD Upper MAC sublayer delivers the Block Ack record on one link to the MLD Lower MAC sublayer of other links”
· The MLD Lower MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Upper MAC sublayer). Optionally, the MLD Lower MAC sublayer receives from the Block Ack record on the other links from the MLD Upper MAC sublayer”
Best,
Po-Kai
From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Wednesday, May 11, 2022 12:13 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Mark,
Thanks for the updates. I do not think the BA scoreboarding changes are needed because D1.5 section 4.9.5 already describes the following:
· The MLD Upper MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Lower MAC sublayer). Optionally, the MLD Upper MAC sublayer delivers the Block Ack record on one link to the MLD Lower MAC sublayer of other links”
· The MLD Lower MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Upper MAC sublayer). Optionally, the MLD Lower MAC sublayer receives from the Block Ack record on the other links from the MLD Upper MAC sublayer”
The spec also has a NOTE saying “NOTE 2—The Block Ack scoreboarding maintenance collaborated between the MLD Upper MAC sublayer and MLD Lower MAC sublayer is implementation dependent.” So it’s clear how the MLD upper and lower layer collaborate is implementation dependent.
Besides, the new term “ML BA Scoreboarding” could be misleading because a reader may try to find a section in the spec that describes how scoreboarding is done in the MLD while the Scoreboard Context procedures are well defined in REVme sections 10.25.6.3 (Full state) and 10.25.6.3 (Partial state) at the link level (not MLD level).
Also whether to do Full or Partial state is a choice of the receiver (per REVme) so we should not mandate Partial BA Scoreboarding in the lower MAC.
I believe the scoareboarding functionalities are mandatory for the lower MAC due to immediate BA but the BA scoreboarding-related functionalities in the Upper MAC should be optional.
Thanks,
Duncan
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 10:46 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 11-21/1111 further discussion
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
All,
Here is some status update, and request for ongoing discussion on the architecture presentation from this morning (document 11-21/1111):
· I removed the word “physical” from “physical links” in the text
· I corrected the typo “the use of”
· In Figure 4-30c, I am renaming “MLD lower MAC sublayer (MLD and legacy)” to just “MLD lower MAC sublayer”. This removes the “legacy” as correctly pointed on the call. However, this leaves the “MLD lower MAC sublayer” as the term for the shared component which is doing both MLD support and affiliated AP support. I note that this term is already in many locations in the draft, in clauses 4 and 5, so I proposed to keep it in the new figures to remain aligned. If there is concern with this use of the term, that can be a comment (on all the occurrences), on the next LB. Any disagreement?
· I am taking the suggestions in the chat, and proposing to change the “Block Ack Scoreboarding” boxes in the figures, as follows:
o For the upper MAC, in the MLD, it will say “ML BA Scoreboarding”
o For the lower MAC, it will say “Partial BA Scoreboarding”
o For the upper MAC, in the affiliated AP, it seems this is an implementation choice (is that right?), so how about “BA Scoreboarding (optional)”?
o There was a request to add some clarification about these Scoreboarding blocks to the text. I suggest that would go just below Figure 5-2b, and I’ll work on that and remit shortly. Suggestions/contributions would be helpful!
· For PS Defer buffering:
o I think the conclusion/agreement on the call was that this is correct to be in the upper MAC (and above the SN assignment). Any disagreement?
o Clearly, the label in the affiliated AP that says “AP MLD only” is just wrong. However, my latest understanding of how frame generation and routing needs to happen resulted in frames (such as Management frames, and group addressed Data frames) will need to be routed from the MLD upper MAC over to the affiliated upper MAC for SN/PN assignment and encryption, so the buffering for these frames needs to be merged with the buffering for “legacy” data frames, and it all needs to happen high in the affiliated AP stack. If this is agreed, then we need this block (in that location) in the affiliated AP upper MAC. I think that means just removing the “(AP MLD only)” text in all copies of this block, in the affiliated AP and the AP MLD. Agreed?
o There was a request to add some more text to better clarify this PS Defer buffering. I think that goes just below Figure 5-2b, and I’ll work on that and remit shortly.
· Figure 5-2b should be clarified with labels for the AP MLD and affiliated APs. The figure is already too complicated, so I do not want to add the outlines shapes, like Figure 4-30c. I suggest maybe just braces across the top of the figure, saying “Affiliated AP” and “AP MLD”? That is slightly misleading in that it is really only correct for the upper MAC sublayers, but would imply it carries into the lower MAC, also. But, I think it’s the best alternative. Comments or other thoughts?
Thanks. Mark
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
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
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
************* MEDIATEK Confidentiality Notice ********************The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwiseexempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do notdisclose the content of this e-mail to any other person. Thank you!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