Retrieve UE Context over Xn: RRC Resume, Message by Message

Reading a small XnAP-over-SCTP capture that shows the inter-gNB half of RRC Connection Resume: a UE waking from RRC_INACTIVE at a new cell, and the target gNB reaching over the Xn interface to pull the UE's suspended context from the gNB that still holds it. 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

This is a compact 5-frame capture of the Xn interface — the direct link between two 5G NG-RAN nodes — carrying the inter-gNB signaling behind RRC Connection Resume. When a UE that was parked in RRC_INACTIVE reappears in a different cell and requests to resume, the new gNB has no knowledge of the UE's state. It uses the identity in the resume request to find the anchor gNB — the one that suspended the UE and still holds its context — and fetches that context over Xn. That fetch is the Retrieve UE Context procedure, and this capture is all five of its messages plus the Xn bring-up that precedes them.

As with the EN-DC SgNB Addition capture, both gNBs here live on 127.0.0.1, distinguished only by SCTP port — a single-machine loopback capture rather than a trace of two nodes over a real Xn link. Several of its values are trivial (a 0x000000 I-RNTI, a 0x0001 MAC-I), so read it for the shape of the procedure — which identities and keys move between the nodes — rather than for realistic field values.

Every step is visible in the packets. In the interactive viewer or the HTML sequence diagram above, click any message to open its parameter details and the complete Wireshark field tree for that frame.

A primer on RRC_INACTIVE and Xn

5G adds a third RRC state between the familiar IDLE and CONNECTED: RRC_INACTIVE. A UE with no traffic can be suspended rather than released — the gNB keeps the UE's access-stratum context and hands the UE an I-RNTI, a token that identifies that stored context. When the UE has data again, it performs RRC Resume: a lightweight return to CONNECTED that reuses the saved context instead of setting everything up from scratch.

The wrinkle is mobility. The UE may resume at a cell served by a different gNB than the one that suspended it. Resolving that is the job of the Xn procedure in this trace.

Two ideas carry the whole flow:

The I-RNTI is a pointer; the shortResumeMAC-I is a signature. The UE's RRCResumeRequest (sent over the air to gNB-1, before this capture opens) carries both. The I-RNTI tells gNB-1 which node holds the context and which context it is; the shortResumeMAC-I is a token that the UE computes from its stored keys, so the anchor can prove the resume request is genuine before releasing anything.

Resuming forward-secures the keys. The context handed back includes a NextHopChainingCount (NCC) and a next-hop key (K_NG-RAN*). The target derives fresh AS keys for the resumed connection from these — vertical key derivation — which provides forward security: the new cell cannot read traffic that the UE exchanged before the resume.

The flow at a glance

The 5 frames fall into two phases. The interactive diagram shows every arrow.

1. Xn interface bring-up (frames 1–2) — Xn Setup Request / Response, non-UE-associated, so the nodes know each other's served cells.
2. Retrieve UE Context (frames 3–5) — Request, Response, and Confirm: gNB-1 fetches, authenticates, and takes over the UE's context.

But the capture is only the Xn leg of a larger procedure. RRC Resume begins over the air — the UE sends an RRCResumeRequest to the target gNB — and finishes over the air, when that gNB answers with RRCResume; the core-network path switch and the release of the context at the anchor still follow. This capture holds only the three Xn messages in the middle. Here is the whole flow, with the captured frames marked:

The procedure advances the UE's RRC state machine — from suspended, back to connected — with the Xn exchange doing the work under the hood:

Now the same story, frame by frame.

Phase 1 — Bringing up the Xn interface (frames 1–2)

Frame 1 — Xn Setup Request (non-UE-associated). gNB-1 opens the Xn association by advertising its served-cell configuration, so the peer knows what it is talking to before any UE signaling:

Frame 2 — Xn Setup Response. gNB-2 accepts and returns its own served-cell info. Because this is a loopback lab capture, its advertised gNB ID (1), NR-PCI (1), and PLMN (260402) mirror gNB-1's exactly — expected for a symmetric pairing on one host, not a real deployment where the two cells would be distinct. With this exchange, the Xn interface is up; everything from frame 3 on is UE-associated signaling over it.

Phase 2 — Retrieving the UE context (frames 3–5)

Frame 3 — Retrieve UE Context Request. A UE has sent an RRCResumeRequest to gNB-1 (the new / target node). Using the I-RNTI from that request, gNB-1 locates the anchor node — gNB-2, which still holds the suspended context — and asks for it. The key contents:

• UEContextID = rRCResume, carrying I-RNTI (short) = 0x000000 — the handle that identifies the stored context at the anchor.
• shortResumeMAC-I = 0x0001 — the authentication token the UE computed; gNB-2 recomputes and checks it to prove the resume request is genuine before releasing the context.
• Allocated C-RNTI = 0x0001 for the UE at the new cell.
• gNB-1 assigns the New NG-RAN node UE XnAP ID = 1 — remember this; it is echoed back in frame 4 and re-confirmed in frame 5.

Here is that request as its fully decoded packet — click any layer to drill in (xnap is open to the message; expand UEContextID → rRCResume for the I-RNTI, and the MAC-I IE for the shortResumeMAC-I discussed above):

Frame 4 — Retrieve UE Context Response. gNB-2 authenticates the request and returns the full UE context. It echoes the new node's UE XnAP ID (1) and allocates its own Old NG-RAN node UE XnAP ID = 2, so the two ends are now cross-referenced by a pair of identifiers.

The security context is the important payload here — carried inside the message rather than on the arrow: NCC = 2 plus the 32-byte K_NG-RAN* next-hop key. With these, the target derives fresh AS keys (K_gNB*) for the resumed connection — vertical key derivation, giving forward security so the new cell cannot read prior traffic.

Also handed over: UE-AMBR 256 Mbps (downlink and uplink) and one PDU-session resource to set up:

5QI 9 is a standardized non-GBR flow — the default best-effort bearer (e.g. TCP-based or buffered video traffic).

And the response as its full decoded packet — the key message of the capture. Expand securityInformation for the NCC and the key-NG-RAN-Star, and PDUSessionResourcesToBeSetup-Item for the PDU session and its QoS flow:

Frame 5 — Retrieve UE Context Confirm. gNB-1 closes the loop, quoting both identifiers — Old UE XnAP ID = 2 and New UE XnAP ID = 1. The context has been taken over; both XnAP IDs are bound to the UE-associated Xn connection, and the RRC Resume preparation on the Xn interface is complete. From here, gNB-1 sends the RRCResume to the UE over the air and, if needed, path-switches the PDU session toward the core.

Retrieve UE Context vs Handover Preparation

Retrieve UE Context has a close cousin on Xn — Handover Preparation. Both procedures move a UE's context between gNBs, but they answer different questions:

• Handover Preparation (HandoverRequest → HandoverRequestAcknowledge) is source-driven: the gNB currently serving a CONNECTED UE decides to move it and pushes the context to a target it chose, based on measurement reports.
• Retrieve UE Context (Request → Response → Confirm) is target-driven: a UE resuming from RRC_INACTIVE shows up at a new gNB, and that gNB pulls the context from the anchor, authenticated by the shortResumeMAC-I the UE supplied.

The tell is the trigger and the direction of the pull. A context that moves because a UE arrived and asked to resume — carrying an I-RNTI and a resume MAC — is Retrieve UE Context, whatever the file is named.

Takeaways

1. RRC_INACTIVE trades state for speed. Suspending a UE preserves its context and hands out an I-RNTI, so resuming is far cheaper than a fresh setup — even when the UE resumes in a different cell.
2. The Xn fetch resolves mobility. When the UE resumes at a new gNB, that gNB uses the I-RNTI to find the anchor and pulls the context over Xn with Retrieve UE Context.
3. The resume is authenticated before anything moves. The shortResumeMAC-I allows the anchor to verify that the request is genuine before releasing the UE's context.
4. Resuming forward-secures the keys. The NCC and K_NG-RAN* in the response drive vertical key derivation, so the new cell derives fresh AS keys and cannot read pre-resume traffic.

Try it on your own capture

Every arrow in this walkthrough was decoded and captioned by VisualEther from a raw Wireshark PCAP — no manual diagramming. Point it at your own 5G, LTE, or IMS trace and read it the same way.