datastorage/uci/msghandler/ubus: add steering with beacon reports #126

PolynomialDivision · 2020-09-06T21:37:41Z

The AP periodically asks all clients in the environment with what signal strength they see the other APs. Instead of the RSSI, which can only be collected if the client scans, the 802.11k values are much more up-to-date.

In the future it will no longer be necessary to exchange all probe request frames with all APs, which will significantly reduce the message overhead and complexity.

Right now there is the issue that clients react very strangely to becaon requests or they do not react at all.

The client will hopefully report back the RCPI or the RSNI.

Theoretically the values can be converted into each other and so compared, but this did not work well in self-experiments. Therefore, we compare the values like the rssi.

We introduce

rcpi: value that is added to the AP score if rcpi is above rcpi_val
rcpi_val: threshold that indicates a good rcpi value (between 0 and 255)
low_rcpi: value that is added to the AP score if rcpi is under low_rcpi_val (use a negative value)
low_rcpi_val: threshold that indicates a bad rcpi value (between 0 and 255)
rsni: value that is added to the AP score if rsni is above rsni_val
rsni_val: threshold that indicates a good rsni value (between 0 and 255)
low_rsni: value that is added to the AP score if rsni is under low_rsni_val (use a negative value)
low_rsni_val: threshold that indicates a bad rsni value (between 0 and 255)

I have to find out values for each parameter myself. So please take a look at the dawn-hearingmap and if you have a good setting, you can send it to me.

It is necessary that u add those values to the config file!

Here is an example, but I have no idea if those values are okay!

config metric
    option rcpi '50'
    option rsni '50'
    option low_rcpi '-1000'
    option low_rsni '-1000'
    option rcpi_val '150'
    option low_rcpi_val '50'
    option rsni_val '150'
    option low_rsni_val '50'
    ... (the rest of the config)

morhimi · 2020-09-07T06:02:54Z

src/storage/datastorage.c

@@ -426,8 +426,21 @@ int eval_probe_metric(struct probe_entry_s* probe_entry, ap* ap_entry) {
    // TODO: Should RCPI be used here as well?
    // TODO: Should this be more scaled?  Should -63dB on current and -77dB on other both score 0 if low / high are -80db and -60dB?
    // TODO: That then lets device capabilites dominate score - making them more important than RSSI difference of 14dB.
-    score += (probe_entry->signal >= dawn_metric.rssi_val) ? dawn_metric.rssi : 0;
-    score += (probe_entry->signal <= dawn_metric.low_rssi_val) ? dawn_metric.low_rssi : 0;
+    if (probe_entry->rsni != -1) // -1 currently magic number


did you mean probe_entry->rcpi ?

yeah thanks.

The AP periodically asks all clients in the environment with what signal strength they see the other APs. Instead of the RSSI, which can only be collected if the client scans, the 802.11k values are much more up-to-date. In the future it will no longer be necessary to exchange all probe request frames with all APs, which will significantly reduce the message overhead and complexity. Right now there is the issue that clients react very strangely to becaon requests or they do not react at all. The client will hopefully report back the RCPI or the RSNI. Theoretically the values can be converted into each other and so compared, but this did not work well in self-experiments. Therefore, we compare the values like the rssi. We introduce - rcpi: value that is added to the AP score if rcpi is above rcpi_val - rcpi_val: threshold that indicates a good rcpi value (between 0 and 255) - low_rcpi: value that is added to the AP score if rcpi is under low_rcpi_val (use a negative value) - low_rcpi_val: threshold that indicates a bad rcpi value (between 0 and 255) - rsni: value that is added to the AP score if rsni is above rsni_val - rsni_val: threshold that indicates a good rsni value (between 0 and 255) - low_rsni: value that is added to the AP score if rsni is under low_rsni_val (use a negative value) - low_rsni_val: threshold that indicates a bad rsni value (between 0 and 255) I have to find out values for each parameter myself. So please take a look at the dawn-hearingmap and if you have a good setting, you can send it to me.

namidairo · 2020-09-11T07:46:55Z

The client will hopefully report back the RCPI or the RSNI.

On that note, I stumbled across this today while messing with an AX200...

It sounds like a Technicolor engineer is having some problems with inverted RCPI values on some Intel clients? 🤔

https://community.intel.com/t5/Wireless/Intel-R-Wireless-AC-9560-160MHz-reports-incorrect-RCPI-for-all/td-p/1207943

So I tried some beacon reports from my AX200...

Normal signal:

{"objid":955158769,"method":"beacon-report","data":{"address":"08:d2:3e:xx:xx:xx","op-class":128,"channel":149,"start-time":0,"duration":3,"report-info":8,"rcpi":144,"rsni":255,"bssid":"88:c3:97:xx:xx:xx","antenna-id":0,"parent-tsf":194},"no_reply":true,"user":"root","group":"root"}

Antennas removed: (Well, can't exactly just move it further away, it's deployed in a desktop...)

{"objid":955158769,"method":"beacon-report","data":{"address":"08:d2:3e:xx:xx:xx","op-class":128,"channel":149,"start-time":0,"duration":3,"report-info":8,"rcpi":198,"rsni":255,"bssid":"88:c3:97:xx:xx:xx","antenna-id":0,"parent-tsf":4183},"no_reply":true,"user":"root","group":"root"}

RSNI is stuck at 255 as well, do we need to do something about that too?

PolynomialDivision · 2020-09-20T07:50:03Z

RSNI is stuck at 255 as well, do we need to do something about that too?

Could u give me a hearing map entry? 255 is indeed a problem. :S
I could just make some changes, to handle the 255 as magic number.

namidairo · 2020-09-20T11:24:15Z

Odd, can't get the Intel client to reply to a beacon request anymore. Maybe they disabled it in that driver update that went out recently...

However, I found another client that would report 255 RSNI though, another router connected as a WDS client. (A Xiaomi MiWifi Mini w/ a MT7612E)

"64:09:80:XX;XX:XX": { "88:C3:97:XX:XX:XX": { "signal": -73, "rcpi": 74, "rsni": 255, "freq": 5745, "ht_capabilities": true, "vht_capabilities": true, "channel_utilization": 13, "num_sta": 6, "ht_support": true, "vht_support": true, "score": 100 }

It's not all clients though (at least the ones that reply to beacon requests), as I can get my phone to return a proper RSNI value.

"A8:DB:03:XX:XX:XX": { "88:C3:97:XX:XX:XX": { "signal": -66, "rcpi": 96, "rsni": 78, "freq": 5745, "ht_capabilities": true, "vht_capabilities": true, "channel_utilization": 12, "num_sta": 6, "ht_support": true, "vht_support": true, "score": 100 } },

Every other client is -1/-1 because I don't have regular beacon reports enabled in DAWN.

namidairo · 2020-09-21T06:43:16Z

Ah, 255 RSNI isn't anything faulty it seems.

The 802.11k spec dictates:

The value 255 indicates that RSNI is not available.

So yeah that'll need to be handled similar to -1

The question remains: What does one do when those broken Intel clients report inverted RCPI? Do a delta with the signal in the neighbour report or just assume that it's right and wait for the vendor to fix it?

jabdoa2 · 2021-06-19T10:44:02Z

In case you need more datapoints. This is one of my clients:

		"38:78:xx:xx:xx:xx": {
			"18:D6:C7:xx:xx:xx": {
				"signal": -46,
				"rcpi": 221,
				"rsni": 0,
				"freq": 5200,
				"ht_capabilities": false,
				"vht_capabilities": false,
				"channel_utilization": 12,
				"num_sta": 1,
				"ht_support": true,
				"vht_support": true,
				"score": 110
			},
			"18:D6:C7:xx:xx:xx": {
				"signal": -89,
				"rcpi": 169,
				"rsni": 0,
				"freq": 5200,
				"ht_capabilities": true,
				"vht_capabilities": true,
				"channel_utilization": 15,
				"num_sta": 4,
				"ht_support": true,
				"vht_support": true,
				"score": -2
			}
		},

			"38:78:xx:xx:xx:xx": {
				"signature": "wifi4|probe:0,1,45,127,191,221(0050f2,8),255,127,221(8cfdf0,1),htcap:01ef,htagg:13,htmcs:0000ffff,vhtcap:339071fa,vhtrxmcs:030cfffa,vhttxmcs:030cfffa,extcap:00000a02|assoc:0,1,33,45,48,54,59,70,127,191,221(0050f2,2),221(8cfdf0,1),htcap:01ef,htagg:13,htmcs:0000ffff,vhtcap:338071b2,vhtrxmcs:030cfffa,vhttxmcs:030cfffa,txpow:1708,extcap:0400080200000040",
				"ht": false,
				"vht": true,
				"collision_count": 24,
				"signal": -42
			}

APs are Archer C7 and Client is a Sony Experia phone. I have also seen this client report 4 or 5 APs.

PolynomialDivision · 2021-07-27T13:41:29Z

@cotequeiroz That some PR I did to compare RCPI, RSNI and RSSI. However, I'm unsure if that is a good option.

cotequeiroz · 2021-07-27T16:42:29Z

I'll slowly get to it when able.

cotequeiroz · 2021-08-05T15:12:46Z

I've encountered some troublesome data from the few clients that responded with RCPI/RSNI.

For example:

Signal (RSSI)	RCPI	RSNI
-45	108	255
-55	199	255
-97	196	40

These are from different clients. Apparently the meaning of what is a strong signal is vendor-dependent, which makes it hard to come up with what is considered a good or bad RCPI.

Another problem is that a client may not have responded with RSNI/RCPI to one AP, but did with others, which, at least here, is most of the time. Then we better have a good metric correspondence between them.

For this PR. to simplify the config options, I would rename and combine the high & low signal score variables into strong_signal_score and weak_signal_score, while keeping the reference metrics separate, and add the implicit high score to the config/variable names:

if (probe_entry->rcpi > 0)
{
    score += probe_entry->rcpi >= dawn_metric.high_rcpi_val ? dawn_metric.strong_signal_score : 0;
    score += probe_entry->rcpi <= dawn_metric.low_rcpi_val ? dawn_metric.weak_signal_score : 0;
}
else if (probe_entry->rsni > 0 && probe_entry->rsni != 255)
{
    score += probe_entry->rsni >= dawn_metric.high_rcpi_val ? dawn_metric.strong_signal_score : 0;
    score += probe_entry->rsni <= dawn_metric.low_rsni_val ? dawn_metric.weak_signal_score : 0;
}
else
{
    score += probe_entry->signal >= dawn_metric.high_rssi_val ? dawn_metric.strong_signal_score : 0;
    score += probe_entry->signal <= dawn_metric.low_rssi_val ? dawn_metric.weak_signal_score : 0;
}

PolynomialDivision · 2021-08-05T15:36:32Z

Then we better have a good metric correspondence between them.

There is some formula that explains the relationship between all. I have to look into the 802.11 standard again.

cotequeiroz · 2021-08-05T17:42:55Z

I'm not so sure the different manufacturers get that right. These are actual data I've just measured--and I won't get as many different devices for a while now. I've score them with the current defaults, including the ones recommended above (150 for RCPI & RSNI).

Client	Signal	RCPI	RSNI	Signal Score
1E:xx:xx:xx:xx:1C	-57	204	40	50
1E:xx:xx:xx:xx:1C	-51	-1	-1	50
1E:xx:xx:xx:xx:1C	-47	-1	-1	50
1E:xx:xx:xx:xx:1C	-93	177	18	50
1E:xx:xx:xx:xx:1C	-71	186	30	50
1E:xx:xx:xx:xx:1C	-87	-1	-1	-500
1E:xx:xx:xx:xx:1C	-88	-1	-1	-500
5C:xx:xx:xx:xx:D5	-46	122	255	0
48:xx:xx:xx:xx:AE	-53	199	255	50
02:xx:xx:xx:xx:8D	-60	200	40	50

Notice that client 5C:xx:xx:xx:xx:D5 with RSSI=-46 got no signal strength bonus even though it has the highest RSSI value of them all, because the RCPI=122 wasn't good enough (<150). At the same time, 1E:xx:xx:xx:xx:1C has gotten a 50 point bonus, even though its RSSI is -93, because its RCPI is 177, >150.

Of course, the bad data may have come from the RSSI, not RCPI, I won't know. In any case, that's the data available at that moment, to make a decision. It illustrates the difficulty in finding a single appropriate value.

PolynomialDivision · 2021-08-05T19:13:40Z

Do your clients support 'a' = active report? If clients support that, we can just stick to the rssi based methods. Since the APs should send us the probe request that was send by the client.

           ┌───┐
           │ 4 │
┌───────┐  └───┘
│Hearing│                ┌──┐
│ Map   │                │3 │
│Probe  │                └──┘
└─Request         Probe Request
         AP 1◄───────────────AP 2
          │        TCP/UDP    ▲
          │                   │
   ┌─┐active────► Client─────Probe Request
   │1│    report               ┌─┐
   └─┘                         │2│
                               └─┘

BUT, I have to look into my code again! I'm unsure what happens if now AP1 gets the beacon report back and is signaling the information back to AP2. I have to test this case, could be some failure case.

PolynomialDivision · 2021-08-05T19:20:19Z

I'm not so sure the different manufacturers get that right.

Yep. Also think that different manufactures handle that differently...

I've just measured--and I won't get as many different devices for a while now.

I have only 1. But I'm working in some community mesh project and maybe I can also collect some information about client capabilities. I also wrote some lua exporter for this case.

Notice that client 5C:xx:xx:xx:xx:D5 with RSSI=-46 got no signal strength bonus even though it has the highest RSSI value of them all, because the RCPI=122 wasn't good enough (<150). At the same time, 1E:xx:xx:xx:xx:1C has gotten a 50 point bonus, even though its RSSI is -93, because its RCPI is 177, >150.

Yep the algorithm is bullshit. I should only consider one metric. :D I won't merge the PR. I will also have a closer look into 802.11.k

cotequeiroz · 2021-08-06T11:22:21Z

Do your clients support 'a' = active report?

Those measurements I've sent were already using active scans, with duration=600 (My 2.4GHz radios have beacon intervals of 300).

Ian-Clowes · 2021-12-24T08:16:42Z

Notice that client 5C:xx:xx:xx:xx:D5 with RSSI=-46 got no signal strength bonus even though it has the highest RSSI value of them all, because the RCPI=122 wasn't good enough (<150). At the same time, 1E:xx:xx:xx:xx:1C has gotten a 50 point bonus, even though its RSSI is -93, because its RCPI is 177, >150.

I had some local work where I was looking at a more N-dimensional approach to selecting a better AP. For each thing that can be different give it a value where equal values are equally beneficial (which means some magic number weighting of various factors). Get the positive difference for all these values between current and candidate AP, square them, sum and square-root. Only use positive difference since the negativity of negative values disappers when squared / rooted.

I was also looking at using just one of RCPI / RSSI which a client has told both AP to avoid any flaky conversions. Could fall back to conversion if it tells one AP only RSSI and the other only RCPI.

I'm hoping to get a lot deeper into OpenWRT and DAWN over Christmas, so will see if I get to these topics.

morhimi reviewed Sep 7, 2020

View reviewed changes

PolynomialDivision force-pushed the feature/steerwithbeaconreports branch from dae4971 to 05565ae Compare September 7, 2020 09:08

PolynomialDivision mentioned this pull request Sep 7, 2020

strange behavior on tp-link archer c7 #125

Closed

PolynomialDivision mentioned this pull request Jul 26, 2021

Correct mode for beacon request? #139

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

datastorage/uci/msghandler/ubus: add steering with beacon reports #126

datastorage/uci/msghandler/ubus: add steering with beacon reports #126

PolynomialDivision commented Sep 6, 2020 •

edited

Loading

morhimi Sep 7, 2020

PolynomialDivision Sep 7, 2020

namidairo commented Sep 11, 2020

PolynomialDivision commented Sep 20, 2020 •

edited

Loading

namidairo commented Sep 20, 2020

namidairo commented Sep 21, 2020

jabdoa2 commented Jun 19, 2021

PolynomialDivision commented Jul 27, 2021

cotequeiroz commented Jul 27, 2021

cotequeiroz commented Aug 5, 2021

PolynomialDivision commented Aug 5, 2021

cotequeiroz commented Aug 5, 2021

PolynomialDivision commented Aug 5, 2021 •

edited

Loading

PolynomialDivision commented Aug 5, 2021

cotequeiroz commented Aug 6, 2021

Ian-Clowes commented Dec 24, 2021

datastorage/uci/msghandler/ubus: add steering with beacon reports #126

Are you sure you want to change the base?

datastorage/uci/msghandler/ubus: add steering with beacon reports #126

Conversation

PolynomialDivision commented Sep 6, 2020 • edited Loading

morhimi Sep 7, 2020

Choose a reason for hiding this comment

PolynomialDivision Sep 7, 2020

Choose a reason for hiding this comment

namidairo commented Sep 11, 2020

PolynomialDivision commented Sep 20, 2020 • edited Loading

namidairo commented Sep 20, 2020

namidairo commented Sep 21, 2020

jabdoa2 commented Jun 19, 2021

PolynomialDivision commented Jul 27, 2021

cotequeiroz commented Jul 27, 2021

cotequeiroz commented Aug 5, 2021

PolynomialDivision commented Aug 5, 2021

cotequeiroz commented Aug 5, 2021

PolynomialDivision commented Aug 5, 2021 • edited Loading

PolynomialDivision commented Aug 5, 2021

cotequeiroz commented Aug 6, 2021

Ian-Clowes commented Dec 24, 2021

PolynomialDivision commented Sep 6, 2020 •

edited

Loading

PolynomialDivision commented Sep 20, 2020 •

edited

Loading

PolynomialDivision commented Aug 5, 2021 •

edited

Loading