Implementing Low-Latency Interactions over 5G in Mobile Applications
Round-trip time in 5G URLLC is theoretically less than 1 ms on the radio interface. In practice, end-to-end latency from screen touch to server response and back is 10–50 ms with good coverage. This fundamentally changes what you can implement in a mobile application: cloud rendering, remote equipment control, synchronous multiplayer mechanics.
Where Time is Actually Lost
Typical latency decomposition for a 5G application:
| Component | Latency | Comment |
|---|---|---|
| Touch → JS event | 8–16 ms | UIKit/Choreographer frame budget |
| JS processing | 1–5 ms | Depends on main thread load |
| 5G radio (UE → gNB) | 0.5–4 ms | Sub-6 GHz, URLLC |
| Transport (gNB → MEC/cloud) | 2–20 ms | Depends on server distance |
| Server processing | 1–50 ms | Depends on task |
| Return path | ~same | Symmetric |
Realistic total: 25–100 ms. This is sufficient for most interactive applications. For surgical robots, it's not—but they use specialized hardware.
Key Pattern: Optimistic UI + Rollback
Waiting for server confirmation before updating UI adds visible latency even at low RTT. The correct approach: apply changes locally immediately, send to server asynchronously, rollback on error.
type OptimisticAction<T> = {
optimisticState: T;
serverCall: () => Promise<T>;
onConflict: (serverState: T) => T; // conflict resolution
};
async function applyOptimistic<T>(
setState: React.Dispatch<React.SetStateAction<T>>,
action: OptimisticAction<T>
) {
const previousState = await new Promise<T>(resolve => setState(prev => {
resolve(prev);
return action.optimisticState;
}));
try {
const serverState = await action.serverCall();
setState(action.onConflict(serverState));
} catch {
setState(previousState); // rollback
}
}
For multiplayer mechanics: state versioning with vector clocks or sequence numbers allows determining whose action arrived later and whether rollback is needed.
WebSocket vs HTTP/3 for Low-Latency
WebSocket is the standard choice for bidirectional low-latency communication. But HTTP/3 (QUIC) has advantages on mobile networks:
- Connection migration: when IP changes (LTE → 5G, access point switch), QUIC connections survive. TCP/WebSocket break and require re-establishment.
- Head-of-line blocking: in QUIC, packet loss in one stream doesn't block others. In TCP, loss blocks everything.
- 0-RTT handshake: reconnecting to a known server, QUIC skips TLS handshake.
In React Native: fetch through Expo's network layer supports HTTP/3 on iOS 15+ (via URLSession with QUIC) and Android 12+ (via OkHttp with QUIC through Cronet). For explicit control, use native modules with Cronet on Android and URLSessionConfiguration with QUIC on iOS.
MEC (Mobile Edge Computing): Server Near the Antenna
To achieve minimum latency, the server must be close. MEC places computing at network operator edge nodes—physically near base stations. Latency from UE to MEC server: 2–10 ms.
For mobile apps: when detecting 5G with low latency, switch to MEC endpoints (operators provide edge discovery APIs). On LTE transition or moving beyond MEC coverage, fallback to cloud server.
Discover MEC through GSMA Open Gateway API or operator-specific APIs (AT&T, Deutsche Telekom provide Edge Discovery Service).
Native UDP for Minimum Latency
WebSocket operates over TCP. For tasks where packet loss is acceptable but latency is critical (online games, physics sync, audio streaming), use UDP. On mobile platforms:
-
iOS:
Network.frameworkwithNWConnection(to:, using: .udp). UseNWParameters.dtlsfor encrypted UDP. -
Android:
java.net.DatagramSocketor via NDK. - React Native: native module required—Expo/Metro don't provide direct UDP.
For gaming: WebRTC Data Channel provides reliable or unreliable UDP with built-in ICE/STUN/TURN for NAT traversal. react-native-webrtc supports DataChannel.
Estimate
Optimistic UI + WebSocket low-latency architecture in React Native: 3–5 weeks. With native QUIC/UDP modules and MEC integration: 6–10 weeks. Cost calculated individually.







