Early Access API - Roaming

[Ajay-Chandrasekaran]

Hi, I tried running the below API call however in the output i see some weird RSSI values. Can someone confirm me why do i see this '0' values ?

API call -https://api.meraki.com/api/v1/organizations/{{orgId}}/wireless/roaming/byNetwork/byInterval?networkIds[]=XXX&timespan=3600

Output -

{
"origin": {
"name": "XX-MR-09",
"serial": "Q4AE-DCWY-NN3P",
"mac": "68:49:92:32:72:b0"
},
"destination": {
"name": "XX-MR-11",
"serial": "Q4AE-67UZ-8X2B",
"mac": "68:49:92:32:6c:60"
},
"ssid": {
"name": "WiFiXXX",
"number": 2
},
"client": {
"id": "kd24161",
"mac": "10:5f:ad:f1:ee:0b"
},
"band": {
"before": 6,
"after": 6
},
"protocol": "802.11r-roam",
"duration": 70,
"rssi": {
"before": 0,
"after": 44
}

[aleabrahao]

A value of 0 does not mean 0 dBm, it simply means Meraki had no usable data for that moment.

[Ajay-Chandrasekaran]

So how do I interpret such data? if it is a good or bad roam? because I see lots of clients with same '0' value.

[aleabrahao]

I think that to evaluate roaming quality, you can use the following criteria:

duration: <150 ms = good
rssi.after: >35 (-65 dBm) = good

[Ajay-Chandrasekaran]

But if it is after then it means client has already roamed right. so, I think it is good to monitor both before & after.

[aleabrahao]

I understand that Meraki defines it as 0 when the AP does not have a valid measurement, which in this case is common and normal in fast roaming.
So I think the correct way would be to use "after" protocol and duration to assess roaming quality.

[Ajay-Chandrasekaran]

Can you help me with logic for Good, Sub-Optimal & Bad roaming? ( 5 to 5 & 5 to 6 ) Roaming. Also, the RSSI value we see in the API response is positive so is it a development mistake that negative is not considered?

[Raphael_L]

That doesn't look normal. Are you using a recent firmware version ? I would reach out to support , early access API often have bugs

[Ajay-Chandrasekaran]

Yes, APs are running on 31.1.8 Firmware and APIs was taken from the Meraki Documentation.

[Ajay-Chandrasekaran]

Just let me know once you have an update.

[Ajay-Chandrasekaran]

Any updates on this issue @Raphael_L ?

[hellencharless54]

The RSSI value of **0 dBm** is not a valid Wi-Fi signal strength, which is unlikely to show the client's actual signal when the roam was taken. Some of these could be: The AP may not have had a valid RSSI measurement prior to the roam so the API returns `0` instead of leaving the field blank. * **Fast roaming (802.11r):** Since this is an **802.11r-roam**, the handoff happens very quickly. The "before" RSSI in some instances may not be recorded prior to the client switching to the new AP. Some Meraki APIs return the value of `0` for a metric that was not available, or was not recorded, and not to show an actual signal level. In your example: ```json "rssi": { "before": 0, "after": 44 } ``` The 44 is a reasonable absolute RSSI (typically –44 dBm), the 0 is probably not 0 dBm, but "RSSI is not available". If this is happening repeatedly during multiple roaming events, you may consider opening a Meraki Support case to verify it is a normal event for this endpoint or a well known Meraki Support report. It would also be helpful if this was found to be a problem just for roam type **802.11r** or if it were a problem with other roam types as well. Does anyone else have a report of seeing rssi.before = 0 in the /wireless/roaming/byNetwork/byInterval API response?

[aleabrahao]

 stop to use AI answer please.