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

[STDS-802-11-TGBE] Fwd: FW: 24/0305r1: Identifying the non-AP MLD with RCM

Hi Mark, All,

 

Forwarding this offline thread on IRM updates for non-AP MLD to the TGbe reflector.

 

Thanks,

Binita


---------- Forwarded message ---------
From: Binita Gupta (binitag) <binitag@xxxxxxxxx>
Date: Thu, May 9, 2024 at 9:17 PM
Subject: FW: 24/0305r1: Identifying the non-AP MLD with RCM
To: Binita Gupta <bingupta.ieee@xxxxxxxxx>



 

Got it. I will upload this revision.

Thanks Binita, Jerome, Po-Kai and other members for your efforts.

 

 

 

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

Hi Jay,

 

Thanks for your response and clarification.

 

I had further offline discussion with Po-kai on the multi-radio device scenario. We concluded that it is fine from the AP side if client uses the same IRM on any of its radio used for sending probe, and it can be in parallel, because probes are sent on different bands/channels and corresponding APs will respond. So, as long as this works on the client side where client can use same IRM on multiple radios (in some cases in parallel), if it wants to be recognized by the network, then Jerome and I are good with a single IRM, which can be used by any of the non-AP STA affiliated with the non-AP MLD.

 

I clarified this on page 12 and 13, that any of the non-AP STA may use the IRM . Please see inline in the attached, plus some other editorials and cleaned up the comments.

 

Thanks for your effort on this.

 

Best regards,

Binita

 

 

Hi Binita ,

 

Thanks for the further comments and suggestion. I will incorporate all the editorial suggestion into the final version.

 

For the following comment, let me clarify as bellow.

 

It's true that a non-AP MLD   may scan all the channels/bands  via mutliple radios in parallel to save time. Let's back to see the corresponding use case in 11bh group

When 11bh group propose IRM  in the probe request frame in pre-association, one use case is to create private BSSID for some special clients based on IRM in the probe request frame. (refer to use case 4.26 in https://mentor.ieee.org/802.11/dcn/21/11-21-0332-37-00bh-issues-tracking.docx ). If we allow a multiple radio non-AP MLD sends probe request on different channels/bands in parallel, perhaps the network will create the same  private BSSID (or AP MLD for MLO ) on different routers due to no enough reaction time, (and then respond with the probe response frame including the same special SSID name in parallel), which will cause the resource waste issue on network side. 

 Also, both non-AP MLD and network need to store multiple IRMs if we allow non-AP MLD provides multiple IRMs during 4-wayhandshake. Some member complain it's too complicated when I propose this solution at the beginning(in R0). To make it simple and easier to be implemented, we change to only IRM solution in the later revision.

Therefore, let's assume the non-AP MLD send probe request on different channels in serial when it includes IRM . 

Hope such clarification can address you concern. And welcome the further comments.

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

Hi Jay,

 

Thank you for your responses and sharing the revised CR doc. I have few additional inline edits in the CR doc in your revised version.

 

RE>>#4: When scanning, only one of the non-AP STA should be able to use the IRM address. Text seems to imply that if multiple non-AP STAs of a non-AP MLD are scanning, they can use the same IRM , which does not seem right.

--><Jay> No sure whether the probe request will be sent by multiple radio/non-AP STAs or single radio on all channels/bands.  And thus I reword this sentence as 

"A non-AP STA affiliated with a non-AP MLD may use that address for active scanning for an AP MLD or ESS that was provided that address, such that the AP MLD may identify the corresponding non-AP MLD "

 What's your thought?

 

Multi-radio devices can perform scan on multiple radios is parallel, and such devices should use a different IRM which is recognized by the AP on each of those radios. Else, we defeat part of the purpose of IRM – where an AP can recognize the STA before the association (e.g. using TA from probe response). For such cases, we could enable a non-AP MLD to provide one or more IRM KDEs in Message 4 and then separate IRM can be used later when scanning on multiple radios in parallel by non-AP STAs . If a device does not scan on multiple radios, then it can provide just one IRM KDE in Message 4.  What’s your thought on that? I think this provides more flexibility to cover both single-radio and multi-radio clients. Others, please share your thoughts as well on this point.

 

Thanks,

Binita

 

 

 

Hi Binita , Jerome,

 

Thanks for the valuable comments. See my response inline in blue font.  Also see the reply in details in the updated CR doc.

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

From: BinitaGupta(binitag ) <binitag @cisco.com>

Date: 2024年04月12日 14:50

Subject: Re: 24/0305r1: Identifying the non-AP MLD with RCM

Hi Jay,

 

Thank you for your contribution on extending RCM to MLO . Jerome and I have reviewed your contribution and have added our comments/suggested edits inline. There are some key aspects below which certainly needs to be clarified in the text. See details inline in the doc.

 

  1. Can the non-AP MLD change both STA MAC address and MLD MAC address while not associated? Current text says it can change either of the two. I assume it can change both as well. Need to clarify.

--><Jay> Yes, both case need to cover,  change it to  "either or both of its affiliated non-AP STA  MAC Address or non-AP MLD MAC address while not associated"

  1. Device ID and IRM exchange does not happen during the association phase as captured in the text. It happens during the 4-way handshake.

--><Jay> In MLO , we only have 4-way handshake case, it's OK to change "during assocation " to "during 4-way handshake"

  1. We are defining a single IRM MAC for the entire non-AP MLD (meaning it is an MLD level IRM MAC), and then using that as TA which is the STA MAC address. We need to explicitly state this, so there is no confusion on this part.

--><Jay>OK, reword the paragragh with the _expression_ like "a non-AP STA affiliated with the non-AP MLD use IRM ....", please find details in the CR document.

  1. When scanning, only one of the non-AP STA should be able to use the IRM address. Text seems to imply that if multiple non-AP STAs of a non-AP MLD are scanning, they can use the same IRM , which does not seem right.

--><Jay> No sure whether the probe request will be sent by multiple radio/non-AP STAs or single radio on all channels/bands.  And thus I reword this sentence as 

"A non-AP STA affiliated with a non-AP MLD may use that address for active scanning for an AP MLD or ESS that was provided that address, such that the AP MLD may identify the corresponding non-AP MLD "

 What's your thought?

Please review and address our comments and let us know if you have any follow-up questions on our comments/suggestions.

 

Thanks,

Binita

 

From: Alfred Asterjadhi <aasterja@xxxxxxxxxxxxxxxx>
Date: Tuesday, April 9, 2024 at 12:16 PM
To: yang.zhijie@xxxxxxxxxx <yang.zhijie@xxxxxxxxxx>, gsmith@xxxxxxxxx <gsmith@xxxxxxxxx>, po-kai.huang@xxxxxxxxx <po-kai.huang@xxxxxxxxx>, liwen.chu@xxxxxxx <liwen.chu@xxxxxxx>, Brian Hart (brianh ) <brianh @cisco.com>, jkneckt@xxxxxxxxx <jkneckt@xxxxxxxxx>, mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>, Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>, Binita Gupta (binitag ) <binitag @cisco.com>, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Subject: RE: 24/0305r1: Identifying the non-AP MLD with RCM

Hello all,

 

This is a gentle reminder to review and provide feedback to Jay on this contribution. Planned SP coming up on April 17th.

 

Regards,

 

Alfred

 

From: yang.zhijie@xxxxxxxxxx <yang.zhijie@xxxxxxxxxx>
Sent: Thursday, March 14, 2024 7:35 AM
To: gsmith@xxxxxxxxx; po-kai.huang@xxxxxxxxx; liwen.chu@xxxxxxx; brianh @cisco.com; jkneckt@xxxxxxxxx; mark.hamilton2152@xxxxxxxxx; Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>; binitag @cisco.com; Alfred Asterjadhi <aasterja@xxxxxxxxxxxxxxxx>; Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Subject: Re: 24/0305r1: Identifying the non-AP MLD with RCM

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Alfred, Binita , Abhi ,

 

Please continue to review the attached doc that I present just now.  And welcome the further comments.

 

 

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

Hi 11bh and 11be experts,

I present the CR document that intends to address the non-AP MLD identification issue in 11be draft today, and update the proposed text as shown in the attachment according to the offline comment.

 I plan to ran the SP on 11be MAC session on Thursday this week. Could you help review it, and welcome the further comment.

 

 

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

 

 

 

 

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