By -

NSA Didn't Break First. Our Assumptions Did.

5G NSA  ·  LTE  ·  architecture assumptions  . 7 min read

There is a common narrative that early 5G NSA deployments struggled because the architecture was transitional. That framing misses what actually happened. NSA did not introduce new problems. It made existing ones visible at a scale that could no longer be ignored.

The LTE anchor had always been treated as the stable, predictable layer. That assumption held when LTE carried LTE traffic and nothing else. Once NR was layered on top, small inconsistencies in the anchor became amplified in ways that no amount of NR-side tuning could fix.

Where the assumption failures actually surfaced
NSA layer interaction diagram showing where assumption failures surfaced
Fig 1 -- NSA layer interaction: three failure classes tied to LTE anchor assumptions, not NR behavior

Each of these failure classes was present in the LTE network before NSA. They had been managed, worked around, or accepted as within-threshold. NSA changed the cost of each one, because NR availability and user-plane quality were now directly dependent on anchor stability.

Anchor reselection timing -- what it looked like in the data
Pre-NSA: anchor cell reselection visible as brief HO event, KPI within target Post-NSA: same event triggers NR SCell release and re-addition Re-addition delay: 280-450ms During re-addition: user plane on LTE only (no NR throughput) Session impact: invisible in voice KPIs, significant in data experience Aggregate NR availability: appeared healthy Per-session NR utilization: 60-70% of session time, not 90%+
Why 2024 traffic made it harder

Applications no longer behaved in long, steady sessions. Short bursts, background sync, and latency-sensitive flows forced the network to make more decisions per second, especially at state boundaries. The scheduler, the mobility layer, and the anchor selection logic were all making independent decisions at higher frequency than the tuning model anticipated.

Traffic diversity impact on NSA decision rate -- 2024 vs 2020: 2020 traffic profile (at NSA launch): Dominant pattern: sustained video, large file transfers Session duration: minutes State transitions per session: low Scheduler decisions per session: high but predictable 2024 traffic profile: Dominant pattern: short bursts, app sync, real-time feeds Session duration: seconds to tens of seconds State transitions per session: high Scheduler decisions per session: compressed into shorter windows Effect on NSA: More anchor reselection events per device per hour More NR SCell add/release cycles More opportunities for timer misalignment to produce visible impact Higher sensitivity to LTE scheduler congestion spikes
What the effective fixes actually targeted

The most impactful changes were not the ones that pushed NR performance harder. They were the ones that reduced unnecessary variability in the anchor layer. Tuning NSA turned out to be mostly a discipline exercise in the LTE configuration.

Fix category What was changed Why it worked Timer alignment T310, T311, SCell deactivation timer synchronized across anchor and secondary Eliminated timer-driven SCell releases that were not triggered by actual radio conditions State churn reduction RRC inactivity timer extended at high-activity cells; C-DRX cycle aligned with burst pattern Reduced unnecessary idle-to-connected transitions that triggered SCell re-addition cycles Anchor selection Anchor cell candidate list filtered by load and mobility history, not coverage alone Devices landed on anchors less likely to reselect during active NR sessions Throughput vs consistency Aggressive CA and NR MIMO configurations relaxed at high-churn cells Slightly lower peak throughput, significantly higher session consistency

None of these were high-visibility changes. They did not show up in vendor feature lists or release notes. They were the kind of unglamorous alignment work that only becomes necessary once you are measuring what the user actually experienced rather than what the network reported.

How validation had to change
Validation scope shift from lab to live network conditions
Fig 2 -- Validation scope: the shift from lab feature checks to live network behavioral testing

Lab success and vendor certification confirmed that a feature functioned. They did not confirm how it behaved when combined with real device population, live mobility, and actual scheduler contention simultaneously. Those conditions are what users experience. They had to be what validation tested.

NSA readiness validation criteria -- what changed: Previous standard: NR SCell addition success rate: above threshold Throughput in test drive: meets minimum Feature enabled in config: confirmed Vendor acceptance: passed Updated criteria: NR session continuity during anchor reselection events (SCell available within 200ms of re-addition trigger) NR SCell utilization per session: p50 above 80% of session time State transition rate at busy hour: within timer design range Anchor reselection rate during active NR sessions: below 3% All measured under mixed broadband + IoT + background sync load

NSA did not fail because it was a transitional architecture. It was hard because it demanded discipline across layers that legacy tuning models treated independently. The LTE anchor assumptions, the mobility decisions, the scheduler priorities -- all of them were designed before NR dependence existed. Adjusting for that dependence was the real work of NSA optimization.

That discipline carried forward into SA readiness work and everything that followed. The lesson was not specific to NSA. Any time a new capability depends on the behavior of an existing layer that was not designed with that dependency in mind, the assumptions in that existing layer become the constraint. Finding them requires measuring the right things. Fixing them is usually quieter than expected.
5G NSA  ·  LTE  ·  RAN Optimization  ·  Architecture  ·  Performance Engineering  ·  OSS Analytics  ·  Telecommunications

Popular posts from this blog

By -
Image
Integrating Two Live Networks Without Breaking the Customer Network integration  ·  5G  ·  observability  .  8 min read  Large-scale network integrations are often described as a cutover problem. In reality, they are a behavioral problem. When two live mobile networks are stitched together, the hardest issues rarely come from radios or core elements in isolation. They emerge at the edges, where assumptions from one network collide with the operational realities of another. One of the earliest lessons during a nationwide integration effort was that roaming logic and native-network logic behave very differently under load. What works well for a roaming footprint can expose weaknesses quickly when millions of devices begin behaving as if the network is home. The issues that surfaced were not configuration gaps. They were assumption gaps. What surfaced only under live conditions None of the hardest problems appeared in lab testing. They appea...
Read more
By -
Image
The Evolution of AI in Telecommunications: From Static Models to Autonomous Agents  AI  ·  agentic systems  ·  RAN automation 9 min read AI in telecommunications is not one thing. It has been three distinct things, each requiring different infrastructure, different trust models, and different relationships between the system and the engineer operating it. Understanding that progression matters because where you sit in it determines what problems you can actually solve. This is not an abstract observation. The analytics platforms built across the past several years went through each stage in sequence, and each transition changed not just what the system could do but how it was used. The pattern that emerged is worth describing in some detail, because it applies broadly to how AI gets deployed in any operationally complex environment. The three paradigms and what separates them Fig 1 -- Three AI paradigms: capability and autonomy increase left ...
Read more
By -
Predictability is a harder engineering target than performance. A network can hit throughput benchmarks and still fail customers — because the failure mode isn't magnitude, it's consistency. Variance that can't be explained by traffic load or device behavior is an engineering debt, not an acceptable range. This became especially evident as VoLTE transitioned from preparation to production reality . The shift exposed a category of problems that lab testing and pre-launch drive campaigns rarely surface. The KPI gap In live LTE networks, many issues did not appear as outright failures. Calls connected, data flowed, and KPIs stayed within limits. Yet subtle inconsistencies — brief latency spikes, uneven uplink behavior, or intermittent retransmissions — created customer-visible quality degradation once voice traffic was introduced. Root cause pattern — VoLTE bearer health vs. perceived quality Uplink scheduling inconsistency → jitter on RTP stream → audio artifac...
Read more