Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi all, I update the text based on received comments. Please review this revision and share your opinion on it. Regards Guogang Huang 发件人: huangguogang [mailto:000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx]
Hi all, I update the text based on received comments. Please review this revision and share your opinion on it. Regards Guogang Huang 发件人: huangguogang
Hi Mark, What do you think if I add the following text “For an AP MLD, a STA affiliated with a non-AP MLD uses the More Data subfield to indicate to an AP in PS mode affiliated with the AP MLD that more BUs, corresponding to Data frames with TIDs
that are mapped to this link by the most recent UL TID-to-link mapping (negotiated TID-to-link mapping or default link mapping, see 35.3.7.1 (TID-to-link mapping)) or Management frames that are not measurement MMPDUs (see 35.3.12.4 (Traf-fic indication)) are
buffered for the AP MLD at the non-AP MLD (see 35.3.7.1.6 (Use of More Data subfield by an MLD)). The More Data subfield is valid in individually addressed Data or Management frames transmitted by a STA (#6581)affiliated with a non-AP MLD to an AP affiliated
with an AP MLD that is in PS mode and in certain control frames as defined below.” Regards Guogang Huang 发件人: huangguogang [mailto:000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx]
Hi Mark, Thanks for your clarification. Please find my response inline. Regards Guogang Huang 发件人: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Hi Guogang, [Guogang Huang] Yes, I get your point. So I modify this current text as following. Please let me know whether it works for you. Thank you, the modification looks fine.
[Guogang Huang]Sorry, I’m not very clear to your question. According to the baseline, the More Data subfield is link-level with the TID-to-link mapping restriction. When the More Data subfield is
set to 0, it means there is at least one buffered BU for the corresponding AP at this affiliated STA. Could you elaborate your question? Please see an example below. The non-AP MLD has 2 MPDUs buffered. It uses a Link Pair in EMLSR, so it cannot predict which link may win an uplink TxOp,
especially when it relies on OFDMA UL (a mandatory 802.11be feature). AP_1 is in Power Save mode, i.e. once STA_1 transmits a More Data = 0 MPDU, AP_1 can enter doze. In this example, if MPDU_y is transmitted over Link 2, AP_1 cannot enter doze, until Link
1 channel is Idle, as the STA missed passing the More Data = 0 info to the correct AP. [Guogang Huang]In this case, STA 1 should send a QoS Null Data frame with More Data="" Thus AP 1 can enter the doze state. The non-AP MLD has the option to hold back transmitting MPDU_y until it gets a TxOp or a Trigger frame on Link 1, but this may never happen. The AP MLD also has the option to only ever use Link 1 with this STA for OFDMA UL, but then EMLSR is pointless. Another potential solution may be to define “More Data = "" for an STA affiliated with an non-AP MLD operating on EMLSR mode means that the non-AP MLD
has no BU for either Link. However, this would require sharing information between the Links which so far I believe has been entirely optional for an MLD (e.g. is used to use to pass Block Ack bitmap info to keep all Link updated). [Guogang Huang] I’m afraid this will conflict the current text shown as follows: Kind regards, Michail [pp Mark] From: huangguogang <huangguogang1@xxxxxxxxxx>
Hi Michail, Thanks for your discussion. Please find my response inline. Regards Guogang Huang 发件人: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
[I am sending this email on behalf of my colleague Michail, who's having trouble posting to the TGbe reflector.] Hi Guogang, Thank you for the contribution and for taking time to answer to our comments. I have 2 comments: The first is in a specific clause; in the new section 35.3.13 you propose:
When an AP affiliated with an AP MLD is operating in the sleep mode,
-
All the existing TWT agreements on this link shall be suspended;
-
All the TID-to-link mapping agreements are teardown and the default TID-to-link mapping is used. Tearing down TID-to-link mapping agreements may be problematic, especially when these agreements have nothing to do with the Link in Sleep Mode. What happens
for TID-to-link mappings which are negotiated after the AP is in Sleep Mode; are these disallowed or cannot be effective either? [Guogang Huang] Yes, I get your point. So I modify this current text as following. Please let me know whether it works for you. Your proposal tries to reuse the existing awake and doze modes, to which I agree with, so power save state of the AP should not interfere with MLD features
which should be managed orthogonally. [Guogang Huang]Thanks for your support on this direction.
My second comments is that the MoreData bit used by the non-AP MLD to signal further BU in the Link, will not very well in EMLSR mode.
In EMLSR mode, the STAs operating on the EMLSR link pair cannot predict which link they will use in the next Uplink TxOp. Therefore the STA may transmit an MPDU with MoreData=1
as it has another MPDU buffered (with More Data="" but the subsequent (More Data="" MPDU may be transmitted on the other (EMLSR) link so the Power Save AP can only rely on the “The
channel has been idle for a given time period.” which may never occur if the channel is busy.
[Guogang Huang]Sorry, I’m not very clear to your question. According to the baseline, the More Data subfield is link-level with the TID-to-link mapping restriction. When the More Data subfield is
set to 0, it means there is at least one buffered BU for the corresponding AP at this affiliated STA. Could you elaborate your question?
Kind regards, Michail From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi all, I have presented my contribution 22/356r5 in the call. But there is no time to take questions. I initiate this email thread to further discussion for doc 22/356. Please let me know your questions and comments. Regards Guogang Huang 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 |
Attachment:
11-22-0356-05-00be-resolution-for-power-save-of-mobile-ap-mld.docx
Description: 11-22-0356-05-00be-resolution-for-power-save-of-mobile-ap-mld.docx