| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi All, Even though the straw poll result is to reject the comment with no change, I still strongly believe the problem exists in the draft and needs to be addressed. Neglecting the mandatory statement in the draft is not a correct way to proceed. I would like to answer to the questions asked during the presentation yesterday.
Q. There is a similar issue in EMLMR. A. Yes. There is the same issue which the comment and the document are pointing out. The EMLMR operation is similar to the EMLSR operation, and the EMLMR operation also defines ‘End of frame exchange’ conditions which is very similar to the EMLSR. I believe the proposed change in the document can also be applied to EMLMR without any change. In conclusion, the EMLSR and the EMLMR have the same problem related to the TXS operation. Once the solution regarding EMLSR in TXS operation is agreed, the same modification can be applied to EMLMR in TXS operation as the following: Within a TXOP initiated by an AP affiliated with AP MLD with an EMLMR STA affiliated with a non-AP MLD as the TXOP responder, the non-AP MLD shall switch to its per-link spatial stream capabilities defined by the EHT Capabilities element or the current operating mode (if different from the EHT Capabilities element) per (EHT) OM Control or Operating Mode Notification element after the time indicated in the EMLMR 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 exchange sequence: — The MAC of the STA affiliated with the non-AP MLD that received the initial frame does not receive a PHY-RXSTART.indication primitive and does not transmit a PHY-TXSTART.request primitive and receive a PHY-TXSTART.confirm primitive during a timeout interval of aSIFSTime + aSlotTime + aRxPHYStartDelay starting at the end of the PPDU transmitted by the STA affiliated with the non-AP MLD as a response to the most recently received frame from the AP affiliated with the AP MLD or starting at the end of the reception of the PPDU containing a frame for the STA from the AP affiliated with the AP MLD or from another STA that does not require immediate acknowledgement or starting at the end of the PPDU transmitted by the non-AP STA that includes a frame a frame with an Ack Policy field that indicates No Ack. Q. In reverse direction case, a similar problem to TXS scenario can occur. However, the document’s proposed solution does not consider RD case. A. The solution option 2 can also resolve the issue related to the RD operation. If you think the proposed solution is not enough, please let me know which change cannot resolve the issue. When an AP is the RD initiator and a non-AP STA is the RD responder. To grant RD, the AP shall transmit initial Control frame to the non-AP STA and receive a CTS frame from the non-AP STA. Then, the AP can send a frame with its permission to the RD responder(the non-AP STA) using RDG. The non-AP STA can transmit a frame in the RD. After receiving the frame with RDG, the non-AP STA can:
In case of 1, current time(aSIFSTime + aSlotTime + aRxPHYStartDelay) starting condition after immediate response frame can lead to the correct behavior. No spec text change is required. In case of 2, there is the same issue which the comment and the document are pointing out. A time of aSIFSTime + aSlotTime + aRxPHYStartDelay starts after transmitting an immediate blockACK, after SIFS, the data frame transmission begins which is before the time(aSIFSTime + aSlotTime + aRxPHYStartDelay) ends. In this case, the non-AP STA shall be switched back to the listening operation after the time. Because this issue is same as TXS case, the proposed change in option 2 can resolve this issue. In conclusion, the proposed modification can resolve the issues in both RD and TXS. Q. The proposed solution is too bulky to change. A. In the document, I clearly stated why we have to change the spec to resolve the issue. “’No change to the spec’ forces implementors to neglect mandatory statement. If an implementation neglects the mandatory statement of not returning to the listening operation, there is no condition of returning to the listening operation after PPDUs transmission (issues #3-1 and #3-2).” I hope this e-mail can explain the concerns about the comment and the document. Best Regards, 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 |