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

Re: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1



Hi Rojan and Laurent, 

I agree that BSSID Index is not clear. 

EHT AP MAC addresses can have a hierarchy and we can pack all address information to the transmitted BSSID. 
The submission 20/865 shows address hierarchy that can make help the STA to derive MLD MAC address from the link specific MAC address and also allow the BSSID-index and LinkId information to be discoverable from the BSSID of the reported RNR. I think this hierarchy can shorten RNR and discovery frames. 

Please take a look. 

Cheers,
Jarkko  


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

Attachment: PastedGraphic-2.pdf
Description: Adobe PDF document



On Jun 10, 2020, at 8:16 AM, Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx> wrote:

Hi Laurent,
 
Thanks for the clarifications, its helpful. I have some further questions, please see inline.
 
Regards,
Rojan
 
From: Cariou, Laurent <laurent.cariou@xxxxxxxxx> 
Sent: Wednesday, June 10, 2020 10:14 PM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1
 
Thanks Rojan,
See below for some responses
Thanks
Laurent
 
From: rojan.chitrakar@xxxxxxxxxxxxxxxx <rojan.chitrakar@xxxxxxxxxxxxxxxx> 
Sent: Tuesday, June 9, 2020 8:41 PM
To: Cariou, Laurent <laurent.cariou@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1
 
Hi Laurent,
 
Thanks for your contributions in Monday’s call. I also had some questions:
 
389r1:
Slide 6: I don’t quite get it how a non-AP MLD receiving this RNR can figure out which MLD a non-transmitted BSSID belongs to based on the BSSID-index. E.g. which MLD does AP2-2.4 or AP3-5 belong to? Are you assuming at least one AP in an MLD is a transmitted BSSID and the BSSID-index is used to point to it? I remember Abhi had a passed SP saying APs in a MLD can be any combination.
[LC] looking at 6 GHz link, there is one transmitted BSSID and 2 non-transmitted BSSIDs. The transmitted BSSID is sending probes/beacons for itself and also for the non-transmitted BSSID. It will then also carry RNR describing APs (in other links) in the same MLD as the transmitted BSSID (at 6 GHz), and APs (in other links) in the same MLD as each non-transmitted BSSID (at 6 GHz). And the transmitted BSSID and the 2 non-transmitted BSSID at 6 GHz are identified by the BSSID-index. (pointer if you like)
In order words, you can see a field included in the Info fields of a reported AP that would say: part of the same MLD as the AP with BSSID-index i in the multiple BSSID set of the reporting AP. 
[RC] I understand the intention but I got confused because in your figure (slide 6) only the APs in the 5 GHz link show the BSSID-index. Is the BSSID-index same as the one below? If so, I wonder if this is enough esp. if the RNR also carries other neighboring Virtual APs that are not collocated, it is very possible that two virtual APs have the same BSSID Index.
 


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

JPEG image

 
390r3:
Slide 4: How does Beacon/regular Probe advertise the MLD information e.g. MAC address, link ID? Within the RNR element? More details about the RNR element (perhaps with a figure) would really help to piece this all together 😊
[LC] we are just discussing the first set of info that we want to make mandatory here in the RNR: operation channel, BSSID, short SSID, BSS parameters, indication that reported AP is part of MLD with xxx. Very likely we’ll want to also have a link ID field in the RNR.
We already agreed to have MLD MAC address be mandated to be included. I don’t think It makes sense to include that in the RNR.
[RC]: Are you referring to SP#32 (An EHT MLD shall indicate its MLD MAC address during ML setup)? It is only for ML Setup, not for Discovery. Can you help to point out where is it mandated in Beacon frames?
 
Slide 9: I asked this during the call as well. My point was that the non-transmitted BSSID profile is almost like a beacon for a non-transmitted BSSID right (except that the info is carried in another AP’s beacons, and many fields may be inherited from the host Beacon frame)? So I was questing why is it that the ML element is included here, but not in the Beacon? If it makes sense to have the ML element here, I would think it also makes sense to include it in the Beacon frames.
[LC] RNR is already present in most of beacons because of 11ax mandate, and is well suited for basic discovery, so it makes sense to use it so that we don’t duplicate info. If we want to optionally include complete info in beacons/probes, as I said, RNR is not the right tool, so we would need ML element in that case to enable to carry all info. Now we’ll see what other info (in addition to the ones we mention in our contribution) we mandate and where (in which element) that fits the best. 
 
Best regards,
Rojan Chitrakar
From: Cariou, Laurent <laurent.cariou@xxxxxxxxx> 
Sent: Tuesday, June 9, 2020 10:31 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1
 
Thanks Ming for the questions and initiating a thread of discussion on this, and glad to see that you like the direction.
 
Based on the feedback, I needed to clarify SP1 so that the text works for all cases (not part of multiple BSSID, transmitted or non-transmitted BSSID in a multiple BSSID set), here’s the adaptation (in green) to the text. That should make things clear:
  • Do you agree:
    • that all APs that are part of the same MLD as a reporting AP and that are collocated with the reporting AP shall be reported in the RNR element that is included in the beacons and the broadcast probe responses transmitted by the reporting AP when the reporting AP is either not part of a multiple BSSID set or corresponds to a transmitted BSSID in a multiple BSSID set.
    • that all APs that are part of the same MLD as a non-transmitted BSSID and that are collocated with the non-transmitted BSSID shall be reported in the RNR element that is included in the beacons and the broadcast probe responses transmitted by the transmitted BSSID that is in the same Multiple BSSID set as the non-transmitted BSSID
      • Note: an AP is not included if it is not discoverable
      • Note: RNR provides basic information (operating class, channel, BSSID, short SSID, …)
 
See inline for your questions
Thanks,
Laurent
 
 
From: Ganming (Ming) <ming.gan@xxxxxxxxxx> 
Sent: Tuesday, June 9, 2020 2:12 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1
 
Hello Laurent,
 
Thank you for presenting the two contributions regarding MLD discovery. I agree with you that RNR is a good direction for basic discovery and MLD element is needed if some specific Probe Request .  I have a few questions
 
Regarding Part 1:
 
1.      In SP 1, what do you mean all APs? Do they contain the Aps which are in the same Multiple BSSID set as the reporting AP. In slide 6, it seems it excludes them. I am fine with the scheme in slide 6.
[LC] hopefully the new text is clear. It maps slide 6. All APs that are part of MLD as transmitted BSSID shall be reported. All APs that are part of MLD with a non-transmitted BSSID shall be reported by the beacon sent by the transmitted BSSID.
 
2.      In SP 2, I understand “same AP” is used to indicate the relationship between the reported AP and the reporting AP. Do you consider the relationship between other reported APs, such as AP2-2.4 and AP3-5 in slide 6, and the reporting AP?
[LC] no, that’s not what it means. As I said, the text just says that we need a way to indicate that the reported AP is part of the same MLD, but does not talk about signaling. For multiple BSSID case, a single bit is not sufficient for sure as there are multiple MLDs that are reported. Our thinking is to use the BSSID-index for that. In the SP, the exact signaling for all cases is TBD.
 
Regarding Part 2:
 
In slide 4, beacon and regular Probe are good. But if AP 1 is in Multiple BSSID set, Multiple BSSID element will be sent in Beacon frame. My question is about the non-transmitted BSSID. If non-transmitted BSSID is in another MLD, do we need a ML element or just simple indication, like BSSID-index, in non-transmitted BSSID profile for basic discovery?
[LC] no need for ML element for basic discovery. As stated above, if a reported AP is in the same MLD as a non-transmitted BSSID, we need a way to link the reported AP to the right AP in the multiple BSSID set, and the BSSID-index is a good fit indeed.
Best wishes
Ming Gan
 
 
 
发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx] 
发送时间: 202069 7:50
收件人: 
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] Candidate SFD text contributions for inclusion to TGbe SFD: Call for Review [REMINDER]
 
Hello all,
 
This is a gentle reminder on this call for review. Please see below.
 
Best Regards,
 
Alfred
 
 
Hello all,
 
Our TGbe Editor has prepared the Rev 26 of the compendium of SPs and potential changes to the SFD, which can be found below: 
 
This is a call for members to review the new SFD text contributions (which are highlighted in yellow  and identified by tags listed as [DCN (Presentation, Author, Affiliation), ...] SP#X, ...) in the compenidum of SPs document.
 
Please do send an e-mail in response to this Call For Review if you would like to identify any of these "new SFD text contributions" as contributions that need further discussion. The deadline for sending these e-mails is June 10th 2020 @10:00am ET.
 
A list of these requested contributions will be queued for discussion and run as a separate motion (Motions >=113) during the Joint conference call scheduled on June 11th 2020.
 
New SFD text contributions that have not received a request for further discussions will be part of the cumulative motion (Motion 112) that will be run at the same Joint conference call. 

Please refer to the document linked below for a list of the motions:
 
For more information please refer to the subclause "Guideline-Building Consensus and Populating the TGbe SFD" in the TGbe teleconference agendas: https://mentor.ieee.org/802.11/dcn/20/11-20-0735-15-00be-2020-mar-may-tgbe-teleconference-agendas.docx.
 
If you have any comments and/or questions please let me know.
 
Best Regards,
 
Alfred
-- 
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #:    +1 858 263 9445
Office #: +1 858 658 5302

 
-- 
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #:    +1 858 263 9445
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