NR-RRC in a Real 5G Capture

One layer of the 5G NR attach walkthrough, followed on its own: 29 messages over frames 2 to 137, covering two RRC connections — the first from its Setup Request through security, capabilities, the reconfiguration that builds the data bearer, and the release, then the mobile-terminated connection that returns after it.

💡 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.

Where RRC sits

That picture explains the whole shape of this page. RRC's peer is the gNB, so an RRC procedure is a radio negotiation, finished in a millisecond or two. But the box above it reaches all the way to the AMF, and it gets there by riding inside RRC messages. So roughly half of what you are about to read is RRC doing its own job, and the other half is RRC acting as a courier for a conversation it cannot read.

What RRC does

RRC — Radio Resource Control (TS 38.331) is the control protocol of the 5G radio link. Everything below it moves bytes; RRC is the layer that decides which bytes move, over what, and for whom. In one connection, it will:

• move the UE between RRC_IDLE, RRC_CONNECTED and RRC_INACTIVE;
• create, modify and destroy radio bearers — and configure the PDCP, RLC, MAC and PHY entities underneath each one;
• turn on Access-Stratum ciphering and integrity protection;
• collect the UE's capabilities so the network knows what it may configure;
• and carry NAS messages between the UE and the core, as opaque payload.

Two structural facts make RRC messages read the way they do. First, they are ASN.1, encoded with the Unaligned Packed Encoding Rules, which is why a message that configures four protocol layers fits in a couple of hundred bytes and why optional fields appear in a Wireshark tree as explicit presence bits. Second, RRC messages are nested: large configuration blocks are encoded separately and carried as OCTET STRINGs inside their parent, so you routinely see a decode go one level deeper than you expected.

Key fields that are worth learning before we walk through the flow:

One more piece of vocabulary, because it changes early in the walk. RRC messages travel on logical channels, and the channel is baked into the message's ASN.1 type:

• UL-CCCH-Message / DL-CCCH-Message — the Common Control Channel. No dedicated bearer, no security, no identity. It is what a UE uses before it has been admitted, and what the cell answers on.
• UL-DCCH-Message / DL-DCCH-Message — the Dedicated Control Channel, carried on a Signaling Radio Bearer. Everything after the setup handshake is DCCH.

Watch for that switch at frame 4. It is the moment the UE stops being anonymous.

The conversation we're following

💡 Where this diagram comes from. The diagram on this page is one session that VisualEther — the tool that decoded this capture and generated the diagrams here — lifted out of the full six-layer trace. VisualEther splits a capture into per-protocol sessions and names each one; this is the session it labels rrc-connection/timeout/00001, keyed on rrc-connection::0x8000, 29 messages over frames 2 to 137. Point VisualEther at the same PCAP, and this is the session it hands you.

0x8000 is the C-RNTI — the Cell Radio Network Temporary Identifier, the short handle a cell uses to address one connected UE — and the capture reuses it. So this single timeline carries two RRC connections: the long one that attaches, secures itself, opens a data bearer, and is released, and the shorter mobile-terminated one that follows — which, as the closing section explains, goes dark on this diagram rather than finishing.

Three reading notes before the walk:

• 29 messages is not 29 distinct RRC messages. Two frames — 4 and 133 — each render as three arrows, because the diagram surfaces the RRC envelope, its NAS container, and the decoded NAS message separately.
• Frames 128 and 129 are one RRC message sent twice. The gNB's RRC layer produced a single RRCRelease; RLC put it on the wire twice when its poll went unanswered.
• The capture has a third RRC connection, and it is not on this timeline. A third RRCSetupRequest arrives at frame 148, after a gap longer than the session extractor's 30-second idle timer, so it lands in a session of its own. The capture ends before it gets past its Setup Complete.

The flow at a glance

Before the frame-by-frame walk, here is the whole RRC conversation on a single timeline — both connections that share C-RNTI 0x8000, in the order the capture shows them. Connection 1 attaches, secures itself, builds the data bearer, and is released; connection 2 is paged back with mt-Access and goes dark after its own security bring-up. Every frame number matches a step in the walk below.

The walk

Frame 2 — the UE names itself before it has a name. A UL-CCCH-Message, 99 bytes on the wire, and the entire RRC content is three fields. There is no rrc-TransactionIdentifier: a transaction identifier pairs a response with a command, and nothing has been commanded yet.

ue-Identity is a CHOICE, and this connection takes the randomValue branch — 39 bits, b34056b184. establishmentCause is mo-Signalling: mobile-originated signaling, the UE wanting to talk to the core rather than move bulk data. And spare, one zero bit, pads the message to the fixed size the Common Control Channel grant allows.

Remember the identity branch. Frame 131 takes the other one.

Frame 3 — what an RRC Setup actually installs

0.708 ms later, the gNB answers on DL-CCCH-Message with rrc-TransactionIdentifier: 0. The message has exactly two payload IEs, and their sizes are wildly lopsided.

radioBearerConfig is the small one: a one-item srb-ToAddModList naming srb-Identity: 1, and nothing else. In particular, there is no pdcp-Config, so SRB 1 takes the specification's default PDCP profile rather than anything signaled here.

masterCellGroup is the big one: a separately encoded OCTET STRING of 209 octets. Everything the lower layers need is inside it, and unpacked, it is a CellGroupConfig with cellGroupId: 0 and four sections:

• rlc-BearerToAddModList — one RLC-BearerConfig: logicalChannelIdentity: 1, servedRadioBearer: srb-Identity 1, and a mac-LogicalChannelConfig setting priority: 1, prioritisedBitRate: infinity, bucketSizeDuration: ms50, logicalChannelGroup: 0. Note what is absent: there is no rlc-Config. SRB 1's RLC entity is never configured anywhere in this capture — which is exactly the fact the RLC companion uses to identify the timer it measures.
• mac-CellGroupConfig — sr-TransMax: n16, periodicBSR-Timer: sf1, retxBSR-Timer: sf80, one timing-advance group (tag-Id: 0, timeAlignmentTimer: infinity), and power-headroom reporting (phr-PeriodicTimer: sf10, phr-ProhibitTimer: sf0, phr-Tx-PowerFactorChange: dB1). Every Buffer Status Report and Timing Advance the MAC companion walks was authorized right here.
• physicalCellGroupConfig — p-NR-FR1: 23 dBm, and pdsch-HARQ-ACK-Codebook: dynamic.
• spCellConfig — the radio-link-failure watchdogs (t310: ms1000, n310: n1, n311: n1, t311: ms1000), plus the CORESET and search space the UE must monitor to find its own downlink grants at all.

That last group is worth pausing on, because it is pure RRC — no layer below ever sees these values. t310 is the timer that starts when the physical layer reports out-of-sync and stops if it recovers; n310 and n311 are how many consecutive bad or good indications it takes to start and stop it; t311 bounds the re-establishment attempt afterward. They are the entire definition of "this link has failed", and they are set before a single byte of user data has moved.

On receipt of this message, the UE enters RRC_CONNECTED.

Expand the tree below to watch that install unwrap. Because an RRC Setup travels on the Common Control Channel, there is no pdcp-nr or rlc-nr layer between mac-nr and nr-rrc — set that against frame 38, where there is. With mac-nr opened a level, the RRC Setup sits directly inside it, and the 209-octet masterCellGroup opens into the nested CellGroupConfig:

Frame 3's full field tree — the RRC Setup that installs SRB 1, with the mac-nr node opened one level. Follow mac-nr -> nr-rrc -> DL-CCCH-Message -> rrcSetup. From there, -> radioBearerConfig holds the one-item SRB 1 bearer, and -> masterCellGroup -> CellGroupConfig holds the nested RLC, MAC and PHY configuration.

Frame 4 — the channel changes. 28.259 ms after Msg4, and this is now a UL-DCCH-Message on SRB 1. Two RRC-owned IEs do routing work: selectedPLMN-Identity: 1 says which broadcast PLMN the UE picked, and registeredAMF names the core node it was last registered with — amf-Identifier: fe0041, guami-Type: native — so the gNB can hand the payload to the right AMF rather than guessing. Frame 133 will solve the same problem a completely different way.

The payload itself is a dedicatedNAS-Message of 92 octets, and to RRC that is all it is: a length and some bytes. Opened, it is a Registration Request with Security header type: Integrity protected (1), message authentication code 0x97a0a3f4, NAS sequence number 6, 5GS registration type: initial registration (1), and a 5G-GUTI carrying 5G-TMSI: 0xc2345678. Keep that TMSI in mind; it comes back on the other side of a release.

Frames 7 to 15 — RRC as a courier. Six messages, and RRC's contribution to all of them is delivery. DLInformationTransfer and ULInformationTransfer exist for exactly one purpose: to move a NAS payload across the air on an existing bearer.

Two RRC-level observations hide in that table.

The first is a field that is missing. Every DLInformationTransfer here carries rrc-TransactionIdentifier: 0; not one ULInformationTransfer carries the field at all. That is not the capture being lossy — TS 38.331 does not define it for the uplink message. Transaction identifiers belong to network-initiated procedures, and a UE pushing a NAS message upward is not answering an RRC command. All five uplink transfers in this session — frames 9, 12, 15, 31 and 36 — are missing it for the same reason.

The second is what happens at frame 12, when the security header type reaches 4, and the container's tail becomes Encrypted data. Nothing changed at the RRC layer. The core's own security context came up inside a payload RRC never inspects, and from here most NAS bodies in the capture are sealed. The radio layers are still completely in the clear. That split is the subject of the decryption companion; here it is enough to notice that RRC neither caused it nor noticed it.

Frames 17 and 18 — the one security procedure that belongs to RRC. The SecurityModeCommand is 81 bytes on the wire, and its whole payload beyond rrc-TransactionIdentifier: 0 is a securityConfigSMC holding cipheringAlgorithm: nea2 (2) and integrityProtAlgorithm: nia2 (2) — AES in counter mode for confidentiality, AES-CMAC for integrity.

Two absences matter as much as those two values. There is no key in this message, and there never is: both ends derive the Access-Stratum keys locally from a hierarchy that never crosses the air, which is precisely why the Wireshark issue had to publish the UE keys before this capture could be read at all. And there is no nas-Container, so this is a plain security activation rather than the key change that accompanies a handover.

Note the scope, too. This one message secures every radio bearer of the connection — including DRB 1, which does not exist yet and will not until frame 38.

The SecurityModeComplete comes back 10.220 ms later, and its entire content is rrc-TransactionIdentifier: 0. No IEs. Not even an echo of the algorithms it just accepted. The message body is empty because the confirmation is not in the body: it is in the integrity tag PDCP wraps around it. A wrong key gives a digest that will not verify, and the gNB learns everything it needs from that. An empty RRC message whose only real payload is proof of a shared secret.

For where ciphering actually begins — which is not quite where most people guess — see the PDCP companion; for the key hierarchy they descend from — K_gNB fanning out into four keys, of which the issue publishes two — the decryption companion.

Frame 20 — and it is a narrower question than it looks. The UECapabilityEnquiry asks for rat-Type: nr, and then does something worth copying: it attaches a capabilityRequestFilter, four octets, 80040040, which decodes to a frequencyBandListFilter with exactly one entry — bandNR: 5.

The gNB is not asking "what can you do?". It is asking "what can you do on NR band n5?". Ask an unfiltered question of a modern UE and the answer runs to many kilobytes. Even filtered, the answer here is the largest RRC message in the capture.

Frame 23 — the answer, and the reason the lower layers had to work. rrc-TransactionIdentifier: 0 matches the enquiry, and a single UE-CapabilityRAT-Container of 1656 octets holds everything else. Inside: accessStratumRelease: rel16, then per-layer blocks that read like a table of contents for this whole article series — pdcp-Parameters (ROHC profiles 0x0000, 0x0001 and 0x0002 supported, maxNumberROHC-ContextSessions: cs24, shortSN: supported), rlc-Parameters (am-WithShortSN, um-WithShortSN and um-WithLongSN all supported), mac-Parameters (longDRX-Cycle and shortDRX-Cycle supported), then the physical-layer parameters, the feature-set machinery, and — for a capture named after Minimization of Drive Tests — loggedMeasurements-r16: supported (0).

The frame itself is 691 bytes on the wire. A 1656-octet container did not fit in one transmission, so RLC cut it into pieces and reassembled it — and RRC never saw the split. It was handed one complete message. The RLC companion walks the same event from below, as a three-segment run.

Frames 30, 31 and 36 — back to couriering. Containers of 53, 10 and 92 octets, all now Security header type: Integrity protected and ciphered (2). Type 2 rather than type 4: the "new security context" marker is gone, so the NAS context established back at frames 11–15 is simply in use. Frame 36's container is 92 octets — the same size as the Registration Request the connection opened with — and the network's answer, two frames later, is the one RRC message on this timeline that builds a data bearer.

Frame 38 — the richest message in the capture

One RRCReconfiguration, rrc-TransactionIdentifier: 0, 235 bytes on the wire, and in those 235 bytes it configures four protocol layers, adds two bearers, and carries a sealed NAS message. Five sibling pages in this series point back at this frame; it lives here.

The bearers. radioBearerConfig carries an srb-ToAddModList naming srb-Identity: 2 — a second signaling bearer, again with no pdcp-Config, so defaults — and a drb-ToAddModList naming drb-Identity: 1, the capture's only data bearer.

What DRB 1 gets. Its cnAssociation is an sdap-Config: pdu-Session: 1, sdap-HeaderDL: absent (1), sdap-HeaderUL: present (0), defaultDRB: True, and a one-item mappedQoS-FlowsToAdd naming QFI: 2. Those two enumerated values are the entire reason every SDAP PDU in this capture is an uplink one — the SDAP companion is a page about a header that is absent, and this is where it was switched off. Its pdcp-Config sets discardTimer: infinity, pdcp-SN-SizeUL: len18bits, pdcp-SN-SizeDL: len18bits, headerCompression: notUsed, and statusReportRequired: true — and, worth noticing, carries no integrityProtection, so user-plane data on this bearer is ciphered but not integrity-protected.

The security restatement. securityConfig repeats cipheringAlgorithm: nea2 and integrityProtAlgorithm: nia2 and adds keyToUse: master. There is no masterKeyUpdate, so nothing is re-keyed: the new bearers are being told which existing key set they inherit.

The 18-octet masterCellGroup. Set that against frame 3's 209 octets and the encoding tells you something about the protocol: a cell-group configuration is a delta, not a replacement. mac-CellGroupConfig, physicalCellGroupConfig and spCellConfig are all absent here, so everything frame 3 established stays exactly as it was. What these 18 octets add is a two-item rlc-BearerToAddModList:

DRB 1's rlc-Config is the only RLC configuration signaled anywhere in this capture: ul-AM-RLC with sn-FieldLength: size18, t-PollRetransmit: ms80, pollPDU: p32768, pollByte: kB750, maxRetxThreshold: t8; dl-AM-RLC with sn-FieldLength: size18, t-Reassembly: ms80, t-StatusProhibit: ms30.

And a NAS message that stays shut. dedicatedNAS-MessageList holds one item of 122 octets — Security header type: Integrity protected and ciphered (2), message authentication code 0x9b072356, NAS sequence number 3, then Encrypted data. One frame in which the RRC decodes completely and the payload inside it does not. That is the capture's two-security-layer story compressed into a single packet, and it is the frame Wireshark work-item 19757 was filed about.

Expand the tree below and the nesting becomes concrete — nr-rrc inside pdcp-nr inside rlc-nr inside mac-nr, and then two more levels of nr-rrc inside itself where masterCellGroup and the NAS container unwrap:

Frame 38's full field tree — the RRC Reconfiguration that builds DRB 1, with the mac-nr node opened one level. Follow mac-nr -> rlc-nr -> pdcp-nr -> nr-rrc -> DL-DCCH-Message -> rrcReconfiguration. From there, -> radioBearerConfig has the SDAP and PDCP settings, and -> nonCriticalExtension holds both -> masterCellGroup (the nested CellGroupConfig that configures RLC and MAC) and -> dedicatedNAS-MessageList (which decodes only as far as its security header).

One last thing worth noting for what is not in frame 38: there is no measConfig and no secondaryCellGroup. No measurement reporting is ever configured in this trace, even though the UE advertised R16 logged-measurement support back at frame 23.

Frame 39 — Reconfiguration Complete, 18.216 ms later. Content: rrc-TransactionIdentifier: 0. Nothing else, for the same reason frame 18 was empty. DRB 1 is live.

And then RRC stops. Frames 40 to 127 contain no RRC message at all. The connection is at its busiest through that whole stretch — user data on DRB 1, RLC status reports, MAC grants, Buffer Status Reports — and the layer that built the road has nothing further to say. This is the normal steady state of a working RRC connection: silence.

Frame 128 — RRC Release, and it is as plain as an RRC Release gets. 79 bytes on the wire, rrc-TransactionIdentifier: 0, and every optional IE explicitly absent: no redirectedCarrierInfo, no cellReselectionPriorities, no deprioritisationReq, and — the one that decides the outcome — no suspendConfig.

That absence is the state transition. With a suspendConfig, the UE would move to RRC_INACTIVE, keeping its context for a cheap resume later. Without one, it goes to RRC_IDLE, and the whole Access-Stratum context is torn down: keys, both SRBs, DRB 1, every entity frames 3, 17 and 38 configured. When the UE comes back at frame 131, it comes back to nothing.

Frame 129 — the same release again, and RRC only sent it once. Identical content, 44.894 ms later. This is not a second RRCRelease; RLC retransmitted the PDU because its poll went unanswered. The RLC companion explains what that 44.894 ms actually measures.

The later connections

Frame 131 — a second connection on the same C-RNTI. 0x8000 is reused, which is why this shares a timeline with everything above, but the RRC connection is genuinely new: no keys, no bearers, nothing inherited. Same message type as frame 2, same 99 bytes on the wire — and both values inside it are different in kind. establishmentCause is mt-Access: the network reaching for the UE rather than the other way round. And ue-Identity takes the other branch of the CHOICE, ng-5G-S-TMSI-Part1, 838468acf0. That difference gets its own section below.

Frame 132 — the same RRC Setup, byte for byte. 0.711 ms after Msg3, against 0.708 ms on the first connection. Its masterCellGroup is 209 octets again, and it is identical to frame 3's: same SRB 1 bearer config, same BSR and PHR timers, same p-NR-FR1: 23 dBm, same t310 and t311 of ms1000. A fresh connection to the same cell gets the same starting configuration; nothing the first connection learned carries into the setup message.

Frame 133 — the second half of an identity. 28.257 ms after Msg4, against 28.259 ms the first time. selectedPLMN-Identity: 1, a 40-octet NAS container holding a Service Request with Service type: Mobile terminated services (2) and mobile identity 5G-S-TMSI carrying 5G-TMSI: 0xc2345678 — the same TMSI frame 4's 5G-GUTI held. And one field frame 4 did not have: ng-5G-S-TMSI-Value: ng-5G-S-TMSI-Part2, nine bits, 0000.

Two fields frame 4 did have are gone: no registeredAMF, no guami-Type. They are not needed, and the next section explains why.

Frames 136 and 137 — AS security, from scratch. cipheringAlgorithm: nea2, integrityProtAlgorithm: nia2 — the same algorithms frame 17 chose, but a genuinely new activation with a newly derived K_gNB, because frame 128 destroyed the previous context. The SecurityModeComplete returns 13.228 ms later, empty apart from rrc-TransactionIdentifier: 0, exactly as at frame 18. Every RRC connection secures itself independently; there is no inheriting radio keys across an idle period.

And then the diagram stops — but the conversation does not, and the distinction matters.

The session ends at frame 137 because the extractor's 30-second idle timer closed it there. The readable RRC ends there too, and for a different reason. Frames 139, 140, 142, 145 and 146 are all LCID 1 PDCP data PDUs on 0x8000 — five more RRC messages on this same connection — and every one of them is opaque. Frame 136 activated security with a freshly derived K_gNB, and the keys the Wireshark issue publishes cover the first connection only, so from frame 139 onward the dissector can report a Signalling Data blob and a length and nothing else.

That is not a gap in the trace; it is the same rule this page has been describing, seen from the other side. The PDCP companion builds its security-boundary argument on exactly these five frames: on a connection nobody holds a key for, the last two messages that stay readable are the two that bracket security activation — frames 136 and 137 — and the very next PDU goes dark.

Two things can still be read off the envelope of that dark stretch. There is no data bearer on it: every logical channel on it is LCID 1, so DRB 1 was never rebuilt on connection 2. And frames 145 and 146 carry byte-identical payloads with the RLC poll bit set, both at PDCP SN 3 — precisely the shape of frames 128 and 129. That is the signature of an RRCRelease and its poll-retransmit. On this connection, though, it is an inference from the envelope rather than a decode.

So the honest comparison with connection 1 is not "nothing follows" — it is that the capture stops being able to show you what follows. The capture's third connection then opens at frame 148 with establishmentCause: mt-Access again, and gets no further than its own Setup Complete before the file runs out.

The identity that arrives in two pieces

Put the two Setup Requests side by side. Same message type, same channel, same 99 bytes on the wire, same 39-bit identity field, and the same zero spare bit — and yet:

The mechanism behind the second column is one of the neater pieces of engineering in TS 38.331, and this capture shows all of it.

A 5G-S-TMSI is 48 bits — an AMF Set ID, an AMF Pointer, and a 32-bit 5G-TMSI (TS 23.003). Msg3 is sent on the Common Control Channel, before any dedicated bearer exists, in a grant whose size is fixed by system information. There is no room for 48 bits of identity, so InitialUE-Identity gives ue-Identity only 39. RRC's answer is to split the identity across two messages: ng-5G-S-TMSI-Part1 carries 39 bits in Msg3, and ng-5G-S-TMSI-Part2 carries the remaining nine in the RRCSetupComplete — the first message with a dedicated bearer beneath it and room to spare.

Both halves are on this timeline, and the second one arrives with a bonus. A 5G-S-TMSI carries the AMF Set ID and the AMF Pointer, so once the gNB holds the whole thing it already knows a good deal about where the UE's NAS context lives — which is the engineering reason registeredAMF is an optional field rather than a mandatory one. Frame 133 leaves it out; frame 4, whose Msg3 named the UE with a random number that says nothing about any AMF, includes it along with guami-Type.

Be careful with the direction of that arrow, though. TS 38.331 conditions registeredAMF on the upper layers supplying a registered AMF — the same NAS-driven conditional that governs ue-Identity. So the honest reading is not that the TMSI caused the omission, but that one NAS decision plausibly drove both.

Which leaves the obvious question: the UE clearly had a 5G-S-TMSI at frame 2 — the very same 0xc2345678 appears in frame 4's 5G-GUTI. Why draw a random number?

Because the choice is not RRC's to make. TS 38.331 §5.3.3.3 says the UE uses ng-5G-S-TMSI-Part1 when the upper layers provide a 5G-S-TMSI for this connection establishment, and a freshly drawn 39-bit random value otherwise. Frame 4's NAS body says the first connection was opened for an initial registration; frame 133's says the second was opened for a mobile-terminated Service request. The wire shows NAS handing an identity down on the second and not on the first, and the spec says that decision belongs to NAS. Same UE, same TMSI in memory, two different identification strategies — chosen one layer above the one you are watching.

There is a diagnostic habit in this. When you open a 5G radio trace at the very first uplink message, before anything is decipherable and before any bearer exists, the ue-Identity branch and the establishmentCause are already there, in the clear, in the first handful of bytes. randomValue plus mo-Signalling says a UE is starting a registration and the network does not yet know who it is. ng-5G-S-TMSI-Part1 plus mt-Access says a known subscriber is being paged back. You know the shape of the next thirty frames before you have read one of them.

Takeaways

1. RRC spends much of its time as a courier. Both InformationTransfer message types exist for nothing but ferrying a dedicatedNAS-Message across the air, and both RRCSetupCompletes and frame 38 carry one too. To RRC, each one is a length and some bytes — which is why the NAS bodies going dark at frame 12 changed nothing at the RRC layer.
2. Absent fields carry as much meaning as present ones. No suspendConfig at frame 128 is the difference between RRC_IDLE and RRC_INACTIVE. No rlc-Config at frame 3 is what makes SRB 1 run a spec default. No integrityProtection at frame 38 is why user data is ciphered but unauthenticated. In an ASN.1 protocol, read the presence bits.
3. Configuration is a delta, not a snapshot. Frame 3's masterCellGroup is 209 octets; frame 38's is 18, and everything it does not mention stays as it was. Never reconstruct a UE's configuration from the last reconfiguration alone.
4. One frame can configure four layers at once. Frame 38's 235 bytes set SDAP's header switches, PDCP's sequence-number size, RLC's timers and MAC's logical-channel priorities in a single message — and then hand over a sealed NAS payload for good measure.
5. Every RRC connection secures itself from scratch. The release at frame 128 destroyed the Access-Stratum context, so frame 136 ran the whole Security Mode procedure again — same algorithms, new K_gNB. Radio keys do not survive a release to RRC_IDLE.
6. The first uplink message already tells you what kind of connection this is. establishmentCause says who started it, and the ue-Identity branch says whether the core handed down a subscriber identity to start it with — both in the clear, both before security exists.

Where this sits in the stack

This page follows one layer of a much larger trace. The layers around it tell different parts of the same story:

• A 5G NR Attach on the Air Interface, Layer by Layer — the full walkthrough this article is a slice of: random access through to two mobile-terminated returns, all six layers on one timeline.
• PDCP-NR: sequence numbers, COUNT, and where ciphering happens — the layer directly below. Every RRC message on this page was one PDCP SDU, and PDCP is where the algorithms frame 17 selected are actually applied.
• RLC-NR Acknowledged Mode — two layers down, and the reason frames 21–23 exist at all. It is also where frame 38's rlc-Config block is spent, and where the frame 128/129 duplicate is explained.
• MAC-NR: contention resolution, LCID multiplexing, and buffer status — the scheduler's view. Frame 3's mac-CellGroupConfig is the rule book every Buffer Status Report on that page follows.
• SDAP: QoS flows, the QFI, and the data radio bearer — the user-plane layer frame 38's sdap-Config brings into existence, including the downlink header it switches off.
• Decrypting a 5G NR radio capture — the key hierarchy behind nea2 and nia2, why the NAS bodies stay sealed while the radio layers open up, and the recipe that made this trace readable.

Try it on your own capture

Every arrow in this diagram was decoded and captioned by VisualEther from a raw Wireshark PCAP — including the session split that lifted one protocol's conversation off a six-layer timeline. Point it at your own 5G, LTE, or IMS trace and read it the same way.