Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

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

Hi Mark,

I quickly check the approved use cases tracking document in 11bh group (https://mentor.ieee.org/802.11/dcn/21/11-21-0332-37-00bh-issues-tracking.docx), Specially in subclause 4.1 Preassociation client steering(AP steering, band steering, network steering).

In the comment part, you marked up as a case to say "Need to consider Neighbor Report ANQP -element" based on the discussion from the group, I guess that's why in current11bh draft, we have the rule to say the IRM can be applied in public action frame.

Personally, I think there is a useful use case in Passpoint network(e.g. 3GPP and Wi-Fi hybrid network), if a STA roams from 3GPP network to Wi-Fi network, the STA may send a ANQP query frame, and the AP will respond with ANQP response frame including NR element. At this moment, based on 11bh identifier, the network can recommend the some serving AP/AP MLD list in NR element. To capture this, I add Basic ML element in Table 9-412—ANQP -element definitions. Please help review it.

Hi TGbe members,

I would like to remind you to help review this documents as well, based on the discussion and the new direction in this mail loop, I add Basic ML element in probe request and ANQP frame to support 11bh feature under MLO framework.

Welcome further comments.

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>

To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;

Date: 2024年05月08日 05:33

Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

HI, Mike,

what is the point of band steering?

I didn’t mean band steering, but AP (that is, the device, not “IEEE AP”) steering. Plus, at least for the short term, we’re seeing a lot of MLD clients that don’t connect on all available bands, and we’d still need to be able to band steer them (perhaps?).

I'd be OK with adding Muti-Link Probe Request frames to the list of frames that could contain the IRM in the Basic Multi-Link element.

That seems like a big help. Good suggestion. Any other public action frames that we really need to round out the use cases? @Yang.zhijie@xxxxxxxxxx: Can you think of significant use cases that would still be missing?

Mark

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, 7 May, 2024 14:25
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi Mark,

In my opinion, the features you are asking for go beyond the scope of the comments.

Even with 11bh with non-MLO , a STA is not required to active scan prior to selecting an AP.

Furthermore, if the device is multi-link (and likely multi-band) what is the point of band steering? You could use TTLM to steer traffic and possibly use link reconfiguration on BTM to steer traffic flow over multiple links.

In any case, a non-AP MLD can elect to do an ML Probe Request which includes an ML element. I'd be OK with adding Muti-Link Probe Request frames to the list of frames that could contain the IRM in the Basic Multi-Link element.

Cheers,

Mike

On Tue, May 7, 2024 at 1:01 PM <mark.hamilton2152@xxxxxxxxx> wrote:

Jay, all,

(NOT as chair, but my individual opinion …)

I know that I haven’t been very active in this discussion (apologies – too much stuff going on). However, I find abandoning any identification of an MLD device while it is pre-association to be too much loss of functionality to support.

This would eliminate:
Pre-association client steering
Which is extremely useful in enterprise and large venue installations
Customer support and troubleshooting
We are going to extreme lengths to solve the WPA3-Personal transition problems (yes, I know, that’s in WFA , but IEEE is talking about it, also) to help providers with support call overload, but we’re going to shoot ourselves in the foot by bringing back complete opaqueness in helping resolve “I can’t connect” issues?
Virtual BSSID
This is catching on as a very powerful tool in “multi-tenant” situations.
We could solve it by requiring an associated non-AP STA to use its same address (TA?) when scanning/probing for AP-AP handoffs , but I suspect the client devices are not going to want to do probes differently depending on context.

These are several of the important advantages that IRM has. We are balancing between two facilities (IRM and Device ID), each has its advantages and tradeoffs , making each useful in different scenarios. If we remove all pre-association support from IRM , in my opinion, we might as well remove IRM . It seems to me that rather than sort out how MAC addresses will be used for MLD devices, we are just “punting” and giving up on trying to solve the problem(s).

I would vote “no” on this direction.

Mark

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, 7 May, 2024 9:10
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi Jay,

Thanks for producing this document. It looks good to me.

Cheers,

Mike

On Mon, May 6, 2024 at 9:53 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:
Hi All,

For 24/305, I received new comments from some members to say, as for the MAC address, the MLD MAC address rather than link MAC address is unique to identify each non-AP MLD . Based on that, in the latest revision 24/305r5, I change the place of IRM from TA field to ML element. Because some frames, like probe request, public action frame don't include ML element according to 11be baseline. I have to drop the relevent use cases in MLO subclause (Maybe these use case are not very strong in MLO senario ) . That's, non-AP MLD may set IRM in MLD MAC address field in basic ML element in authentication and association frame.
Besides, I have some offline checked with 11bh group members and the Chair Mark, they confirmed that the Reassocation case is out of 11bh scope, and 11bh group intends to git rid of them after initial SA ballot. To keep this align with the on-going 11bh draft, I change (Re)association to Association in all occurrences in new subclause .
This is all the change compared with 305r4 that we are ageed with, Welcome futher comments or thought on this.

Hi Alfred,

Could you help put 24/305r5 (https://mentor.ieee.org/802.11/dcn/24/11-24-0305-05-00be-cr-for-rcm-relevant-cids.docx ) to the MAC queue in F2F meeting?

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
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