Hi All,
I think this is overall a good direction and the TDLS operation over multiple links between two non-AP MLDs would be an important feature for P2P eco-system.
I agree that the co-existence (NSTR/EMLSR/EMLMR) issue is a valid concern, but this is not particular to multiple-link TDLS; the issue can arise also for single link TDLS cases and there are quite a few comments on this. If we can holistically
address the TDLS-coexistence issue for single link TDLS cases, the multiple-link TDLS case would automatically be solved. If needed, this document can be treated in conjunction with the coexistence document.
If there is any issue that is particular to multiple-link TDLS compared to single link TDLS, we can work to address those instead of rejecting the feature altogether.
Best
Rubayet
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, November 30, 2022 3:09 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion related to multi-link TDLS [doc 11-22/1796]
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
Hi all,
In the discussion today and from the emails above, I don't see any technical reasons why TDLS should be extended to support a TDLS link between non-AP MLDs.
Could somebody please explain what the specific technical issues are in supporting this mode? The MIB variable quoted above was removed from the draft and was originally tied to the failed "release strategy".
This feature is valuable and it would be good to understand, at a minimum, what is missing in this proposal.
I have the same comment as Minyoung.
For Draft 2.3 , we already accepted the following changes:
A TDLS (#12242) non-AP STA affiliated with a non-AP MLD
(#10213) that has dot11EHTBaseLineFeaturesImplementedOnly equal to true shall
only negotiate TDLS over a single link.
I understand that all features coupled with dot11EHTBaseLineFeatureImplemented should not be in 11be spec.
Do you want to add more features that we agreed to work in R2, like EHT SST, dynamic preamble puncturing?
Or, do you just want to add only multi-link TLDS that you wanted but the group postponed to R2?
I have a concern that the CR progress is delayed, because of R2 feature discussion.
As discussed offline, adding a new feature is not very helpful to the comment resolution. It can cause more comments in the next round. (Just one example, you need to update 12.5.2.3.3 (Construct AAD)).
I suggest rejecting those CIDs as the group agreed not supporting the R2 feature in the spec based on the discussion of CID 10213.
Hi Abhi,
I wanted to comment that what you are proposing has a conflicting requirement with the following paragraph in the same subclause:
"35.3.21 TDLS procedure in multi-link operation
35.3.21.1 General
When the frames that are exchanged during TDLS discovery or setup do not include a TDLS Multi-Link
element or include a TDLS Multi-Link element containing only the Common Info field carrying only the AP
MLD MAC Address, then the TDLS direct link discovery or setup respectively, is for a single link. A TDLS
(#12242)non-AP STA affiliated with a non-AP MLD
(#10213)shall only negotiate TDLS over a single link."
Hi All,
I presented doc
11-22/1796r0 (Multi-Link TDLS) during today's TGbe MAC call. There were several members in the queue who didn’t get a chance to comment.
I am initiating this email thread to trigger a discussion on the topic.
Here’s a brief description of the comments and the corresponding responses that we discuss during the call:
-
Po-Kai – need to consider channel access rules if the TDLS links form an NSTR pair.
-
Response – agree. However the group has decided (see SP result for 11-22/1586) to let implementations worry about handling such scenarios (i.e., group is of the opinion that the standard doesn’t need to provide any guidance). It is the choice of an initiating
non-AP MLD to initiate TDLS discovery/setup for links that would form an NSTR pair. Similarly it is the choice of the responding non-AP MLD to accept links that would form an NSTR pair. If it helps, a clarification NOTE can be added which says that both peers
need to honor the channel access rules as specified in 35.3.16.x if the links form an NSTR pair.
-
Jason – need to update the sentence related to inclusion of per-STA profile to exclude the link where the frame is sent.
-
Response – agree. The sentence will be updated in the next revision of the doc.
-
Liwen – need to consider a general scenario where the number of links being considered for TDLS discover/setup are greater than those with the intermediate AP (MLD).
-
Response – the intention is to keep the design simple. The LINK ID is based on the link ID assigned by the intermediate AP MLD (it serves as a common reference). Furthermore, TPK generation requires a common trusted entity – which will be the AP MLD’s MLD MAC
address and the BSSIDs of the APs operating on the links that are being setup between the peers.
Regards,
Abhi
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
|