5G NSA (EN-DC) Attach Call Flow in 5G NR

1. Why NSA Exists, and What It Is Not

NSA exists because in 2018 operators had spectrum at 3.5 GHz, a requirement to launch 5G, and no 5G core. EN-DC -- E-UTRA-NR Dual Connectivity, the radio mechanism behind what everyone calls NSA -- let them put an NR carrier on the air, aggregate it with an existing LTE carrier, and sell the result as 5G, without replacing a single EPC node or writing a line of 5G NAS. TS 37.340 cl. 4.1

That is a deployment-economics answer, not an engineering one, and it is worth being blunt about it because it explains every awkward property of NSA. The awkwardness is not accidental design; it is the price of not touching the core.

Start with what NSA is not. It is not a 5G attach. There is no 5G registration, no AMF, no SUCI, no 5G-GUTI, no 5G NAS security context and no NR RRC state machine of the UE's own. The UE performs an EPS attach over E-UTRA to an MME, exactly as an LTE-only UE would, and everything NR-related happens afterwards, inside an already-established LTE RRC connection, as an addition to it. The companion 01 Registration Process describes the SA case; hold the two side by side while you read this table.

Table 1. Read the last column top to bottom. Every row turns into a diagnostic that has no equivalent in SA, and every one of them is a place where NR can be absent while the UE is perfectly happy on LTE.

One more piece of vocabulary discipline, because it causes real confusion. Option 3 is the 3GPP architecture-option number for EN-DC with an EPC TS 37.340 cl. 4.1.2; option 2 is SA NR with a 5GC. Within option 3 there are three user-plane variants -- 3, 3a and 3x -- which are about where the S1-U terminates and nothing else (§3). And the node names differ from everything in the rest of this document set: the LTE node is the MeNB (master eNB), the NR node is the SgNB (secondary gNB, formally an en-gNB, meaning a gNB with an S1 rather than an NG interface). en-gNB and gNB are different node types in 3GPP terms, not two names for the same thing.

2. The Nodes, the Interfaces, and What Is Missing

Four network nodes, five interfaces, and two protocols you may not have looked at in years. The most useful way to learn the architecture is by subtraction: list what an SA deployment has, then delete the half of it that NSA does not.

Table 2. Note the asymmetry in the last two rows: which node's S1-U carries the traffic is a per-bearer decision taken at SgNB addition, and it is the only architectural choice in NSA that the transport planner cares about.

Two X2AP details are worth having in your head before §6. First, X2AP here is the same X2AP as LTE-to-LTE X2, extended in Rel-15 with the SgNB-prefixed procedures -- so an X2 association that works for LTE handover does not necessarily support EN-DC. The X2 SETUP exchange carries served-cell information, and an en-gNB advertises NR served cells in an ServedNRCellsToAdd structure the peer must understand. An eNB with pre-Rel-15 software will complete X2 Setup and then reject every SGNB ADDITION REQUEST.

Second, the SgNB-prefixed procedures are all UE-associated, keyed on the pair MeNB UE X2AP ID and SgNB UE X2AP ID. The MeNB allocates the first and the SgNB the second, and the SgNB's identity does not exist until the acknowledge comes back. That is why the request carries only one of the two and why correlating an NSA X2 trace means keying on the MeNB identity for the first message pair and on both thereafter.

3. Option 3, 3a and 3x: Where the User Plane Anchors

All three variants have the identical control plane: S1-MME at the MeNB, RRC at the MeNB, X2-C between the nodes. They differ in exactly one thing -- which node the S-GW's downlink GTP-U tunnel terminates at -- and that one thing decides where PDCP lives, which site needs backhaul, and whether X2-U carries user data at all.

Table 3. Option 3x moves the transport requirement to the node that was just built and sized for it. That is the entire argument, and it is a civil-engineering argument rather than a radio one.

Assume 3x unless you have evidence otherwise. Effectively every commercial EN-DC deployment uses it, and the variants show up in the trace clearly: in the SGNB ADDITION REQUEST the MeNB asks for an sgNB-terminated bearer option per E-RAB, and the acknowledge returns an S1 downlink tunnel endpoint at the SgNB. If instead the acknowledge returns an X2-U endpoint and the S1-U never moves, you are looking at option 3.

4. Phase 1: The LTE Attach, and the Two Bits That Decide Everything

This is an NR document set, so phase 1 gets a summary rather than a treatment -- but it gets the summary in order, because the ordering is the argument. Everything below happens on E-UTRA, with the EPC, with no NR involvement whatsoever.

1. E-UTRA cell search and PLMN selection. The UE scans E-UTRA carriers, acquires PSS/SSS and PBCH, reads SIB1 for the PLMN identity list and the tracking area, and selects a cell. In our running scenario: EARFCN 1650, band 3, PCI 118, PLMN 001-01. There is no NR SSB search here and no NR SIB1 read -- ever, in the whole of NSA. The UE will never read an NR SIB1 for access purposes.
2. RRC connection establishment. RRCConnectionRequest on CCCH, RRCConnectionSetup, RRCConnectionSetupComplete on SRB1 with the initial NAS message piggybacked. TS 36.331 cl. 5.3.3 The equivalent NR procedure is in companion 15 RRC Procedures.
3. EPS Attach Request, carried in that SetupComplete and relayed by the eNB in an S1AP INITIAL UE MESSAGE. This message carries the UE network capability IE, and inside it the DCNR bit. That is gate one.
4. Authentication and NAS security. EPS AKA: Authentication Request/Response against the HSS-derived vector, then Security Mode Command/Complete establishing NAS integrity and ciphering under K_ASME. TS 33.401 cl. 6.1 Note what is absent: no SUCI, no concealment, no 5G-GUTI, no K_AUSF.
5. Initial context setup and the default EPS bearer. The MME sends S1AP INITIAL CONTEXT SETUP REQUEST with the default E-RAB -- E-RAB 5, QCI 9 in our scenario -- the S-GW's uplink S1-U endpoint, the UE's security capabilities including the NR ones, and a Handover Restriction List. The eNB derives K_eNB, runs the LTE SecurityModeCommand, and configures the bearer as an ordinary LTE DRB: DRB 1, LTE PDCP, LTE RLC, MCG only.
6. Attach Accept, in a NAS message inside DLInformationTransfer. This carries the EPS network feature support IE, and inside it the restrictDCNR flag. That is gate two.
7. Attach Complete. The UE is attached, has an IP address, and is passing traffic on a bearer that has nothing to do with NR and will keep working whatever happens next.

4.1 Gate one: the UE's DCNR bit

DCNR -- dual connectivity with NR -- is a single bit the UE sets in the UE network capability IE of the Attach Request and of every Tracking Area Update. TS 24.301 cl. 9.9.3.34 Set means I support dual connectivity with NR. Clear means do not offer me NR, and the network will not.

A UE clears it for reasons that are entirely outside the radio: the user turned 5G off in settings, the modem's carrier policy profile has NSA disabled for this PLMN, the device is in a battery-saving mode that disables EN-DC, or the SIM's operator configuration does not enable it. None of these produce anything visible except a cleared bit. This is the single most common cause of this phone has no 5G icon and that phone does.

4.2 Gate two: the MME's restrictDCNR flag

restrictDCNR is a bit in the EPS network feature support IE the MME sends in the Attach Accept and in every TAU Accept. TS 24.301 cl. 9.9.3.12A Set means use of dual connectivity with NR is restricted for this UE, and a compliant UE will then not attempt or accept EN-DC even if it set DCNR itself.

The MME sets it from subscription data -- an HSS field, per-subscriber, often tied to the tariff -- or from local policy, per tracking area or per roaming partner. The corresponding RAN-side control is the NR Restriction in EPS as Secondary RAT bit inside the S1AP Handover Restriction List, which the MME sends to the eNB rather than to the UE. TS 36.413 cl. 9.2.1.22 The two are supposed to agree, and when they do not, behaviour depends on the vendor.

One asymmetry to note. restrictDCNR can be cleared by a later TAU Accept, so a UE that could not use NR at 09:00 may be able to at 09:05 after moving into a different tracking area, with no other observable change. If your NSA attach-success statistics are bimodal by tracking area, the MME's per-TA policy table is the first thing to read.

5. Phase 2: Capability, Band Combinations, and Event B1

Both gates open. The UE is attached and passing traffic. Now the MeNB has to answer two questions before it can offer an NR leg: can this UE do EN-DC on the bands I have, and is there an NR cell here worth adding. Neither answer is available yet, and getting them takes two more LTE RRC exchanges.

5.1 UECapabilityEnquiry and the two containers

The MeNB sends an LTE UECapabilityEnquiry with ue-CapabilityRequest listing the RATs it wants: eutra, eutra-nr and nr. TS 36.331 cl. 5.6.3 Three RAT types, three separate containers in the response, and they answer different questions.

Table 4. The middle row is the one that decides EN-DC. The bottom row only decides what the NR configuration looks like once EN-DC has already been agreed.

The nesting is worth naming now because it recurs throughout: UECapabilityInformation is an LTE RRC message whose ue-CapabilityRAT-ContainerList holds, per RAT, an OCTET STRING. For eutra-nr and nr those octets are NR ASN.1, encoded per TS 38.331 and unparseable by an LTE-only decoder. This is the first of three places in NSA where an LTE message carries NR ASN.1 (§8).

5.2 Why the band combination list is what actually gates a band pair

A UE's UE-NR-Capability may list band n78. Its UE-EUTRA-Capability may list band 3. Neither fact means the UE can do EN-DC on B3 + n78. What means that is an entry in rf-ParametersMRDC.supportedBandCombinationList whose bandList contains both, with usable bandwidth classes on both. TS 38.331 cl. 6.3.3

That is not pedantry. A band combination is a statement about the UE's RF front end: two simultaneously active transmit and receive chains, with filters, duplexers and enough isolation to avoid intermodulation products landing in its own receiver. B3 uplink at 1710-1785 MHz and n78 at 3300-3800 MHz are far apart and easy; some combinations create a harmonic or intermodulation problem the UE simply cannot support, and those combinations are absent from the list even though both bands are individually present.

Table 5. Every row is optional in the ASN.1 and absent by default. In EN-DC capability signalling, absence is the answer to most questions, and it never comes with an explanation.

5.3 Event B1: the only trigger there is

The MeNB now knows EN-DC is possible. It still does not know whether there is an NR cell in range, and it has no way to find out except by asking the UE to look. It does that with an LTE measConfig containing two new-in-Rel-15 structures: a MeasObjectNR-r15 describing the NR carrier, and a ReportConfigInterRAT carrying eventB1-NR-r15. TS 36.331 cl. 5.5.4.1

Table 6. Eight fields, and getting any one of them wrong produces the same symptom: no B1 report, ever, from any UE in the cell. The three most commonly wrong are the SMTC, the SSB subcarrier spacing and the ARFCN.

The inequalities themselves are short. With Mn the UE's L3-filtered measurement of the NR neighbour in dBm, Ofn the measurement object's frequency offset, Hys the hysteresis and Thresh the threshold, all in dB or dBm TS 36.331 cl. 5.5.4.7:

B1 entering condition (B1-1):   Mn + Ofn - Hys  >  Thresh
B1 leaving  condition (B1-2):   Mn + Ofn + Hys  <  Thresh

With Ofn = -2 dB, Hys = 2 dB (IE value 4), Thresh = -96 dBm:

  entering when   Mn  >  Thresh - Ofn + Hys  =  -96 + 2 + 2  =  -92 dBm
  leaving  when   Mn  <  Thresh - Ofn - Hys  =  -96 + 2 - 2  =  -96 dBm

-- 4 dB of hysteresis band between the two levels, as designed.
-- Note there is no A3-style neighbour-versus-serving comparison here:
-- B1 is an absolute threshold on the NR cell alone. The LTE serving
-- cell's quality does not enter the arithmetic at all.

6. Phase 3, Part 1: SGNB ADDITION REQUEST

The B1 report has arrived. The MeNB resolves the reported NR PCI and frequency to a neighbour en-gNB, checks it has an X2 association to it, and sends the message that starts everything: X2AP SGNB ADDITION REQUEST, the initiating message of the SgNB Addition Preparation procedure. TS 36.423 cl. 8.4.1

This is a class-1 procedure -- it has explicit outcomes -- and it is the only message in NSA that hands a UE from one node to another. Everything the SgNB will ever know about this UE is in it. The SgNB has no S1-MME, no path to the MME, no subscription data and no prior contact with the UE; if a fact is not in this message or a later SGNB MODIFICATION, the SgNB does not have it.

Table 7. The two mandatory containers do the interesting work: SgNB Security Key makes the SgNB cryptographically part of this UE's session, and MeNB to SgNB Container is the only channel through which NR-specific information ever reaches it.

6.1 The SCG configuration query, and what admission control decides

The request does not tell the SgNB what to configure. It tells it what is needed and asks it to decide -- which is the CG-ConfigInfo container's real function, and the reason the procedure has a preparation phase at all. On receipt the SgNB runs, in order:

1. Per-E-RAB admission control. For each requested E-RAB, is there capacity at the candidate cell for its QoS class? A GBR bearer may be refused while a non-GBR one is admitted, which is why the acknowledge has both an admitted and a not-admitted list.
2. PSCell selection. From candidateCellInfoListMN in the container -- the relayed B1 measurement results -- pick the cell and the SSB beam the UE reported best. Our scenario: PCI 502, SSB index 1. The SgNB may prefer a different cell for load reasons, but it can only pick from cells the UE has actually reported.
3. Bandwidth part and numerology choice, constrained by the UE's UE-NR-Capability and by supportedBandwidthCombinationSet for the selected band combination.
4. CFRA resource reservation. A dedicated preamble and RACH occasion at the PSCell, so the UE's arrival is contention-free. Our scenario: preamble 58. This is a real resource, held from now until the UE arrives or the procedure fails.
5. Security algorithm selection from NR UE Security Capabilities, and derivation of the NR AS keys from S-K_gNB.
6. Authoring the NR RRCReconfiguration for the secondary cell group, then wrapping it as an OCTET STRING inside a CG-Config (§7).

If admission control fails for every bearer, or the container will not parse, or the UE's capabilities cannot be satisfied, the SgNB answers with SGNB ADDITION REQUEST REJECT -- a distinct message with a Cause IE, not an acknowledge with an empty admitted list. The common causes and what they mean are in the failure taxonomy (§17).

7. Phase 3, Part 2: The Acknowledge and the CG-Config

SGNB ADDITION REQUEST ACKNOWLEDGE is the most information-dense message in NSA. It allocates the SgNB's UE identity, returns the per-bearer verdict with tunnel endpoints, and -- the part that matters most -- carries a complete NR RRCReconfiguration the MeNB will relay to the UE without understanding a byte of it. TS 36.423 cl. 9.1.4.2

Table 8. Only the third and fourth rows have anything to do with the radio. The rest is transport plumbing -- which is a fair summary of what X2AP is for.

7.1 Inside CG-Config

CG-Config is an inter-node RRC message: an NR RRC structure that is never transmitted on any air interface, defined in TS 38.331 clause 11.2 precisely so that two network nodes can exchange NR configuration in NR ASN.1. Its NG-RAN cousins are HandoverPreparationInformation and HandoverCommand, which serve the same purpose in companion 23 Xn Handover.

Table 9. Two of these eight fields are opaque octet strings, and they are the two that contain everything the UE will actually be told. That structural fact is §8.

8. Three Levels of Container: NR RRC Inside LTE RRC Inside X2AP

This is the most important structural fact in NSA, and it deserves its own section because it explains a category of problem rather than a single one. The NR configuration the UE applies is authored by the SgNB in NR ASN.1, wrapped in an inter-node NR RRC message, wrapped in an X2AP octet string, unwrapped by the MeNB, re-wrapped in an LTE RRC octet string, and transmitted on an LTE air interface. The MeNB relays bytes it cannot parse. The SgNB authors bytes it cannot transmit.