When a carrier’s coverage map lights up with “5G”, the assumption that quietly follows is that latency is now uniformly low enough to offload real-time inference to the network. That assumption is where NSA deployments break streaming pipelines. 5G NSA — Non-Standalone — is not a full 5G network; it is a 5G radio bolted onto an existing LTE core, and the control plane it depends on delivers LTE-class latency, not the sub-10ms figures marketed for standalone 5G. If you designed a server-side text-to-speech pipeline around a stable low-latency uplink, and your target market runs on NSA infrastructure, the jitter and dropout you will see in the field are enough to break streaming audio. Understanding what NSA actually guarantees — and what it doesn’t — is what tells you whether on-device inference is a nice hedge or a hard requirement. What does 5G NSA mean in practice? NSA is a deployment mode defined so carriers could launch 5G radio quickly without first building a new core network. In an NSA deployment, the 5G New Radio (NR) provides the fast data-plane pipe for user traffic, but the control plane — the signalling that sets up, tears down, and steers your connection — is anchored to the 4G LTE Evolved Packet Core (EPC). The device attaches to LTE first, then the NR carrier is added as a secondary cell. This is the 3GPP “Option 3” family (EN-DC, E-UTRA-NR Dual Connectivity). The practical consequence is subtle and easy to miss. Your peak downlink throughput can genuinely jump — that is the part carriers advertise, and it is real. But the round-trip characteristics that matter for real-time inference are governed by the control plane and the LTE-anchored connection management, not by the raw NR bandwidth. You get 5G-class throughput riding on an LTE-class latency and signalling foundation. Standalone (SA) 5G, by contrast, replaces the EPC with the 5G Core (5GC) and its service-based architecture. Only in SA do features like ultra-reliable low-latency communication (URLLC) and network slicing become deployable in the way the marketing implies. This distinction is the whole game for latency-sensitive workloads, and we cover the deployment-side implications in more depth in 5G NSA vs SA: what the architecture choice means for edge CV workloads. Why does NSA still depend on the LTE core? Because the control plane was never migrated. In EN-DC, the LTE base station (eNB) is the master node and the 5G base station (gNB) is the secondary node. Session setup, mobility management, and much of the connection-state machinery run through the LTE anchor. When your device needs to re-establish or re-steer a connection — which happens constantly as radio conditions change, especially for a moving user — the timing of those events is bounded by LTE signalling, not by NR. This is why the latency floor of NSA sits well above SA. The NR data path can be fast in a burst, but the connection managing that path is doing LTE-era signalling. For a bulk download the difference is invisible; the transfer completes and nobody measures the setup cost. For a streaming inference workload that sends small packets continuously and cannot tolerate a stalled frame, the LTE-anchored control plane is exactly the part that hurts. There is a second-order effect worth naming: dual connectivity means the device is juggling two radios. Handovers, secondary-cell addition and release, and the interplay between LTE and NR coverage boundaries all introduce timing variability. That variability — jitter — is often more damaging to a real-time pipeline than a higher-but-stable average latency. What latency and jitter profile can you expect on NSA? Treat the following as directional planning figures, not a benchmark. Measured behaviour depends on the carrier, the spectrum band, cell load, and how far you are from the tower. Characteristic NSA (Non-Standalone) SA (Standalone) Control-plane anchor LTE EPC (4G core) 5G Core (5GC) Typical RTT profile LTE-class (tens of ms), variable Lower floor; URLLC targets single-digit ms Jitter under mobility Elevated (dual-connectivity handovers) Lower, more predictable URLLC / network slicing Not available Available What it’s genuinely good at Peak downlink throughput Deterministic low-latency, small-packet traffic The number to internalise is this: on an NSA network, plan for LTE-class round-trip latency with radio-side jitter, not the sub-10ms figure attached to 5G in marketing material (observed pattern across telecom deployment planning; not a carrier-published benchmark). If your end-to-end budget assumed a stable 10ms uplink and you meet a real NSA cell that delivers 40–60ms with occasional multi-hundred-ms spikes during handover, your streaming buffer either grows until the interaction feels laggy, or it underruns and the audio drops. For a fuller side-by-side of the two generations, the 4G vs 5G comparison table for video anomaly pipelines frames the same trade-off from the throughput direction. How does NSA latency variability change where you place the inference boundary? This is the decision the whole article exists to inform. The inference boundary is the line in your architecture where model execution happens — on the client device, or on a server reached over the network. NSA’s jitter profile moves that line. If you place inference server-side, every real-time interaction pays the network round trip twice — request up, result down — plus whatever variability the NSA control plane injects. For a batch or near-real-time workload, that is fine. For streaming TTS, where a listener perceives even small gaps in synthesised speech, the variance is the killer. It is not the average latency that breaks the experience; it is the p99 spike during a secondary-cell handover that produces an audible dropout. Placing inference on-device removes the network from the critical path entirely. The model runs locally through a runtime like CoreML on Apple silicon or ONNX Runtime on other targets, the audio is synthesised where it is consumed, and the network is relegated to non-real-time tasks — model updates, telemetry, content sync. The connection can jitter all it likes without touching the streaming experience. The cost is that you must ship and maintain a model that fits the device’s compute and memory envelope, which raises its own portability questions — the tensor-layout and runtime-compatibility issues we unpack in 3D tensors in TTS inference: shape, layout, and cross-runtime portability and the build-time tuning covered in compiler flags for cross-platform ONNX and CoreML inference. A quick decision rubric Use this before you commit to a network-dependent architecture: Is the workload streaming and latency-perceptible? (TTS, live captioning, interactive audio) → jitter, not average latency, is your binding constraint. Lean on-device. Do target markets run predominantly on NSA infrastructure? → assume LTE-class latency plus handover jitter in your budget. Do not design against SA figures you cannot guarantee. Can the model fit the device envelope after quantisation? → if yes, on-device inference removes the network from the critical path. If no, you may be forced server-side and must budget generously for the tail. Is the interaction batch-tolerant? (offline synthesis, non-interactive generation) → server-side is fine; NSA latency is invisible here. The reframe is straightforward once the NSA distinction is clear: on-device inference is not a premature optimisation you defer until the network disappoints. On NSA-dominant markets, it is the architecture that lets you set a realistic end-to-end budget up front and avoid a re-architecture cycle when field latency exceeds your assumptions by tens of milliseconds. We treat these network assumptions as first-class inputs to any real-time deployment we scope in the media and telecom practice. FAQ What does working with 5G NSA meaning involve in practice? NSA (Non-Standalone) is a deployment mode where a 5G New Radio carrier is added on top of an existing 4G LTE network. The 5G radio carries the fast data pipe, but the control plane — connection setup, mobility, signalling — stays anchored to the LTE Evolved Packet Core. In practice you get 5G-class peak throughput riding on an LTE-class latency and signalling foundation. What is the difference between 5G NSA (Non-Standalone) and SA (Standalone) architecture? NSA anchors the control plane to the 4G LTE core (3GPP Option 3 / EN-DC), while SA replaces it with the 5G Core (5GC) and its service-based architecture. Only SA enables ultra-reliable low-latency communication (URLLC) and network slicing. For latency-sensitive workloads, SA delivers a lower, more deterministic latency floor; NSA behaves closer to enhanced LTE. Why does NSA still depend on the LTE core, and how does that affect latency and jitter? In NSA the LTE base station is the master node and the 5G base station is a secondary node, so session setup, mobility management, and connection-state machinery run through the LTE anchor. This puts the latency floor above SA, and the dual-connectivity juggling of two radios adds jitter during handovers and secondary-cell changes. The data path can burst fast, but the connection managing it does LTE-era signalling. What latency and jitter profile can I realistically expect on an NSA network for real-time streaming? Plan for LTE-class round-trip latency — tens of milliseconds — with radio-side jitter, not the sub-10ms figure marketed for standalone 5G (observed pattern in deployment planning; not a carrier benchmark). Expect occasional multi-hundred-millisecond spikes during handovers. For streaming workloads it is those p99 spikes, not the average, that break the experience. How does an NSA network’s latency variability change where I place the inference boundary — on-device versus server-side? Server-side inference puts the NSA round trip and its jitter on the critical path of every real-time interaction, so handover spikes surface as audible dropouts. On-device inference removes the network from the critical path entirely, relegating the connection to non-real-time tasks like model updates and telemetry. NSA’s variability therefore pushes latency-perceptible workloads toward the on-device boundary. When should a real-time TTS pipeline assume on-device inference (CoreML/ONNX) rather than rely on network offload? Assume on-device inference when the workload is streaming and latency-perceptible and the target markets run predominantly on NSA infrastructure, provided the model fits the device’s compute and memory envelope after quantisation. In that case running the model locally through CoreML or ONNX Runtime lets you set a realistic budget up front. Batch-tolerant or non-interactive synthesis can stay server-side, where NSA latency is effectively invisible. The uncomfortable part of NSA is that nothing on the coverage map warns you it is not full 5G — the label is identical, the throughput graph looks great, and the latency problem only appears once your streaming pipeline meets a real cell under mobility. Knowing what the control plane is actually anchored to is what lets you draw the inference boundary before the field data forces you to.
