Hello Abhi
Thanks for your comments. Please see my response inline
Best wishes
Ming gan
发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
发送时间: 2021年3月18日
10:13
收件人: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/17/2021]: Agendas Posted
Hi Ming,
Thank you for preparing the PDT.
The spec needs to provide guidance for the case when the link with the max BI is not accepted by the AP MLD.
Without such clarification, a non-AP MLD will lose frames.
Let’s assume an AP MLD had 3 links and AP 1 had BI=300ms, AP2 had BI=200ms and AP3 had BI=70ms.
During assoc, non-AP MLD requested LI=1 in assoc req frame.
Per the current motion, listen interval is in units of max BI. This means the requested listen interval value is 300ms
Now, it is possible that the AP MLD does not accept link 1 (corresponding to AP1). So the ML setup consists of link 2 (200ms) and link 3 (70ms).
What is the minimum duration for which the AP MLD buffers frames intended for the non-AP MLD in this situation?
[Ming] The minimum duration for which the AP MLD buffers frames is the listen interval value, that is LI*unit=300ms
If you say it is 300ms, then as shown in the figure below (fig 1), the non-AP MLD will be losing frames.
NOTE – the LI is 300ms, therefore the non-AP MLD is expected to be in doze state for up to 300 ms.
[Ming] The non-AP MLD is expected to be in doze state for up to 300 ms, but non-AP MLD will not lose any frame. During this 300 ms, the AP MLD will
send at least one beacon in either link 2 or link 3. So the non-AP MLD could receive at least one beacon during this 300 ms such that it can retrieve the DL buffer for the associated AP MLD
If you are expecting the non-AP MLD to listen to the beacon at 200ms (if monitoring link 2), or the beacon at 280 ms (if monitoring link 3), then the requested
LI value of 300ms has no meaning.
[Ming] It is non-AP MLD’s choice, it can choose to receive beacon either at 200 ms by using STA2 or at 280 ms by using STA 3. it is up to 300 ms.
Listen Interval feature is meant to aid power-save operation on the client device. A client device requests a listen interval value based on its local power constraints.
If the spec requires the client to wake-up sooner than the specified LI, it can have severe impact on the power-savings.
[Ming] Not severe, 280 ms approximates to 300 ms. This is negotiation, if the request interval is too large, AP also could reject it. If this is
not satisfied (server impact), non-AP MLD can choose to do disassociation.
Given that AP has more resources and is not power constraint, it makes sense for the AP to buffer the frames longer so that the client can benefit.
In this example, if the AP were to buffer the frames for up to 400ms (fig 2), the requested LI is satisfied and the client will not lose any frames regardless
of which link it decides to monitor.
[Ming] this proposal is bad and violates the motion. The changed value is not requested by non-AP MLD, AP should use the requested interval to buffer
frames.
In fig 2, the max duration of doze state in 300 ms and the AP buffered BU for 400 ms, then when does non-AP MLD wake up? at 200ms (if monitoring
link 2) or at 280 ms (if monitoring link 3)? You still requires the client to wake-up sooner than the specified LI, but you change the requested interval at the AP side which does not make sense. On the other hand, you mean the non-AP MLD wake up at 300ms,
then it wastes power since there is no beacon sent on any link. Or you say at 400ms (if monitoring link 2) or at 350 ms (if monitoring link 3), then this violates the request value, note that the max duration of doze state in 300 ms.
I would like to get the group’s view on this topic and make sure everyone understands the implication if we put a requirement that the client is expected to wake-up
sooner than the requested LI.
Fig 1: Non-AP MLD will lose frames if the AP MLD buffers for only 300ms
Fig 2: AP MLD buffers for at least 400ms.
Regards,
Abhi
From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, March 17, 2021 6:12 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/17/2021]: Agendas Posted
CAUTION: This email
originated from outside of the organization.
Hello Alfred
Could you help add the SP about the following contribution into agenda
11-21-0082-01-00be-pdt-mac-mlo-power-save-listen-interval SP
https://mentor.ieee.org/802.11/dcn/21/11-21-0082-01-00be-pdt-mac-mlo-power-save-listen-interval.docx
Best wishes
Ming
发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2021年3月16日
4:17
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] TGbe Teleconferences [03/17/2021]: Agendas Posted
Hello all,
I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Wednesday, March
17 (MAC/PHY), 10:00-12:00 ET.
The agendas can be found here:
https://mentor.ieee.org/802.11/dcn/21/11-21-0385-05-00be-mar-may-tgbe-teleconference-agenda.docx
DIAL IN DETAILS FOR WEDNESDAY:
Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=mfb2eb674f949c8c6823ca5a367ae501a
Meeting number: 129 723 0407 Meeting password: wireless (94735377 from phones and video systems)
Join the PHY meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=mc9ba8ba8d04b96937f3fbda4d419a8e3
Meeting number: 129 582 0621 Meeting password: wireless (94735377 from phones and video systems)
Notice: Please note that by now all authors of the submissions for PDTs and CRs (especially MAC) should have sent requests for feedback to the IEEE TGbe reflector. Members are invited to provide feedback
for these contributions prior to the conference call via e-mail so that the time in the conf calls is used efficiently.
Best Regards,
Alfred
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