Thanks so much for your discussions and detailed derivations, and some comments and clarification questions are listed below. Please review them. Thanks.
Maybe it’s more efficient to have a F2F discussion in the next TGaz meetingJ
1.
The derivation of
1.2 Detection and EVM is usually used for evaluation of receiver performance of data frames and the derivation in
1.1 channel estimation is of more interest to the ranging performance evaluation, since in NDP frame there is no data payload and the SNR of the channel estimation directly relates with ToA estimation accuracy.
2.
Using the equation in
1.1 channel estimation, if we use abs(Hk)^2/(abs(Ak)^2+
abs(Bk)^2) as SNR definition per subcarrier, we can observe that when L=1, the SNR value
is 3dB higher than L=2, but since L=2 gives two independent channel estimation for 2 Tx antennas, and this Tx diversity is expected to provide additional 3dB gain, and finally L=1 and L=2 is expected to have similar or same ranging performance. Please note
when L=1, the Hk is boosted by 3dB due to unintentional beamforming.
3.
In the second line of the equation in
1.1 channel estimation, the “l=1” may be “n=1”?
4.
In the denominator of equation (1), according to the definition of Tx EVM in 11ax, why not use the average constellation power of Xk
instead of Yk? Also, in the numerator why is there a sum over subcarrier k, but in the
denominator there is no sum over k? The variable Qk
includes a deterministic component Vk and why assume Qk
has zero mean?
5.
Below equation (1), in the equation deriving average power of Ak,
the denominator may be “L” instead of “LEs”, since Sk
has unit power and Es
is the average power of Yk.
6.
Do equations (2) and (3) have special requirement for mean and variance of Z? When assume Z is a complex Gaussian variable with zero mean and variance
0.2, a numerical test shows that equation (2) and (3) are not equal.
7.
Please double check equation (4), and the left side and right side are not equal.
8.
In the last equation for EVM, in the first line there is a sum over k, but in the second line of this equation, there is no sum over the power of Bk.
Please double check.
9.
In the plot, what values are used for EVMstat
and EVMdet?
Does the Y axis indicate the 1/SNR? Why does the SNR decrease with increase of power Pout?
Best regards,
Feng Jiang
From: Rethna Pulikkoonattu [mailto:rethnakaran.pulikkoonattu@xxxxxxxxxxxx]
Sent: Monday, October 21, 2019 11:14 AM
To: Jiang, Feng1 <feng1.jiang@xxxxxxxxx>
Cc: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx; Christian Berger <crberger@xxxxxxxxxxx>; Li, Qinghua <qinghua.li@xxxxxxxxx>; Segev, Jonathan <jonathan.segev@xxxxxxxxx>
Subject: Re: [STDS-802-11-TGAZ] IEEE submission 11-19/1572r4
Hi Feng,
Thanks for the mail. A few comments. Itemized the same order.
1. Firstly, the channel estimation loss is not as trivial as you summarized. It depends on what regime we look at. The point of interest (if you are looking at the worst possible loss and best possible SNR) is usually dominated by Phase
noise (from my experience). There are a lot of details here, we will have to touch to do justice to the problem.We can do this face to face. Let me try to scrub a little here. The gist of the problem is whether we lose performance loss at all, if we are to
lose half of the preamble/LTF. The answer is yes. Here is a short summary scribe, if you are really looking to chase down that gap. A plot of simulation is attached in the end. You can trust me, I had scrubbed this to its bran on both product as well as
theory:-)
That said, channel estimation error is least of my concern, regarding this problem. I am more concerned about the spec, placing a hole and in a way leaving potential products to make use of this and instead have to look elsewhere for similar
solutions (Remember, there are competing standards elsewhere).
2. We are imposing a lot of assumptions here, how a product should be etc. First of all, the PAPR of Golay sequence is 2, which is 3 in dB scale. The PAPR of the payload is free to be tinkered, as long as one can meet the product design
goals. For example, there are schemes to reduce the PAPR for low MCS. The point is that, for ranging needs, there could be future products, which can be worked with 3 or 4dB PAPR. By imposing a design requirement of 6dB headroom, is detrimental to some markets.
IMO, we should leave that option open. I do agree that, it is possible to design a good margin solution, but that comes at unnecessary cost, which is effectively shunting that option.
3. Aha, this is exactly the point. If we repeat, we solve the problem, but then the memory requirement is 50% more than the proposal. In anycase, the memory scales with P, which is 7 or less than 10 cells (not even KB), which in memory
units, is epsilon big.
Here is the snapshot of the theoretical justification, if you will. The main thing here is how L is related to SNR, through channel estimation error.
Regards,
Rethna.
On Thu, Oct 17, 2019 at 4:55 PM Jiang, Feng1 <feng1.jiang@xxxxxxxxx> wrote:
Thanks for your detailed responseJ Some further discussions are listed below:
1. For the channel estimation with L=2, assume the received signal during two HE-LTF symbols are y1=h1+h2+n1, and y2=-h1+h2+n2, then the channel estimation for h2 is (y1+y2)/2=h2+(n1+n2)/2, and further assume h1=h2 (unintentional beamforming case), then y1=2*h2+n1 and y2=n2, then if we still use equation (y1+y2)/2 for estimating h2, we still gets h2+(n1+n2)/2. It’s still not clear why there is a 1.25dB loss for estimation of h2 and we can have more discussions in the next meeting.
2. For low end device the ADC may have less bits and also low end device is expected to support smaller Nsts and bandwidth, for example, Nsts=2. Please note that for the 20MHz band, the PAPR of the L-STF and HE-STF are around 2dB, and the PAPR of a data frame with MCS0 is around 8dB (90% CDF), and this means the ADC should allow at least 6dB headroom to receive MCS0 in secured NDP frame ((L-SIG and HE-SIG-A)) and location measurement report (LMR) frame. This 6dB headroom should be good enough to cover the worst case 3dB power boost for secured HE-LTF with Nsts=2. Also, on top of this, there is additional 3dB gain from repeated HE-LTF in secured NDP. This repetition is not a waste of resource and it’s a mandatory requirement for secured NDP to provide security protection.
3. The proposed new design in 1572r4 approximately doubled the memory size at transmitter and receiver sides for random LTF sequence generation, added additional phase rotations in frequency domain at transmitter and receiver sides for channel estimation, and changed the random bits generation format for some random LTF sequence from 4P+3bits to 3P+3 bits. It will require a lot of changes. Now it’s still not clear how much the unintentional beamforming will hurt the ranging performance and it’s worth for the interested parties to further investigate more details. As mentioned earlier, if there is not much ranging performance degradation, it’s better to keep the current secured NDP design for implementation simplicity. Thanks.
Best regards,
Feng Jiang
From: Rethna Pulikkoonattu [mailto:rethnakaran.pulikkoonattu@xxxxxxxxxxxx]
Sent: Thursday, October 17, 2019 9:01 AM
To: Jiang, Feng1 <feng1.jiang@xxxxxxxxx>
Cc: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx; Christian Berger <crberger@xxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGAZ] IEEE submission 11-19/1572r4
Thank you all for joining in the call and discussions.
Hi Feng,
Thanks for the mail and comments.
1. This is easy to simulate. The max theoretical loss in SNR (i.e., the loss, compared to that of perfectly known channel) can also be quantified to \sqrt(1+1/L) where the L the length of the LTF. The default here is L=2. The scenario in discussion is when half of that is nulled out due to destructive interference. This effectively becomes a loss of 20*log10(sqrt(1+1/1))-20*log10(sqrt(1+1/2)) ~ 1.25dB. I guess this is a well known result. If you wish, I can send you small write up, or we can discuss this at Hawaii. We didn’t quantify the ranging performance per se here, but as you know, it will get hurt. The larger worry is on the receiver dynamic range requirements, which we believe is an important thing to get fixed.
2. Yes, it is true that, we can get back the lost gain in channel estimation, by repeated HE-LTF, but this is simply a round about way of wasting resources, by not addressing the problem which can be easily solved in the first place. On the other hand, with repeated LTF option in place, we can enhance the performance even further, if we resolve the nulling problem. As you can see, the fix on the table is much easier!
3. Thanks. Yes, Shall fix this.
Anyway the moot point is: Should we leave a hole in the spec, which in turn necessitate over designing the receiver? In principle, yes, we can budget a lot more head room (e.g., ADC requirements as Christian mentioned) and circumvent this by employing expensive solutions. IMO, it is not a good idea to limit potential future products, which can otherwise be designed economically. A car key fob is a great example. It may not be a viable option on such product line to have a 12 bit ADC. May be we can even make it work with 8 bit or even 6 bit ADC, depending on the market it cater to.
We can as well fix this right now by addressing the problem, instead of unnecessarily burdening the receiver. And a great side benefit is that, we make the ranging even more more secure:-)
Regards,
Rethna.
On Wed, Oct 16, 2019 at 8:46 PM Jiang, Feng1 <feng1.jiang@xxxxxxxxx> wrote:
Hi Christian,
Do you mean it’s not practical to further tune the AGC gain based on the fading information obtained from L-LTF? What is the limitation for processing delay and timing?
Also for the less bits ADC, how many bits do you assume? How much the SNR/ranging accuracy will be lost for such a less bit ADC? Thanks.
Best regards,
Feng Jiang
From: Christian Berger [mailto:crberger@xxxxxxxxxxx]
Sent: Wednesday, October 16, 2019 6:41 PM
To: Jiang, Feng1 <feng1.jiang@xxxxxxxxx>; STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Cc: Li, Qinghua <qinghua.li@xxxxxxxxx>; Segev, Jonathan <jonathan.segev@xxxxxxxxx>
Subject: RE: IEEE submission 11-19/1572r4
Estimating the channel on the legacy-LTF and adjusting the ADC setting on the HE preamble accordingly is unfortunately not practical at all, if you are familiar with processing delays and timing.
Furthermore receiving 1024 QAM is not necessarily a standard feature available on all devices that might provide secure ranging, like a car key fob. Same devices will potentially have a lower performance (less bits) ADC. With such design choices, we are potentially precluding a lot of devices from using secure ranging or alternatively providing such poor receiver SNR that will not make the next generation of ranging accuracy possible.
Christian
From: Jiang, Feng1 <feng1.jiang@xxxxxxxxx>
Sent: Wednesday, October 16, 2019 5:29 PM
To: Christian Berger <crberger@xxxxxxxxxxx>; STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Cc: Li, Qinghua <qinghua.li@xxxxxxxxx>; Segev, Jonathan <jonathan.segev@xxxxxxxxx>
Subject: [EXT] RE: IEEE submission 11-19/1572r4
External Email
Hi Christian,
Thanks for your comments. In the ADC dynamic range design some margin need to be allowed to cover the PAPR of the received signal. For example, for 1024QAM the PAPR can be up to 10dB, and if the data packet can be received successfully with no saturation, then using the same AGC setting, the secured NDP frame should also be received correctly with no saturation. Additionally, the PAPR of the secured NDP frame is already optimized by several dB and this will be helpful for relaxing the dynamic range of ADC.
It seems not true that “The channel conditions will *not* be known a priori,” since the legacy preamble in the L-LTF field of NDPA or secured NDP frame can indicate whether it’s heavy fading or AWGN.
As shown in the submission 11-19/1572r4, the max SNR degradation of channel estimation due to this unintentional beamforming is 1.2494dB, and it may not hurt ranging performance too much. Unless we see significant ranging performance degradation, it’s better to keep the current secured NDP design unchanged for simplicity.
Best regards,
Feng Jiang
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Christian Berger
Sent: Wednesday, October 16, 2019 5:02 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] IEEE submission 11-19/1572r4
Hi Feng,
There was a claim in the discussion today that the increased dynamic range will not be an issue since:
- For line-of-sight channels the increased dynamic range requirements for the ADC will be 3/6/9 dB for 2/4/8 streams, but line-of-sight channels have good SNR
- For heavy fading/ non-line-of-sight channels the increase in dynamic range will be much less, since intentional beamforming will be mitigated by the multipath
This is not true in practice, as to avoid saturation the ADC will have to back off an extra 3/6/9 dB after decoding the NDP-A /NPD SIGA and determining the number of streams/LTF. The channel conditions will *not* be known a priori, so for *any* secure NDP with multiple streams, including for heavy fading channels the ADC will have to back off sufficiently to avoid saturation.
So we are increasing the required dynamic range of the ADCs used in secure Ranging by 3/6/9 dB. This will carry through to baseband processing and FFT cores which usually rely on gain targets.
Christian
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** <STDS-802-11-TGAZ@xxxxxxxx> On Behalf Of Jiang, Feng1
Sent: Wednesday, October 16, 2019 4:48 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: [EXT] Re: [STDS-802-11-TGAZ] IEEE submission 11-19/1572r4
External Email
Hi Rethna,
Thanks for the good discussions in today’s TGaz telecon.
A few more questions/comments regarding 11-19/1572r4 are listed below for your review. Thanks.
- In slide 7, it stated the max SNR degradation for channel estimation due to unintentional beamforming is 1.2494 dB, and could you please show more details how this number is derived? Also, have you evaluated how much ranging performance will be degraded by this 1.2494dB SNR loss? If the ranging performance doesn’t suffer too much, then maybe we don’t need to worry about this unintentional beamforming issue in secured ranging.
- In secured NDP frame for ranging, the HE-LTF field is always repeated (at least two HE-LTF fields), and one repetition will provide 3dB additional gain after combining the channel estimation results. Even if there is 1.2494dB degradation for channel estimation of a single HE-LTF field, the 3dB gain of the repeated HE-LTF field will compensate it.
- In slide 27, a minus sign is missed before “h11_k“ in the equation “ y1[n+1] / A2k = h11_k + h12_k’ ”
Best regards,
Feng Jiang
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Rethna Pulikkoonattu
Sent: Thursday, September 26, 2019 10:59 AM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Oct. 2nd telecon
Hi Jonathan,
Could you also allocate a slot at the Oct 2nd, 2019 TGaz Telecon for the following submission?
11-19/1572r4, Secure-LTF: Unintentional Beamforming Problem and A Solution Proposal
Thanks and regards,
Rethna.
On Thu, Sep 26, 2019 at 10:56 AM Segev, Jonathan <jonathan.segev@xxxxxxxxx> wrote:
Thank you both,
I will add this to the submission pipeline.
Best,
Jonathan
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Venkatesan, Ganesh
Sent: Thursday, September 26, 2019 10:49
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Oct. 2nd telecon
Hello Jonathan:
Could you please add the following submissions to the agenda pipeline:
11-19-1686r0 – resolutions to a set of LB240 CIDs (part-7)
11-19-1368r2 -- resolutions to a set of LB240 CIDs (part-8)
Cheers --
ganesh
“It is amazing what you can accomplish if you don’t care who gets the credit.” – Harry Truman
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** <STDS-802-11-TGAZ@xxxxxxxx> On Behalf Of Jiang, Feng1
Sent: Thursday, September 26, 2019 10:31 AM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Oct. 2nd telecon
Hi Jonathan,
Could you please add the following submission to Oct. 2nd TGaz telecon? Part of this submission was presented in Hanoi meeting, but due to agenda time limitation, it was not completed.
We would like to finish the CR to the remaining 5 CIDs in the coming telecon. Thanks.
- 11-19/1563R1 CR for Miscellaneous CIDs in LB240_part 2
Best regards,
Feng Jiang
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Segev, Jonathan
Sent: Wednesday, August 28, 2019 12:03 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Aug. 28th telecon
Thank you Ali, added to the submission queue.
From: qi_wang2@xxxxxxxxx [mailto:qi_wang2@xxxxxxxxx]
Sent: Tuesday, August 27, 2019 16:15
To: Segev, Jonathan <jonathan.segev@xxxxxxxxx>
Cc: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Aug. 28th telecon
Hi Jonathan,
Would you please add the document “11-19-1460-00” to the presentation queue? It proposes resolutions to a few LB240 CIDs on DMG/EDMG ranging.
Regards,
Qi
On Aug 27, 2019, at 2:41 PM, Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:
Hi Jonathan,
I want to postpone discussion on “11-19-678 CR for CID 1115” till the FTF based on offline request.
Regards,
Dibakar
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Ali Raissinia
Sent: Tuesday, August 27, 2019 2:01 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Aug. 28th telecon
Hi Jonathan,
Please add document 11-19-1455-01 CR for 1118, 1129 and 1324 in the agenda queue in case we have time for me to present it.
Thanks,
Ali
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** <STDS-802-11-TGAZ@xxxxxxxx> On Behalf Of Segev, Jonathan
Sent: Tuesday, August 27, 2019 1:28 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAZ] TGaz Aug. 28th telecon
CAUTION: This email originated from outside of the organization.
Hello folks,
Agenda topics for tomorrow’s telecon is as follows:
• 11-19-678 CR for CID 1115 (Dibakar)
• 11-19-1422 Clause 11 PXDMG CIDs (Assaf)
Agenda document is submission 11-19-1362, be sure to use latest version.
Please let me know of any additional agenda topic you may have.
Best,
Jonathan
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Segev, Jonathan
Sent: Tuesday, August 20, 2019 11:19
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Aug 21st Telecon agenda and call for submissions
Thank you Assaf, added to the queue.
From: Assaf Kasher [mailto:akasher@xxxxxxxxxxxxxxxx]
Sent: Monday, August 19, 2019 23:47
To: Segev, Jonathan <jonathan.segev@xxxxxxxxx>; STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: RE: TGaz Aug 21st Telecon agenda and call for submissions
Hi Jonathan,
Please add 11-19-1422-00-00az-Clause-11-PXDMG-CIDs to the queue.
I will need about 40 minutes to review it.
Thanks,
Assaf
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** <STDS-802-11-TGAZ@xxxxxxxx> On Behalf Of Segev, Jonathan
Sent: Tuesday, August 20, 2019 2:19 AM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Aug 21st Telecon agenda and call for submissions
CAUTION: This email originated from outside of the organization.
Here is a link to the updated agenda 11-19-1362r5, https://mentor.ieee.org/802.11/dcn/19/11-19-1362-05-00az-july-to-sep-telecon-agenda.pptx
Best,
Jonathan
From: Segev, Jonathan
Sent: Monday, August 19, 2019 08:21
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: RE: TGaz Aug 21st Telecon agenda and call for submissions
thank you Dibakar I will add this to the Wed. telecon agenda for this week.
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Das, Dibakar
Sent: Monday, August 19, 2019 05:18
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Aug 21st Telecon agenda and call for submissions
Hi Jonathan,
Can you please add the following submission to the agenda:
“11-19-678r0- CR for CID 1115” ?
I will need about 30 minutes for discussion.
Regards,
Dibakar
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Jiang, Feng1
Sent: Thursday, August 15, 2019 12:12 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAZ] TGaz Aug 21st Telecon agenda and call for submissions
Hi Jonathan,
Could you please add the following contribution to agenda? Thanks.
- DCN 1438 CR for PHY related comments for LB240-part3
Best regards,
Feng Jiang
From: *** 802.11 TGaz - NGP - Next Generation Positioning *** [mailto:STDS-802-11-TGAZ@xxxxxxxx] On Behalf Of Segev, Jonathan
Sent: Wednesday, August 14, 2019 12:07 PM
To: STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAZ] TGaz Aug 21st Telecon agenda and call for submissions
Hello all,
- TGaz telecon scheduled for Wed. Aug. 21st 13:00 ET/10:00AM PT for 1:30 hrs.
- Telecon agenda slide deck is submission 11-19-1362, be sure to use latest revision.
- If you’re planning a submission and would like to allocate agenda time please let me know.
- Note that teleconferences are bounded by the conditions stipulated by the documentation below.
Please review and bring up any questions/concerns you may have before proceeding with the teleconference:
IEEE Patent Policy - http://standards.ieee.org/board/pat/pat-slideset.ppt
Patent FAQ - http://standards.ieee.org/board/pat/faq.pdf
LoA Form - http://standards.ieee.org/board/pat/loa.pdf
Affiliation FAQ - http://standards.ieee.org/faqs/affiliationFAQ.html
Anti-Trust FAQ - http://standards.ieee.org/resources/antitrust-guidelines.pdf
IEEE 802.11 Working Group Operations’ Manual – https://mentor.ieee.org/802.11/dcn/14/11-14-0629-16-0000-802-11-operations-manual.docx
Best Regards,
Jonathan Segev,
Cell (WhatsApp): +1-408-203-3337 (note # change)
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1
To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1