1762r17 now available on the server:Gaurang,I do agree that the motions do not explicitly state that the AP enables or disables NPCA, but if this is not the case, then who does enable/disable NPCA?Certainly not some random non-AP STA. So I think that it is reasonable to have included a simple on/off switch by the AP in the current text.Supposing that the group agrees that some less "sudden" enablement of NPCA is needed, I do not see how adoption of a change to accommodate for example, a mechanism along the lines of channel switch announcement that spans several beacons for use by NPCA would be prevented by the existing text, which can be easily modified when some alternative "soft mode switch" text is available and agreed upon to replace it.Additionally, if such a change were agreed upon, it would affect more than just the cited paragraph, as additional changes would be needed in the frame formats.As to the need for such a change, I would like to hear the arguments and see the group agreeing to it.I do not understand why a "sudden change" in the mode would cause any problems.The current situation is likely to be that there are many STAs associated with an AP and maybe only a few can perform NPCA.So if there are STAs that have a slow enablement, then it just means that the STAs that can perform NPCA rises slowly.A "failure" would be that an AP might attempt to TX to a slow STA that is not yet ready to switch.There would be a lost transmission. We have TX failures frequently. When NPCA is disabled, all of that available secondary BW is lost already.So in this case, you've just lost it for a bit longer until everyone switches to NPCA operation. Not a problem.I still do not understand why a STA would need a long time (100 ms??) to switch on NPCA anyway..If the delay is less than 5 ms, then I see virtually no problem.Junbin,generally followed your suggestionsLiangxiao,Please note:Any comment that was in your document that is not referenced in the list below was generally accepted:1.NPCA information field AP vs non-AP STAwe have an open item on determining exactly what parameters are sent in UL vs DL direction and in what frames, only when there is a group consensus on how this is to be resolved should we bother to make modifications here2.channel number vs the number of the channel"channel number" is a term that already exists in the baseline, so it is better to keep using this termthe sentence is a bit complex, but quite parsable3.OBSS activity vs NAVthe language used so far in the document is very careful to avoid explicitly using the term NAV because:a. for PPDU cases, the NAV in the MAC header can only be extracted sometimes (based on MCS and signal level) and even then, can only be definitively verified at the end of the MPDU where the FCS occurs, meaning that it is either low quality or too late to be usedb. for PPDU cases, one might, depending on the PPDU format, be able to extract NAV information from a PHY header, but this information has a high quantization error and also has an upper bound that might render the information inaccurate and is sometimes absent and some people have objected to the possibility of using NAV even if you are able to get accurate information because the initial NAV might represent only an upper bound estimate of the upcoming TXOP which might be either shortened or lengthened during the TXOP, and if NPCA is being performed during that initial value of NAV, then any subsequent changes to the NAV by the original OBSS TXOP holder will be invisible, potentially causing issuesc. the more exact meaning of the field is clarified with the much more complex behavioral description within 37.104.received from or transmitted tothe statement needs to be applicable to both AP and non-AP STA, since both will enter NPCA operationbecause it is the AP that sets the parameter with a transmission, the reception case applies only to the non-AP STA and the transmission case applies only to the APhence the current wordingMatthew Fischer, BroadcomOn Sat, Jan 11, 2025 at 11:55 PM Liangxiao Xin <xlx20190808@xxxxxxxxx> wrote:Hi Matt,Thanks for preparing the document. Please see my comments in the attached file.Regards,LiangxiaoOn Sun, Jan 12, 2025 at 3:24 PM Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:Hi Matt,I have a comment on the following text in r16.I understand the text to mean that an AP can set the bit to 1 in one Beacon and then to 0 in the next, abruptly disabling the mode. I've had offline discussions with members about the need for a smoother transition method for enabling/disabling and potentially to update other NPCA-related parameters.None of the current motions address how an AP enables/disables NPCA mode. Therefore, I propose deleting the first two sentences of the paragraph above (highlighted). If necessary, we can add a note such as: "NOTE - The method by which an AP enables/disables NPCA mode or updates NPCA-related parameters is TBD."Thanks,Gaurang
From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Wednesday, January 8, 2025 8:05 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCAWARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
1762r16 now available:
Mickael,
1.The double "to" in the NPCA Primary Channel field description is not a typo - it is correct syntax, albeit possibly confusing.The situation arises because of the adjacent positioning of two verbs:switch toto performThere are a couple of alternatives, but I am not certain that they are better:
0. choice 0, existing language:The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel that the NPCA AP and its associated NPCA non-AP STAs switch to to perform NPCA operation1. choice 1The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel to which the NPCA AP and its associated NPCA non-AP STAs switch to perform NPCA operation
2. choice 2The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel that the NPCA AP and its associated NPCA non-AP STAs switch to in order to perform NPCA operation
3. choice 3, combining 1 and 2The NPCA Primary Channel field indicates the channel number of a channel within the BSS bandwidth that corresponds to the channel to which the NPCA AP and its associated NPCA non-AP STAs switch in order to perform NPCA operation
I have not changed the existing language at this point.
2.Regarding the NPCA Supported fieldAs you note, there has been discussion as follows:The existing document uses the presence of NPCA parameters transmitted by the AP to indicate that the AP supports and has enabled NPCA within the BSSBecause of this, the use of an individual NPCA Supported bit by the AP seems redundant but to some people, it seems odd that the AP does not set the bit.In order to reduce confusion, you suggest adding language for the AP that indicates that the bit is reserved.I am actually ok with either solution - i.e. marking the bit as reserved for the AP or allowing the AP to set it.I feel that we should see a few more opinions before I change anything.After the initial discussion on the reflector, the existing situation has stood until your comment.
3.removed the leftover reference to the previously deleted item c) TBD
4.Not from you, but modified some other editorial change - regarding the untriggered UL operation - trying to use language that is more formal
On Wed, Jan 8, 2025 at 1:16 AM LORGEOUX Mickael <Mickael.Lorgeoux@xxxxxxxxxxxx> wrote:Hi Matthew and all,
Happy new year to everyone !
Thanks Matthew for your work on this PDT NPCA document.
My review on the revision r15 is here attached :
-Two comments on page 12 and 14 highlight some typos.
-One comment on page 13 is related to NPCA support indication.
Best regards
Mikael
From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: mardi 7 janvier 2025 22:46
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA
BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Please report all suspicious emails to the ISS department as an attachment.
r15 now on the server:
https://mentor.ieee.org/802.11/dcn/24/11-24-1762-15-00bn-pdt-mac-npca.docx
Laurent,
1. modified text as requested, as there is no mention of frames in the motion, even though I know of no magic technique outside of a transmitted frame that can be used to communicate a mode change for the BSS from an AP to any of its associated non-AP STAs. However, see my statement on the use of "TBD" in my item 2 comments.
2.
M144 does indicate that these two items are used to switch to NPCA but the motion also includes the phrase "NOTE: other conditions TBD", echoing M11!
Now, one could read the M144 "other conditions TBD" as corresponding to "other conditions" found in M11, which seems like a very natural reading, or one could regard the M144 reference as indicating that there will be other conditions that provide more details for the first two items of M144.
The motion is poorly worded, in that it does not state which case is correct and I can see that either interpretation could be correct.
In any case, I am happy to remove item c) since anything that is not currently present in any draft text is always implicitly TBD and having a TBD in the draft is not really much different from having nothing in the text.
In either case, a motion is needed to add new text to a draft and putting such text into a draft does not first require an existing TBD that would be replaced.
If anyone really has any item c) TBD condition that they want to replace item c) TBD, then they can certainly propose it during the meeting and the success or failure of that proposal is unaffected by the presence or absence of item c) TBD.
Now, this does leave a few other TBDs in the document - I did not touch them because I really do not care either way.
On Tue, Jan 7, 2025 at 11:57 AM Cariou, Laurent <laurent.cariou@xxxxxxxxx> wrote:
Hi Matt,
1. Then please follow the text that was agreed.
And replace the sentence by the following: An NPCA AP may enable or disable a mode of operation in NPCA where the NPCA non-AP does not use untriggered UL transmissions on the NPCA primary channel.
2. We indeed have that initial motion. However, we also passed motion 144 that determines the event that trigger the switch to the NPCA PC and those are the 2 items a) and b) in your doc. That means that other events are no longer there. I would remove bullet c) unless someone insists on keeping that.
Thanks
Laurent
From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Tuesday, January 7, 2025 7:53 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA
No update to doc 1762r14
I.e. 1762r14 remains the current version.
Responses to comments from Laurent,
1.
Laurent suggests deleting the following line of text, with the rationale that this text is not yet agreed to:
An NPCA AP may enable or disable the use of untriggered UL transmissions on the NPCA primary channel, by transmitting TBD frames
Yet, this text is nearly an identical match to the text of the passed motion 129.
Here is M129:
• TGbn defines a mode of operation in NPCA where the NPCA non-AP does not use untriggered UL transmissions on the NPCA primary channel
• This mode can be enabled/disabled by the AP
• Whether the mode is for all associated non-APs or per non-AP is TBD
• TBD whether MU EDCA parameters mechanism is used for this or not
[Motion #129, [1]]
2.
Laurent suggests deleting condition c) in the "conditions to initiate NPCA operation"
For review:
condition a) is primary channel BUSY due to reception of a OBSS PPDU that is not a control frame sequence
condition b) is primary channel BUSY due to reception of an OBSS PPDU that is a control frame sequence
condition c) is "primary channel BUSY due to TBD additional conditions"
again, this condition c) is based on a passed motion, M11:
• TGbn defines a mode of operation that enables a STA to access the secondary channel while the primary channel is known to be busy due to OBSS traffic or other TBD conditions.
• The mode of operation shall not assume that the STA is capable to detect or decode a frame and obtain NAV information of the secondary channel concurrently with the primary channel.
• A BSS shall only have a single NPCA primary channel (name TBD) on which the STA contends while the primary channel of the BSS is known to be busy due to OBSS traffic or other TBD conditions.
[Motion #11, [1]]
The passed motion yields the text of item c) ni 1762r14:
c) The primary channel is known to be busy and TBD conditions
This text is nearly a match for the passed motion text.
On Tue, Jan 7, 2025 at 5:43 AM Cariou, Laurent <laurent.cariou@xxxxxxxxx> wrote:
Hi Matt,
Some comments/modifications attached.
Thanks
Laurent
From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Friday, January 3, 2025 11:16 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] PDT-MAC-NPCA
Junbin,
In reviewing the motions that have passed, you can see that no frames have been specified, so the existing text is already a bit speculative, but it matches how things have been done for almost every amendment of 802.11, i.e. inclusion of CAP and OP IEs and placing those IEs within Assoc, etc frames.
The Probe Req and Probe Resp frames are similar in history.
Because of the speculative nature of the existing text (i.e. the inclusion of the information in the CAP and OP elements and then those within the frames), all of that text is effectively speculative, and hence, keeping a TBD in the text is a reminder that the exact finalized set of fields, elements and frames is yet to be agreed upon. So I would rather not remove the TBD.
As for the suggested modified text that you include, I believe that the existing language is almost identical to what you suggest.
I do not see any real differences except that you are adding the name of the element in which the fields are found, but this is unnecessary, as these fields only exist within those elements.
Interestingly, your AP text mentions the fields and the elements and the non-AP text only includes the fields.
Maybe there is a better approach, but now that we are so close to the JAN meeting, I'll wait to see what motions are passed that might clarify this and other issues within the PDT.
Thanks.
On Thu, Jan 2, 2025 at 7:35 PM 陈俊斌 <00003c9288e54ba2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi, Matthew:
Thanks for your contribution, and I have a few clarification questions on the PDT here:
In 37.10 of the PDT, there is:
An NPCA AP that has enabled NPCA operation shall include the NPCA Operation Information field in its UHR Operation element and indicate its NPCA switching delay and NPCA switch back delay respectively in the NPCA Switching Delay field and NPCA Switch Back Delay fields of the TBD frames. M124
I am a little bit confused about the “TBD frames“ here.
In 9.4.2.aaa and 9.4.2.aab of the PDT, the NPCA Switching Delay field and the NPCA Switching Back Delay field are included in the UHR Cap IE and UHR OP IE, which are included in the frames as listed in 9.3.3.x of this PDT;
Is here the aforementioned “TBD frame” suggests that, for an NPCA AP, the NPCA Switching Delay field and the NPCA Switching Back Delay field might be included in some field other than the UHR Cap IE and UHR OP IE? Or, the UHR Cap IE and /or UHR OP IE might be carried in some frames that is not listed in 9.3.3.x of this PDT?
As recorded in the open issue 1 and 7, I agree that the NPCA op info might appear in some frame which a non-AP STA transmits;
But since we are talking about the NPCA AP in the cited paragraph here, I am thinking that maybe we can make the aforementioned “TBD frames” more clear here, and leave the open issue about the indication of the NPCA parameters of non-AP STA in another paragraph?
For example, how about the following texts:
An NPCA AP that has enabled NPCA operation shall indicate its NPCA Switching Delay and NPCA Switch Back Delay respectively in the NPCA Switching Delay field and NPCA Switch Back Delay field, by including the NPCA Operation Information field in the UHR Operation element. M124
A non-AP NPCA STA that has enabled NPCA operation shall indicate its NPCA Switching Delay and NPCA Switch Back Delay respectively in the NPCA Switching Delay field and NPCA Switch Back Delay field via TBD frames. M124
Best Regards!
---------------------
Junbin Chen 陈俊斌
发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
发送时间: 2025年1月3日, 星期五 上午 03:21
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
1762r14 is available on the server:
https://mentor.ieee.org/802.11/dcn/24/11-24-1762-14-00bn-pdt-mac-npca.docx
Gaurang,
1.
Re the first paragraph of 37.x (which has been changed to 37.10 NPCA
Whether the last sentence should begin with an NPCA STA or a non-AP NPCA STA:
The current consensus is that the AP and non-AP have different methods for indicating their support for NPCA.
2.
your comment on whether or not NPCA information would be carried in beacons being an unsettled issue is not relevant to the cited paragraph
the cited paragraph only indicates that a bit should be set - it does not indicate which frame the bit is carried in
3.
other comments generally accepted
On Thu, Dec 19, 2024 at 9:59 PM Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> wrote:
Hi Matt,
Thanks for your work on this. I have a few comments in the attached.
Thanks,
Gaurang
From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Thursday, December 19, 2024 9:49 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
New and Improved! r13:
https://mentor.ieee.org/802.11/dcn/24/11-24-1762-13-00bn-pdt-mac-npca.docx
Re MIB (Li Quan):
I agree that having a default value does not make sense.
An item for TGmf is that in at least 23.x and 27.x there are PHY MIB tables with many XxxxOptionImplemented variables with default values.
Re (Haorui):
In 37.x, within 1762r13, removed redundant phrase "and the channel occupied by the received PPDU(s)"
On Thu, Dec 19, 2024 at 7:00 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
It makes no sense for a capability variable to have a default.
A STA is either capable or not capable.
Also, it should be "STA" not "station", I think.
[Also, I always forget about the current preference re
dot11FooImplemented v dot11FooEnabled.]
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Li Quan <quan.li@xxxxxxxxxx>
Sent: Thursday, 19 December 2024 14:30
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
Hello Matthew and all,
Thank you for updating the PDT.
Recently, I have been revising the MIB and would like to ask your opinion.
Below is the MIB I drafted for NPCA. Would you prefer to use this version or do you have any suggestions for modifications?
dot11NPCAOptionImplemented OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a capability variable.
Its value is determined by device capabilities.
This attribute, when true, indicates that the station implementation is
capable of supporting NPCA operation."
DEFVAL { false }
::= { TBD }
BR，
Li Quan
Original
From: MatthewFischer <matthew.fischer@xxxxxxxxx>
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;
Date: 2024年12月19日 07:10
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-NPCA
r12 is now on the server:
https://mentor.ieee.org/802.11/dcn/24/11-24-1762-12-00bn-pdt-mac-npca.docx
John Wullert,
Generally agree with both of your comments, r12 includes changes that generally follow the spirit of those comments.
Haorui,
1. - agree, changed to multiple BSS in r12
2. the commas in the cited item in r11 are in the correct locations
note that as long as conjunctions are used, no comma should appear as those conjunctions are adding/modifying the single, albeit long, qualifying phrase
i.e. the entire phrase beginning with "identified" and ending with "received PPDU(s)" is a single qualifying phrase referring to the subject "channel" that appears at the very beginning
the predicate for channel is "does not overlap", making everything in between is a single qualifying phrase, which must be set aside by commas
so the structure of the sentence is:
the channel, identified by some means, does not overlap something
"identified by some means" is then expanded into that big long multiply-qualifying phrase
the commas serve to separate the qualifier from the subject and the predicate
this is because the natural English order is:
adjectival phrase subject predicate object
In the cited sentence, when the order of adjectival phrase and subject is reversed, commas are used to separate the adjectival phrase
subject, adjectival phrase, predicate object
3. agree, removed "/or"
NOTE - this email has been truncated by removing quoted text from previous emails.
If you want to view the previous emails, please refer to earlier emails in the thread.
On Tue, Dec 17, 2024 at 11:01 PM Haorui Yang(Rae) <yanghaorui0217@xxxxxxx> wrote:
Hi Math,
Thanks for your efforts on updating the draft over and over.
I have the below comments further:
1. MBSS in baseline = mesh BSS so in this PDT the MBSS should be changed to multiple BSS set, or other better wording;
2. for b)-c, the highlighted comma seems in a wrong place. Maybe it should be after "CH_BANDWIDTH_IN_NON_HT of the received PPDU(s)";
"c.the 20/40/80/160 MHz channel occupied by the received PPDU(s), identified by the STA based on the channel allocations in the corresponding band and the PPDU bandwidth that is signaled in the received PPDU(s) or obtained from the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the received PPDU(s) and the channel occupied by the received PPDU(s), does not overlap with the NPCA primary channel"
3. based on Motion #164, only receiving the CTS without RTS cannot trigger NPCA switch, but in current bullet b) "and/or" means 3 possible cases including the case where only the response frame is received, which seems against the Motion.
b)the STA received a PPDU containing a Control frame and/or a PPDU containing a initial response frame of a Control frame exchange on the BSS primary channel and all of the following conditions apply:
BRs,
Haorui Yang(Rae)
China Mobile
--
--Matthew Fischer
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
--
Matthew Fischer
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
--
Matthew Fischer
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
--
Matthew Fischer
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
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: 90-92 route de la Reine, 92100 Boulogne, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 EurosThis e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
Matthew Fischer
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
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: 90-92 route de la Reine, 92100 Boulogne, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 EurosThis e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
Matthew Fischer
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
--
Matthew Fischer
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
--Liangxiao XinOPPO
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
--Matthew Fischer
