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

Thanks Ming.

With current rules, we would not mandate that BSSID-2x is included in RNR, because it is not in an AP MLD with an AP on the same link as reporting AP.

However, the reporting AP can optionally include that if it wants, and there is 11ax rules that still apply that mandate some behaviors as well.

Let me add a quick note to make that clear. Thanks for bringing clarity to that point.

 

  • 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 on that link 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, …)
    • Note: 11ax rules also apply, and any AP in other AP MLDs can optionally be reported

 

Thanks,

Best regards

Laurent

 

 

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, June 10, 2020 10:07 AM
To: Cariou, Laurent <laurent.cariou@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1

 

A quick response, in the below figure the BSSID-1x is reporting AP and transmitted BSSID. Moreover, BSSID with “x” is transmitted BSSID.

 

发件人: Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
发送时间: 2020年6月10日 23:15
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1

 

Hi Ming,

Can you please clarify in your figure which AP is a transmitted BSSID, which is non-transmitted BSSID, and you are looking into the beacon/probe sent by which AP?

 

For co-located, the intention is to limit the mandate to co-located only for now. As you know, we have defined MLD so that it can also include APs that are not co-located, but have mostly designed the protocol having in mind co-located APs. If there are APs that are non-collocated, they can obviously also be optionally included. We can discuss separately/later if we mandate that also for non-collocated.

BSSID-index: see if response to Rojan answers your question.

 

Thanks

Laurent

 

 

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, June 10, 2020 2:44 AM
To: Cariou, Laurent <laurent.cariou@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] DCN 20-0390r3 and DCN 20-0389r1

 

Hello Laurent

 

Thanks for your response. In the modified SP 1, you may miss the reported AP, such as BSSID-2x, in RNR as per the following figure. By the way, why do you mention “collocated with” in addition to “same MLD”? Don’t you say the APs in the same MLD could be not collocated with each other? After reading the last response below, I got confused about BSSID-Index . Is BSSID-Index an existing terminology in Multiple BSSID element? How does the receiver link the reported AP to the right AP in the multiple BSSID set by using the BSSID-index?

 

Best wishes

Ming Gan

发件人: Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
发送时间: 2020年6月9日 22:31
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: 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]
发送时间: 2020年6月9日 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