Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

Matt,

 

  Please find inline some clarifications.

 

 

From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 28, 2025 12:29 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

 

Salvatore,

 

On Mon, Jul 28, 2025 at 3:03 AM Salvatore Talarico (Nokia) <0000391239bb5db0-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Matt,

 

Please find inline some further comments from my side.

 

  Many thanks,

       -Salvatore (Nokia)

 

Salvatore,

 

1) 

what is the technical reason to substract the largest between switch back delays of the STA and its intended recipients. 

This would also lead to effectively have STAs returning to primary channel at different times if bullet 1 of section 37.10.3 is kept, which may cause medium sync issues.

Several people have suggested that differing switch back times will cause medium sync problems on the BSS primary channel.

This should not be the case:

 

Regardless of when any STA switches back, there should never be a channel sync problem because every STA that switched did so based on received OBSS information

which is nominally the same information. In such a case, each STA can switch back at different times so long as all STAs switch back BEFORE the end of the OBSS occupancy.

So long as this is true, all returnees will only be able to sit and wait for the end of the OBSS busy time.

If you return earlier, it does not matter, because you are just going to sit and wait.

 

[ST] I agree, but the assumption here is that STA will receive same OBSS information, which is not always the case. Also on top of medium sync issue, my understanding is that by letting a STA switch earlier there would be a less efficient use of the resources as STAs that switch earlier would be able to neither transmit or receive anything on the primary, while they could have stayed longer on the NPCA primary channel and perhaps continue communication.

 

Assuming that two STAs receive different OBSS information to invoke NPCA, then the switch back delay is not the thing that is causing them to return to the main channel out of sync.

It is the OBSS information that they received which causes this mis-sync.

But I could argue that this is not a mis-sync anyway, because, for a STA that has different OBSS information, that information is still valid and still prevents the STA from using the main channel.

 

[ST] Understood – One question: the STAs that switching back to the primary channel while there is still an OBSS will maintain the NAV information, and this won’t be reset even if they switch earlier?  

 

 

One might propose that if the AP switches, then all STAs should switch, since for STAs that remain on the main channel, communication with the AP will not be possible.

The opposite is not true.

That is, if a STA switches but the AP does not, then there is little that can be done or that should be done.

This is more of a switch or not switch, not a difference in detected OBSS durations.

Such a proposal is problematic because the AP has detected an OBSS BUSY and is not supposed to transmit, so how can it communicate the switch information to the STAs?

 

[ST] Agree that if AP switches back, then all STAs should also do so. However, my comment was for the case when the AP does not switch back because its switch back is shorter. In this case, the AP could still serve those STAs with similar switch back delay, while the STAs with higher switch back can start return to the primary channel.  

 

 

None of this seems to be related to the switch back delay or switch back rules.

So I remain confused about exactly what you are looking for here.

 

 

 

 

The idea behind the subtraction of other STA switch back time has to do with the STA being able to communicate with other STAs on the NPCA channel.

If STAx is operating on NPCA and is switching back at time Tx, then STAy should stop transmitting to STAx before time Tx, otherwise, STAx will be gone and not receive the transmission.

 

Now, several people have objected to the very conservative statement that is found in the draft.

I.e. the most conservative approach is for every STA to jump back, or at least, stop transmitting, before the earliest STA switches back.

But yes, there are a couple of problems:

1) only the AP knows what all of the switch back times are

2) even if you give all STAs all of the switch back times you suffer from:

a) everyone is forced to waste some time, based on the worst performing STA in the BSS

b) the slowest switch back STAs might not even be participating, so you are uselessly wasting valuable time

c) even if the slowest switching STA is on NPCA, you might not be transmitting to that STA

 

A less conservative approach is to let each implementation switch back whenever it has advertised to switch back.

I'll change it to this for now.

 

[ST] Just as clarification,  would this mean that switch back would only be dependent on the STA’s own switch back delay? Or are you having in mind any other change? 

 

Yes.

NPCA_TIMER being adjusted by the STA's own switch back is, I believe, the most basic rule.

It achieves the basic goal of maximizing the time spent on the NPCA channel.

 

[ST] Thanks for the change.

 

 

2)

Regarding switch back when NPCA_TIMER reaches zero.

 

You said:

I understand the intention, I would suggest to remove this bullet as the switching back procedure has not been widely agreed, and no related motions have passed, and this could be discussed as a second level detail after D1.0. In this matter, there are many members that have raised comments in the current ballot to solve this issue.

If this bullet is removed, then the STA never switches back!

This is the MOST BASIC, least controversial statement in this document!

I.e. when the OBSS time on the main channel has expired, you MUST return!

This is implicitly agreed by the entire group.

If anyone on the reflector thinks that the STA can stay longer than this, I'd like to hear them expose themselves....

[ST] The rule per se as a baseline is OK, and reasonable, and I understand that conditions could be always added on top if the group is able to converge upon it, but what is not OK to me is the way how the timer is set, which links to the discussion above.

 

I see, because of the value chosen for NPCA_TIMER, you want to also remove the statement that says to switch back when the NPCA_TIMER reaches zero.

I believe that removing the NPCA_TIMER reaches zero statement is the wrong approach.

The correct approach is to agree on the value of the timer.

The statement to return remains.

 

[ST]  With the changes you have made or intend to make on how to set the value of the timer I am OK with keeping the sentence as is. Thanks.

 

 

Unfortunately, in the way this is written this bullet sets a precedent in the spec that switching back can only occur based on a timer which is set based on worse case individual assessment of the OBSS’s PPDU and TxOP, under the assumption that there is no asymmetric view across devices and without accounting for early termination from OBSS. 

?????

There is NOTHING in this statement that prevents the addition of a statement that says:

If a STA encounters condition XYZ, then the STA may switch back to the main channel (i.e. earlier than NPCA_TIMER expiry).

I.e. additional conditions can be added which are effectively logically OR conditions.

 

 

 

On Mon, Jul 28, 2025 at 12:41 AM Salvatore Talarico (Nokia) <salvatore.talarico@xxxxxxxxx> wrote:

Hi Matt,

 

  Please find embedded in the attachment a few comments from my side as well.

 

   Many thanks,

       -Salvatore (Nokia)

 

 

 

From: Kaiying Lu <000019325336b823-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, July 25, 2025 12:21 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

 

 

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 Matt,

 

Please see my comments attached.

 

Thanks,

Kaiying

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Friday, July 25, 2025 12:44 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

 

External email : Please do not click links or open attachments until you have verified the sender or the content.

 

See r11.

 

On Fri, Jul 25, 2025 at 12:40 AM Morteza Mehrnoush <morteza.80211@xxxxxxxxx> wrote:

Hi Matt,

 

Based on the discussion in ELR doc (11-25/915), the ELR PPDU can be only sent on primary 20MHz.

Could you please remove the highlighted text below from the NPCA doc?

 

UHR ELR PPDUs, HE ER SU PPDUs, EHT MCS14/15 shall not be transmitted on the NPCA primary channel except for a UHR ELR PPDU that contains a control response frame (see 37.4.2 (Enhanced long range (ELR))).  

 

Thanks,

Morteza

 

On Fri, Jul 25, 2025 at 10:32 AM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:

 

Shawn,

 

 

 

 

 

 

On Thu, Jul 24, 2025 at 1:40 AM Shawn Kim <shawn.kim@xxxxxxxxxxxxxx> wrote:

Dear Matthew,

 

Thank you for updating the document.

 

I have one clarification question and one comment regarding r10. 

 

(p.48)

The MAC variable NPCA_PPDU_REM_DUR derived from a received PPDU is equal to the value in usec, of the remaining duration of the received PPDU, determined by the MAC at the time of the receipt of the PHY-RXSTART.indication primitive associated with the received PPDU, by subtracting the time elapsed between the reception of the PHY-CCA.indication(BUSY) and PHY-RXSTART.indication primitives associated with the received PPDU from the value of RXTIME of the received PPDU. (#1056)

 

(Shawn) I'd like to confirm my understanding about RXTIME corresponding to the received HE/EHT PPDUs.
As I understand it, calculating RXTIME requires the LENGTH field value from the L-SIG and the signal extension length of the PPDU.
However, it appears that the RXVECTOR for HE/EHT PPDUs does not include the necessary parameters for RXTIME calculation.
Is it assumed that the PHY is expected to provide the RXTIME to the MAC via the RXVECTOR, or is the MAC calculate RXTIME by itself?

 

I believe that you are suggesting the following:

1) the proposed text includes the need for the value of RXTIME 

2) the RXTIME value is calculated for a PPDU by using some values that come from the RXVECTOR received as part of the PHY-RXSTART.indication of the received PPDU, in particular, the value of LENGTH from the L_SIG field

3) the RXVECTOR parameter LENGTH, corresponding to the LEN value from the L_SIG field is not present in the RXVECTOR for an HT PPDU reception

 

I believe that you are basing this understanding on your reading of the HE TXVECTOR and RXVECTOR parameters sublcause.

 

I believe that your reading of the standard is incorrect/incomplete.

 

First, the "problem" that you are highlighting, i.e. of not being able to calculate RXTIME from the HE RXVECTOR, if correct, would be a problem that exists in general for RXTIME.

I.e., what you are pointing to is not something that document 936 or the NPCA subclause is creating or introducing

The equation for RXTIME has existed in the standard for a long time. NPCA is just referring to that equation.

 

But I do not think that there is a problem anyway:

 

If you read the RXVECTOR description for HE, you see this:

 

27.2 HE PHY service interface

27.2.2 TXVECTOR and RXVECTOR parameters

Table 27-1—TXVECTOR and RXVECTOR parameters

 

Parameter:

L_LENGTH

 

Condition:

FORMAT is HE_SU, HE_MU, or HE_ER_SU

 

RXVECTOR column:

N

 

So, it seems like there is no Legacy LEN Value returned in the RXVECTOR for an HE PPDU.

But I believe that this simple reading of the standard is incorrect.

 

See:

 

8.3.4.4 Vector descriptions

 

The HE PHY TXVECTOR and RXVECTOR contain additional parameters related to the HE PHY modes
of operation as described in 27.2 (HE PHY service interface). 

 

Because of the use of the word "addiitonal" in the text cited above, I believe that the TXVECTOR and RXVECTOR descriptions for HT, VHT, HE, UHR, are all additive to the existing TXVECTOR and RXVECTOR descriptions. In other words, I believe that the RXVECTOR that is included for an HE PPDU includes the RXVECTOR tables from all of the preceding RXVECTOR tables in previous subclauses.

 

Going back to:

 

27.2.2 TXVECTOR and RXVECTOR parameters

 

The parameters in Table 27-1 (TXVECTOR and RXVECTOR parameters) are defined as part of the
TXVECTOR parameter list in the PHY-TXSTART.request primitive and/or as part of the RXVECTOR
parameter list in the PHY-RXSTART.indication and PHY-RXEND.indication primitives.

 

We see additional support for my conjecture, based on the inclusion of the phrase "part of the RXVECTOR parameter list..."

I.e. the HE RXVECTOR parameter list in clause 27 is only PART of the total RXVECTOR.

The complete RXVECTOR will include a legacy LENGTH value.

 

Going back to my earlier statement - even if my interpretation is incorrect and there is no legacy LENGTH value included in the RXVECTOR for an HE PPDU, then, per your interpretation there is some larger problem in the baseline standard which was not created by document 936 because the HE clause 27 RXTIME equation includes the use of the legacy LENGTH value and therefore, it would have the problem that you think exists. (And the same problem would exist for HT, VHT, TVHT, etc.)

 

I don't think that is the case, but I do agree that the description that does exist is a bit tricky and maybe could be done better.

If that is an objective, then any attempt to improve this aspect of the baseline would need to be done within TGmf.

 

 

 

(p.47)

c)      An indication that a valid TXOP was obtained on the BSS primary channel, as verified by the receipt of a PHY-RXEARLYSIG.indication or PHYRXSTART.indication primitive corresponding to the third PPDU that occurs during a time window that:

i)      has a duration that is equal to NPCA_START_TIMEOUT which is (2 x aSIFSTime) + (2 x aSlotTime) + aRxPHYStartDelay + ICR_Timeout, where ICR_Timeout is equal to:

(1)    The length (in usec) of the expected CTS if the initial Control frame is an RTS or an MU-RTS Trigger frame

(2)    The value of the UL Length field of the Common Info field of the BSRP Trigger frame if the initial Control frame is a BSRP Trigger frame

ii)    begins when the MAC receives a PHY-RXEND.indication primitive corresponding to the first PPDU PHY-RXEARLYSIG.indication or PHYRXSTART.indication primitive is received from the PHY during a NAVTimeout period starting when the MAC receives a PHY-RXEND.indication primitive corresponding to the detection of the  , indicating that a valid TOP was obtained on the BSS primary channel (#2146) (#2433) (#2649)

 

(Shawn) Item c) seems to define a time window for determining whether a 3rd PPDU is being transmitted.

My concern is that, as per sub-item ii), the time window begins right after the end of the 1st PPDU. In this case, the 2nd PPDU (i.e., the initial control response frame) could be misclassified as the 3rd PPDU, since the PHYRXSTART.indication of the 2nd PPDU would occur within the time window.

Additionally, there is a possibility that a PPDU received within this window may be transmitted by a third-party STA. 

Therefore, it may be preferable to define a more precise time window that better aligns with the expected start time of the 3rd PPDU.

 

Agreed, see r11.

 

 

 

Best regards,

Shawn

 

 

2025년 7월 24일 (목) 오후 4:29, Matthew Fischer <matthew.fischer@xxxxxxxxx>님이 작성:

 

Yongho,

 

 

 

On Wed, Jul 23, 2025 at 8:10 PM Yongho Seok <yongho.seok@xxxxxxxxx> wrote:

Hi Matt, 

 

a)      The bandwidth of the PPDU is determined by the STA to be 20, 40, 80 or 160 MHzthe 20/40/80/160 MHz channel occupied by the PPDU is identified by the STA, (#3045) (#3046)based on the Bandwidth field in the PHY preamble of the PPDU and the channel allocations in the corresponding band indicated in the RXVECTOR parameter RU_ALLOCATION of the PHY-RXSTART.indication associated with the PPDU, if present (#421), and the channel occupied by the PPDU does not overlap with the NPCA primary channel (#1236)

Since the 320 MHz channel uses overlapping channelization, when a UHR BSS operates on 320 MHz-2 (e.g., channel center frequency numbered 63) and an NPCA STA receives an OBSS PPDU with the Bandwidth field set to 4 (320 MHz-1), the NPCA STA can use NPCA because the received OBSS PPDU does not overlap with the NPCA primary channel. Is there any reason this case is excluded? Otherwise, 320 MHz should be listed. 

The same comment applies to 2-f.

 

I agree that this disjoint 320 MHz case could work, except:

Is there anything in the received OBSS 320 MHz PPDU that allows a STA to determine which 160 MHz subchannels are occupied by the 320 MHz OBSS PPDU?

I.e. while the case that you describe seems reasonable, will the NPCA STA be able to correctly identify the specific subchannel occupancy of the 320 MHz OBSS PPDU?

If you can direct me to the PHY HEADER information that will definitively provide the specifics of the occupied channels of the 320 PPDU to the NPCA STA, then I can add that as a rule to use.

Otherwise, it will not work.

 

 

5)      The STA shall begin all frame exchanges on the NPCA primary channel with an NPCA  (#3056) ICF using non-HT PPDU or non-HT duplicate PPDU format using a rate of 6 Mb/s, 12 Mb/s, or 24 Mb/s.

a)      Details on the NPCA ICF are TBDFor TXOPs initiated by an AP, the initial Control frame (ICF) shall be a BSRP Trigger frame or an MU-RTS Trigger frame except when at least one of the target non-AP STA(s) is operating in the DUO mode, in which case, the ICF) may be a BSRP Trigger frame or a BSRP NTB Trigger frame but not an MU-RTS. In addition: (#1063) (#1225) (#1515) (#2371)

i)       The ICF shall conform to the rules in 37.11.2 (Dynamic Unavailability Operation (DUO) mode) if at least one of the target non-AP STA(s) is operating in DUO mode. (#1063) (#2371)

ii)     The ICF shall conform to the rules in 37.13 (Enhanced multi-link single-radio (EMLSR) operation for a UHR non-AP MLD) if at least one of the target non-AP STA(s) is affiliated with a non-AP MLD that is operating in EMLSR mode. (#1063) (#2371)

iii)    The ICF shall conform to the rules in 37.9.1 (Dynamic power save (DPS) operation) if at least one of the target non-AP STA(s) is operating in DPS mode. (#1063) (#2371)

Clarification question: 

Even though the DPS non-AP STA establishes the parameterized LC mode, does it mean that the NPCA AP shall use the default LC mode on the NPCA primary channel? The phrase “conform to the rules” does not necessarily imply that the rule is overriding. In the first main bullet, you state that the ICF shall be sent using the default LC mode.

 

The first bullet is a generic requirement for sending ICF/ICR during NPCA in order to increase the probability that other devices that may be present on the NPCA channel will hear the NPCA TXOP.

By also mandating non-HT 6, 12, 24, the odds of other devices receiving MAC information to protect the NPCA TXOP is further increased.

The fact that such a requirement also helps the operation of several reduced capability modes is an additional benefit but not necessarily the initial motivation for the requirement.

Nothing in the first bullet contradicts the rules in 37.15.1 DPS - you might argue that if a DPS STA is in HC mode, then there is no need for ICF/ICR and the rule here requiring the ICF/ICR is therefore somehow an override of the DPS rules - but that is not true - the DPS rules do NOT disallow the use of 6 mbps ICF/ICR during HC mode. Using such might be less efficient, but it is not forbidden.

 

I.e. Mandating the use of ICF/ICR during NPCA is not the same as mandating the use of LC mode during NPCA!

 

 

 

a)      For TXOPs initiated by a non-AP STA, if the intended recipient STA is a mobile AP operating in the DPS mode, the ICF shall conform to the rules found in 37.9.1 (Dynamic power save (DPS) operation). (#1063) (#2371)

I think we need further analysis on whether the mobile AP can use the NPCA. Currently, the spec does not state anything explicitly, but the current wording could be interpreted to mean that the mobile AP is allowed to use the NPCA. I would suggest removing this sentence until we have completed a more thorough analysis. 

 

Due to ongoing discussion on this item, I will not change it for now.

 

 

 

 

Thanks, 

Yongho 

 

2025년 7월 23일 (수) 오전 4:39, Matthew Fischer <matthew.fischer@xxxxxxxxx>님이 작성:

 

Morteza,

 

Draft not ready yet, pending review of additional reviews...

 

1) added a line for the 80 MHz BSS case regarding NPCA channel placement, per your comment

 

2) and vs or regarding BW of OBSS PPDU - discussing this paragraph with other reviewers - not settled on a change yet

 

3) initial Control response

I was not certain if the response is always a control frame, but I guess it is

 

4) request to merge conditions a) and b) of condition 2)

the conditions are distinct - note that condition a) requires a sequence to be identified and condition b) describes the parts of the sequence that must be identified

While it might be possible to merge them, there is no value in merging them - it would just be an exercise in attempting to create accurate text

 

5) UL length field of the BSRP frame - 

added NTB case

 

6) BW of OBSS determination

The language here is being reviewed by multiple people

I have a tentative change that I think solves your problem

It identifies the BW of interest as only extracted from the first frame, and in that case, even though RTS is explicitly called out in the sub bullet, this does not mean that BSRP, for example is ignored

I.e. anything that is not explicitly named in the sub bullets is already covered by the generic statement of the main bullet, so BSRP is already covered

 

7) indentation

if you switch to simple markup I believe that the indentation is correct

if it is not, then it is probably because of a formatting problem that I am unable to correct and will leave to the TGbn editor

 

8) existing values of the variables

I think that the phrase is straightforward

if you look at the existing baseline EDCA, it mentions these variables, and clearly, they are dynamic.

IF it helps, I can change "existing" to "current"

 

9) received INIT_QSRC value - 

added transmitted, as per comment

 

10) ICF for NPCA by non-AP STA

merged your comments with those from others

 

11) switch back time

yes - trying to get agreement among various people

Will add at least a minimal statement that a STA switches back when NPCA_TIMER expires

A lot of people have a lot of opinions about the exact nature and conditions for the switch back, but that base statement should at least exist

 

 

 

 

 

On Thu, Jul 17, 2025 at 5:48 PM Morteza Mehrnoush <morteza.80211@xxxxxxxxx> wrote:

Hi Matt,

 

Thank you for preparing the new revisions. Attached please find some comments on r8.

 

Thanks,

Morteza

 

On Wed, Jul 2, 2025 at 6:19 PM 顾祥新 (Xiangxin Gu) <000046f9987a2d10-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Matt,

 

Thanks for the clear answer. I’d like to respect the group’s selection.

 

BTW, the method captured in the PDT is not align with the motion:

•         The NPCA operation shall use the same EDCA parameters ((MU) EDCA Parameter Set, EPCS EDCA Parameters), on both the BSS primary channel and the NPCA primary channel.

[Motion #145, [1] and [203, 195]]

 

BR,

 

Xiangxin Gu

Institute of Communication Technology

unisoc-signature

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Tuesday, July 1, 2025 7:55 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

 

 

Xiangxin,

 

You have correctly raised this question on the reflector so that the question is actually addressed to the entire TGbn and not just to me.

 

The current mechanism is the result of previous discussions which to the best of my recollection, included a proposal such as yours.

 

 

 

On Sun, Jun 22, 2025 at 10:50 PM 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx> wrote:

Hi Matt,

 

Thanks for the excellent job on NPCA PDT.

 

During the last Thu. teleconference, many members asked questions on the mode of the non-AP STA not using untriggered UL transmission on NPCA channel by setting NPCA AIFSN to 0.

To my understanding, it is hard for the AP to make the non-AP STA not EDCA NPCA channel by this way.

Firstly, the AP has to keep triggering UL transmission to the non-AP STA to keep the corresponding MUEDCATimer not expired.

Secondly, the situation becomes more sophisticated in case that EDCA BSS channel is allowed for the non-AP STA.

 

Why not just use a single bit in the signaling to indicate the mode, which is easier for the AP implementation and also clearer for reading ?

 

BR,

 

Xiangxin Gu

Institute of Communication Technology

unisoc-signature

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: Thursday, June 19, 2025 11:05 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] PDT MAC NPCA document 11-25-936 updated to r7

 


In response to various comments received, a new revision is available.

 

 

 

 

--

Matthew Fischer

Broadcom

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

This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does not accept liability for any errors or omissions.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、 使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。


 

--

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


 

--

Sanghyun Kim, Ph.D 
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea 
T +82 31 712 0523
www.wilusgroup.com

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

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

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