This simulator models a device (UE) moving across three radio cells connected through a mobile core network. Four tabbed sections take you from a hands-on drive lab to reference material, radio and end-to-end test experiments, and a knowledge check — with three camera views (overview, radio cells, core network) and a component selector covering the device, cell towers and core nodes.
• Lab (01): drive the device across the route (▶ Travel across cells or Move +100 m single steps) and watch the serving cell change; adjust environment, interference, cell power, frequency, bandwidth and hysteresis/time-to-trigger handover parameters; toggle automatic handover; a mobility-events log with clear-events action; three camera views — Overview, Radio cells, Core network — plus walls/coverage overlay toggles. • Learn (02): reference explanation of how a cellular network follows you as you move. • Experiments (03): a radio experiment with predict/change/measure workflow reading signal strength, RTT, SINR and a live signal chart; a full end-to-end test path running Registration, Ping server IP, DNS lookup and Download tests with pause/step/stop controls and a test log/summary; fault injection (e.g. DNS or backhaul faults) to predict which tests should fail before running them. • Knowledge check (04): a quiz testing understanding of handover, control-plane vs. user-plane paths, and link-budget behavior. • A guided tour button walks through six tips covering device/cell/core selection, receive power comparison, the neighbor-better timer, registration vs. ping paths, fault prediction and the knowledge check.
As the device moves, it continuously compares the serving cell's received power against neighboring cells. When a neighbor becomes sufficiently stronger by the configured hysteresis margin and that condition holds for the time-to-trigger duration, a handover occurs and the device switches its serving cell — the hysteresis and TTT parameters exist specifically to prevent rapid back-and-forth handover (ping-pong) at cell boundaries.
Signal strength at the device is governed by transmit power, distance-based path loss, environment (which affects attenuation) and interference from other cells; SINR (signal-to-interference-plus-noise ratio) combines received signal power against both noise and interference to determine link quality, which in turn affects achievable data rate.
Registration and Ping server IP use different paths through the network: registration is a control-plane exchange with the core (authenticating and attaching the device to the network), while ping is a user-plane data path once attached. This distinction matters when diagnosing faults — a DNS fault will break the Download test (which needs to resolve a hostname) while leaving a raw IP ping unaffected, and a backhaul fault between a cell and the core will affect every test routed through that path. The lab's fault-injection experiments are built specifically to let you predict which tests should fail given a fault, then verify your prediction by running them.
The device continuously compares its serving cell's received signal power against neighboring cells. A handover triggers when a neighboring cell becomes stronger by more than the configured hysteresis margin, and that condition persists for the time-to-trigger duration. Both parameters exist to prevent rapid, unnecessary handover (ping-pong) right at cell boundaries.
Registration is a control-plane exchange between the device and the core network — it authenticates and attaches the device before any data can flow. Ping is a user-plane data test that only works after the device is registered and attached. They travel different logical paths through the network, which is why fault injection can affect one without affecting the other.
SINR (signal-to-interference-plus-noise ratio) measures how strong the wanted signal is relative to both background noise and interference from other transmissions. Higher SINR generally allows higher achievable data rates, which is why the radio experiment lets you adjust interference and power to see SINR and resulting performance change together.
Download requires resolving a hostname to an IP address via DNS before any data transfer can begin, so a DNS fault blocks it. A ping test aimed directly at a server IP address does not need DNS resolution at all, so it can succeed even while DNS is faulted — this is exactly the kind of distinction the fault-injection experiments are designed to teach.