Seamless access is best defined by the work that continues during a network change. A new web page loading after a switch, a call resuming after a pause and a call continuing without a noticeable gap are three different results.
WiMAX's fixed, nomadic and mobile uses brought these questions into focus. They remain useful when a modern network changes Wi-Fi access points, cellular cells or internet providers.
Name the kind of change
On a narrow screen, scroll the table horizontally. Keyboard users can focus the table region and use the arrow keys.
| Mechanism | What changes | What to observe |
|---|---|---|
| Radio handover | The serving radio cell or base station. | Link interruption, coverage and application recovery during movement. |
| Wi-Fi roaming | The access point serving a local wireless device. | Authentication, packet loss and whether the client remains on the intended network. |
| WAN failover | The gateway uses an alternate upstream internet connection. | Failure detection, new connection success and existing-session behavior. |
| Load balancing | Separate traffic flows are distributed across paths. | Per-flow behavior and whether a service sees changing source addresses. |
| Bonding or a continuity overlay | A supported system coordinates traffic over multiple paths. | Required endpoints, overhead, service dependency and tested session behavior. |
Two plugged-in modems establish two possible paths. The gateway's configuration determines how those paths are used, and the transport/application determines how a session reacts. Ask which mechanism a product's “seamless” claim actually describes.
Why existing sessions need a separate check
Changing upstream providers can change the public source address and the path state held by gateways. Some sessions reconnect automatically; others wait for a timeout, require authentication again or stop. A browser loading a new page only demonstrates that a new request can use the available route.
Netgate's gateway-group documentation gives a concrete example: applications that associate a session with a client IP address can behave poorly when subsequent connections take a different WAN. Its state-handling guidance also explains that clearing states can aid recovery but disrupt connections. Those are pfSense-specific controls; use your own gateway's documentation.
Some transports have explicit migration support. QUIC's connection-migration specification describes mechanisms for changing network paths. That capability belongs to a supported, correctly implemented connection; it cannot establish continuity for every application on the device.
Test failure and recovery as two separate events
Use equipment you control, a maintenance window and a way to restore the starting configuration. Save the relevant settings and consult the gateway's documented test method. A small office should notify affected users before intentionally interrupting connectivity.
- Record the starting state. Identify gateway/firmware, primary and backup services, health-check method, application and whether the client is wired or wireless.
- Establish a baseline. Start a test call, remote session or noncritical transfer. Check that each service also works when deliberately selected on its own.
- Trigger a controlled primary-path failure. Use the documented method and record its time. A cable disconnect tests loss of that local link; it may not reproduce an upstream outage while the modem stays connected.
- Measure two outcomes. Record when a new request succeeds and what happened to the existing session. Note interruption duration, automatic reconnection and any manual action.
- Restore the primary path. Observe whether traffic stays on the backup or returns, and whether that return causes another interruption.
- Repeat and compare. Repeat the same scenario, then test another failure type only if your equipment provides a controlled method. Keep the scenarios distinct.
Turn observations into an acceptance decision
Use the printable connection-continuity log to define a target, record the failure method and compare recovery with it. State separate targets for new requests and existing sessions.
Check whether the backup is independent enough
List common dependencies: power, the gateway, indoor Wi-Fi, building cabling and possibly upstream infrastructure. Two services that share a failed component may go offline together. Ask providers about the aspects you cannot observe, and record uncertainty instead of assuming diversity from two brand names.
Also test the backup's ordinary performance and allowance. It may restore basic access while supporting fewer concurrent users. Choose a continuity target that reflects the work you actually need to sustain, and retest after gateway firmware, provider or application changes.