@am4c130d A few things to try, use the combo WPA2 and WPA3 mode for the SSID, in case the Pixel just doesn't like WPA3 transitions.  If you have 11r turned on, try turning it off, it's known to cause issues on phones when using WPA3.  And as a last resort, you could turn on "Force-Disassociation", I have it on for the little IoT devices that like to to stick to the first AP they see after a reboot, even if it's a poopy connection.

  @JoeSea thanks.

I've disabled 11r. There is only one WPA Personal option since the last server upgrade - WPA2-PSK/WPA3-SAE/AES which is the one you are suggesting, so that was good. I won't be able to test for a few days, but will do so and report back.

I don't really want to use Force Disassocitation to fix the phones - especially as I'm trying to get them to roam seamlessly. When I tried it in the past, it gave other devices problems - ones who are fixed and working fine at a lower RSSI levels due to physical location.

Thanks again.

  @KimcheeGUN thanks for the advice re roaming. In the case of Pixel phones, any seamless roaming was the goal - currently it's 0%, they never ever roam of their own volition. But as virtually all other devices on my network do, no need to abandon 11k/v yet.

A forced disassocation with a raised RSSI does overcome the phone's desire to never changed AP, but the same configuration causes problems for other devices on my network, so it's not really desirable. It would be good enough if there were no consequences.

I'm comfortable that the radio power settings are OK on the APs: nearly all parts of the coverage area "measure" (using apps on Android) as better than -75 dBm, and the main parts typically can see one AP better than -65 dBm. There are nearly no areas where two APs can be seen with greater than -65dBm at the same time.

I'm concluding that the Pixel phones don't support 802.11k/v, and I either accept that, workaround it, or replace them. To the last point, what mobile phones/devices have other users had success with seamlessly roaming on a TP Link Omada network?

I appreciate your response, thanks.

  @Shoresy thanks for the reply.

Hmm, I wonder where I am going wrong - Pixel 6 is same vintage as your 6 Pro and Pixel 6a is newer, unless roaming is a Pro only capability which doesn't seem logical. Apple and Samsung are both very open about their support for 11k/v/r which is encouraging - I just don't use either product.

The only real deployment differences are the EAPs we're using and my controller is on Linux (I just upgraded to 5.8.4). AI WLAN Optimization hadn't worked with 5.7.4 - but it just ran successfully with 5.8.4 and is now set to run weekly. It may help.

Thanks for sharing your experiences as well, it all helps.

  @Shoresy understood and that is my frustration. I have no reason not to believe other people's experience with Pixel phones, other than when my own conflicts - and then checking my settings are correct is the logical thing to do.

In my network, my pixel 6a will remain connected to an AP with less than -80 dBm RSSI while it can see an RSSI of -40 dBm from an AP with same ESSID. These signal strengths were taken from the Android developer debug info from Settings -> Network & Internet -> Internet section on the Pixel 6a at the time. This is anti-roaming in my book and makes no sense. The Pixel is slowing down other devices at that stage. The Pixel 6a will stay at -80 dBm overnight, rather than roam to a stronger signal. The two APs were an EAP-615 Wall (the one the Pixel was connected to) and an EAP-610 v2 indoor AP (the one the Pixel was next to), both connected over wired/1G links to a TP-Link PoE switch and controlled by Omada SW configured for Fast Roaming and AI Roaming with 802.11 k/v in the beacons from both APs verified using Wireshark and Analiti.

Initially the APs were on full power, and as roaming wasn't happening, there was arguably too much coverage, so I turned the power down manually by 3-5 dB to create more reasonable coverage - the above scenario is with the TX power at 17 dBm on all the APs. When standing next to any AP, the RSSI is typcially -40 dBm and the other APs are typically around -80 dBm - but during the time to walk between APs, there are overlaps where two APs are at around -67 dBm, so there is/was good overlap.

Your comments re "doesn't happen instantly" and "sometimes takes data" may be the keys, as they are somewhat at odds with my expectations of 11k/v, but that may be the issue - my expectations could be wrong. Certainly, when I walked around with the Pixel 6a on top of an Windows 11 PC - the PC roamed instantly and as soon as there was a clear difference in the RSSIs - which is what I would expect. My Linux PC, which can hold on longer than I like, roams once the difference is obvious and takes a few seconds, but it is only seconds.

AI WLAN Optimization is now working/enabled, so I've reset all the APs to use Auto power - I'll let that run a few times and see what happens.

My network is almost yours, but inverted. I have each of the two 615-Wall APs at opposite ends of the first floor, one towards the front the towards the back, the 610 is on the second floor in the center of the house. Due to floors and walls, some of the second floor is better covered by the 615s, but in general, the best AP signal is on the floor the client it is on.

Appreciate you continuing to share your experiences, thank you.

  @Shoresy

I've been able to duplicate your experienced with Pixel 6a. On a Zoom call, the Pixel will roamed from one AP to another a couple of times, and did reasonably quickly. I didn't detect any drops in voice or video, so that meets my needs. Your explanation that data needed to be flowing was the key!

AI WLAN has turned the TX power up to max on my APs as well - so I rarely drop below -77 dBm now.

Thank you for providing the incremental insights, it certainly helped me reach a point where I am comfortable with how the Pixel is roaming over Wifi. Thank you!