Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答���: [STDS-802-11-TGBE] TGbe Teleconferences [03/17/2021]: Agendas Posted



Hello Abhi

 

Please see my response inline.

 

Best wishes

Ming

 

发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
发送时间: 2021318 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]
发送时间: 2021318 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]
发送时间: 2021316 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)    

 

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