Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11

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

Hi Jarkko,

For the use case 4.2, I think every member is clear it now, as such implementation already in current market for many years and widely used in all kinds of AP and mobile AP product, why it’s out of 11bh scope? I don’t see the reasonable explanation in your previous mail.

If the IEEE team doesn’t support the current implementation, why we need 802.11bh group, can we propose to dismiss such group right now as it doesn’t help the WIFI industry to address any critical problem.

JKN: The associated STA can send and receive data. In non-associated state, data is not moving and this is not good.

I think it is perfectly OK to wait for 4way handshake.

à<Jay> If the AP doesn’t want a special STA to access, the AP need to complete the SAE procedure and 4 way handshake with the STA, and then disconnect the STA after recognizing it. Seems it’s a stupid design IMHO.

You can ask the AP vendors who adopt such approach today.

For the pre-association activity, the STA can do anything as they did today, like passive scan to find the AP, but the SPEC doesn’t say all the STAs should follow such behavior. Why we can’t improve the use experience if some of STAs want to perform active scan or send other public action frame?

For the AP mute probe response case, in one case, we saw some stupid dual-band capable STAs will associate with 2.4GHz first even if the 5GHz band is very good, but the customer complain its network issue if we don’t do anything to improve it.

For the BTM in the post-association, I post my question in previous mail, please think about how to fulfill the link metric/preference value as I see most members support BTM approach.

The fundamental issue lies in the STA’s behavior are different from different STA vendor, there is no rule in 802.11 SPEC to align all the STA behaviors as you said. From the AP vendor perspective, we need to compatible almost kinds of STAs in WIFI industry. If we can find one or two simple solutions to address such bugs caused by 11aq, why we can’t walk on this direction to improve the use experience and promote the development of WIFI industry?

Thanks

Best Regards

Jay Yang

From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 2022年7月27日 6:21
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

Hi Kurt,

I think we shall use inclusive language, for instance names like blocklist or denylist. In general such lists should be considered as implementation specific issues and they should be out of the scope of 802.11bh.

You are raising issues that some STAs do not want to transition as requested by the BTM Request frame.

I do not know the situations where this happens, but there may be reasons for not following immediately the AP guidance.

For instance, a STA may have D2D data exchange or other radio operating on the link to which the AP is requesting the STA to transition.

I think the STA will select the candidate AP to which it will associate regardless of AP steering.

STAs have sophisticated low power receive radios to continuously monitor the channels. STA is aware of the BSS and OBSSs and the STA needs to be able to select the BSS for association even without network steering.

I can understand how BTM steering works in post-association, but I have no idea how this STA specific preassocaition steering works.

Maybe there could be presentations that explain the basics?

For instance, STA has no clue why an AP would violate 802.11 spec and not respond to a Probe Request. Is the AP assuming that STA will not find it, if it does not send probe responses? This does not seem work well, STA likely finds the AP by doing passive scanning.

Cheers,

Jarkko

On Jul 26, 2022, at 8:42 AM, Lumbatis, Kurt <kurt.lumbatis@xxxxxxxxxxxxx> wrote:

Apologies for the late response.

Currently in the industry there are systems which track non-AP Stations from their historical behavior. They are tracked by several things

Bands Supported
How it reacts to BTM requests (not all STAs react well to BTM Requests) as has been seen in our deployments.
Blacklist(s) on different bands set by the user. (Dad doesn’t want the kids on his band taking his bandwidth)
Blacklists(s) on bands when the BTM didn’t cause the STA to change bands (temporary blacklists) – Oh, the station didn’t move when I sent him a BTM, so I will blacklist him and disassociate him.
Blacklist to NOT respond to Probe Requests on a band based on system settings. To ensure certain equipment ONLY associates with a certain band.

Note that there are some large Over-the-top control systems which utilize this feature to identify the non-AP station pre-association and do pre-association
steering to move it to where the system wants it prior or during association.

This can also be important if a band is very congested, but the STA still tries to join a band when the system may know that it will be better served on another band.

We as a company have seen this feature appear in RFPs from some rather large ISPs.

This is in response to Mark Rison’s questions and perhaps others who have the same questions. It is also a little off the top of my head. There may be other use cases as well.

Kurt Lumbatis

Distinguished Software Engineer

DOCSIS CPE R&D SW Architecture (Wi-Fi)

ARRIS AND RUCKUS HAVE JOINED COMMSCOPE

3871 Lakefield Dr, Suwanee, GA 30024 USA

Office: +01-678-473-2921

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 25, 2022 7:57 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

Hi Mark,

Will have a go at responding:

Graham

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, July 25, 2022 5:48 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

Hello Graham,

Thanks for these pointers.

Use Case 4.1 is labelled “Pre-Association Client Steering” but the description has changed so much that it is now not that clear, and I may not the best expert to describe it correctly as the description therein does not seem to describe the title. However, the idea, as I understand it, is that a mobile probes the ESS and the ESS/BSSIDs recognize the mobile and respond such that the mobile is steered to the “best” BSSID. This can be done before association.

Can't we just use BTM for client steering?

BTM uses action frames, post association. Usually for when the AP is shutting down. Also allowing the Association sort of defeats the objective. If the STA can be steered before association then why not?

Use Case 4.2 is based upon Parental control but generally also covers cases where the mobile may be identified from the Association Request (or directed probes) such that it is allowed (or not) to associate and/or certain settings applied. Conversely, non-recognized mobiles can be dealt with. Also we have similar Use Case 4.3 Home Automation, such as, for example, the lights are switched on.

Why does this need to be done prior to association; why isn't

waiting for the 4WH acceptable?

Again, I understand present apps (prior to RCM) did it pre-association, so why not now? The idea maybe to stop someone associating, not kick them off once associated.

Use Case 4.8 talks about “A managed WLAN network may desire to detect unapproved client stations operating in its service area, even when they do not (cannot) connect to the network”, the converse being Use Case 4.9 “A managed WLAN network may desire to detect unapproved client stations operating in its service area, even when they do not (cannot) connect to the network”.

OK, but why, specifically?

Hey I’m just the messenger. Need an Enterprise expert for this

Use Case 4.6 Grocery Store notifications talks about pre-recognition.

Just to be clear: I'm not saying there are no use cases for pre-association

identification. I'm currently in the "undecided" camp, and trying to decide

which side's arguments I find more persuasive! So

a presentation that hopefully will explain things better vis a vis “pre-association”, the PAR, reassociation, steering, privacy

will be helpful.

I will try

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, 25 July 2022 21:55
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

Hi Mark,

The main idea behind using a “one-time MAC address” is that noting that the fixed MAC address was for many years used as the ‘identifier’, and that is what caused RCM to happen. If the MAC address can still be the ‘identifier’, then applications that used it before, should be able to use it again. The big difference being that now, only the particular BSS/ESS recognizes that one-time address. Hence, Applications that used the MAC Address as the identifier before RCM should be able to be easily adapted, i.e. a true TGbh solution, as per the PAR.

Then, to distinguish the idea of using a “one-time MAC address” from the “Device ID” post association scheme, it became easier to refer to these other schemes, where the non-AP STA can be recognized from the Association Request, as “pre-association schemes”. That is the where the name comes from but it is not true that the so called “pre-association schemes” are restricted to just pre-association, they are simply schemes where the non-AP STA is identifiable from its TA.

Having said that, there are Use Cases of particular interest where the non-AP STA (mobile) is able to be recognized before it associates, including being recognized from the Association Request. The Issues Tracking document 21/0332 is supposed to be the place which captures all the Use Cases but have to admit the definitions and descriptions of those Use Cases is not always that clear.

Use Case 4.1 is labelled “Pre-Association Client Steering” but the description has changed so much that it is now not that clear, and I may not the best expert to describe it correctly as the description therein does not seem to describe the title. However, the idea, as I understand it, is that a mobile probes the ESS and the ESS/BSSIDs recognize the mobile and respond such that the mobile is steered to the “best” BSSID. This can be done before association.

Use Case 4.2 is based upon Parental control but generally also covers cases where the mobile may be identified from the Association Request (or directed probes) such that it is allowed (or not) to associate and/or certain settings applied. Conversely, non-recognized mobiles can be dealt with. Also we have similar Use Case 4.3 Home Automation, such as, for example, the lights are switched on.

Use Case 4.8 talks about “A managed WLAN network may desire to detect unapproved client stations operating in its service area, even when they do not (cannot) connect to the network”, the converse being Use Case 4.9 “A managed WLAN network may desire to detect unapproved client stations operating in its service area, even when they do not (cannot) connect to the network”.

Use Case 4.6 Grocery Store notifications talks about pre-recognition.

Hopefully others will chime in with better explanations and maybe other cases.

As a result of the 15/14 vote, I am working on a presentation that hopefully will explain things better vis a vis “pre-association”, the PAR, reassociation, steering, privacy. Hopefully this will be ready for prime time soon.

Regards

Graham

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, July 25, 2022 12:02 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)

Could I ask the proponents of pre-association identification to succinctly

describe one or more specific use cases where this would be useful, please?

(Or point me at certain slides in a submission, if this has already

been done.)

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Friday, 15 July 2022 13:45
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Mishandled TGbh motion vote

All,

I have made a large mistake, and I apologize to the group.

I failed to properly save the results of the voting on our motion in Thursday’s TGbh session: “In order to meet the PAR, the TGbh Amendment shall include a scheme or schemes that address the pre-association use cases 4.1 and 4.2 in Document 21/332r37”. As a result, while we have the raw vote results (15-14-5, “procedural” voting rules, meaning a 50% passing threshold, so that count results in “Passed”):

Those results cannot be verified. As the vote was so close, clearly if there were any voting irregularities, it could affect the result.
The vote was requested to be a recorded vote, but the detail records are lost, and I don’t believe there is any way to get that information.

At this point, there seems to be nothing I can do, but to apologize to the group and the mover and seconder. Thus, my sincere apologies.

All that said, I would like to remind everyone that even if this motion’s results were properly recorded in detail, those results show that the group is clearly split on this topic. Our work cannot proceed until we find a consensus with support by at least 75% of the members on our technical decisions related to this (and other) technical topics. I strongly suggest that proponents and opponents on these topics PLEASE take some actions to help the group progress.

I strongly encourage discussion, either off-line with individuals that have expressed interest or an opinion to understand each other’s’ opinions, or on the reflector to pull in all the interested members and work toward a broad consensus. A reminder, once again, we need to find a consensus for our work to progress, so when decisions reach an apparent impasse, it is very important to dig in more deeply to understand the root of the disagreement, and try to find compromise.

Thanks. And, again apologies for the process error!

Mark

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1