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

Re: [STDS-802-11-TGBE] SPs in doc 11-20/0356

Hi Yonggang,

 

Thank you for your comments.

 

Please see my response in-line below in purple:

 

Regards,
Abhi

 

From: yfang@xxxxxxxxx <yfang@xxxxxxxxx>
Sent: Tuesday, June 9, 2020 10:36 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re:[STDS-802-11-TGBE] SPs in doc 11-20/0356

 

CAUTION: This email originated from outside of the organization.

Hi Abhi ,

 

Thanks for initiating discussion.  I have some comments in line.

 

Best Regards 

Yonggang Fang

ZTE (TX)

Phone 858-883-7984

Original Mail

Sender: AbhishekPatil <appatil@xxxxxxxxxxxxxxxx>

Date: 2020/06/08 18:24

Subject: [STDS-802-11-TGBE] SPs in doc 11-20/0356

Hi All,

 

I had presented doc 11-20/0356 during last week’s 11be call and deferred the SPs for further discussion.

 

I have made a few updates to the SPs based on offline feedback that I receive so far.

 

Could you please take a look at the revised SPs and let me know if you have additional feedback/suggestions?

 

SP1:

  • Do you agree to define mechanism(s) to include MLO information that a STA an AP of an MLD provides in its mgmt . frames, during discovery and ML setup, as described below?
    • Capabilities and Operational parameter of other STAs of the MLD other than the advertising STA
    • Information common to all the STAs of the MLD
    • MLD (common) Information
    • Per-link information

 [YG ]   "Capabilities and Operational parameter of other STAs of the MLD other than the advertising STA"  could belong to MLD common info or Per-link info. It does not need to be listed separately.

Sorry I dint follow this – any information that is at the MLD level and common to all the STAs of the MLD is advertised as a common. I think you have a copy-paste error. The bullets you listed above a not in the order I have in my SP.

BTW, I received offline feedback to keep the original SP with a note for probe response. So the revised SP would look as follows:

  • Do you agree to define mechanism(s) to include MLO information that a STA of an MLD provides in its mgmt. frames, during discovery and ML setup, as described below?
    • MLD (common) Information
      • Information common to all the STAs of the MLD
    • Per-link information
      • Capabilities and Operational parameter of other STAs of the MLD other than the advertising STA
    • Note: The condition under which a STA of a non-AP MLD includes MLO information in its Probe Request frame is TBD

 In addition, It is better to separate the information included in the Beacon frame from the link setup frame (like association frame) as different frame may require different information of MLD .

I agree with you. In doc 356 and in the SP, it is broad to say as a framework, we would have the ability to provide common and per-link info. The amount of information carry in a Beacon versus an association resp frame will be quiet different – see my example in SP#3

 

SP2:

  • Do you support that the MLO framework should follow an inheritance model to prevent frame bloating when advertising complete information of other links?
    • Note: inheritance mechanism is similar to that defined in 11ax for multiple BSSID feature
    • For example, if an element is not carried in the profile for a link, the value of the element is the same as that of the advertising link

 

SP3:

  • Do you support that an AP of an AP MLD may advertise complete or partial information of other links when possible?
    • Partial information to prevent frame bloating
    • For example, frames exchanged during ML setup are expected to carry complete information while Beacon frame is expected to carry partial information
    • Exact content of partial information is TBD  

[YG ]  If the AP MLD advertises a partial information of other links, if may require extra frame exchange in the link set process which creates the extra delay.  We suggest to remove "or partial" from the SP3. 

We need to be mindful about Beacon bloating but at the same time providing sufficient information so that a non-AP STA would be able to select appropriate APs as candidate set. It is a delicate balance.

We as a group (standard) would need to agree on what comprises of a partial set.

In my view, a Beacon and regular probe response frame is expected to provide partial information of each AP of the MLD. A probe response in response to a directed probe request asking for specific information will carry complete information. The association req/resp frames will carry complete information. This way we have a balance between bloating and providing complete information to the STA.

 

SP4:

  • Do you support that a STA of non-AP MLD shall include in its Probe Request an indication that it supports MLO operation?
    • Note: Exact signaling TBD

[YG ]  Could you please clarify "ML operation":  ML with STR or ML with STR constraint operation as they are different. 

ML operation here refers to the STA supporting multi-link operation of any kind regardless of the constraints (such as STR or n-STR).

 For any kind of ML operation (STR/n-STR or sync/async), we need the two MLDs to exchange their capabilities and parameters for each link (STA instance of the MLD).

 

SP5:

  • Do you support that an AP of an AP MLD shall include MLO information when responding, with an individually addressed Probe Response frame, to a Probe Request frame from a non-AP STA that has indicated support for MLO ?

[YG]  Similar comment as to SP4

 

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