Hi Giovanni,
Thank you for the feedback. I looked at the spec and you are correct that the term “TWT schedule” seems to have been used as a term to indicate SPs in RevME. It is somewhat an unfortunate usage of the word,
particularly when it comes to the phrase “protection of a schedule”, but I suppose that is something that should be addressed in TGm.
I am ok with the proposed text.
From: Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>
Sent: Tuesday, December 10, 2024 4:48 PM
To: Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; xiangxin.gu@xxxxxxxxxx; brianh@xxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] PDT MAC CR-TWT
Proposed Draft Text for CR-TWT
Dear Xiangxin, Xiaofei, all,
Thanks a lot for the continued work on the Co-RTWT PDT!
I uploaded 24/1966r2 on Mentor:
https://mentor.ieee.org/802.11/dcn/24/11-24-1966-02-00bn-pdt-mac-crtwt.docx
I also attach to this email a Redline version to highlight the differences from the 24/1966r1 that was discussed during the TGbn call on 12/09/24.
A summary of changes is provided below:
- Fixed a typo (DCN) in the document’s header, (@Brian
Hart (brianh) commented online)
- Fixed list of authors,
- Replaced the MIB variable “dot11CRTwtOptionImplemented” with “dot11CoRTwtOptionImplemented”
to align with the acronym “Co-RTWT”, (@Brian Hart (brianh) commented online)
- Clarified the description of “Co-RTWT requesting AP” in 37.11.1 (General),
- Clarified the description of the feature in 37.11.1 (General) to highlight that Co-RTWT involves OBSS APs, (@xiangxin.gu@xxxxxxxxxx
request)
- Clarified the role of “Co-RTWT negotiations” in 37.11.1 (General),
- Clarified that an AP may signal “enablement of Co-RTWT negotiations” in 37.11.2 (Co-RTWT negotiations), as opposed to “its willingness to participate in Co-RTWT
negotiations”),
- Other editorials
@Xiaofei Wang, thanks for
the good discussion point, I did not apply changes on this at this time and I’ll provide below the rationale I am following:
- An R-TWT schedule comprises of a set of R-TWT SPs (same for TWT schedules, or Co-RTWT schedules)
- An action on set of SPs (e.g., membership establishment, negotiation, etc.) should refer to an R-TWT schedule
- An action on a specific SP (e.g., transmitting a trigger frame, or interrupting the TXOP before a start time) should refer to an R-TWT SP
- This seems to be in line with the approach taken in 26.8 (TWT operations) and 35.8 (Restricted TWT)
Please feel free to discuss on this, so that we can proceed with a common understanding within the group.
Thanks,
Giovanni Chisci (QC)
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Giovanni,
Thank you for your work on CR-TWT. I think the wording you proposed is better than what is currently in 11-24/1966r1. Though I would suggest to use “R-TWT SPs” instead of the two “R-TWT schedules” in the proposed
text. If I understand correctly, the coordination and protection is really for the R-TWT service intervals, not just for the scheduling of them.
Proposed Draft Text for CR-TWT
Dear Xiangxin,
Thanks for the comment.
I agree with you that the condition right now is looser that the one you mention that uses the wording
“OBSS”.
At this time, I will not create a revision due to the upcoming call (I will discuss the 24/1966r1 uploaded on mentor).
Please feel free to suggest a wording via email, and we can check if it is acceptable for members.
One possibility would be to adopt something along the lines of:
Thanks,
Giovanni
Hi Giovanni,
Thanks for the effort on PDT.
I think that
“APs in the same neighborhood that belong to different BSSs” is different to
“OBSS APs”.
“APs in the same neighborhood that belong to different BSSs”
does not mean overlapped operating channel and overlapped coverage.
BR,
Xiangxin Gu
Communication Standards Devision
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Proposed Draft Text for CR-TWT
Dear all,
Thanks for the continued effort and help for improving the Co-RTWT PDT!
I submitted 24/1966r1 on Mentor that incorporates the newly received comments from Ross, Pascal, and Kerstin (thanks for your valuable input!).
Please find the 24/1966r1 clean version on Mentor:
https://mentor.ieee.org/802.11/dcn/24/11-24-1966-01-00bn-pdt-mac-crtwt.docx
I also attach a Redline version to highlight the delta changes from r1_Draft_v01 that was previously circulated to 24/1966r1 uploaded on Mentor. The changes are summarized and discussed in the following:
- The subclause numbering and title is aligned to 37.11 (Coordinated R-TWT)
- Please keep providing your preference on whether that section should be hierarchically under 37.7 (Multi-AP
coordination framework) à this type of change is not implemented at this time
- To
@ross.yujian@xxxxxxxxxx: my personal opinion is that if we go that way (no strong opinion on going that way per-se), it would be better to name the section 37.7 Multi-AP coordination
(since it may one or more subclauses for the general framework, and other feature-specific subclauses, e.g., 37.7.4 Coordinated R-TWT)
- Replaced all occurrences of “CR-TWT” with “Co-RTWT”.
- Please keep providing your preference on whether “Co-R-TWT” should be used instead of “Co-RTWT” (I note
that so far Brian and Kerstin may prefer the former)
- On subclause 3.2 (Definitions specific to IEEE Std 802.11)
- Addition of definitions of Co-RTWT SP and Co-RTWT SP start time
- Addition of definition of Co-RTWT agreement and Co-RTWT negotiation (these are now called out in 37.11.1 (General) and in 37.11.2 (Co-RTW negotiations),
introduced to improve clarity since negotiations and agreements are going to be available for each M-AP coordination feature)
- Reordering of items to be in alphabetic order.
- On subclause 37.11.1 (General)
- Reordered the definitions of Co-RTWT requesting/responding/coordinated APs in that order
- Replacement of “extends the protection for” with “extends the protection to”
à the change is applied
- My original intention was in fact hinting that an R-TWT protection exists already (in the BSS of AP1, STAs protect that schedule, it is legacy 11be R-TWT)
and with Co-RTWT “protection is extended [by AP2 in its own BSS] for the R-TWT schedules [of AP1]”. The other interpretation offered by Kerstin also works (it does only change the perspective, and there seems to be no practical difference). The change is
therefore applied. In case there are issues with the updated wording, we can revert.
At this point I consider that 24/1966r1 is sufficiently stable for presentation in TGbn, and will notify it to the TGbn chair.
If there are still critical comments (hopefully it won’t be the case) or small editorial changes, please provide them as usual directly on 24/1966r1 (e.g., on a Word document 11-24-1966-01-00bn-pdt-mac-crtwt_MemberX.docx)
or as a reply to this thread.
Best,
Giovanni Chisci (QC)
Hi Giovanni et. Al,
Please find my edits/comments into the updated, clean draft.
Some highlights:
- The wording is quite difficult to follow (even for a native speaker). I realize this is “par for the course” w/ specifications, but there is still room
for improvements. I’ve tried to make the wording more concise to make reading the text easier.
- In Co-R-TWT, an AP “extends protection to” another AP’s SPs. It does not “extend the protection for” those SPs.
The former wording (which I’ve inserted into the draft in all relevant locations) implies that protection is being “newly offered/provided”, where it did not exist before. The latter (which was originally
used) implies that protection already exists and is simply “being prolonged”.
- You’ll see that I re-ordered the discussion of “responding AP” and “coordinated AP”. Again, I don’t see why you’d discuss “coordinated AP” before discussing
“responding AP” – that’s putting the cart before the horse. An AP must first respond before it can be coordinated. So, it makes sense to discuss it in that order.
BR,
From: Kerstin Johnsson (Nokia)
000039130cefe96b-dmarc-request@xxxxxxxxxxxxxxxxx
Sent: Thursday, December 5, 2024 4:51 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT
I agree with Ross that using the acronym “CR” can be confusing. I prefer “Co”, e.g., Co-R-TWT.
From: VIGER Pascal
Pascal.Viger@xxxxxxxxxxxx
Sent: Tuesday, December 3, 2024 5:08 AM
To: Giovanni Chisci
00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] PDT MAC CR-TWT
Hi Giovanni,
Thank you for your coordination.
I have one concern about the ‘CR-TWT SPs’ terminology that is used in document (e.g. 37.x.4) but never introduced.
I think this terminology is still useful and would provide simple text compared to repeating multiple times something like “R-TWT SP for which protection …”.
This is why I propose you a draft definition in the attached document.
Best regards,
Pascal
From:
Yujian (Ross Yu) <00001792b51ef4ea-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Tuesday, December 3, 2024 at 03:27
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT MAC CR-TWT
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
|
Hi Giovanni,
Thanks for pointing the issues out.
Let’s try to settle the terminology and subclause number before D0.1. Otherwise, the cross reference, searching the whole draft take a lot of time.
I suggest people share opinions on your two highlighted issues using this email thread.
In the SFD, I am using the following terminologies:
Coordinated spatial reuse: Co-SR
Coordinated beamforming: Co-BF
Coordinated TDMA: Co-TDMA
Coordinated restricted TWT: Co-RTWT (in 11be, R-TWT is used)
Regarding multi-AP structure, comments are also welcome.
regards
于健 Ross Jian Yu
Huawei Technologies
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
|
Proposed Draft Text for CR-TWT
Dear Brian, John, and all,
Thanks for the continued effort for improving the CR-TWT PDT!
This email:
- closes the first round of comments on r1_Draft_v00 (find attached a response to Brian, I provide also a
response to John’s suggestions inline)
- kicks off the second round of comments on r1_Draft_v01 (please provide comments and edits in track change on the attached r1_Draft_v01_Clean)
- Please provide comments on r1_Draft_v01 by Wednesday 12/04 at 5pm Pacific time – in about 48h from now (I
target to upload a hopefully stable r1 on Mentor by Friday 12/06 COB)
A few highlighted issues from the comments that I would like to collect opinions on are the following:
- Name of the feature: Currently I am using CR-TWT, there have been proposals to have an additional hyphen as in C-R-TWT, and to use “Co” as in CoR-TWT
or Co-R-TWT. Granted that it is not urgent (we can replace all the occurrences easily), I would like to hear member’s opinions on this.
- Organization of the subclauses: currently CR-TWT is a 37.x clause, and the assumption that there will be another clause for M-AP coordination framework
(e.g., 37.y). A comment discussed on whether CR-TWT clause should be a subclause (e.g., 37.y.x) of M-AP coordination framework clause (e.g., 37.y). Also this is not extremely urgent, but we can keep this in mind as we see how the M-AP coordination framework
clause evolves (in its own TTT discussion).
Thank you in advance,
Giovanni Chisci (QC)
Hi Giovanni
Many thanks for your detailed work! Some quick responses on the old document threads and also on the new document.
Best wishes
Brian
From: Wullert, John R II (PERATON LABS)
jwullert@xxxxxxxxxxxxxxx
Sent: Monday, November 25, 2024 1:20 PM
To: Giovanni Chisci gchisci@xxxxxxxxxxxxxxxx;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] PDT MAC CR-TWT
Giovanni,
Thanks for the continued coordination!
One comment:
- In the last paragraph of Clause 37.x.2 in the latest draft, you refer to a CR-TWT responding AP following the rules
to “establish or teardown agreement(s)”. Given the definitions, it makes sense that a CR-TWT responding AP would follow the rules to establish agreements, but shouldn’t it be the CR-TWT coordinated AP that is responsible for tearing down agreements? (While
they refer to the same device, the definitions represent different states of that device. In addition, restricting teardown to the CR-TWT responding AP seems to suggest that only the CR-TWT requesting AP can initiate the teardown process, which I don’t think
has been decided.)
[GC] Thanks for the good point. For the time being I decided to remove everything related to teardown (since it has not been discussed yet). That being said I
think that AP2 (the one that is extending the protection for an R-TWT of AP1) changes state from CR-TWT responding AP to CR-TWT coordinated AP on a per schedule (per agreement) basis, so I am in agreement with you that once we define “tearing down” agreements,
AP2 would be an action as a “CR-TWT coordinated AP”.
John
Cisco Confidential
Proposed Draft Text for CR-TWT
Dear Gaius, Brian, Kumail, Kerstin, and all,
Thanks a lot for providing the initial set of comments. They were very useful to provide the new draft for r1.
This email:
- Includes Word documents including the PoC responses based on the received comments on r0 on separate documents (from Brian and Kumail)
- Unify the thread since I noted a branching out between text suggestions directly on email thread (Gaius and Kerstin) and suggestion on Word documents
(Brian and Kumail).
- Replies
inline to the suggestions made directly on this thread.
- Provides two new documents (r1_Draft_v00_Clean and r1_Draft_v00_Redline) for the new round of comments collection kicked off by this email.
Please keep providing comments on r1_Draft_v00_Clean.
I’ll keep updating the r1 Draft by increasing the version count at each round (e.g., next round will be kicked off with new r1_Draft_v01), until the draft is stable for upload. The next round will be kicked
off as soon as there are a sufficient number of comments on r1_Draft_v00_Clean.
Best,
Giovanni
From: Kerstin Johnsson (Nokia)
000039130cefe96b-dmarc-request@xxxxxxxxxxxxxxxxx
Sent: Friday, November 22, 2024 3:09 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT
Hi Giovanni et. al,
I had similar (and in some cases the same) edits as Gaius. I will copy paste his changes here with my additional changes inserted:
37.x.1 General
CR-TWT operation described in this subclause enables APs in the same neighbourhood that belong to different BSSs to:
a) coordinate their R-TWT schedule(s),
b) ensure that one AP extentds the protection for the R-TWT schedule(s) of the other AP.
b) request protection for their R-TWT schedule(s) from other APs
c) respond to requests to protect R-TWT schedule(s) of other APs
[GC] Thanks for the suggestion, I would try to avoid splitting request/response in this part. Please check if the version in r1_Draft_v00 is satisfactory.
A CR-TWT requesting AP is an AP that requests protection for one or more of its R-TWT schedule(s).
A CR-TWT responding AP is an AP that responds to a CR-TWT request from another AP, potentially resulting in negotiation of a CR-TWT agreement per the rules defined in 37.x.2 (CR-TWT negotiation).
A CR-TWT coordinated AP is an AP that has agreed to provides protection for the requested R-TWT schedule(s) of a CR-TWT requesting AP
either by establishing an per a CR-TWT
agreement reached through negotiations or other means.
A CR-TWT responding AP is an AP that responds to a CR-TWT requesting AP that initiates a CR-TWT negotiation to establish an agreement by following the rules defined in 37.x.2 (CR-TWT negotiations).
[GC] I provided clarifications on this part in r1_Draft_v00, please check if it is satisfactory. I would avoid using the terminology “has agreed” for the CR-TWT coordinated AP, since
CR-TWT responding APs are those that make the agreements via negotiations (and then extend the protection), but some others just extend the protection.
[GC] On the swapping places for the definitions of CR-TWT coordinated AP and CR-TWT responding AP, I would still try to keep this order, since the text seems to be clearer if the
superset is defined first, and the subset after. Please check the r1_Draft_v00 is satisfactory. Let’s hear also other opinions.
IfWhen
a CR-TWT coordinated AP extends
the protection of
to an R-TWT schedule of a CR-TWT requesting AP, then:
it shall ensure that its TXOPs ends before the start time(s)
of the CR-TWT requesting AP’s SP(s) as identified by
corresponding to that
R-TWT schedule, and
if it has at least one associated
non-AP STA
that is capable of R-TWT, it shall advertise
the R-TWT schedule in the
its Beacon frames it transmits that R-TWT schedule
so that those STAs also extend protection to the R-TWT per the rules defined in 35.8.4.1 (TXOP and backoff procedure rules for R-TWT SPs).
if it has at least one associated
non-AP STA
that is capable of R-TWT, it shall advertise
the R-TWT in
the its Beacon frames
it transmits that R-TWT schedule
so that its associated non-AP STAs
capable of R-TWT also extend protection to
supporting R-TWT follow
the R-TWT per the
rules defined in 35.8.4.1 (TXOP and backoff procedure rules for R-TWT SPs)
for that R-TWT schedule.
[GC] Some of the suggestions are implemented.
Please check if the version in r1_Draft_v00 is satisfactory.
Thanks everyone!
Kerstin
From: Muhammad Kumail Haider
kumail.ieee@xxxxxxxxx
Sent: Thursday, November 21, 2024 11:07 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT
Hi Giovanni, thanks for initiating this effort and a great first draft.
Please find attached some suggestions and comments.
Best,
Kumail.
Many thanks for kicking this effort off! My comments attached.
------------------------------------------------------------------
From: Gaius Yao Huang Wee
yaohuang.wee@xxxxxxxxxxxxxxxx
Sent: Monday, November 18, 2024 5:31 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC CR-TWT
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Giovanni,
Thanks for preparing the initial PDT for CR-TWT. I have some editorial suggestions on your current text.
37.x.1 General
CR-TWT operation described in this subclause enables APs in the same neighbourhood that belong to different BSSs to:
a) coordinate their R-TWT schedule(s),
b) ensure that one AP
extentds the protection for the R-TWT schedule(s) of the other AP(s).
[GC] Agreed, updated
A CR-TWT requesting AP is an AP that requests protection for one or more of its R-TWT schedule(s).
A CR-TWT responding AP is an AP that responds to a CR-TWT requesting AP that initiates a CR-TWT negotiation to establish an agreement by following the rules defined in 37.x.2 (CR-TWT negotiations).
A CR-TWT coordinated AP is an AP that provides protection for the requested R-TWT schedule(s) of a CR-TWT requesting AP either by establishing an agreement through negotiations or by other means.
A CR-TWT responding AP is an AP that responds to a CR-TWT requesting AP that initiates a CR-TWT negotiation to establish an agreement by following the rules defined in 37.x.2 (CR-TWT negotiations).
[GC] On the swapping places for the definitions of CR-TWT coordinated AP and CR-TWT responding AP, I would still try to keep this order, since the text seems to be clearer if the
superset is defined first, and the subset after. Please check the r1_Draft_v00 is satisfactory. Let’s hear also other opinions.
IfWhen
a CR-TWT coordinated AP extends the protection of an R-TWT schedule of a CR-TWT requesting AP, then:
a) it shall ensure that its TXOP ends before the start time of the CR-TWT requesting AP’s SP(s) corresponding to that R-TWT schedule, and
b) if it has at least one associated STA that is capable of R-TWT, it shall advertise in the Beacon frames it transmits that R-TWT schedule so that its associated STAs supporting R-TWT follow
the R-TWT rules defined in 35.8.4.1 (TXOP and backoff procedure rules for R-TWT SPs) for that R-TWT schedule.
[GC] Agreed, updated. This text is now in dedicated sections.
Best regards,
Gaius
Proposed Draft Text for CR-TWT
As POC,I have created an initial PDT document which is 11-24-1966:
The CR-TWT feature currently (at the end of 2024 November IEEE 802 Plenary Session) has two passing motions.
The initial PDT-MAC-CRTWT document r0 includes proposed text based on this two motions.
As additional motions are passed, we will add to the text in the document.
I have taken the author list from the TTT list found in the document
11-24-1698-13-00bn-tgbn-d0-1-spec-text-volunteers-and-status
If you have volunteered for the CR-TWT TTT, please check the author list of 24/1996r0.
If your name is spelled incorrectly, or is missing an affiliation, or has an incorrect affiliation, or if your name is missing entirely, or if you are in the list and do not wish to be included in the author
list, then please send an individual email to:
to indicate which particular problem exists so that I can update the document.
Feel free to send any comments on the existing PDT (i.e. the draft text, not the author list) in 24/1996r0 as a response to this email, so that all TTT members
may see your comment and so that we can discuss the comment and then debate any changes to the document. This will be the general process going forward for text that is included in the document. I hope that there is little discussion on the initial text, since
it is so high level and there are only a few sentences. If there is a firestorm over these first few sentences, then I will be anxiously awaiting the next passing motion...
At some point, the group should pass a few more motions relating to CR-TWT, and when this happens, then we will try to find volunteers to create draft text sections corresponding to those new motions. Depending
on the size/complexity of that text, it should appear for discussion within this email thread either as:
a) text that is directly included as native text within an email sent to this thread (usually for small text additions/changes)
b) text included within a new WORD document that does not need to be an official 802.11 submission or uploaded to the server, since the text on its own will not be subject to a motion, but will only be subject
to motion as part of a complete CR-TWT PDT document (i.e. 24/1996rx) - such a document would be sent as an attachment to this email thread for discussion
c) text included within a copy of the 24/1996rx WORD document, showing additions and changes to the existing 24/1996rx doc that again, should not be uploaded to the server, but attached to the email thread.
We will try, with any new proposed draft text, to discuss new proposed text within this thread and come to a super-majority regarding such new text (e.g. 75% of the TTT membership, whatever that is). I do
not want to use the word consensus, because that implies near unanimous agreement and I feel that such a goal is impractical. But suggesting something like 75% is also problematic, as there is no real defined TTT membership - it is fluid. So there will be
a judgement call as to when we should close the debate on any new text; Such a decision will occur when the number of objections quiets down to some small number of members (e.g. <25%, which is currently estimated to be about 15 people - but that too will
be a judgement call because someone could invite a dozen of their friends to send an objection to the thread even though they are not listed as TTT members and there probably is nothing that can be done about that). In cases where such quieting does not occur,
then we will have to throw the text into TGbn for a straw poll and update our document 1762rx based on that outcome.
I hope it will be generally obvious when we can accept text vs when we need to perform an SP in the TG, and I hope that we do not need to frequently submit SPs in the TG or we will never complete a D0.1....
P.S.: Many thanks to Matthew Fischer for the initial email that kicked off the discussion for the PDT of the NPCA feature, which has been taken as example to define the process in this thread.
Thank you and best regards,
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
|