Hi Vishnu,
Thanks for your responses. I have embedded my followup comments inline.
Regards,
Shubho
Hi Shubhodeep,
Thank you for your comment and sorry for forgetting to respond to this. I think there is some confusion regarding the “protection” mechanism. The protection mechanism is not to enable or improve fidelity of reception of beacons by an EMLSR non-AP MLD. As you rightly mentioned, currently an EMLSR non-AP MLD can always switch to a link to receive the beacons. Rather, the protection is for ensuring reliability of individually addressed frames that are transmitted during group addressed frame transmission times on other EMLSR links. Since there is a significant chance that an EMLSR non-AP MLD may not respond to individually addressed frames transmitted by an AP MLD on an EMLSR link during group addressed frame transmission on another EMLSR link, an AP should avoid such transmissions. This is so that the AP does not loose its TXOP or to prevent it from suffering a frame re-transmission. I have now updated the discussion section of the CR document to prevent such confusion.
>>If the proposal does not intend to improve the fidelity of beacon reception, why does it put a transition delay on one link before the beacon reception on another link?
I think it is important to improve the fidelity of both the DL data reception from the AP on one link + beacon reception on another link. My concern is that the proposed protection procedure provides a conservative way of doing so.
Given this context, it is not clear if an EMLSR non-AP MLD indicating if it wants such a protection or not would make sense (as suggested by the middle path you mention), since the protection is for the AP’s transmissions.
>> It is a non-AP’s capability whether it can receive beacons on one link that overlap with DL data reception on another link. In many cases, the DL PPDU duration on one link is much longer than the beacon duration on another link. In such cases, as we discussed earlier, some EMLSR non-APs may be able to receive both, without needing protection for beacons or protection for the DL PPDU from the AP. Since this behavior also depends on non-AP capability, I had brought up the proposal of an indication from the non-AP. Importantly, without such an indication, the AP wouldn’t know and may make the most conservative assumption and protect both beacons and DL PPDU by providing gaps in case there is any overlap between the two.
Regarding the example you state, I think it is a corner case that all the devices associated with an AP MLD are either EMLSR or NSTR. Even if it were true, the same would also apply for the OBSS AP. So although an AP may lose out on some TXOPs to the OBSS during its beacon frames, it will also gain the same during the OBSS APs beacon frames. I don’t see this as a major issue causing loss of throughput for the AP.
>>In 11be, ML non-APs can only be EMLSR or NSTR in 5G/6G. So, why is this a corner case? Many simulations that evaluated 11be as well as lab tests consider simple and tractable scenarios such as the following: an AP transmits full buffer DL to an EMLSR/NSTR non-AP on 2-links in the presence of 1 (or more) single-link OBSSs on each link. These tests would show a throughput drop in the presence of the proposed procedure. One can argue that a real world deployment would be more complex and with many more nodes and of different types. But simulations and lab tests that are set up to showcase ML performance vis-a-vis legacy are seldom more complex than what I have described, and so poor performance in these tests can undermine ML.
In fact allowing repeated re-transmissions of ICF to an EMLSR device on a link when it may not respond may be a bigger concern.
>>Yes, this is a concern. That is why I had suggested that a non-AP dynamically indicate whether it wants the AP to not send it DL PPDUs that overlap with a beacon on another link. If the non-AP has indicated this, the AP should not transmit a DL PPDU to such a non-AP during beacon transmission on another link. In such cases, the AP restricts its transmissions to only those non-APs that have not indicated such a restriction. This would prevent the loss of ICF as well as prevent any gaps on one link during beacon transmission on another link.
I see this as a win-win situation.
That being said, one potential middle ground can be to only keep the 1st of the below conditions and remove 2nd one, because the 1st condition prevents a loss of the frame while 2nd one only prevents failure of ICF (and sometimes loss of TXOP):
1. An AP of an AP MLD should terminate a frame exchange sequence with an EMLSR non-AP MLD before the group-addressed frame transmission time on another EMLSR link, if the non-AP MLD is expected to receive those group-addressed frames. This is so that the non-AP MLD switching to the other link does not cause a failure in the reception of the first frame exchange sequence.
2. An AP of the AP MLD should not transmit an ICF to a STA of an EMLSR non-AP MLD if the ICF overlaps in time with the group-addressed frame transmission time on another EMLSR link, if the non-AP MLD is expected to receive those group-addressed frames. This is because, when an EMLSR non-AP MLD is receiving group-addressed frames on an EMLSR-enabled link, it may not be able to receive and respond to initial control frames (ICFs) transmitted by an AP of the AP MLD on another EMLSR-enabled link. This can cause the AP to lose the TXOP and suffer a back-off if the ICF it transmits initiates the TXOP.
Regards,
Vishnu
From: Shubhodeep Adhikari <00000c144a46bcee-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, September 26, 2022 5:41 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Thanks for your emails.
I am ok with Yongho’s proposed changes, as I think it makes the expected behavior clearer.
As noted last week, my key concern is the impact on throughput and latency stemming from the recommendation that the AP ends its TXOP on one link at least a transition delay before the beacon reception on the other link and provide a further transition delay after the end of beacon reception. There is a similar recommendation for NSTR too, except that the transition delay is not required.
Since most 11be non-APs in 5GHz/6GHz are expected to be either EMLSR or NSTR, such a recommendation can insert gaps on one link whenever there is a beacon on another link. In the presence of even 1 OBSS device with moderate to high offered load, the AP in question can lose the link in this gap. Considering a nominal beacon periodicity of 100ms, the AP on the DL can lose up to 1 TXOP + curtail 1 more TXOP every 100ms.
That is why I think that it need not be recommended that the AP provide such gaps on one link for beacon/group addressed frame reception on another link. Rather, the non-AP can determine if it wants to receive a beacon on a link that overlaps with a TXOP directed towards it on another link. If the EMLSR non-AP decides to receive a beacon, it should not respond with a CTS/BSRP whenever the AP initiates such a TXOP with an initial control frame. Putting the decision of beacon reception on the non-AP can minimize the throughput/latency loss. For example, based on various factors, the non-AP can conditionally decide to not receive a beacon on a given link at a particular TBTT and rather continue with the data Tx/Rx on another link. The AP on the other hand, does not have any information that it can use to balance the throughput/latency loss with the fidelity of beacon reception.
Can we also explore the following middle path? The non-AP can semi-statically indicate to the AP if it should protect beacon overlaps in the proposed manner, so that the AP bases such a decision on the non-APs request. This would not force the AP to leave gaps for all non-APs and for all beacons, as only a subset of non-APs may send such a request. The non-AP can also semi-statically withdraw its request.
Regards,
Shubho
On Sat, 24 Sept 2022 at 09:57, Yongho Seok <yongho.seok@xxxxxxxxx> wrote:
Hi Vishnu,
Regarding the green text, "interrupted" is a little ambiguous since an interrupt can be interpreted as various meanings.
Can you change the following sentence
"After using a link to receive the group addressed frame(s), the non-AP MLD shall return to the listening operation on all the EMLSR links on which listening operation was interrupted due to the reception of the group addressed frames."
to
"After using a link to receive the group addressed frame(s), STAs(s) affiliated with the non-AP MLD which operates on the EMLSR links but was not able to perform the CCA during the reception of the group address frames shall return to the listen operation."
Thanks,
Yongho
2022년 9월 21일 (수) 오전 11:05, Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>님이 작성:
Hi Shubhodeep,
If I understand correctly, your intention is that reception of non-HT PPDU beacon frames is potentially possible for an EMLSR device during listen operation. Correspondingly an EMLSR transition delay is not required after the end of the frame exchange sequence. Note that the EMLSR transition delay is however still required after the group-addressed data and management frames sent after the DTIM beacon. It will also be required for HT PPDU beacons and, for some implementations of EMLSR, it may be needed for all beacons it receives as well. So, as suggested, I have changed the sentence as:
- [13587]The non-AP MLD may receive group addressed frame(s) on a link at the scheduled group addressed frame transmission time on that link. After using a link to receive the group addressed frame(s), the non-AP MLD shall return to the listening operation on all the EMLSR links on which listening operation was interrupted due to the reception of the group addressed frames. The return to listening operation shall be a duration of the EMLSR transition delay, indicated in the EMLSR Transition Delay subfield, following the end of the group addressed frame(s) or, if the group addressed frame(s) include non-GCR-SP group addressed BUs, a duration of the EMLSR transition delay, indicated in the EMLSR Transition Delay subfield, following the reception of an indication from the AP MLD that there is no more buffered non-GCR-SP group addressed BUs following the rules defined in 11.2.3.7 (Receive operation for STAs in PS mode).
I would appreciate any further offline feedback from other members as well, if any, so that we can make progress on this important topic which already has been presented twice. The latest version is:
21-Sep-2022 ET
2022
1335
3
TGbe
CR for CIDs related to Group-addressed frame Reception in EMLSR/NSTR
Vishnu Ratnam (Samsung)
21-Sep-2022 13:56:07 ET
Regards,
Vishnu
From: Shubhodeep Adhikari <shubhodeep.adhikari@xxxxxxxxxxxx>
Sent: Wednesday, September 7, 2022 1:09 AM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
The cited clause is applicable for frame exchanges (i.e. tx/rx with any applicable NSS/MCS/PPDU format) that follow an initial control frame.
From the perspective of the capability of a non-AP in EMLSR mode, a beacon reception in non-HT format is no different from listening on EMLSR links for MU-RTS/BSRP in non-HT format or doing CCA. These latter cases i.e. listening for MU-RTS/BSRP/CCA do not have any transition delay at their end; so why should a beacon-only reception require a transition delay or any other special handling?
That is why when I initially read the proposal, I thought it is to support group addressed data frames, as unlike beacons these can be transmitted in higher frame formats and MCSs, and so may require a transition delay. Can you not restrict your proposal to include only such frames?
Note that the time sequence [Tx/Rx between non-AP in EMLSR mode and AP on one EMLSR Link] ====> [Beacon reception on a different EMLSR link] may still require a delay in some EMLSR architectures. So, my concern is only with [Beacon reception on one EMLSR link ] ====> [Listen on all EMLSR links]
Regards,
Shubho
On Wed, 7 Sept 2022 at 01:05, Vishnu Ratnam <vishnu.r@xxxxxxxxxxx> wrote:
Hi Shubho,
Thank you for the question. However I think your question is not specific to group addressed frames but is rather applicable to reception of any frame on an EMLSR link. Kindly note that the baseline spec has the following bullet:
“The non-AP MLD shall be switched back to the listening operation on the EMLSR links after the time indicated in the EMLSR Transition Delay subfield of the EML Capabilities subfield in the Common Info field of the Basic Multi-Link element if any of the following conditions is met and this is defined as the end of the frame exchanges:”
The same behavior is also applicable for reception of group-addressed frames. Therefore the proposed changes include the EMLSR transition delay after the end of the group-addressed frame transmission time. I hope that answers the question?
Regards,
Vishnu
From: Shubhodeep Adhikari <shubhodeep.adhikari@xxxxxxxxxxxx>
Sent: Tuesday, September 6, 2022 7:59 AM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Thanks for the clarifications.
So, the current proposal covers mechanisms to enable a non-AP in EMLSR mode to receive any group addressed frames, including only beacons.
But then, a non-AP in EMLSR mode can already do CCA as well as receive MU-RTS/BSRP in non-HT (or non-HT dup) format on all EMLSR links. In that case, if it receives a beacon in non-HT format, why does it need a transition delay after receiving a beacon on one link to being in listen mode on all EMLSR links?
Regards,
Shubho
On Thu, 1 Sept 2022 at 21:13, Vishnu Ratnam <vishnu.r@xxxxxxxxxxx> wrote:
Hi Gaurang,
I am fine with the suggested changes except for the following: “An AP affiliated with the AP MLD that intends to exchange individually addressed frames with the non-AP MLD on one of the EMLSR links shall begin the frame exchanges by …”. I am not sure if “intends to exchange” would be accurate. Note that the later text reads: “shall begin the frame exchanges by ..”, i.e., the frame exchange is being initiated (whether it will be successful or not is different question). So I think it is more appropriate to just say: “An AP affiliated with the AP MLD initiates individually addressed frame exchanges the non-AP MLD on one of the EMLSR links shall begin the frame exchanges by …”. The discussion on the call was slightly different and was related to including the term “individually addressed” if I am not wrong.
Hi Shubhodeep,
I am fine with the suggested change: “on all the EMLSR links on which listening operation was interrupted due to the reception of group addressed frames”
I also plan to add the changes suggested by Gaurang, as indicated in his email with Ben.
Regarding the third point,
- As per my understanding and discussion with others, beacon frames are also included in the list of group addressed frames. This is why we do not specifically mention beacons here. The scheme is designed to provide switching delay before all beacons, not just DTIM beacons. [I will have to do some digging if you want me to find the relevant spec text].
- For buffered group-addressed frames that are delivered after DTIM beacon, the “switching delay protection” is provided before the start of the DTIM beacon.
- Regarding the last point of whether we need to define a new type of EMLSR delay that unfortunately is beyond the scope of this CR document, and it is not clear to me why such a delay would be different from the delay to transition from receiving/transmitting operation on one link to listening operation on all links. Do you recommend providing a protection period of “EMLSR padding delay + EMLSR transition delay”? Or defining a new delay all together?
Regards,
Vishnu
From: Shubhodeep Adhikari <00000c144a46bcee-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, September 1, 2022 9:13 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Thanks for preparing the contribution. Please see comments below.
CID 13587: As noted, the EMLSR architecture does not preclude a non-AP from listening on the other EMLSR links while it is receiving group addressed frames on one of the EMLSR links. So, the following can be added:
- [13587]A non-AP MLD that is operating in EMLSR mode may receive group addressed frame(s) on a link at the scheduled group addressed frame transmission time on that link. A non-AP MLD that is operating in EMLSR mode that used a link to receive the group addressed frame(s) shall return to the listening operation on all the EMLSR links on which listening operation was interrupted due to the reception of group addressed frames after the end of the group addressed frame(s) or, if the group addressed frame(s) include non-GCR-SP group addressed BUs, upon receiving an indication from the AP MLD that there is no more buffered non-GCR-SP group addressed BUs following the rules defined in 11.2.3.7 (Receive operation for STAs in PS mode).
One can further add the changes suggested by Gaurang to include a transition delay.
- [10039][10863][12726][12728][12892][13588][13813] If an AP MLD expects that a STA affiliated with a non-AP MLD operating in an EMLSR link is expected to receive those group addressed MPDUs, an AP affiliated with the AP MLD that is operating on another EMLSR link should ensure the following:
· frame exchanges initiated with another STA affiliated with the non-AP MLD which is associated with the AP ends at least an EMLSR transition delay, indicated in the EMLSR Transition Delay subfield, before the group addressed MPDU reception by the STA.
- Is the scheme designed to provide a switching delay for all beacons or only for group addressed frames immediately following a DTIM beacon? If yes, why is this necessary only for group addressed frames but not normal beacons? Is this required because group addressed frames might be transmitted in higher frame formats (e.g. EHT, EHT MU or EHT MU with RU) and MCSs compared to normal beacons?
- Furthermore, even if the group addressed frame is an EHT PPDU, it is preceded by an DTIM beacon. So, the EMLSR STA on that link may already be receiving the beacon. In that case, why is there a need for an additional transition delay OR is the transition delay between the end of frame exchange on one link and the start of the DTIM beacon on the other link?
- The EMLSR transition delay (as it is currently defined) is the delay between the end of frame exchanges on one link and listen operation on all EMLSR links. However, in the above proposal, the same delay is being applied between frame exchanges on one link and Rx on another link. These two are different transitions and can potentially require different delays.
Regards,
Shubho
On Thu, 1 Sept 2022 at 06:36, Benjamin Rolfe <ben@xxxxxxxxxxxxxx> wrote:
Thanks that is quite clear now!
Ben
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, August 31, 2022 3:28 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Ben,
The intention is to apply the same delay (EMLSR transition delay) to both cases. Does the following answer your question?
Thanks,
Gaurang
From: Benjamin Rolfe <ben@xxxxxxxxxxxxxx>
Sent: Wednesday, August 31, 2022 2:26 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi All,
Potentially this question has already been covered, but in the response [13587], "following the reception of an indication from the AP MLD that there is no more boffered non-GCR-SP..." in the first part we define (precisely?) what "following" means (duration of EMLSR transition delay). Do you mean to apply the same duration to the second condition, or is "following" meaning some other (hopefully bounded) delay value?
Thanks
Ben
From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, August 31, 2022 12:48 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Pls see the suggested change for CID 13587 as I mentioned during the call.
Also, there regarding the term ‘individually addressed’ in the resolution for CID 10434, I suggest making the following change to make the intention clear.
I believe you also made live changes during the call for CID 10434. Could you please upload the version with those changes?
Thanks,
Gaurang
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Wednesday, August 31, 2022 11:34 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Dear all,
Thank you for discussion during the meeting on CR doc 1335 (Group addressed frame reception in EMLSR/NSTR). I summarize below the comments discussed on the call, and I look forward to additional feedback which was not discussed during the meeting:
· CIDs 10434, 12813: The text “individually addressed frame exchanges“ may be inaccurate. The text “affiliated (non-MLO) upper MAC sublayer functions of the AP MLD (5.1.5.1 General ) served for the EMLSR links” is controversial. Recommended to delete: “non-AP MLD with dot11EHTEMLSROptionImplemented equal to true that is associated with an AP MLD with dot11EHTEMLSROptionImplemented equal to true” to simplify text.
· CID 13587: Change the bullet to ensure that it doesn’t preclude listening operation on other EMLSR links when receiving group-addressed frames on one link, i.e., the return to listening operation is only for the STA that was receiving group-addressed frames. Also suggested to add that the return to listening is after the EMLSR transition delay.
Kindly let me know if I missed any of the comments on call. I would also appreciate if you can share feedback on CIDs which were not discussed during the meeting: [10039][10863][12726][12728][12892][13588][13813] and [10008][11594][13589].
Regards,
Vishnu
From: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Thursday, August 18, 2022 2:28 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Xiangxin,
Please find my responses inline.
Regards,
Vishnu
From: 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>
Sent: Tuesday, August 16, 2022 9:14 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Thanks for your response. I make inline reply.
BR,
Xiangxin Gu
Communication Standards Devision
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Wednesday, August 17, 2022 12:19 AM
To: 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Xiangxin,
Thank you for your comments and initiating the discussion.
- I personally don’t have a very strong opinion about this, i.e., is a capability indication by the AP MLD necessary or not. Others had suggested that a capability indication should be used during offline discussions. Without a capability indication, it may be unclear what the AP operation will be if an indication of group-link is provided by an EMLSR non-AP MLD, i.e., will it take action based on it or not.
[// Xiangxin Gu] If this mechanism is incorporated, there is no reason for an AP MLD not to support this because it make the AP MLD easier to operating with EMLSR/EMLMR mode. So I don’t understand why the capability indication is needed.
[VR] Since there are conflicting opinions on this, let us discuss this during the call to see what the group generally prefers. I would be happy to also collect other opinions of this as a response here to see which approach is more preferred.
- Beacon frames are also included in the list of group addressed frames. So even if no services are running over group-addressed data frames, the proposed mechanism is still required for protecting beacon frames. Can you elaborate further what case you are referring to and what is your suggestion?
[// Xiangxin Gu] Agree.
Further, an indication on whether there is services over group addressed frames other than Beacon frames at non-AP MLD side is suggested. Because it is gainful that the duration of transmission of these frames doesn’t need to be kept away from EML frame exchanges if no such services at non-AP MLD side. These frames occupy much more time than Beacon frame.
Moreover, for EMLMR, in case some RF chains are kept at the STAs on other links during the EML frame exchange, there is no need for EML frame exchanges to be away from the duration of transmission of group addressed frames on any links. For example, a multi-radio non-AP MLD with 3 affiliated STA1 and STA 2 and STA 3 setups link 1 and 2 and link 3 respectively with AP 1 and AP2 and AP3 affiliated with an AP MLD. All STAs support 2 SS. The non-AP MLD supports EMLMR mode, and has enabled EMLMR mode with 4 SS on link 1 and link 2 and link 3. The EMLMR mode does not use all RF chains of the non-AP MLD.
[VR] Regarding the indication of group addressed frame services, I see your point, But I think the issue may be that group addressed management frames are also buffered and transmitted after the DTIM beacon, and they can be meant for all non-AP MLDs. So even if a non-AP MLD is not subscribed to a group addressed service, it may want to decode the group addressed frames. Note that as of now there is no indication in TIM regarding whether the buffered group-addressed frames are data frames or management frames (there are some CIDs on that topic), so the non-AP MLD may not know if it can stop decoding.
Since many things regarding EMLMR are yet unclear, I removed the clause corresponding to EMLMR from the document. There are other CIDs for EMLMR section that can be used to extend this procedure for EMLMR. I encourage you to bring this idea up during the resolution of those CIDs.
- This point was also in debate in offline discussions, and two people suggested that the indication should be in a new EHT action frame. One of the reason is also that the indication of group link can be provided after switch to EMLSR mode, at any time. So reusing EML Operating Mode Notification frame might in fact reduce flexibility that the indication can only be provided when the switch to EMLSR mode happens. The EML Operating Mode Notification frame also has a response frame, while for this feature we don’t require a response frame from AP MLD. We can also have an offline discussion on this if you want a more detailed discussion.
[// Xiangxin Gu] Yes, we have to make decision for the tradeoff. Actually I doubt such flexibility make sense in practice.
[VR] Since there are conflicting opinions on this, let us discuss this during the call to see what the group generally prefers, I would be happy to also collect other opinions of this as a response here to preemptively see which option is more preferred.
Regards,
Vishnu
From: 顾祥新 (Xiangxin Gu) <Xiangxin.Gu@xxxxxxxxxx>
Sent: Tuesday, August 16, 2022 12:41 AM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Vishnu,
Thanks for the contribution document 22/1335r0, I have concerns:
- With this mechanism, the AP MLD get easier to operating with EMLSR/EMLMR mode. So it is unreasonable to have a capability item on this.
- The solution doesn’t cover the case that there is no services running over group addressed frames at non-AP MLD side.
- It’s better to put the information in EML Operating Notification frame, which consumes less steps and less signal overhead. I don’t think it’s a good idea to utilize an inefficient way just because we want to cover NSTR case. Actually no CID is related to NSTR. We can have a separate discussion on NSTR.
BR,
Xiangxin Gu
Communication Standards Devision
From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Friday, August 12, 2022 11:18 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Hi Alfred,
Could you kindly add the following document to the MAC queue. It resolves 13 CIDs.
12-Aug-2022 ET
2022
1335
0
TGbe
CR for CIDs related to Group-addressed frame Reception in EMLSR/NSTR
Vishnu Ratnam (Samsung)
12-Aug-2022 11:13:05 ET
In addition, I have uploaded the 1201r1 which is a PDT (in place of 1201r0 which was a ppt). As discussed, could you kindly move that document to the MAC Comment Resolution queue from the contribution queue? It resolves 1 CID.
12-Aug-2022 ET
2022
1201
1
TGbe
ML traffic indication using A-control
Vishnu Ratnam (Samsung)
12-Aug-2022 11:04:33 ET
Thanking you,
Vishnu
From: Edward Au <edward.ks.au@xxxxxxxxx>
Sent: Thursday, August 11, 2022 6:52 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Latest comment spreadsheet on LB266 (11be D2.0) posted
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Dear Alfred and all,
Revision 16 of the comment spreadsheet is posted:
This version updated the status of selected CIDs after the motions on Wednesday, together with a few TTT assignments and PoC reassignment.
Regards,
Edward
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
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.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、 使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。
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.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、 使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。
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
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
