A 5G NSA Attach, End to End

Reading a real 5G NSA / EN-DC (Option 3) capture, taken on the LTE leg of an open5gs test network — from the first LTE random-access message to the event-B1-NR measurement report that pulls a 5G gNB into the call. The trace was decoded and annotated with VisualEther, which turns a Wireshark PCAP into a sequence diagram.

💡 Read the walkthrough and the diagram side by side. Open the interactive diagram (or PDF) in a split-screen window so the captions stay in view as you read. In Edge, Chrome, or Firefox, right-click the link and pick your browser's split-screen option (Edge labels it "Open link in split screen window"). On macOS, prefer Chrome or Firefox — Safari has no in-browser split screen. Otherwise, open the diagram in a new tab and snap the two windows side by side.

Overview

In 5G Non-Standalone (NSA) Option 3, sometimes called EN-DC — E-UTRA-NR Dual Connectivity — there is no 5G core. The UE attaches to the 4G EPC through an LTE anchor eNB, exactly as it always has, and 5G arrives later as a secondary leg: the eNB asks a nearby 5G gNB to add an NR data radio bearer to the connection already in progress. This capture is that whole flow, read from the LTE side.

The trace is 40 frames, which VisualEther renders as 57 messages. The interfaces come up first — S1 to the core, then the EN-DC X2 to the gNB — and then, once a UE arrives, the attach itself unfolds in about 1.2 seconds. A few facts hold for the whole capture:

• One UE, identified by its cell radio identity C-RNTI 23133, on the LTE serving carrier EARFCN 3100 (Band 7, ~2630 MHz). The 5G neighbor it will eventually report is on NR band n78 (NR-ARFCN 640000, ~3600 MHz).
• It is a single-host loopback capture. The emulated eNB, MME, and gNB all run on 127.0.0.1, so VisualEther labels the four actors by role — 📡 eNB, ☁️ MME, 📶 SgNB, 📱 UE — rather than by address. One practical consequence: every NAS message appears twice, once on the S1 leg (S1AP over SCTP, eNB ↔ MME) and once on the radio leg (PDCP/RLC over the MAC-LTE framing, eNB ↔ UE). The diagram interleaves both; you can watch a single NAS message cross the core interface and the air interface in the same picture.
• Access-Stratum security uses the EEA0 null cipher with EIA2 integrity — a lab choice. Nothing is ciphered over the air, but messages are integrity-protected once security activates. Notably, this trace shows no NAS authentication and no NAS security-mode exchange; the only NAS between the Attach Request and the Attach Accept is the ESM information exchange. That is characteristic of a test rig, not a commercial network.

For the deep dive into the X2AP SgNB Addition procedure on its own — the Request, the Acknowledge, and the fields that mint the SgNB-UE-X2AP-ID — see the companion post, EN-DC SgNB Addition over X2. This walkthrough puts that procedure in its full context: what has to happen before the eNB can even ask.

A primer on the NSA / EN-DC stack

NSA rides two control interfaces and one radio stack, all captured here:

Those seven rows collapse into four actors and four interfaces. Taken on the LTE leg of a single loopback host, this capture sees three of them at once — the LTE air interface (Uu), S1-MME, and the EN-DC X2 — and the one it never sees is the NR radio leg the gNB adds at the end:

Two ideas do most of the work in this capture:

The anchor node adds the secondary node — never the other way around. The LTE eNB is the anchor (MeNB): it owns the RRC connection, the mobility, and the NAS relay. The 5G gNB is the secondary (SgNB): it contributes NR radio resources on request. In Option 3, the control plane is 100% LTE; the gNB carries only user data.

5G is triggered by a measurement, not by the attach. The UE does not "attach to 5G." It attaches to LTE, and only once the eNB has configured NR measurements and the UE reports a good-enough NR cell does the eNB decide to add the 5G leg. The report that carries that decision — an event-B1-NR measurement report — is the hinge of this whole flow, and the reason the measurement configuration below deserves its own section.

The flow at a glance

Before the frame-by-frame walk, here is the whole connection in one picture. The interfaces come up, the UE attaches over LTE, and the network arms NR measurements — then everything hinges on a single decision: does the UE report a good-enough NR cell? Only when an event-B1-NR report crosses that gate does the eNB add the 5G leg and rehome the bearer onto it.

The flow above breaks into six phases, each covered in a section below. The interactive diagram shows every arrow, and clicking any message opens its full Wireshark field tree.

1. Interface bring-up (frames 1–4) — S1 Setup to the MME, then the EN-DC X2 Setup to the gNB. No UE yet.
2. Random access and attach begins (frames 5–13) — LTE Msg3/Msg4, the EPS Attach Request, the ESM information exchange, and the InitialContextSetupRequest that carries the Attach Accept.
3. Security, capabilities, and the arming reconfiguration (frames 14–23) — AS Security Mode, UE Capability, and the RRC Reconfiguration that installs the bearers and the NR measurement configuration, followed by Attach Complete.
4. The 5G trigger and SgNB Addition (frames 24–29) — the event-B1-NR report, the X2 SgNB Addition Request/Acknowledge, and the reconfiguration that adds the NR secondary cell group.
5. User-plane rehoming (frames 31–32) — the E-RAB Modification that redirects downlink user data to the gNB.
6. Steady-state measurement reporting (frames 30, 33–40) — the periodic reports that keep both legs monitored.

This one connection advances three state machines. The radio link (RRC) and the EPS mobility layer (EMM) both go from idle/deregistered to connected/registered; a third — the EN-DC secondary node — starts absent and becomes active on the measurement trigger.

Now let us dig deeper and look at each frame in the flow.

Phase 1 — Bringing up the interfaces (frames 1–4)

Before a single UE can be served, two interfaces have to come up.

Frames 1–2 — S1 Setup. The eNB introduces itself to the MME (open5gs-mme0) over SCTP, advertising its Global eNB ID, supported tracking areas, and PLMN; the MME accepts and returns its served GUMMEIs and relative capacity. The S1-MME control link is now live.

Frames 3–4 — EN-DC X2 Setup. This is the NSA-specific handshake. The secondary gNB and the anchor eNB bring up the X2 interface between them, advertising Global gNB-ID 3584, the 5GS-TAC, PLMN 505/01, and each other's served cells (the eNB's DL-EARFCN 3100). Ordinary X2 exists for LTE-to-LTE handover; the EN-DC X2 variant is what makes per-UE SgNB Addition possible later. Nothing here is UE-specific — it is pure infrastructure.

Phase 2 — Random access and the start of attach (frames 5–13)

Frames 5–6 — LTE random access (Msg3 / Msg4). The UE speaks first on the Common Control Channel (CCCH) with an RRC Connection Request — this is Msg3 of contention-based random access. It picks C-RNTI 23133, offers a randomValue identity, and gives establishment cause mo-Signalling. The eNB answers with RRC Connection Setup (Msg4), whose MAC carries the UE Contention Resolution Identity control element (LCID 0x1c) that resolves the contention and installs SRB1. The UE enters RRC_CONNECTED.

Frame 7 — Attach Request reaches the core. The eNB wraps the UE's NAS in an S1AP Initial UE Message and sends it to the MME, tagging the UE with eNB-UE-S1AP-ID 12041263. The NAS is an EPS Attach Request of type Combined EPS/IMSI attach, with a PDN Connectivity Request piggybacked to bring up the default bearer. This message also carries the first EN-DC signal in the whole trace: the UE Network Capability sets the DCNR bit (Dual connectivity with NR: Supported), telling the core this UE can run EN-DC. Everything the flow does later to add a gNB depends on this bit — the network will not offer 5G to a UE that never asked for it.

Frames 9–12 — the ESM information exchange. Instead of authentication (absent here), the network runs one round-trip: an ESM Information Request (frame 9 on S1, frame 10 over the air) asking the UE for the APN and protocol configuration options, and an ESM Information Response (frame 11 on S1) returning them. Frame 10 is worth pausing on — its MAC-I is 0x00000000 because AS security is not active yet. Compare it with the first post-security PDU in the next phase.

Frame 13 — the pivotal S1 message: InitialContextSetupRequest. The MME now delivers, in a single S1AP message, everything the eNB needs to finish the job: the NAS Attach Accept + Activate Default EPS Bearer Context Request, the default bearer E-RAB 5 (QCI 9), the K_eNB key the eNB will use to switch on AS security, and the UE's security capabilities. That last field is the quiet enabler of everything 5G that follows: alongside the EPS EEA/EIA algorithms, it carries the UE's NRUESecurityCapabilities (NEA1/2/3). The network now knows this UE can do NR security — a precondition for EN-DC. The Attach Accept in the same message closes the loop the DCNR bit opened in frame 7: it marks dual connectivity with NR Not restricted — the core's explicit go-ahead for this UE to use a 5G secondary RAT.

Phase 3 — Security, capabilities, and the arming reconfiguration (frames 14–23)

Frames 14–15 — AS security. The eNB switches on Access-Stratum security, keyed from K_eNB: cipher EEA0 (null) and integrity EIA2. The UE confirms. From here on, SRB and DRB PDCP PDUs are integrity-protected.

Frame 16 — security on the wire, and the capability request. The first downlink PDCP PDU after activation now shows security context EEA0/EIA2 and a real integrity tag, MAC-I 0x76596de5, not the 0x00000000 from frame 10. That first secured downlink PDU is the RRC UE Capability Enquiry — the eNB asking the UE what it can do. This first enquiry requests RAT-Type: eutra (the LTE capabilities); the UE's answer in the next two frames already carries its supported NR bands. The EN-DC-specific enquiry — for eutra-nr and nr — comes separately in frame 21.

Frames 17–18 — UE capabilities. A large uplink segment (2331 bytes) carries the UE Capability Information over the air, answering the frame-16 enquiry; the eNB relays it to the MME as an S1AP UE Capability Info Indication. Although this response is the E-UTRA container, it records the UE's NR bands (n78) and EN-DC band combinations — the eNB keeps a copy to drive the measurement configuration it is about to send.

Frame 19 — the reconfiguration that arms the whole flow. One RRC Connection Reconfiguration does three jobs at once: it delivers the piggybacked NAS Attach Accept; it sets up the radio bearers (SRB2 plus the default DRB1 for EPS bearer 5); and it installs the measurement configuration. That last part is what makes 5G possible, so it gets its own section below. The UE confirms with Reconfiguration Complete (frame 20), and the EPS attach finishes with Attach Complete on the newly built SRB2 (frames 22–23, relayed to the MME later in frame 31).

Phase 4 — The 5G trigger and SgNB Addition (frames 24–29)

This is the heart of the flow.

Frame 24 — the report that pulls 5G in. The UE sends its first measurement report carrying NR (measId 7). Event B1-NR has fired: alongside the LTE serving-cell result, the report includes a measResultNeighCellListNR entry — NR PCI 0, SS-RSRP in the −91 to −90 dBm bucket, SS-RSRQ around −11 dB. Crossing the B1 threshold is exactly the "this UE can see 5G" signal the eNB was waiting for, and it reacts in the very next frame.

The tree below shows it: expand lte_rrc -> measurementReport -> measResults, then measResultNeighCells -> measResultNeighCellListNR-r15, to find the NR cell (PCI 0, with its SS-RSRP / SS-RSRQ) next to the LTE serving measResultPCell in this single measId-7 report:

Frame 24 — an event-B1-NR measurement report (measId 7). The NR neighbor rides in measResultNeighCellListNR-r15; measId 1/2 reports carry no such list.

Frames 25–26 — SgNB Addition over X2. The eNB asks the gNB to allocate NR resources for E-RAB 5 / DRB 1, handing over the S-KgNB security key (derived from K_eNB), the UE's NR security capabilities, and the en-DC-ResourceConfiguration. Here the bearer's resource-configuration is sgNBPDCPpresent — PDCP is placed at the gNB, making this an SgNB-terminated (SCG) bearer, in contrast to the MCG-anchored split bearer (PDCP kept at the eNB) walked through in the companion X2AP post. Because the bearer now terminates at the gNB, the Request also carries the S-GW's uplink S1-U endpoint (s1-UL-GTPtunnelEndpoint, 0x00000010), so the gNB can send this bearer's uplink straight to the core. For the UE-association, the Request carries only the MeNB-UE-X2AP-ID; the Acknowledge completes the pairing — the gNB mints its own SgNB-UE-X2AP-ID 1779 — and returns two things that matter downstream: its downlink GTP-TEID 0x649bacbf (the SCG leg's endpoint) and the NR RRCReconfiguration (the SCG CG-Config) for the UE.

The gNB's reply carries all of that in one X2AP message. In the tree below, expand x2ap to the SgNBAdditionRequestAcknowledge, then E-RABs-Admitted-ToBeAdded-SgNBAddReqAckList for the admitted E-RAB 5 and its gTP-TEID (0x649bacbf, the gNB's downlink endpoint), the assigned SgNB-UE-X2AP-ID, and the SgNBtoMeNBContainer that holds the NR RRC config the eNB forwards to the UE in frame 27:

Frame 26 — SgNB Addition Request Acknowledge. The gTP-TEID here is what frame 31's E-RAB Modification later hands to the MME to rehome the downlink.

Frames 27–29 — configuring the NR secondary cell group. The eNB forwards the gNB's NR configuration to the UE inside an RRC Reconfiguration: nr-SecondaryCellGroupConfig (band n78, p-NR-FR1 = 20 dBm, SSB and CSI reporting) plus nr-RadioBearerConfig1. The same message also releases LTE DRB 1 (drb-ToReleaseList) — the radio bearer the attach set up for EPS bearer 5 back in frame 19 — and re-adds that bearer under nr-RadioBearerConfig1 on the SCG. So the default bearer's radio leg, and with it the PDCP entity, migrate from the eNB to the gNB in one step; the E-RAB Modification in Phase 5 then completes the move at the S1-U level. The eNB tells the gNB it is done (X2 SgNB Reconfiguration Complete, frame 28), and the UE confirms — its Reconfiguration Complete (frame 29) embeds the NR SCG-complete. Its MAC now carries a Dual Connectivity Power Headroom Report (LCID 0x18): concrete, on-air proof that the UE is now running two cell groups.

That control element has a fixed, spec-defined layout (TS 36.321 §6.1.3.9). Its MAC subheader carries LCID 0x18 plus a 7-bit length; the control element itself is a 4-octet bitmap marking which SCells report power headroom, followed by one PH field per reported serving cell:

How the report is used. Power headroom is the margin between the UE's configured maximum transmit power on a carrier — the PCMAX,c in the report — and the power its current uplink actually needs; in short, how much more the UE could transmit if the scheduler asked. A scheduler reads it for uplink link adaptation: a UE with ample headroom can take a larger grant or a higher-order modulation, while one near its ceiling has to be scheduled gently or its transmission gets power-scaled.

Dual connectivity requires this because two nodes with no shared scheduler — the LTE eNB on the master cell group and the NR gNB on the secondary cell group — schedule the UE while it draws on one transmit-power budget. If each node sized its grants as though it had the UE to itself, the two uplinks could together demand more power than the UE has, forcing it to scale back. Power headroom is reported per MAC entity, each to its own node: this report rides the LTE MAC on the uplink to the eNB, so the eNB is what consumes it, while the gNB relies on the separate NR headroom reports the UE sends on the NR leg — which this LTE-side capture never sees. What ties the two together is not a shared report but a shared limit: when the SCG is set up, the eNB and gNB agree over X2 on how the UE's total power is divided between LTE and NR, and each then schedules its own leg within that split. That is also why the report switches to the dual-connectivity form here — the format tells the eNB the UE is now in dual connectivity, with the NR leg sharing its power amplifier; before the SCG, an ordinary PHR would do. Each per-cell field carries the headroom along two axes — the PH value is tagged Type 1 (headroom for a data PUSCH) or Type 2 (also accounting for a control PUCCH). The V bit marks whether it is a real measurement or a virtual estimate computed from a reference format when the UE is not actually transmitting on that cell.

Phase 5 — Rehoming the user plane (frames 31–32)

The control plane says the 5G leg exists; the user plane still has to point to it. Frame 31 is a bundle — it carries the S1AP InitialContextSetupResponse, the uplink NAS Attach Complete, and the NSA-specific piece, an E-RAB Modification Indication. That PDU tells the MME the downlink S1-U endpoint for E-RAB 5 has moved to the gNB's GTP-TEID from frame 26. The MME answers with E-RAB Modification Confirm (frame 32), so the serving gateway now streams this bearer's downlink data to the gNB. Only the downlink needs this step: the uplink endpoint reached the gNB back in the SgNB Addition Request (frame 25), so both directions of E-RAB 5 now bypass the eNB entirely. With the attach complete and the bearer rehomed to NR, the EN-DC data path is fully live.

Measurement reports, in depth

The key question is: which measurement report brought in 5G, and what did it carry? This capture answers it: the whole measurement configuration arrives in one frame (frame 19), then plays out in the reports that follow.

The configuration (frame 19). The measConfig defines two measurement objects and seven measurement identities:

Only measId 7 points at the NR measurement object, and only its report config is reportConfigInterRAT with eventB1-NR-r15. Its b1-ThresholdNR is set to the RSRP floor, so it triggers as soon as the UE detects any NR cell — a deliberately eager configuration for a lab that wants EN-DC to come up the moment a gNB is in range.

In the tree below, expand lte_rrc -> ... -> measConfig, then measObjectToAddModList (the E-UTRA and NR objects), reportConfigToAddModList (report config 7 holds the eventB1-NR-r15 threshold), and measIdToAddModList (where measId 7 binds to the NR object, measObjectId 2):