Hi Sharan and Ming,
On SP-4 as well the suggested text, what is the definition of the “common TWT” agreement ?
Say, an AP and STA sets up overlapping SPs in two links. I assume in the new design there is a single TWT Flow ID and new fields signaling links where its valid.
Now, if you want to change SP parameters (periodicity, duration..) for just one link without changing the other, how will you achieve it since both have same Flow ID? It seems
to me just as simple and flexible to setup independent individual TWT SPs in each individual link as we do in baseline.
I think what you really want to achieve is to ensure that due to clock drift the SPs on each link don’t end up differing wildly from each other. That is a problem you will
need to solve regardless of how the TWT SP is setup. 426r0 seems to propose a solution for that.
Regards,
Dibakar
From: Sharan Naribole <n.sharan@xxxxxxxxxxx>
Sent: Tuesday, May 26, 2020 11:21 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 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
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.
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
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