Hi Payam,
Thank you for reviewing the doc. Good feedback.
I have revised the doc based on your inputs:
https://mentor.ieee.org/802.11/dcn/21/11-21-0650-09-00be-cc34-resolution-for-cids-related-to-mlo-discovery.docx
Regards,
Abhi
From: Payam Torab <torab@xxxxxxxx>
Sent: Friday, July 9, 2021 7:01 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [CR-MAC] Feedback Requested for CRs related to MLO Discovery [11-21/650]
Hi Abhi – Minor comments/editorials to improve the text attached (supporting the doc regardless). I find this text useful too.
Thanks,
Payam
Hi all,
I also agree explanations in 650 are useful.
Thanks,
Laurent
Hi Abhi, Tomo, Ming and all,
The revised version (rev8) looks good to me. While I do not disagree with Ming’s comment that we should be mindful of spec bloat, I agree with Tomo that MLO Discovery is a fairly complex topic, especially when the RNR element, MLE and Multi-BSSID
element are all present together and 21/650 provides a good overview of the operation and I find it helpful as well. Improving the Spec readability/understandability is a welcome direction in my opinion.
Regards,
Rojan
Hi Ming and Abhi,
I support 21/0650r8 as one of the commenters whose CID was taken care of by it.
J
In the previous draft, it was difficult to figure out the whole picture of the MLO discovery, which would have led issues in conformance tests in the
future.
This document is very useful from such point of view.
According to Annex G, as was discussed in the past thread in ARC SC(? I believe), it is becoming too complex to maintain and is not a good place to try
describing things there anymore.
Best regards,
tomo
Hi Ming,
Thank you for your feedback.
I have revised the doc based on your feedback. Rev8 is posted to mentor:
https://mentor.ieee.org/802.11/dcn/21/11-21-0650-08-00be-cc34-resolution-for-cids-related-to-mlo-discovery.docx
In addition, I have embedded responses to some of your comments in the attached doc.
Regarding moving it to Annex G, I had an offline discussion with members active in REVme and Arch group. Members have started work on either deleting Annex G or replacing it with a ‘light’ version with
references to sections in the core spec. As part of this effort, some of the content from Annex G will move the main text. Based on these inputs, the structure of doc 650 is good the way it is.
In the current spec, the rules related to MLO discovery and frame content (including field values) is spread across various sections. Doc 650 was prepared in collaboration and inputs from several members
to provide informative text in a dedicated section.
Hope this helps!
Regards,
Abhi
CAUTION: This email originated from outside of
the organization.
Hello Abhi
Thanks for your update. I have a few comments on your document, include some technical issues.
Overall, this is good summary. But my concern is that this will bloat the draft, it has much redundant info. If this is frame exchange sequence, I suggest to move it to Annex G, like M/O in PICS
Best wishes
Ming Gan
Hi Alfred, Jeongki,
I have not received any further comments on this document.
I would like the run an SP on r7 of the doc. Could you please help add it to the agenda for the next TGbe MAC call?
https://mentor.ieee.org/802.11/dcn/21/11-21-0650-07-00be-cc34-resolution-for-cids-related-to-mlo-discovery.docx
Regards,
Abhi
CAUTION: This email originated from outside of
the organization.
Hi All,
A few members were still in the queue when the chair had to cut the discussion on doc 11-21/650.
I received offline emails from most of the members in the queue with editorial suggestions.
I have incorporated their suggestions and prepared an r7 of the doc (attached copy).
I’d like to hear if any other member has additional feedback on the document.
Regards,
Abhi
Hi All,
I have posted an r2 of the document which includes updates based on additional feedback from various members:
https://mentor.ieee.org/802.11/dcn/21/11-21-0650-02-00be-cc34-resolution-for-cids-related-to-mlo-discovery.docx
Regards,
Abhi
CAUTION: This email originated from outside of
the organization.
[subject updated]
Hi All,
Thank you to all the members who reviewed doc 650 and provided offline feedback.
I have posted r1 of the document to mentor.
https://mentor.ieee.org/802.11/dcn/21/11-21-0650-01-00be-cc34-resolution-for-cids-related-to-mlo-discovery.docx
Could you please take a look and let me know if you have additional feedback?
Regards,
Abhi
From: Abhishek Patil
Sent: Monday, April 12, 2021 2:45 PM
To: 'matthew.fischer@xxxxxxxxxxxx';
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted
Hi Laurent, Mike, Matt, All,
I have prepared CR doc
11-21/0650 which provides a high-level summary of the frame sequences and the contents of each frame during MLO discovery. I hope it provides clarity and answers some of the questions that were raised on this email thread.
I’ve attached a copy of the doc for your convenience. I would appreciate your feedback.
Regards,
Abhi
Your description is very nice.
Can we get that as introductory text to be included somewhere in the draft?
There's one part that I think might be incorrect:
Non-AP MLD can get all info by probing (regular) or
receiving beacon on all 3 links.
I believe that this should say:
Non-AP MLD can get all info by probing (regular) or receiving
any one beacon on any of the 3 links.
Hi Laurent,
I don't believe the information you provided is complete.
I'm not sure what your mean by STA1. Do you actually mean that the non-AP MLD transmits the frame on STA1? Its the non-AP MLD SME that kicks this off, the affilitated STAs just transmit the frames. In order to associate, a non-AP MLD needs
to have the RSNE/RSNXE for each affiliated AP link of an AP MLD. Inn which frames is this information received?
Hi Matt, Mike,
That’s correct.
Example: an non-AP MLD wants to discover an AP MLD with 3 APs/links (AP1/link1, AP2/link2, AP3/link3).
Beacon and regular probe response from AP1 will carry:
-
RNR to report AP2 and AP3 with BSSID, SSID, MLDID, linkID, operating channels, change sequence…)
-
ML element with MLD level info (MLD MAC address, …) and with missing info for AP1 (linkID, change sequence), but no per-STA profile for AP2 and AP3
Non-AP MLD can get all info by probing (regular) or receiving beacon on all 3 links.
Or non-AP MLD can send ML probe request to each of these AP and ask for complete info.
ML probe response from AP1 will carry:
-
ML element with MLD level info (MLD MAC address, …) and a per-STA profile for AP2 and AP3 (carrying complete info).
-
Complete info for AP1 is carried in the core of the response (except linkID, change sequence in the ML element)
If non-AP MLD wants to associate with the AP MLD
STA 1 will include in assoc request to AP1:
-
Complete info for STA 1 in core of assoc request
-
ML element with MLD level info (MLD MAC address, …), and with per-STA profile for STA2 (with link ID corresponding to AP2) and STA3 (with linkID corresponding to AP3).
AP1 will respond with assoc response to STA1:
-
Complete info for AP1 in core of assoc response
-
ML element with MLD level info (MLD MAC address, …), and with per-STA profile for AP2 and AP3.
Hope the example clarifies.
Best
Laurent
From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Thursday, April 1, 2021 5:35 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted
Hello Matt
I am not sure what is profile you mentioned? Is that per STA profile? If it is, actually, it will not be carried in Beacon frame such
that to avoid bloating issue in typical case (does not touch exception). That is to say, only common field of ML IE is carried in Beacon frame.
Best wishes
Ming Gan
发件人:
Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2021年4月1日 2:38
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted
In the Beacon, the AP include the ML IE plus the RNR.
So, in the Beacon, the ML IE contains only one profile and the RNR has the others.
Then, in the ASSOC REP, the AP transmits multiple profiles in the ML IE and does not include an RNR.
Hi Matt,
Why do you say AP will have only one per-STA profile?
Say for example, non-AP MLD were to request 3 links for ML setup, then the assco req will include Basic variant ML IE containing complete profile for 2 STAs. The transmitting STA’s
info is in the core frame and the per-STA profile of basic variant ML IE carries the info of each of the other 2 STAs of the non-AP MLD.
AP MLD accepts all 3 links. The AP’s assoc resp frame include Basic variant ML IE containing complete profile for 2 APs. The
transmitting AP’s info is in the core frame and the per-STA profile of Basic variant ML IE carries the info of each of the other 2 APs of the AP MLD.
Some of this is already covered in clause 35.3.5 (D0.4).
There are CR docs in the queue (from Po-Kai, Insun, myself) which will provide further clarification.
Regards,
Abhi
This is where I started: I had thought that this was the answer for the AP.
So there is an asymmetry, in that for the AP, there is only one per-STA profile but for the non-AP STA, there are
n.
Hi Matt,
Good question. That portion is getting clarified in my doc 11-21/254.
The (Re-)Assoc Req frame will carry the MAC address of the corresponding STA that is capable of operating on that link.
Regards,
Abhi
What about the other direction?
Can the AP determine, during an ML setup operation, what the per link non-AP STA MLD MAC addresses are?
And can it determine which link ID they correspond to?
If the per link addresses are found in the RNR, then certainly, there is no RNR being transmitted by a non-AP MLD.
So how are these addresses and their relationships to the links provided to the AP during the setup operation?
Thanks, I was aware you guys’
response just now. The below answer is right.
Hi Matt,
Check 35.3.4.1 for the rules for inclusion in RNR.
Best
Laurent
Hi Matt,
The Beacon and Probe Response frame transmitted by an AP affiliated with an AP MLD includes Reduced Neighbor Report (RNR) IE [9.4.2.170.2] which carries the BSSID, Op class, Op channel for each reported AP that is affiliated with the same AP MLD. The RNR also
carries Link ID and CSN for each of the reported AP that is affiliated with that AP MLD.
Ming’s document provides Link ID and CSN for the reporting (i.e., transmitting) AP.
Hope this helps!
Regards,
Abhi
I realize that 397 was just approved, but let me be certain that I understand what was approved:
It looks like, if I am a non-AP STA, then I need to receive a separate ML element on each of the links of an AP MLD in order to establish the AP link address,
link ID and channel values for each link.
I.e. based on the approved text changes, I cannot see a method that allows an AP to include the following information in a single MPDU that could be received
on a single link:
1) the AP link address for every link of the AP MLD
2) the link ID values every link of the AP MLD (and of course, the correspondence with each AP link address)
3) the channel/operating class/freq information for every link
Each of these pieces of information must be received one at a time on the associated link.
Hi Gaurang
You miss my response in previous attached file- update it in the later version. Please see the attached new version. Meanwhile please
see my response inline
The ML ID is just for discussion in the attached file
For discussion:
The MLD ID for any reported AP should be unique and not changed sent by a reporting AP according to the approved document
The usage of MLD ID in RNR element:
MLD ID could be used to solicit the info of specific AP MLD which is advertised by the reporting AP, such as AP MLD which contains nontransmitted BSSID in the same MLD as the reporting AP
Link ID is used to solicit the info of the transmitting AP, same as other link ID in the STA profile.
Hi Ming,
Thank you very much for responding to my comments.
I looked at the responses in both versions of the document and found that a few of my questions/comments were not
addressed. I have reinserted a few comments in the latest version (r2).
Also, the approved SP text (copied below) relates to Link ID and CSN, both of which apply to an AP MLD. The motion
doesn't talk about MLD ID. Could you kindly explain why the probe request variant of ML IE needs to carry MLD ID and Link ID?
The CSN and Link ID fields are reserved when transmitted by a STA of a non-AP MLD transmits ML IE and therefore,
this change must be captured in clause 9 not clause 35. This is the normal practice in baseline spec.
[Ming] Since it clause 9, it already mentions
The condition for the presence of the MLD MAC Address subfield, the Transmitting AP Link ID subfield and the Transmitting AP Change Sequence subfield in the Common Info field is defined in 35.3.5.4 (Usage and rules of Multi-link element in the context of
multi-link setup) and 35.3.4.3 (Multi-link element usage rules in the context of discovery).
So it is not needed in clause 9
In addition, I also noticed that the changes in clause 35 are not with respect to approved text (for example, clause
35.3.4.4 was updated by a few docs). The numbering of the subclauses is also incorrect. I’m afraid this can create a conflict when the editor tries to incorporate your changes. Resulting in some of the changes from your doc being missing in the next draft.
I suggest that you base your changes with respect to the latest approved text.
[Ming] It is updated, please refer to the attached file. Thanks
Thanks,
Gaurang
Hi Ming,
I have similar questions as Gaurang. It is not clear to me why the MLD ID and Transmitting AP link id is included in the Probe Request variant MLE. Moreover, the PDT does not contain
any normative text that explains what these fields are for. My impression of the Motion covered in the PDT was that it only targets the Basic variant MLE; I believe SP2 about ML probe request has not been run yet. Shouldn’t
we run the SP first?
Hello Gaurang
Thanks for your comments, please see that attached response.
Best wishes
Ming
Hi Ming,
I noticed that a newer version of the document was posted on mentor. I have one additional comment that I have inserted in the attached file. Could you kindly take a look?
Thanks,
Gaurang
Hi Ming,
I have a few comments that I have inserted in the attached document. One of them aligns with what Rojan described below. Could you kindly review my comments?
Thanks,
Gaurang
Hi Ming,
I meant that transmitting AP information is not relevant for Probe Request variant ML element, so I did not understand why the common info has to be the same. I am working on the
CRs for CIDs related to 9.4.2.247b.3 (Probe Request variant Multi-Link element) and think this discussion may be more relevant in that document and would appreciate if you can take this clause out from your CR document. I will share my CR document soon.
Regards,
Rojan
Thanks Rojan, so you are saying common part of ML element is not needed?
actually there is still difference between basic variant and Probe request variant. That is Per STA profile, the Probe Request variant
only has Per-STA Control field.
Best wishes
Ming Gan
Hi Ming,
Thanks for the PDT. Regarding the below changes:
9.4.2.247b.3 Probe Request variant Multi-Link element
…
The presence and format of the Common Info field in the Probe Request variant Multi-Link element are
TBD.
The format of the Common Info field in the Probe Request variant Multi-Link element is as same as Basic variant Multi-Link element as defined in Figure 9-xxxx - Link Info field
of the Basic variant Multi-Link element.
The Motion is not relevant to the probe request variant ML element since the transmitting AP’s information will never be carried
in it. There is no meaning of having a separate variant of ML element Type for Probe Request if the format is the same as the Basic variant. Also, I am making changes to this sub-clause as part of the D0.3 CRs. Would you be ok to take this out from your PDT
and we can discuss this during my CRs if needed?
Thanks.
Hello Alfred
Could you add the following PDT document into the queue? Thanks.
11-21-0397-00-00be-PDT ML element for transmitting AP
https://mentor.ieee.org/802.11/dcn/21/11-21-0397-00-00be-pdt-ml-element-for-transmitting-ap.docx
best wishes
Ming Gan
Hi Alfred,
I have a CR document for clause 35.3.11. Can you add it to the MAC queue?
https://mentor.ieee.org/802.11/dcn/21/11-21-0320-00-00be-cr-for-35-3-11.docx
Best,
Po-Kai
Hi Alfred,
I have a CR document for clause 12.4. Can you add it to the MAC queue?
https://mentor.ieee.org/802.11/dcn/21/11-21-0260-01-00be-cr-for-12-4.docx
Best,
Po-Kai
Hello all,
I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on
Monday, March 01 (MAC/PHY), 19:00-22:00 ET and
Wednesday, March 03 (JOINT), 10:00-12:00 ET.
The agendas can be found here:
DIAL IN DETAILS FOR WEDNESDAY:
Join the JOINT meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=m1d1c71d54a60bd6b9c5fafd719c959d9
Meeting number: 179 925 7715
Meeting password: wireless (94735377 from phones and video systems)
Notice: Please note that by now all authors of the submissions for PDTs and CRs (especially MAC) should have sent requests for feedback to the IEEE TGbe
reflector. Members are invited to provide feedback for these contributions prior to the conference call via e-mail so that the time in the conf calls is used efficiently.
--
Qualcomm Technologies Inc.
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
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
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is
addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to
the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete
it from your computer, and destroy any printed copy of it.
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
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is
addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to
the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete
it from your computer, and destroy any printed copy of it.
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
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is
addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to
the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete
it from your computer, and destroy any printed copy of it.
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is
addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to
the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete
it from your computer, and destroy any printed copy of it.
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
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is
addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to
the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete
it from your computer, and destroy any printed copy of it.
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
|