Thanks Sharan for your response. Generally speaking, I agree with your suggested change.
Please see my response inline.
Abhi, regarding the BSS parameters, if I understand your proposal correctly, there is no conflict with my sp. Note that the detail is TBD now. What
is your opinion?
Best wishes
Ming Gan
发件人: Sharan Naribole [mailto:n.sharan@xxxxxxxxxxx]
发送时间: 2020年5月27日
2:21
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] SPs in Document 19/0988r2
Hi Ming,
Hope you enjoyed Monday with no TGbe call
J Please find my suggestions/responses below inline.
Thanks,
Sharan
Hello Sharan
Hope you enjoy your holiday now. Please see my response in line.
Best wishes
Ming Gan
Hi Ming,
Thanks for your contribution and extended discussion!
On SP 2, providing all the BSS Specific parameters of other links or even the updated parameters might not be necessary. I have a related contribution
on potential mechanisms to indicate BSS Parameters update of other link(s). Please refer to slides 15-16 in DCN 11-20/226r5. Main objective is to minimize Beacon bloating. This presentation is in the queue.
[Ming] According to your contribution, I think we are in the same page. Now this sp is used to determine a direction. It does not say it will provide
the detailed BSS Specific parameters of other links on one link. Regarding the indication, that is the detail, I leave it to be TBD now (see the bullet of this SP).
[SN] I suggest the following text:
SP 2
•
Do you agree 11be shall define a mechanism for an AP in an AP MLD to indicate BSS specific parameters update for another AP in the same
AP MLD
–
The mechanism specifics is TBD
[Ming Gan]
Based on your suggestion, I change it as follows
• Do you agree that an AP in an AP MLD shall provide BSS specific parameters update
indication for another AP in the same AP MLD
– The detail for BSS specific parameters update
indication is TBD
On SP 4, I agree having “almost” synced TWT SPs would be good for STA MLDs and may be even help AP scheduling. With this approach, at the STA MLD
side, the power consumption of PHY and upper MAC can be reduced compared to completely asynchronous power states/ TWT SPs.
[Ming] Good
[SN] I suggest following text.
SP 4
•
Do you agree that a common TWT agreement could be set up between a AP MLD and a non-AP MLD for more than one setup link?
•
NOTE – The specific TWT parameters common across links is TBD.
[Ming] the same meaning, but to avoid unclear concept “a common TWT”, I would like to use “a TWT”, change it as follows, it is like multi-link setup.
•
Do you agree that the a TWT could be set up
on one setup link between a AP MLD and a non-AP MLD for more than one setup link?
On per-link AID, I did not find strong motivation in your slides. Could you please elaborate?
[Ming] In my contribution, it can be used to for individual addressed BU notification, also can be used for other functions.
[SN] Isn’t the BU at the MLD level considering a TID might be mapped to multiple links. My main concern is that the AID overhead will add up if
AP includes buffered info of other links to each non-AP MLD.
Thanks,
Sharan
Hello all,
Because of no time for Q&A for the following SPs, please let me know if you have comments or suggestion on the wording
SP 2
•
Do you agree that an AP in an AP MLD shall provide BSS specific parameters update for another AP in the same AP MLD
–
The detail for BSS specific parameters update is TBD
SP3
•
Do you agree that an AP in an AP MLD shall provide DL traffic notification for another AP in the same AP MLD for TID-to-Link Mapping
–
The detail for DL traffic notification is TBD
SP 4
•
Do you agree that the a TWT could be set up between a AP MLD and a non-AP MLD for more than one setup link?
SP 5
•
Do you agree that each non-AP MLD should select one link to monitor DL traffic indication and BSS parameter update
Regarding AID per link, I also want to hear the group’s opinion.
Best wishes,
Ming Gan
发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2020年5月21日
23:05
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] TGbe Teleconferences [05/01 and 05/25]: CANCELLED - Reminder
This is a gentle reminder that Monday's (05/25) conference call is
cancelled.
Hello all,
MAC conference call of 05/01/2020, and MAC/PHY conferencal calls of
05/25/2020 are Cancelled as they fall on holidays, which i missed when setting up the calls.
PS: I will see if I can find an alternative day in the available calendar schedules in the subsequent months for replacement sessions.
--
Qualcomm Technologies Inc.
Office #: +1 858 658 5302
--
Qualcomm Technologies Inc.
Office #: +1 858 658 5302
--
Qualcomm Technologies Inc.
Office #: +1 858 658 5302
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