Hi Alfred,
Can you please help me queue doc 11-22/1796 for running SP?
Hi All,
The doc 11-22/1796 resolves comments that are asking to enable multi-link TDLS. I had presented it in late November and we have had follow-up discussions over the reflector (see below) without coming to a conclusion.
I'd like to run an SP and go with the group's opinion.
Regards,
Abhi
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Sunday, December 18, 2022 4:04 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion related to multi-link TDLS [doc 11-22/1796]
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Minyoung, Yongho,
Thank you for your inputs. With the removal of the dot11EHTBaseline… MIB, the spec requires that all frames involved in discovery and setup for TDLS (regardless of whether it is single link or multi-link) are exchanged over a single link.
The proposal in 1796 is consistent with this requirement – i.e., the frame exchange (i.e., negotiation) for multi-link TDLS discovery/setup will occur on a single link. We could delete the ‘only’ to make it clearer.
“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.”
Hi Yongho,
Can you please elaborate on the changes need for AAD construction?
Hi Rubayet,
I agree with you. However, as you are aware, in spite of offline discussions we could not reach consensus on suitable spec text for addressing (NSTR/EMLSR/EMLMR) co-ex issues. Many members are of the opinion that implementations can use
existing tools such as power-save (PM=1 and TDLS Peer PSM indication) along with mechanisms such as channel usage procedures. In other words, standard does not need to provide explicit guidance on this topic. Perhaps, if it agreeable to the group, we can add
a NOTE to highlight the existing tools.
Hi Jay,
“<Jay> The link number of AP MLD is possible less than the non-AP MLD in several cases, e.g. AP MLD removes several links via reconfiguration and leave one link, non-AP MLDs don’t have any chance to setup multiple TDLS connection in this
senario. If so, I don’t believe anyone could buy it. According to my understanding, AP or AP MLD just forwards some of TDLS discover and setup frames in baseline. Why combine the TDLS link number with AP MLD link number, I don’t find any necessity among them.
”
As I explained during the call and in my previous email, the intention is to keep the design simple. The LINK ID is based on the link ID assigned by the intermediate AP MLD (as 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.
We can consider a more generic scenario (i.e., participating non-AP MLDs have more links than intermediate AP) in the next generation.
Regards,
Abhi
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
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
|
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
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
|