Hi Gaurang,
I would like to jump to the discussion.
Each AP within shall operates independently, e.g. obtain the TXOP, stop scheduling based on its own TBTT. Seems your proposal make such rule break, which causes the operation on current AP operation need refer to the behavior on other APs
within same AP MLD. According to your talk with Vishnu, Shawn and Yiqing, I understand your propose that each AP associated by the STA within EMLSR non-AP MLD need to stop its TXOP at the TBTT of any AP within same AP MLD. I can image such behavior will cause
a serious TP drop issue on the EMLSR non-AP MLD side and overhead issue due to no response to the initial frame during overlap time. Therefore, I believe less members will buy such sell point.
If we want to avoid such issue, non-AP MLD shall signal the AP MLD of the link that is used to receive groupcast frame, and the indication can be changed by non-AP MLD at any time , which is aligned with the proposal of “primary link”.
Thanks
Best Regards
Jay Yang
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: 2022年1月25日 1:52
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hi Vishnu, Shawn,
Thanks for the discussions.
@Shawn, thank you for illustrating through an example and all the arguments.
@Vishnu, the text in rev0 considered both (i) and (ii). The text in rev1 calls out (i) but IMO (ii) naturally follows. The AP ended frame exchanges with the STA so that the non-AP MLD could move to another link and receive Beacon/Group
Addr frames. Therefore, from AP’s perspective it makes little sense to re-initiate frame exchanges with the same STA. That being said, if the AP sends an initial Control frame to the same STA one of two things would happen – (a) the non-AP MLD wants to receive
Beacon on another EMLSR link so the STA does not respond, or (b) the non-AP MLD does not want to receive Beacon and responds.
If the AP can end frame exchanges with the non-AP MLD before the TBTT (accounting for the transition delay), the non-AP MLD does not need to take additional actions and this is the general recommendation that the text provides. However,
given the traffic load the AP might not want to keep ‘holes’ where it cannot service any EMLSR non-AP MLDs, even if it is just one primary link. In such cases, the AP might send an initial Control frame although the TBTT on another link is approaching, but
if the Beacon/Group Addr frame reception is critical from non-AP’s perspective, it may not respond to the that initial Control frame. Thus, as Shawn highlighted, the text in doc 1706 provides enough flexibility to the AP and the non-AP so that the non-AP MLD
can receive Beacon/Group Addr frames.
Thanks,
Gaurang
From: Shawn Kim <shawn.kim@xxxxxxxxxxxxxx>
Sent: Monday, January 24, 2022 1:04 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Dear Vishnu and Gaurang,
Yes, I think your understanding is correct. (at least it is aligned with my understanding.)
As you pointed out, I agree that it seems unclear how an AP MLD expects a non-AP MLD to have intent to receive the beacons. However, I'm not sure if there is a need to specify more detailed TXOP management rules for AP MLD. This is because
the non-AP MLD can manage all the TXOPs in which it is involved when the non-AP MLD has intent to receive beacon/group addressed frames on the other EMLSR link (end its TXOP as a TXOP holder/reject to be a TXOP responder).
Thanks for sharing your good thoughts.
Best regard,
Shawn
2022년 1월 24일 (월)
오전 5:14, Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>님이
작성:
Hi Shawn and Gaurang,
Thank you for the clarification. Indeed there seems to have been some miscommunication. I just want to double check the current understanding.
My initial understanding, based on Gaurang's rev0 and initial comments in this thread, was that an AP of the AP MLD should (i) terminate TXOPs with an EMLSR nonAP STA before the TBTTs on other EMLSR links and, additionally, (ii) should also not schedule TXOPs whose start time overlaps with TBTTs on other EMLSR links. To improve the efficiency of this operation, I was suggesting the use of a primary link. It would (i) reduce the number of TXOP terminations to only those that overlap with primary link TBTTs, and (ii) allow TXOP start times to overlap with TBTTs on non-primary links. The primary link is basically a way for the AP MLD to partially know which beacons the nonAP MLD is expected to be decoding.
Based on your comments and Gaurang's latest comments, it seems the proposed operation is that an AP of the AP MLD should (i) terminate TXOPs before TBTTs on other EMLSR links. But the AP is free to schedule TXOPs whose start time overlaps with TBTTs on other EMLSR links by transmitting an initial control frame (to basically probe and see if it is successful). Is this the correct understanding? In this case, I don’t follow how the number of TXOP terminations are reduced (since the AP MLD does not know which beacons the nonAP MLD is expected to be decoding) but yes the TXOP start opportunity is significantly improved.
If this second understanding is correct, then it is basically a trade-off between (a) the increased overhead of negotiating a primary link, and corresponding restrictions on group addressed frame decoding versus (b) the cost of slightly more frequent TXOP terminations, and unsuccessful TXOPs due to no response to the initial control frame. The trade-off would be subject to opinion, but I understand your view point.
Regards,
Vishnu
From: Shawn Kim <shawn.kim@xxxxxxxxxxxxxx>
Sent: Friday, January 21, 2022 10:53 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Dear Vishnu and Gaurang,
I think there are two different understandings on the TXOP termination of an EMLSR link.
1) A TXOP of an EMLSR link must be ended prior to TBTT of the other EMLSR link(s).
2) A TXOP of an EMLSR link may be ended prior to TBTT of the other EMLSR link(s). And, a non-AP STA of a non-AP MLD operating on an EMLSR link may not respond to the Initial control frame when the non-AP MLD wants to receive a Beacon frame on a different EMLSR link.
-My guess is that the primary link concept is proposed to prevent frequent TXOP terminations(or scheduled short TXOPs) taking into account 1), but 21/1706 describes 2).
As a simple example for the 2), we can consider a non-AP MLD with the two EMLSR links:
-The non-AP MLD may receive a Beacon frame of Link1 by not responding to the initial control frame received from Link2 even if Link1 is not defined as the primary link.
-The non-AP MLD can receive a Beacon frame on Link2 also by not responding to the initial control frame received from Link1.(Initiation of a TXOP expected to overlap with a Beacon intended to be received by the non-AP MLD is denied by the non-AP MLD.)
-By terminating its TXOP(or scheduling the TXOP as short) of Link1, the AP MLD can let the non-AP MLD to receive group addressed frames that are scheduled on Link2.
(In this case, the non-AP MLD is expected to receive the frames)
(If the non-AP MLD has an additional link that is a non-EMLSR link, the AP MLD and the non-AP MLD do not need to consider the behavior regarding the Beacon Tx/Rx.)
I think the described operations in 21/1706 provide sufficient degrees of freedom for the AP MLD and the non-AP MLD, and provide a way to ensure that AP MLD and non-AP MLD can Tx/Rx the Beacon/group addressing frames reliably.
So, I would like to support going without the primary link concept.
Best regard,
Shawn
2022년 1월 22일 (토) 오전 10:29, Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>님이 작성:
Hi Vishnu, Shawn,
Even if the primary link is conveyed in the EML OMN frame, it is fixed for the time for which the non-AP MLD is in the EMLSR mode. The next update to the primary link is when the non-AP MLD exits and re-enters the EMLSR mode. In your viewpoint, the non-AP MLD can declare a primary link and yet receive the Beacon/Group Addr frames on any link. But in that case, why does the AP need to ‘protect’ the Beacon on the primary link? Or in other words, why define the primary link at all? Not to mention that the AP needs to block transmissions to the non-AP MLD during the entire duration of Beacons and Group Addr frames when the non-AP is likely to receive only few among the many Beacons within its Listen Interval.
I think we cannot mix this with r-TWT since r-TWT SPs are negotiated b/w the AP MLD and the non-AP MLD. Unlike other times, the AP MLD and non-AP MLD have a common understanding on when the non-AP MLD is expecting frame exchanges and on which link.
Thanks,
Gaurang
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Friday, January 21, 2022 8:28 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Shawn, Yiqing and Gaurang.
@Shawn: You raise a good point. But the purpose of the (optional) primary link indication is only to inform the AP MLD that among the EMLSR links of a nonAP MLD which link will be the one used for group addressed frame decoding. The nonAP MLD can still use other non EMLSR links for decoding group addressed frames. The purpose of this indication is that if the AP knows which among the EMLSR links is the primary link, it only has to avoid overlapping TXOPs on any EMLSR link with the TBTTs on the primary link. Without the indication, as shown in attached image, the AP MLD would have to avoid overlapping the TXOPs on any EMLSR link with TBTTs on all other EMLSR links (or the AP MLD has to use a ‘probe and try’ approach as Gaurang suggests). Beyond the transmission efficiency, this indication also improves reliability of rTWT, for example, since an rTWT SP on an EMLSR link will only be interrupted by a TBTT on the primary link. Also note that reception/transmission on a non-EMLSR link may not hinder operation on the EMLSR links.
@Gaurang: The primary link doesn’t have to be fixed from association. The primary link indication can be an optional field in the EML operating mode notification frame, such that the EMLSR mode when enabled, can be optionally enabled with a primary link. Such a primary link can then be changed by sending another EML operating mode notification from the EMLSR nonAP MLD to the AP MLD. The expectation would be that, among the EMLSR links, the nonAP MLD only listens to beacons on this primary link (unless there is a critical update corresponding to another link). Could you kindly elaborate what bunch of issues this would create?If I understand correctly, your POV is that during group addressed frame transmission on another EMLSR link, you prefer the AP MLD to “probe and try” by sending an initial control frame to see if the EMLSR nonAP MLD responds or not. Although this is a simpler solution, in my opinion it is less elegant and may reduce reliability of operations like rTWT due to the uncertainty at AP MLD.
Regards,
Vishnu
From: Shawn Kim <shawn.kim@xxxxxxxxxxxxxx>
Sent: Friday, January 21, 2022 3:53 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hi Gaurang, Vishnu and Yiqing,
Thanks for the discussion on the primary link for EMLSR MLD.
If the reason for defining the primary link is to ensure the reception of the beacon/group addressed frame transmitted on the primary link, I think we need to consider the following case.
-There might be an additional setup link that is not an EMLSR link between an AP MLD and a non-AP MLD(please see 21/283). If the non-AP MLD has just received the beacon frame through another link(non-EMLSR link), the non-AP MLD does not need to receive the next beacon frame of the primary link.That is, even if we define a primary link, we cannot force an EMLSR MLD to receive the beacon(and group addressed) frame transmitted on the primary link.
So I doubt that the primary link defined helps clarify the behavior of EMLSR mode.
Best regard,
Shawn
2022년 1월 21일 (금) 오전 9:04, Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>님이 작성:
Hi Yiqing,
Thank you for your email.
As I mentioned in my previous email, defining a primary link is not a desirable solution. Are you suggesting that the primary link is specified by the non-AP MLD during association and never changes? That would be too restrictive for the non-AP MLD. But if non-AP can receive Beacons on any link despite defining a primary link, it defeats the purpose of defining one. It also warrants additional mechanisms by which non-AP updates the primary link and that creates a bunch of new issues.
A simpler solution proposed in 1706 is to grant the AP MLD and non-AP MLD both some flexibility. The non-AP MLD need not receive every Beacon frame. When it is critical for the non-AP MLD to receive one and the AP tries to initiate frame exchanges on another link, the non-AP MLD can receive the Beacon by not responding to the initial Control frame on the other EMLSR links. This also allows the AP MLD to initiate frame exchanges with the non-AP MLD when it has critical traffic to send to the non-AP MLD.
Thanks,
Gaurang
From: liyiqing (C) <00001782e0ccda1b-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, January 20, 2022 3:33 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Vishnu and Gaurang,
Thanks for raising the discussion. I also want to echo with setting primary link for non-AP MLD in EMLSR mode. It can provide flexibility and help clarify transmission and reception behavior for non-AP MLD in EMLSR mode. It remains many unclear procedures currently for example how to receive management frames for non-AP MLD. At least we should open some discussion for this topic to see if it is a good way to complete the descriptions for EMLSR mode.
Thanks,
Yiqing Li
发件人: Vishnu Ratnam [mailto:vishnu.r@xxxxxxxxxxx]
发送时间: 2022年1月20日 15:12
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hi Gaurang,
I am not sure I follow you argument here for point 1. The response to PS-polls, IFS + backoff is applicable for the link which just finished the beacon frame transmission, but my argument also valid for the other links. To elaborate, consider a scenario where an AP MLD operates on two links (link1 and link2) and there is a nonAP MLD operating in EMLSR mode on these two links. Say AP1 of AP MLD is sending a beacon frame on link1 and the STA of EMLSR nonAP MLD associated on link1 is decoding this beacon. After the end of the beacon frame, the EMLSR nonAP MLD requires the EMLSR transition delay to switch to listen mode on all links. During this transition delay, AP2 of the AP MLD should not be sending an initial control frame on link 2 since it will be missed by the nonAP MLD. This is the case that is not covered by your text. In my opinion, same condition should also be applied to link1 (which transmitted the beacon), although the chance of violation can be low, as you mentioned in your response.
Regards,
Vishnu
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, January 19, 2022 8:47 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hi Vishnu,
Thank you for your response.
I believe the transition delay right after the transmission of the group addressed frames is not essential. From a non-AP side, it is not guaranteed that it is receiving the group addressed frames, since it can elect to do so on any link. From the AP side, it is anyway likely to be responding to the PS-Polls received from STAs that wake up after seeing BUs in the TIM element. Furthermore, there is IFS + backoff for the AP which would likely take similar order of time as the transition delay.
About the definition of the primary link, the way I see it, if there is a primary link that the STA selects, it must stick to receiving Beacons and group addr frames on that link. Otherwise, the purpose of defining the primary link is defeated. If the primary link is static, it curtails the flexibility of the non-AP MLD. If the primary link is to be changed, we would need to define an update mechanism, which would add unnecessary complexity and would not be in the scope of this CR document. The proposed resolution in doc 1706 keeps things simpler.
Thanks,
Gaurang
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Monday, January 17, 2022 2:44 PM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Guarang,
Thanks for the response.
For your first point, I guess your current text covers the case of when a first frame exchange has already started on an EMLSR link before the start of a group addressed frame reception period on another link. In that case the text suggests termination of the first frame exchange sequence. But it probably doesn’t cover the case when the frame exchange starts after the end of a group addressed frame transmission on another link. The point is that the AP must wait for at least an EMLSR transition delay after the end of a group addressed frame exchange sequence on another link, before transmitting an initial control frame. This part isn’t covered in current set of rules.
Regarding your second point, I am not prescribing to enforce that the EMLSR client only listen to beacons and other group addressed frames on one link, it can indeed be a client implementation decision. Rather, I am saying the spec should enable an EMLSR client to choose to receive beacons primarily on one link, if it desires to do so. If an EMLSR client does choose such a “primary link” for group addressed frame reception, the AP MLD should accordingly prevent overlap of individually addressed frames on any link with the group addressed frame transmissions on only this primary link. As per the current text, the overlap of a frame exchange sequence with group-addressed frames on any link is prevented, which is unnecessary in such cases. The proposed spec rules should at least be generalized to accommodate such optimization.
Regards,
Vishnu
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, January 12, 2022 1:40 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hi Vishnu,
Thank you for reviewing the document and for the offline discussions.
I will incorporate the editorial change in the next revision. Thank you for pointing it out.
Regarding initiation of the frame exchange sequence, I think the current statement does imply that AP should not initiate frame exchanges either (in addition to ending it). However, if you think that it needs to be explicitly called out, I can revise the statement.
About the second point, as I mentioned in our offline discussions, a non-AP MLD must have the flexibility to decide which link to receive the Beacons on. Moreover, it cannot be assumed that the non-AP MLD listens to the Beacons on the same EMLSR link each time. The proposed text in document 1706r1 provides a recommendation to the AP to avoid overlaps b/w frame exchanges and group addressed frames on two EMLSR links. If the AP MLD does initiate frame exchanges, then it also provides flexibility to the non-AP MLD to not respond to the initial Control frame. Therefore, the problem you mentioned in your example will not occur.
Thanks,
Gaurang
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Tuesday, January 11, 2022 3:49 PM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Thanks Gaurang for the draft, discussions and for incorporating some of my offline comments. I still have few more comments (some of which we discussed about before but I want to include here for others’ consideration as well):
- Minor grammatical correction: “An AP affiliated with the AP MLD should end frame exchanges initiated with a STA affiliated with the non-AP MLD in one of the EMLSR links at least an EMLSR transition delay, indicated in the EMLSR Transition Delay subfield, before another AP …”
- Your text seems to have rules on termination of frame exchanges by AP but not on the start of a frame exchange. Why not also have additional text of the form: “An AP affiliated with an AP MLD shall not initiate a frame exchange with an STA of a non-AP MLD in one of the EMLSR links if:
- Either the frame exchange duration is expected to overlap with group-addressed frame transmissions on another EMLSR enabled link or the frame exchange duration is separated from group-addressed frame transmission on another EMLSR enabled link by less than an EMLSR transition delay
- and the STA affiliated with the non-AP MLD in the other EMLSR link is expected to receive those group addressed frames”.
I remember you had some text for start time before. Any reason it was removed?
- According to your current text, a frame exchange between an AP and a nonAP EMLSR STA will not be feasible if it overlaps with a TBTT on any of the other EMLSR enabled links of the nonAP MLD. Considering a 100ms beacon rate and 3 EMLSR links, this can be very inefficient since many potential TXOPs can be lost, as illustrated in red in the figure below. In particular, a nonAP MLD may decode just one beacon every listen interval (shown in green in the Figure) so preventing TXOP overlap with all TBTTs on all links can be an overkill. Some better mechanism may be required to improve channel access opportunities of EMLSR, especially considering a nonAP MLD doesn’t decode all beacons. One possible option can be that an EMLSR nonAP MLD elects a primary link to receive group-addressed frames on. There needs to be defined a mechanism for the EMLSR client to inform the AP about the same and correspondingly the AP operation would be to avoid TXOP overlap with only group addressed frames on this primary link. I bring this up because this is inherently tied to the resolution of this comment CC6946.
Regards,
Vishnu
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Monday, January 10, 2022 3:07 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hi Alfred,
Could you please queue document 1706r1 to the MAC queue?
All,
Kindly let me know if you have any feedback.
Thanks,
Gaurang
From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, January 9, 2022 11:13 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Alfred,
Please add the following contribution to the MAC queue:
11-22-0041-00-00be-Some-issues-on-SCS-operation.pptx
Regards,
Guogang Huang
发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2022年1月5日 5:36
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hello all,
First of all I would like to wish everybody a Happy New Year!
I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Wednesday January 05 (JOINT), 10:00-12:00 ET and Thursday January 06 (MAC), 10:00-12:00 ET.
The agendas can be found here:
https://mentor.ieee.org/802.11/dcn/21/11-21-1775-18-00be-nov-jan-tgbe-teleconference-agenda.docx
Note for CR documents: Please update the baseline to TGbe D1.31 for the CR documents.
DIAL IN DETAILS FOR WEDNESDAY:
Join the JOINT meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=m47e46089d108a8ef448b7a3a11976593
Meeting number: 233 886 75218 Meeting password: wireless (94735377 from phones and video systems)
DIAL IN DETAILS FOR THURSDAY:
Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=mff9e3bd94518bedcc608845d389fdd3e
Meeting number: 234 227 52561 Meeting password: wireless (94735377 from phones and video systems)
Let me know if you have any questions and/or suggestions.
Best Regards,
Alfred
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
--
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-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
--
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-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&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-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1