Hi Thomas,
<The only "new" part would be adding some kind of identifier>
A STA sends a Query ID corresponding to Neighbor Report and the AP responds with the ANQP Neighbor Report. How does the AP “know” or “identify” the STA and steer it? Just telling the STA that these APs are in the ESS or the area is nothing more than the STA can gather from its passive scan. Assuming the AP could identify the STA (e.g., from its MAC address), the AP could then decide which BSSs to inform. But this identification has to be pre-association.
Hence, I agree with Joe, it is not simply using ANQP Neighbor Report (which does exist) it is HOW it is used.
Thanks
Graham
From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, August 10, 2022 7:03 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 Joe
The mechanism is not new - it already exists in baseline (ANQP query for Neighbor Report, see 9.4.5.19).
The only "new" part would be adding some kind of identifier, which would apply no matter which mechanism(s) are used.
Best
Thomas
On Wed, Aug 10, 2022 at 4:00 PM Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Jarkko, Thomas, and All
While it may be desirable to implement a new mechanism for pre-association steering, providing a new non-AP STA driven mechanism to replace the prior steering implementations that were based on fixed MAC address is really not in scope for TGbh. Also, there is a significant difference between a network steering a non-AP STA as it sees fit and the non-AP STA asking where it should go.
Hence, I think it is desirable for TGbh to provide a pre-association solution that would allow networks to steer non-AP STAs by allowing the non-AP STA to provide an ID that is known to the network before the STA associates and that does not undermine the privacy gains provided by RCM. Several such mechanisms for providing pre-association ID have been proposed, I suggest we accept at least one of them.
Note that providing a pre-association ID can also be used to address the other pre-association use cases.
Regards,
Joseph
From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, August 10, 2022 6:01 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 Thomas and Jay,
This has become very long email thread. 64 emails according to my mail program.
I would like to second the Thomas main points:
I am not suggesting to drop pre-association steering. I am simply saying that trying to do this based on probe response suppression will be increasingly problematic in the future.
A mechanism whereby a STA can elect to send an ANQP query with some protected identifier, with the intention of receiving a more “intelligently selected”, STA-specific, BSS recommendation list from the network, sounds OK to me in principle. Whether or not STAs elect to use that mechanism will be up to their implementations.
+1 fully agree on this.
I am not going to comment on any specific implementations. More generally, I would note that results obtained in limited test environments can be misleading.
I mentioned earlier that there is an industry trend towards increased use of power efficient passive scanning techniques on client devices. I don’t think this reflector is an appropriate place for implementation-specific discussions, but feel free to contact me offline and I can point you to publicly available references.
+1. Power efficient passive scanning is likely available on the most client devices. These devices have good understanding of available APs.
Cheers,
Jarkko
On Aug 10, 2022, at 2:47 PM, Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Jay
Thanks for both your mails. A couple of brief responses as follows:
As you know, the latency of AR/VR application talked in IEEE other group is less than 10ms, I doubt whether we can address the broken issue in AR/VR business in current and WIFI7 BSS transition solution if we still insist on current status.
AR devices are likely to be in mobility, so if they (or their companion device) are connected to infrastructure network, they will likely need to transition between BSSs as they move location anyway. FT and FILS protocols can in practice achieve L2 outage less than the target you mention above. Devices that need low-latency transitions should implement those features. Sure those are optional capabilities, but I don’t think it’s effective to add new optional features in the standard in the hope of addressing implementations that do not implement optional features that already exist in the standard.
All of them will cause the complicated implementation on AP side if we drop the pre-association Client steering solution totally.
I am not suggesting to drop pre-association steering. I am simply saying that trying to do this based on probe response suppression will be increasingly problematic in the future.
A mechanism whereby a STA can elect to send an ANQP query with some protected identifier, with the intention of receiving a more “intelligently selected”, STA-specific, BSS recommendation list from the network, sounds OK to me in principle. Whether or not STAs elect to use that mechanism will be up to their implementations.
Seems it’s possible to keep some implementations based on identifiable probe in pre-association phase.
<snip> As you know, the active scan is more efficient approach to find the APs in short time in WIFI industry,
I am not going to comment on any specific implementations. More generally, I would note that results obtained in limited test environments can be misleading.
I mentioned earlier that there is an industry trend towards increased use of power efficient passive scanning techniques on client devices. I don’t think this reflector is an appropriate place for implementation-specific discussions, but feel free to contact me offline and I can point you to publicly available references.
Best
Thomas
On Aug 8, 2022 at 3:18:03 AM, "Yang, Zhijie (NSB - CN/Shanghai)" <zhijie.yang@xxxxxxxxxxxxxxx> wrote:
Hi Thomas,
I start to doubt the following description after we done some tests on some modern cellphones(S21 and iphone12) in different scenarios(see them in attachment), the conclusion is that the active scan is a general behavior on them after WIFI function enabled.
Please note such test was done in shield room, and there is no doubt these probe request frames are sent by the cellphone although in different RMAs.
Seems it’s possible to keep some implementations based on identifiable probe in pre-association phase. Actually, I’m struggling to understand the passive scan only operation on STA side in pre-association, it’s better you can clarify more on the use case.
As you know, the active scan is more efficient approach to find the APs in short time in WIFI industry, I don’t believe any STA vendor plan to drop it.
“My general point is that a STA (particularly a modern one) might or might not send a probe request as part of a scan, and whether or not it sends a probe may depend on many factors.”
Thanks
Best Regards
Jay Yang
From: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Sent: 2022年7月30日 1:24
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)
Hi Jay
Thanks for your response. Let me respond to the technical parts first:
My general point is that a STA (particularly a modern one) might or might not send a probe request as part of a scan, and whether or not it sends a probe may depend on many factors.
For 6 GHz scan, yes in general the standard permits (SSID/BSSID)-directed probe requests to be sent, although there are some restrictions (see 26.17.2.3.3) depending on whether the STA has already received indication that an AP should be present on the channel (e.g. RNR, NR), which channel it is (PSC vs non-PSC), whether or not the STA has already received a beacon or (broadcast) probe response from the corresponding AP, etc. In practice there are also regulatory constraints, e.g. the STA must determine a permissible transmit power for the probe based on the AP(s) present on the channel.
However, even in cases where the standard permits sending a probe request, it does not mean the STA will actually send a probe in practice (e.g. it may well elect to use passive scan instead). This not only applies to 6 GHz but other bands too (see point (a) in my previous mail).
In addition, in the event that the STA sends a probe but the AP tries to influence its join decision by electing not to respond, the STA might still end up discovering the AP. In particular, if the STA already expects the AP to be present (e.g. due to out-of-band RNR), and does not receive a probe response that it expected, it may well fallback to passive scan on that channel instead. Even if it does not do so, the STA might end up receiving a beacon or (broadcast) probe response during its on-channel dwell time prior to sending the probe request (e.g. dot11FILSProbeDelay) or while waiting for a response.
Regarding out-of-band RNR transmission, it is mandatory for a colocated AP to send RNR in 2.4/5 GHz bands that advertises the 6 GHz BSSs (see 11.53).
In principle, I agree there may be some subset of STAs whose implementations always try to use active scan when permitted. Selective probe response suppression techniques might be more effective for such STAs, at least in 2.4 and non-DFS 5 GHz bands.
However, the standard does not provide any mechanism by which an AP can identify STAs that have such implementation.
(As an aside, I’m not sure fixed IoT devices are the best example to use here, as they can be readily handled by post-association steering since they are not in mobility).
To be clear, it is not the job of this TG to restrict “special sauce” techniques that might be implemented by AP vendors to help optimize their networks, assuming those techniques are (broadly) compliant with the standard.
However, I do not think the standard should endorse, or introduce new features that are solely intended to support, techniques that (in my view) cannot be designed in a robust manner.
Thanks
Thomas
On Jul 28, 2022 at 3:49:15 PM, "Yang, Zhijie (NSB - CN/Shanghai)" <zhijie.yang@xxxxxxxxxxxxxxx> wrote:
Hi Thomas,
I agree some of your points, 11bh group should provide the solution on these implementations, like NR in ANQP, association rejection and AP metric collection.
But I think the following description need more discussion to decide whether 11bh group need to address RCM issue in discovery phase:
. Specifically, while historically most-all client devices have performed discovery using exhaustive active scan (sending probes), this is no longer true due to:
(a) implementation of power-efficient passive scanning technologies on client devices, and
à<Jay> It’s up to STA product variant , It’s true for the mobile STA that relies on battery power is in favor of passive scan. But if you look at current IOT/fixed STA product in the market, which is powered by the cable, active scan is still widely used as it’s a fast way to find the AP. For AP vendor perspective, they need consider to improve the user experience on IOT device as well.
(b) standards-defined rules that constrain probe request transmission by clients (FILS, 6 GHz, ..), and
à<Jay> There is no much constrain for the directly probe on 6GHz in current SPEC, and thus 11bh group can consider only apply the solution on directly probe.
(c) use of out-of-band discovery (and standards-defined rules for advertisement of such information) such that discovery of a given BSS also results in discovery of other BSSs
à<Jay> The current SPEC also mentions the AP can decide one or more neighbor APs/co-located AP in RNR element can be discovered by some STAs, right?
Referenced SPEC sentence:
(1)An AP that intends to report neighboring or co-located APs may include more than one Reduced Neighbor Report element in a Beacon,
Probe Response or FILS Discovery frame, if the reported APs do not all fit in a single Reduced Neighbor Report element; otherwise, it shall not include more than one Reduced Neighbor Report element.
(2)“the AP operating in the 6 GHz band does not intend to be discovered by STAs”
Thanks
Best Regards
Jay Yang
From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 2022年7月29日 1:48
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)
Thanks Mark, all.
I agree in general with your description of the 11bh scope. However I think part of the disagreement here relates to the level of detail and assumptions associated with a given use case.
For example, there is a substantial difference between 11bh addressing a use case where "a network can influence which BSS in a network an RCM client initially connects to” (a high level use case)…
vs 11bh addressing a use case where “a network can influence which BSS in a network an RCM client initially connects to by correlating multiple probe requests sent by the client and selectively suppressing probe responses” (a use case and a description of a specific technique used).
While the specific technique described above has been effective for legacy clients (and, yes, deployed quite broadly for many years), it relies on multiple assumptions on client behavior which are not mandated in the standard and (I am asserting) are no longer valid for many modern client devices. Specifically, while historically most-all client devices have performed discovery using exhaustive active scan (sending probes), this is no longer true due to:
(a) implementation of power-efficient passive scanning technologies on client devices, and
(b) standards-defined rules that constrain probe request transmission by clients (FILS, 6 GHz, ..), and
(c) use of out-of-band discovery (and standards-defined rules for advertisement of such information) such that discovery of a given BSS also results in discovery of other BSSs
Given this particular technique is “broken” not only by RCM but also by other capabilities in the standard and other (standards-compliant) client implementations, I do not think it is in-scope for 11bh to try to “fix” the RCM aspects of the issue given that, even if those are fixed, the technique itself will still not be viable.
Rather, we should focus on other (preferably standards-defined) capabilities to achieve same/similar high-level objective, and ensure those will work with RCM clients.
Examples of these capabilities include Neighbor Report ANQP element, association rejection / comeback delay, and AP metrics that influence clients’ BSS join decisions based on link quality assessment.
These might or might not be 100% equivalent to the legacy techniques from a functional perspective, but really that is irrelevant given the above.
Thanks
Thomas
On Jul 27, 2022 at 7:18:15 AM, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
All,
(This time, with my Chair hat on…)
I would just like to note to those following this thread, that we seem to have left the discussion of understanding this use case (or these use cases), or discussing whether this is a use case that used to work (before RCM) and has been broken by RCM. Rather we now seem to be discussing whether we think it is a good thing/necessary to make this use case work again, or if some other approach is preferred.
I don’t mean to pass any judgment on such discussion, but I’ll note that our scope was to consider use cases that used to work, and have been broken. Whether the “solution” to those situations should be to replace the prior operation, or require deployments to use other alternative methods to accomplish similar results, is getting into a grey area.
Just something to keep in mind, before we get too far into debate over preferred ways to address these scenarios.
Mark
From: Luther Smith <l.smith@xxxxxxxxxxxxx>
Sent: Wednesday, July 27, 2022 7:21 AM
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 Jarrko,
As to 4.2 which does indicate parental controls, as Jay indicated, I have not found any APs that support multiple non-802.1X credentials on a single BSS. This means that separate BSSes would need to be setup/configurated on the AP to handle different network. Like wish I have not found any COTS/non-enterprise APs that support 802.1X networks using an internal AAA for authentication, all have required an external AAA (Not many deployments of COTS/non-enterprise have an AAA in the network).
This also goes beyond just parental control, in some locations (countries) an AP operator can be fined for not knowing who is on their network. https://www.zdnet.com/article/five-bar-and-cafe-owners-arrested-in-france-for-running-no-log-wifi-networks/ Base on this we get into legal investigation and intercept. The way these devices are identified, tracked, and if needed traced is via their MAC addresses. While TGbh addresses how MAC addresses could be anonymized, there remains the needs of identifying a device. As part of this, in some countries it is legal to even allow the device to connect to the network. The question is what determines “connect to the network”. As indicated this was done through access/deny lists which have been based on MAC addresses and the rejection of the association. I have to be honest, I do not know at which point is the device rejected, has the association process started or is the initial association message from the STA just ignored (This is a question for an AP vendor).
Back to the parental control is the inclusion of a mess network, extender APs have different BSSes for the like SSID, so the device would have to maintain the same RCM MAC address for the extender AP as the main AP to allow the device to be under any control (be it parental or other reason access/deny is needed).
Respectfully
Luther
Luther E. Smith
Director Wireless Access Technologies/ Distinguished Technologist
CISSP
303-661-3305 voice
303-661-9199 fax303-931-1759 mobile
From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Tuesday, July 26, 2022 10:07 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 Jarkko,
See my response inline in red font.
Thanks
Best Regards
Jay Yang
From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 2022年7月27日 10:17
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Pre-association identification (was: [STDS-802-11-TGBH] Mishandled TGbh motion vote)
Hello Jay, thank you for your comments.
On use case 4.2, parental controls, there has been long debates on this use case.
Maybe better solution is to setup a separate network for adults and kids, or have different credentials for them, than try to identify the devices by their MAC addresses.
à<Jay> Even if we follow you suggestion to set up different BSSes for the adults and kids, when the parent decides to close the kids’ internet service at a special time slot, how to do it? A simple solution is that the network disconnects the kids’ client, and reject the further association request sent by the client. Actually, such proposal is still based on the MAC address identification.
If I understand correctly, different credentials on same BSS is impossible for non-802.1X network. If you propose multiple SAE identifier solution, I don’t know which STA support such feature in current implementation, at least Iphone device doesn’t support it according our study.
Anyway, if you have a better solution, it’s better to give the whole story and whole picture, so that the AP vendor can evaluate it and check whether it’s implementable or not.
In pre-associated steering there seems to be big interest to steer the STA to operate on one specific AP.
Some STA implementations are capable to operate simultaneously on 2.4 and 5 GHz BSSs. These devices lose the benefits of operating in two BSSs, if they are steered to a single network.
Simultaneous operation in two BSS has similar benefits as 802.11be MLD association.
à<Jay> Seems you misunderstand Kurt’s and my comments. As Kurt mentioned, the pre-association steer is based on the historical behavior of the STA as well as STA’s capability information, if the AP already know an approved STA that has the dual MAC and is capable to operate on 2.4GHz and 5GHz simultaneously, why it rejects the 2.4GHz connection and allow the 5GHz connection only?
For the 11be MLD association, the AP MLD is easy to determine whether these links belongs to one non-AP MLD or not based on non-AP MLD MAC address, and thus such implementation is still forward compatible with WIFI7 devices.
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.
This sentence is not fully clear to me. Are you saying that the network has difficulties to set the Candidate AP preference value for the STA? Why that is STA’s problem?
à<Jay> Actually, the whole procedure is already discussed in the previous meeting, and all group members agree with it at that moment. I copy the procedure as bellow from the contribution(https://mentor.ieee.org/802.11/dcn/22/11-22-0818-03-00bh-use-case-further-discussion-and-rule-based-random-mac-identification-proposal.pptx ), so that you can review each steps.
[Network topology] Gateway connects with AP2,AP3 via wired/wireless backhaul.
(STA1) connects with Gateway in the initial association.
(STA1) moves from L1 to L2 and the GW(Gateway) detects the RSSI lower than a predefined threshold.
(GW) sends a Beacon request frame to instruct STA1 to send a probe request frame to AP2 and AP3 on their operating channel respectively.
(AP2, AP3) calculate and report the CSI and RSSI information of the received probe request frame from STA1 to Gateway respectively .[identified probing]
(AP2,AP3) respond with probe response to STA1.
(STA1) send Beacon report based on the received probe response frame to the GW
Note: the Beacon report has the RSSI information of the target APs, but no CSI information of them.
(GW) generates the preference list based on AP2 and AP3’s report, send a BTM request frame containing the prefer list(like AP2) to STA1.
(STA1) associates with AP2 via FT based on the preference list(like AP2) in the BTM request frame
Cheers,
Jarkko
On Jul 26, 2022, at 4:08 PM, Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> wrote:
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
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
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