Hello Abhi
Please see my response inline.
Best wishes
Ming
发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
发送时间: 2021年3月18日
11:35
收件人: 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,
Thanks for the quick response.
>>
[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
Per the definition of Listen Interval, the non-AP will not listen to beacons
before 300ms:
[Ming] It is allowed, the listen interval is the maximum allowed period for doze state, please refer to the following sentence in the Revmd, the
following sentence the STA need send at least frame every listen interval, that is to say, it could be before 300ms
The STA with dot11NonTIMModeActivated equal to true is not required to wake up to receive a Beacon frame and shall transmit
at least one PS-Poll or trigger frame that is individually addressed to the associated AP every listen interval starting from the last known transition of the S1G STA in non-TIM mode
in doze state
Or are you saying the non-AP can listen to beacons after 300ms? I do not think this is correct since AP can only buffer its DL BU for 300 ms.
Moreover, we can not make each STA affiliated the non-AP MLD to wake up at exactly same time slot as TBTT (the last beacon reception time) + Listen
interval since this interval value can not be multiple of each beacon interval on each link.
>>
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.
Per the definition of LI, the non-AP will wake-up to catch the beacon after 300ms – if it is monitoring link 2, it will be the beacon at 400ms. If it is link 3,
then it will be the beacon at 350ms
[Ming] So you are saying
the non-AP can listen to beacons after 300ms? This conflicts with what you said in your previous email, I copy it here. Now it is not “up to”, it is longer
than 300 ms, which is not requested by non-AP MLD.
NOTE – the LI is 300ms, therefore the non-AP MLD is expected to be in doze state for up to 300 ms.
Regards,
Abhi
From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, March 17, 2021 8:10 PM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
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 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