Unifi had this on their old access points (Multi-AP coordination outside of the spec)
Now we have 802.11r fast roaming and with 802.11bn (WiFi-8) it will be basically instant, because that standard adds SMD (Seamless Roaming Domain). The APs will talk to each other and share the client connection state.
Yeah, definitely. Fast roaming can work very well, and things like 802.11r and the newer work in Wi-Fi 8 should make handovers even better.
What we’re doing is slightly different though. We’re not only reacting to signal strength or a broken connection. Because we have multiple active paths, we can also move real-time traffic away from a Wi-Fi path that is still connected but has temporarily become bad - for example because that AP is congested or somebody else is consuming a lot of airtime.
So even if the roaming itself is perfect, you can still have a path that is technically connected but no longer able to meet the latency budget.
Another advantage is that this doesn’t depend on the AP infrastructure supporting fast roaming or coordination features. It works above the Wi-Fi layer, and the same mechanism can also combine Wi-Fi with completely different networks such as 5G or Starlink.
- The 3 interfaces detail is a bit buried. For a second I thought you were somehow changing the adapter channel and association quickly enough on a single adapter.
- What approach are you taking to still present the client as a single IP source during the video call? (partly curiosity, largely curious how that interacts with using the network).
- Why are the comparisons to a single pinned AP only instead of normal roaming across them (preferably with KVR)? It makes me particularly suspicious of the results would be better, especially since pinning to AP B the entire time was already itself 0.17% off perfect.
- Do you have any comparisons with newer MLO setups to say "gives you x% of MLO without having to wait for infrastructure to catch up" or anything?
On the three interfaces: others have pointed that out too, and we’ll try to make it clearer in the article. In this test the laptop had three Wi-Fi adapters, each pinned to a different AP. There’s nothing particularly special about three though - with two adapters connected to two different APs you should already be able to get a lot of the benefit.
On the IP side, the overlay works a bit like a VPN. Traffic is sent over all the available interfaces to software on the other side, which combines the paths and presents a normal IP stream towards the final destination. Encryption isn’t the primary purpose here - the main goal is making the connection more robust - although encryption can of course be added.
The pinned-AP comparison is a fair criticism. For this demo we deliberately kept each interface associated with one AP because we wanted to isolate the effect of using several paths at once, rather than also introducing the behaviour of the Wi-Fi roaming implementation into the test. Comparing against normal roaming, including 802.11k/v/r, is definitely something we want to test next.
We want to experiment with a small daemon that keeps the different Wi-Fi interfaces associated with different APs. If one drops out, it can reassociate that interface with another available AP, so in principle you can move through a much larger Wi-Fi deployment while still maintaining multiple active paths.
We haven’t done a proper comparison against Wi-Fi 7 MLO yet, but that would be a very interesting comparison. Conceptually there is definitely some overlap, although our approach sits above the individual Wi-Fi link and can also combine completely different networks.
We’ve been experimenting with real-time streaming over Wi-Fi where packets have a 100 ms latency budget.
The problem we wanted to look at was roaming. Even when you have good Wi-Fi coverage, moving between access points can cause short interruptions that are long enough to matter for a real-time application.
Instead of relying on a single Wi-Fi connection and hoping the handover is fast enough, we tested our overlay multi-connectivity transport using three Wi-Fi access points at the same time.
The transport can use all three paths simultaneously, so a roaming event or temporary interruption on one connection doesn’t necessarily interrupt the stream.
We’re still digging into the results, but it’s an interesting way of thinking about Wi-Fi reliability: rather than trying to make one connection perfect, use several imperfect ones together.
This is a great result and a very nice visualization. One thing I’d suggest is making it clearer upfront that this requires a computer with multiple WiFi adapters; it’s not mentioned until more than halfway through the article.
That’s a great point. I’ll see if we can make that clearer upfront.
In this particular test, the laptop had three Wi-Fi adapters, one connected to each AP. You should still see benefits with just two independent Wi-Fi connections, but for the results shown here we used three.
Unifi had this on their old access points (Multi-AP coordination outside of the spec) Now we have 802.11r fast roaming and with 802.11bn (WiFi-8) it will be basically instant, because that standard adds SMD (Seamless Roaming Domain). The APs will talk to each other and share the client connection state.
Yeah, definitely. Fast roaming can work very well, and things like 802.11r and the newer work in Wi-Fi 8 should make handovers even better.
What we’re doing is slightly different though. We’re not only reacting to signal strength or a broken connection. Because we have multiple active paths, we can also move real-time traffic away from a Wi-Fi path that is still connected but has temporarily become bad - for example because that AP is congested or somebody else is consuming a lot of airtime.
So even if the roaming itself is perfect, you can still have a path that is technically connected but no longer able to meet the latency budget.
Another advantage is that this doesn’t depend on the AP infrastructure supporting fast roaming or coordination features. It works above the Wi-Fi layer, and the same mechanism can also combine Wi-Fi with completely different networks such as 5G or Starlink.
Hey mortenvp, ex-enterprise network admin's thoughts & questions:
- The 3 interfaces detail is a bit buried. For a second I thought you were somehow changing the adapter channel and association quickly enough on a single adapter.
- What approach are you taking to still present the client as a single IP source during the video call? (partly curiosity, largely curious how that interacts with using the network).
- Why are the comparisons to a single pinned AP only instead of normal roaming across them (preferably with KVR)? It makes me particularly suspicious of the results would be better, especially since pinning to AP B the entire time was already itself 0.17% off perfect.
- Do you have any comparisons with newer MLO setups to say "gives you x% of MLO without having to wait for infrastructure to catch up" or anything?
Yeah, good points.
On the three interfaces: others have pointed that out too, and we’ll try to make it clearer in the article. In this test the laptop had three Wi-Fi adapters, each pinned to a different AP. There’s nothing particularly special about three though - with two adapters connected to two different APs you should already be able to get a lot of the benefit.
On the IP side, the overlay works a bit like a VPN. Traffic is sent over all the available interfaces to software on the other side, which combines the paths and presents a normal IP stream towards the final destination. Encryption isn’t the primary purpose here - the main goal is making the connection more robust - although encryption can of course be added.
The pinned-AP comparison is a fair criticism. For this demo we deliberately kept each interface associated with one AP because we wanted to isolate the effect of using several paths at once, rather than also introducing the behaviour of the Wi-Fi roaming implementation into the test. Comparing against normal roaming, including 802.11k/v/r, is definitely something we want to test next.
We want to experiment with a small daemon that keeps the different Wi-Fi interfaces associated with different APs. If one drops out, it can reassociate that interface with another available AP, so in principle you can move through a much larger Wi-Fi deployment while still maintaining multiple active paths.
We haven’t done a proper comparison against Wi-Fi 7 MLO yet, but that would be a very interesting comparison. Conceptually there is definitely some overlap, although our approach sits above the individual Wi-Fi link and can also combine completely different networks.
Using the MikroTik HWMP+ protocol and OpenMPTCProuter, we did something similar in very remote locations for government video calls.
[dead]
WiFi is a real pain in many situations! This can actually help!
Bot?
No - But WiFi really sucks :)
We’ve been experimenting with real-time streaming over Wi-Fi where packets have a 100 ms latency budget.
The problem we wanted to look at was roaming. Even when you have good Wi-Fi coverage, moving between access points can cause short interruptions that are long enough to matter for a real-time application.
Instead of relying on a single Wi-Fi connection and hoping the handover is fast enough, we tested our overlay multi-connectivity transport using three Wi-Fi access points at the same time.
The transport can use all three paths simultaneously, so a roaming event or temporary interruption on one connection doesn’t necessarily interrupt the stream.
We’re still digging into the results, but it’s an interesting way of thinking about Wi-Fi reliability: rather than trying to make one connection perfect, use several imperfect ones together.
This is a great result and a very nice visualization. One thing I’d suggest is making it clearer upfront that this requires a computer with multiple WiFi adapters; it’s not mentioned until more than halfway through the article.
That’s a great point. I’ll see if we can make that clearer upfront.
In this particular test, the laptop had three Wi-Fi adapters, one connected to each AP. You should still see benefits with just two independent Wi-Fi connections, but for the results shown here we used three.