5G Deployment Strategy for Telecom Operators: NSA vs SA

1. Introduction

An operator that already runs 2G, 3G, and 4G/LTE has one fundamental question to answer before switching on 5G: do we deploy Non-Standalone (NSA) 5G anchored on our existing 4G core or do we go straight to Standalone (SA) 5G with a native 5G Core (5GC)?

This decision affects RAN procurement, core network investment, interoperability testing effort, feature roadmap (network slicing, ultra-low latency, massive IoT) and critically how hard the eventual migration to full SA will be. This blog walks through the architecture, the trade-offs, what happens technically when NSA and SA domains from different vendors need to hand a subscriber between them and whether an NSA 5G layer needs to come from the same vendor as the existing 4G/LTE network.

2. NSA vs SA: Architecture Fundamentals

2.1 Non-Standalone (NSA): 3GPP Option 3x (EN-DC)

In NSA, the 5G New Radio (NR) does not have its own core network. Instead, the 5G gNB is "anchored" to the existing 4G Evolved Packet Core (EPC) through the LTE eNB. The UE is dual-connected to both the LTE eNB (Master Node, MeNB) and the 5G gNB (Secondary Node, SgNB) simultaneously, this is called EN-DC (E-UTRA-NR Dual Connectivity).

- Control plane (signaling, mobility, NAS) stays anchored on LTE/EPC via the MeNB.

- User plane can be split: some bearers stay on LTE, some move to NR, some are split across both (this is what gives the throughput boost).

- The interface between the LTE eNB and the 5G gNB is X2-C/X2-U (or Xn in some deployment variants).

Key point: in NSA, the gNB has no direct signaling relationship with the core network for mobility/session management. Everything is brokered through the LTE eNB. If the eNB or the X2 link fails, the UE loses its 5G leg entirely and falls back to LTE-only.

2.2 Standalone (SA): 3GPP Option 2

In SA, the 5G gNB connects directly to a native 5G Core (5GC), a cloud-native, service-based architecture (AMF, SMF, UPF, PCF, UDM, NRF, etc.) over the N2 (control plane) and N3 (user plane) interfaces. There is no LTE anchor required.

SA unlocks the features that NSA structurally cannot deliver: network slicing, ultra-reliable low-latency communication (URLLC), massive machine-type communication (mMTC), edge computing integration (MEC via local UPF breakout), and true end-to-end 5G QoS control.

3. NSA vs SA: Detailed Comparison

3.1 Merits and Demerits

NSA: Merits

- Fast time-to-market; monetize 5G speeds within months using existing core investment.

- Lower initial CAPEX, no immediate 5GC buildout.

- Leverages existing OSS/BSS, IMS/VoLTE and O&M processes already built around the 4G core.

- Good fit for capacity relief in dense urban areas where LTE is congested.

NSA: Demerits

- Structurally cannot deliver network slicing, deterministic low latency or full 5G QoS differentiation — the "real" value proposition of 5G for verticals (Industry 4.0, V2X, remote surgery) is unreachable.

- Hard dependency: every 5G cell needs 100% co-located/overlapping LTE coverage. No LTE anchor signal = no 5G service, even if the gNB is healthy.

- Creates technical debt: the operator eventually re-engineers RAN and rolls out 5GC anyway. NSA is a bridge, not a destination.

- Increased RAN complexity for split-bearer scheduling, tighter timing/synchronization requirements between eNB and gNB.

SA: Merits

- Full 5G feature set: network slicing (e.g., dedicated slice for enterprise/URLLC), MEC integration, deterministic latency, service-based core scalability.

- Independent 5G coverage planning, not shackled to LTE footprint.

- Cleaner multi-vendor boundary at N2/N3 (service-based interfaces are more standardized/testable than X2 EN-DC coupling).

- Future-proof. This is the terminal architecture, no forced second migration.

SA: Demerits

- Higher upfront investment: cloud-native 5GC, new OSS/BSS integration, new voice strategy (VoNR/EPS Fallback).

- Device/chipset SA support and roaming SA support have historically lagged NSA, especially internationally.

- Longer deployment timeline: integration, testing and hardening of a brand-new core is non-trivial.

- Operationally new skill set required (cloud-native ops, Kubernetes/CNF lifecycle management, service mesh, etc.) vs traditional EPC operations.

4. Multi-Vendor NSA↔SA Handoff: What Actually Happens on the Wire

This is the scenario operators worry about most: the NSA layer (say, Vendor A's eNB + Vendor A's gNB) and the SA layer (say, Vendor B's gNB + Vendor B's 5GC) are built by different manufacturers. How does a UE move between them?

4.1 The interworking interface: N26

3GPP defined the N26 interface specifically to allow seamless mobility between EPC (4G/NSA world) and 5GC (SA world). N26 connects the MME (in EPC) to the AMF (in 5GC) and carries context-transfer signaling so a UE's session can be handed over with minimal service interruption (target: near-zero-loss handover for supporting cases).

Interworking path: NSA/EPC domain (eNB - S1-MME - MME) ↔ N26 interface (context transfer, standardized 3GPP) ↔ SA/5GC domain (AMF - gNB) with X2 used within the NSA domain for eNB↔gNB coordination and handover triggered between the two domains.

If N26 is deployed (an "interworking-enabled" configuration), the handover between the NSA/EPC domain and the SA/5GC domain is treated much like an inter-system handover: the source MME and target AMF exchange UE context (security context, bearer/PDU session mapping, mobility restrictions) directly, even though they are built by different vendors, because N26, like S1/X2/N2, is a standardized 3GPP reference point with defined message sets (GTP-C-based signaling reusing Forward Relocation Request/Response constructs, adapted for 5GC).

If N26 is not deployed ("N26-less" interworking, which some operators choose to avoid EPC-touching costs), the handover falls back to an idle-mode reselection with re-registration: the connection is released, and the UE re-attaches to the target system via NAS signaling from scratch. This means noticeably more service interruption (typically hundreds of ms to a few seconds versus a near-seamless handover with N26).

4.2 Step-by-step technical flow (N26-based inter-system handover)

1. UE is active on the NSA/EPC domain, dual-connected to eNB (MeNB) and gNB (SgNB).

2. A handover trigger occurs (e.g., moving out of NSA coverage, load balancing, or a policy decision to move the UE to the SA domain).

3. The source MME initiates a Forward Relocation Request toward the target AMF over N26, carrying the UE's security context, bearer/PDU session mappings, and mobility restrictions.

4. The target AMF, in coordination with the target gNB, establishes the necessary N2/N3 resources and PDU sessions.

5. The AMF acknowledges back to the MME over N26 and the network executes the handover command to the UE.

6. The UE switches over to the SA/5GC domain, resuming service under the new AMF/gNB with (ideally) minimal interruption.

4.3 Multi-vendor engineering realities that this diagram hides

The signaling flow above is standardized on paper but in a real multi-vendor deployment, three practical issues dominate the engineering effort:

1. Interoperability Testing (IOT) is mandatory and non-trivial: 3GPP specs leave implementation choices (timers, optional IEs, vendor-specific extensions in proprietary containers) that differ between vendors. Operators typically run dedicated IOT campaigns in a lab (and then field trials) pairing Vendor A's MME/eNB against Vendor B's AMF/gNB before any commercial N26 link goes live. GSMA and NGMN publish common IOT test frameworks that most Tier-1 vendors (Ericsson, Nokia, Huawei, Samsung, ZTE) align to, but "alignment" ≠ "identical behavior."

2. Timing and mapping of QoS/bearer semantics differ: EPS bearers (4G) map to QoS Class Identifiers (QCI); 5G QoS Flows use 5QI. The N26 handover requires QCI↔5QI mapping tables and if Vendor A and Vendor B implement slightly different default mapping tables or rounding of guaranteed bit rates, users can experience QoS mismatches (e.g., a VoLTE bearer not mapping cleanly to a voice-appropriate 5QI on the SA side).

3. Security context translation: The security keys (K_ASME on the EPC side vs K_AMF on the 5GC side) must be derived/translated during the handover per 3GPP TS 33.501 Annex A. Vendor implementations of key derivation and the "mapped security context" indicator must be tested end-to-end, since a mismatch here causes silent call/session drops rather than a clean error.

Practical example: if Operator X has Nokia running the NSA layer (Nokia eNB + Nokia gNB + Nokia EPC) in one region and rolls out a Huawei or Samsung 5GC-based SA layer in an adjacent region, the N26 link between Nokia's MME and Samsung's/Huawei's AMF must go through a formal IOT cycle. This is standard practice. Vodafone, Deutsche Telekom and other Tier-1 operators have publicly documented multi-vendor 5G IOT programs for exactly this reason, but it adds weeks-to-months of testing lead time per new vendor pairing and typically a small residual risk of edge-case handover failures that get fixed via software patches post-launch.

5. Should NSA 5G Be the Same Vendor as Existing 4G/LTE?

This is the more nuanced and operationally important question if the operator's initial 5G strategy is NSA. Operating 4G and 5G in Non-Standalone (NSA) mode with different vendors is technically possible, but it is very difficult and rare in practice.

While 3GPP standards define the X2 interface for multi-vendor interoperability, each vendor implements it with proprietary extensions and vendor-locked configurations.

5.1 Why vendor alignment matters more in NSA than in SA

Recall from Section 2.1: in NSA/EN-DC, the LTE eNB (MeNB) and the 5G gNB (SgNB) are tightly coupled over X2-C/X2-U for:

- Dual-connectivity setup and teardown (SgNB Addition/Modification/Release procedures)

- Split-bearer scheduling coordination (which packets go over LTE vs NR)

- Timing/synchronization (both nodes must align frame timing for efficient split-bearer operation)

- Fast SgNB change (mobility between multiple 5G cells while staying anchored to the same or a neighboring 4G cell)

5.2 Technical answer: it is possible to mix vendors, but with real caveats

Standards-wise: 3GPP defines X2-C/X2-U (and Xn for newer deployments) as standardized interfaces precisely so that multi-vendor EN-DC is technically supported. An operator is not required to use the same RAN vendor for the 4G anchor and the 5G NR layer.

Practically, however:

1. Same-vendor NSA is the dominant real-world choice for a first-phase rollout, because:

- The eNB↔gNB coordination for split-bearer scheduling is latency-sensitive and benefits from a shared internal proprietary optimization layer that vendors build on top of the standard X2 interface (3GPP defines the baseline; vendors differentiate on scheduling efficiency, which works best intra-vendor).

- Software lifecycle management is simpler; one vendor's roadmap, one set of firmware/software upgrade cycles, one NOC/OSS integration.

- Faster time-to-market: no multi-vendor IOT lab campaign required before commercial launch.

- Single accountability for performance SLAs (no vendor finger-pointing when a split-bearer throughput issue appears).

2. Multi-vendor NSA is done, but usually as a deliberate strategic choice (e.g., to preserve a multi-vendor RAN strategy for negotiating leverage or because different regions of the network already have different incumbent 4G vendors and the operator wants a single 5G RAN vendor across the whole footprint). Example pattern seen in the industry: an operator with Huawei 4G RAN in Region 1 and Nokia 4G RAN in Region 2 decides to standardize on a single 5G RAN vendor (say, Ericsson) across both regions for supply-chain simplification. This results in Ericsson gNBs pairing with both Huawei eNBs and Nokia eNBs via standardized X2, each pairing requiring its own IOT validation. To make a multi-vendor NSA setup work, mobile operators must request customized software patches, buy specialized multi-vendor integration licenses and perform extensive interoperability testing. Because this process is costly and complex, most operators prefer to use the same vendor for both their 4G anchor and 5G radio layers or transition directly to 5G Standalone (SA).

3. Feature parity risk: some advanced EN-DC features (e.g., Ericsson's or Nokia's proprietary enhanced mobility robustness algorithms, dynamic spectrum sharing (DSS) coordination between 4G and 5G on the same carrier) are easiest and sometimes only available in a same-vendor configuration because DSS in particular requires extremely tight, often proprietary, real-time coordination between the LTE and NR schedulers sharing the same spectrum. This is one of the strongest practical arguments for same-vendor NSA when DSS is part of the strategy (which it very often is, since DSS is how operators launch 5G on existing LTE spectrum without a dedicated 5G carrier).

6. Migration Road Map: From NSA to SA

Because NSA is a bridge and not a destination, it's worth planning the eventual SA migration from day one rather than treating NSA as a standalone end-state. Key elements of a well-sequenced roadmap include:

- Designing the N26 interworking architecture (or explicitly deciding to go N26-less) before NSA contracts are signed.

- Planning the 5GC investment and vendor selection in parallel with the NSA rollout, rather than as an afterthought.

- Running multi-vendor IOT campaigns early for any anticipated NSA↔SA vendor boundary.

- Defining the voice strategy (VoNR vs EPS Fallback) ahead of SA launch.

- Sequencing spectrum refarming and DSS usage so the eventual SA rollout isn't blocked by NSA-era spectrum commitments.

7. Conclusion

For an operator moving from 4G to 5G, the NSA-vs-SA decision is really a decision about sequencing risk, not avoiding it:

- NSA gets 5G speeds to market fastest and cheapest, reusing the existing EPC, but it is architecturally incapable of delivering network slicing, deterministic low latency or independent 5G coverage, and it is a transitional state that will eventually be replaced.

- SA is the real destination, it's where slicing, MEC and vertical-industry use cases live. But it requires a new cloud-native core and a longer runway.

- Multi-vendor NSA↔SA handoff is standards-supported via the N26 interface, but real-world multi-vendor deployments require dedicated interoperability testing around QoS mapping (QCI↔5QI), security context translation and vendor-specific protocol extensions.

- For the NSA phase specifically, while 3GPP's X2 interface makes multi-vendor eNB/gNB pairing technically possible, same-vendor NSA remains the more common and lower-risk choice.

The operator that plans the N26 interworking design and the eventual SA core investment before signing NSA contracts will have a materially smoother and cheaper path to full 5G SA than one that treats NSA as a standalone finish line.

Disclaimer

The views and technical opinions expressed in this blog are my own and are presented from my perspective as a Communication Engineer. They are intended for technical discussion and knowledge sharing and should not be considered an official position, policy or statement of any organization or institution with which I am affiliated.