LTE-RRC in a Real VoLTE Capture: One Connection, Fourteen Reconfigurations

The RRC layer of the LTE attach and VoLTE walkthrough, followed on its own. One phone, UE 70, opens one RRC connection in the capture's first 10 ms and still holds it 113 s later. In between come 57 RRC messages: setup, security, capabilities, two reconfigurations that build the data bearers, and twelve more that add and remove a voice bearer for each of six calls.

💡 Read the walkthrough and the diagram side by side: open the interactive diagram in a split-screen window, or open it in a new tab and snap the two windows side by side.

Where RRC sits

That picture explains the page. RRC's peer is the eNB, so an RRC procedure is a negotiation over one radio link, usually answered in 20 to 45 ms. But the NAS box above it reaches the MME, and NAS gets there inside RRC messages. Part of what follows is RRC doing its own job; the rest is RRC carrying messages it doesn't read.

What RRC does

RRC (Radio Resource Control, TS 36.331) is the control protocol of the LTE radio link. The layers below it move bytes. RRC decides which bearers exist and how each lower layer handles them. In this one connection it:

• moves UE 70 from RRC_IDLE to RRC_CONNECTED;
• turns on radio (Access Stratum, AS) integrity protection and ciphering;
• asks the UE what it can do;
• creates and removes radio bearers, configuring PDCP, RLC, and MAC for each;
• carries NAS messages between the UE and the MME without reading them.

RRC messages are ASN.1, packed with the Unaligned Packed Encoding Rules (PER). A field the sender leaves out costs one presence bit, so messages stay small: frame 846 configures PDCP, RLC, and MAC for a new bearer and carries a NAS message, all in 98 bytes.

A few fields carry most of the story:

RRC messages travel on logical channels, and the message's ASN.1 type names the channel. UL-CCCH-Message and DL-CCCH-Message use the Common Control Channel, which needs no dedicated bearer and has no security. Everything after the first two messages is UL-DCCH-Message or DL-DCCH-Message, on a Signaling Radio Bearer (SRB):

The connection we're following

💡 Where this diagram comes from. VisualEther, which decoded this capture and drew the diagrams here, splits a capture into one session per protocol entity. This diagram is the session it keys rrc-connection::70: every RRC message to or from C-RNTI 70, 57 messages over frames 2 to 3288.

C-RNTI 70 is the Cell Radio Network Temporary Identifier, the short number the cell uses to address one connected UE. UE 70 is an iPhone; UE 71, the phone it calls, has an RRC connection of its own that this page doesn't follow.

Three reading notes:

• 57 arrows, 46 frames. Eleven frames carry two RRC messages each: a Reconfiguration Complete on SRB1 and a UL Information Transfer on SRB2, packed into one uplink MAC PDU.
• Frame 22 stands for three. The UE Capability Information was cut into three RLC segments, frames 20 to 22. The diagram draws it once, at the frame that completes it.
• Long silences are normal. Between frames 34 and 846, UE 70 registers with IMS, and nothing changes on the radio, so RRC sends nothing for 23 s.

All times below are seconds from the capture's first frame.

The flow at a glance

The first 0.7 s build everything the phone needs. After that, RRC only adds and removes the voice bearer.

Every reconfiguration on this connection, all 14 of them:

Read down the LCID column: it never goes back. That climb is the subject of the last section.

Setup: frames 2 to 4

Frame 2 — the UE names itself with a random number. RRC Connection Request is Msg3 of random access, sent on UL-CCCH (LCID 0). RLC runs in transparent mode here, and there is no PDCP, so the RRC bytes sit directly in the MAC PDU. The message holds three fields. ue-Identity takes the randomValue branch, 40 random bits (9a1ba5de5a). TS 36.331 §5.3.3.3 has the UE send its S-TMSI instead only when NAS provides one. establishmentCause is mo-Signalling: the UE wants to talk to the core network. There is no rrc-TransactionIdentifier, because no command has been sent yet.

Frame 3 — RRC Connection Setup, 2 ms later. It goes down on DL-CCCH in the same MAC PDU as a Contention Resolution control element, which echoes Msg3's 6-byte message so the UE knows the cell answered it and not another UE that picked the same preamble. The RRC part has rrc-TransactionIdentifier 0 and one radioResourceConfigDedicated:

• srb-ToAddModList adds SRB1. Its rlc-Config and logicalChannelConfig are both defaultValue: the settings are written into TS 36.331 §9.2.1.1 rather than sent. SRB1 runs RLC AM with logical channel priority 1, the highest.
• mac-MainConfig sets maxHARQ-Tx to 4, a periodic buffer status report every 20 subframes, and timeAlignmentTimerDedicated to infinity. With that timer at infinity, the UE never loses uplink timing because of a quiet spell, so it never has to redo random access to send again.
• physicalConfigDedicated sets up the uplink control channel, CQI reporting, and a scheduling request opportunity every 20 ms.

On receipt the UE enters RRC_CONNECTED.

Frame 4 — Setup Complete, the first message on SRB1. 44 ms later the UE answers on UL-DCCH, LCID 1, RLC sequence number 0, PDCP sequence number 0. From here every RRC message rides a Signaling Radio Bearer. selectedPLMN-Identity: 1 picks the first network in the cell's SIB1 list. dedicatedInfoNAS carries the NAS Attach Request (a combined EPS/IMSI attach that identifies the phone by a GUTI from an earlier registration) with a PDN Connectivity Request inside it. RRC treats all of it as a length and some bytes. The PDCP MAC-I field is four zero bytes: PDCP reserves room for an integrity tag on every SRB message and fills it with zeros until AS security starts (TS 36.323 §6.3.4).

NAS rides through: frames 6 to 14

DLInformationTransfer and ULInformationTransfer (TS 36.331 §5.6.1 and §5.6.2) have one payload field, dedicatedInfoNAS. They ride SRB1 here only because SRB2 doesn't exist yet. Once it does, they move to it.

The MME answers the GUTI with an Identity Request for the IMSI (frame 6), so it couldn't use the GUTI. The UE sends IMSI 001011234567895 back within 38 ms. Authentication follows (frames 9 and 11): the UE's answer takes 214 ms, while the SIM computes the response, and RRC is idle the whole time. Frames 13 and 14 are the NAS Security Mode procedure, which selects EEA0 (null ciphering) and EIA2 integrity for NAS. That secures the link between the UE and the MME, not the radio. The radio needs its own procedure.

The NAS details of this exchange belong to the NAS layer. On this layer, the point is that RRC carries them without looking.

AS security: frames 16 and 17

Between frames 14 and 16 the MME sends the eNB Initial Context Setup over S1AP, 0.7 ms before frame 16 goes out. It carries K_eNB, the key the radio security is derived from (the S1AP companion shows the message). The eNB can now secure the radio link.

Frame 16 — Security Mode Command. securityAlgorithmConfig selects cipheringAlgorithm: eea0 and integrityProtAlgorithm: eia2. No key appears: both sides derive the RRC and user-plane keys from K_eNB themselves. TS 36.331 §5.3.4 has the eNB integrity-protect the command itself, and it does: frame 16's PDCP MAC-I is 0x4efe0942, the first non-zero MAC-I on SRB1. Wireshark marks the digest "wrong" only because it has no keys to compute the expected value.

Frame 17 — Security Mode Complete. The message holds nothing but its transaction identifier. The proof is one layer down: the UE can only produce a valid MAC-I (0xc1047431) if it derived the same keys. Every SRB1 and SRB2 message from here on carries a non-zero MAC-I.

The null cipher reaches the radio too. eea0 means "ciphering on, with an algorithm that leaves the data unchanged", which is why every later RRC message, and the NAS inside it, still decodes without keys. The main walkthrough explains why every layer in this capture uses a null cipher.

Capabilities: frames 19 and 22

Frame 19 — UE Capability Enquiry, 1.85 ms after the Security Mode Complete, with ue-CapabilityRequest: eutra. The eNB asks after security starts, so the answer is integrity-protected.

Frame 22 — UE Capability Information. accessStratumRelease: rel12, UE category 4. The message is too big for one uplink grant, so RLC sends it in three segments, frames 20 to 22. The eNB forwards it to the MME in S1AP UE Capability Info Indication, so the next eNB doesn't need to ask. The release matters later: features added to RRC after Release 12 are features this phone doesn't claim.

The attach reconfiguration: frames 24 to 29

Frame 24 — reconfiguration 1, 4 ms after the capabilities. An RRCConnectionReconfiguration doesn't restate the whole configuration: it lists only what changes. This one changes a lot:

• SRB2. Added with defaultValue settings again (TS 36.331 §9.2.1.2): RLC AM, logical channel priority 3, below SRB1.
• DRB 1. For EPS bearer 5, on LCID 3, in RLC AM, with PDCP discardTimer 150 ms, logical channel priority 11, and logical channel group 3. The RLC settings are in the RLC companion.
• measConfig. One measurement object, the E-UTRA carrier at EARFCN 3150, and a quantity configuration, but no report configuration and no measurement ID. TS 36.331 §5.5 links an object to a report through a measurement ID, so with none configured, the UE never sends a Measurement Report, and none appears in the capture.
• dedicatedInfoNASList. The NAS Attach Accept and Activate Default EPS Bearer Context Request for APN internet, QCI 9.

The NAS and the bearer travel together on purpose. TS 36.331 §5.3.5.3 has the UE apply the radio configuration and then pass the NAS messages up, so when NAS hears about EPS bearer 5, DRB 1 already exists to carry it.

Frame 27 — two messages, two bearers, one MAC PDU. 26 ms later the UE sends RRCConnectionReconfigurationComplete on SRB1 and, in the same transport block, the first message on the new SRB2: a ULInformationTransfer with NAS Attach Complete and Activate Default EPS Bearer Context Accept. UE 70 is attached 466 ms after its first RRC message.

The Complete echoes rrc-TransactionIdentifier 0, and so does every other response on this connection. The field allows 0 to 3, to tell apart procedures in progress at the same time. The eNB runs one procedure at a time here, so 0 is all it ever needs.

Frame 29 — the one DL Information Transfer on SRB2. NAS EMM Information, the network's name and time zone, 174 ms after the attach completes. It is the only downlink NAS message on this connection that travels in a DLInformationTransfer after SRB2 exists. Every later downlink NAS message comes with a radio bearer change, so it rides inside a reconfiguration on SRB1 instead.

The IMS bearer: frames 30 to 34

VoLTE needs a second packet data network (PDN) for IMS. At frame 30, 0.66 s into the capture, the UE asks for APN ims in a NAS PDN Connectivity Request, on SRB2.

Frame 32 — reconfiguration 2 adds DRB 2 for EPS bearer 6, APN ims, QCI 5, on LCID 4. This message has no SRB2, no measConfig, and no MAC or physical-layer fields: only the new DRB and its NAS. DRB 2 runs RLC AM too, but tuned for signaling: t-PollRetransmit 80 ms, pollPDU 128, pollByte 125 kB, maxRetxThreshold 4, t-StatusProhibit 60 ms, PDCP discardTimer infinity, logical channel group 2.

Frame 34 completes it, 32 ms later, with the NAS accept on SRB2 in the same MAC PDU. UE 70 now holds SRB1, SRB2, DRB 1, and DRB 2. The SIP companion picks up from here: the phone registers with IMS over DRB 2, and RRC stays silent for 23 s.

Six calls, six new DRBs: frames 846 to 3288

From here the connection repeats one pattern twelve times. When a call starts, the IMS core asks for a voice bearer, and the eNB adds a DRB. When it ends, the eNB removes it.

Frame 846 — the voice bearer. UE 70 dialed call 1 in frame 821. Reconfiguration 3 adds DRB 3 for EPS bearer 7 on LCID 5, and every setting says voice:

The NAS inside is an Activate Dedicated EPS Bearer Context Request: QCI 1, an 80 kbit/s guaranteed bit rate each way, linked to EPS bearer 6, the IMS PDN. The UE confirms 33 ms later in frame 847. The RLC companion follows the voice packets on this bearer.

Frame 1146 — the release. UE 71 hangs up. Reconfiguration 4 carries drb-ToReleaseList with one entry, DRB 3, and the NAS Deactivate EPS Bearer Context Request for bearer 7 with ESM cause 36, "regular deactivation". Releasing a DRB removes its PDCP entity, its RLC entity, and its logical channel in one step (TS 36.331 §5.3.10.2). Nothing on DRB 3 needs a goodbye: its UM entity keeps no state the peer must confirm. 40 ms later, UE 70's next comfort-noise packet goes up on DRB 2 instead.

Calls 2 to 6 repeat the same two reconfigurations. The bearer settings in the six add messages are identical apart from three numbers: the DRB identity, the LCID, and the EPS bearer identity. All six releases carry ESM cause 36. The Reconfiguration Complete arrives 19 to 38 ms after each command. In three releases (frames 1148, 2319, and 2928) it goes up alone, and the NAS accept follows 9 to 20 ms later; everywhere else the two share one MAC PDU.

Why the DRB number keeps climbing

UE 70 never has more than three data bearers at once: DRB 1, DRB 2, and one voice bearer. Yet the voice bearer comes back with a new DRB identity and a new LCID every call. LCID 5 has been free since frame 1146, and it is never used again. Every DRB in the capture fits one rule: DRB = EPS bearer − 4, and LCID = DRB + 2. The MME hands out a fresh EPS bearer identity for each call, 7 up to 12, and srsRAN's numbers follow it.

TS 36.331 limits the numbers differently:

LCIDs 0, 1, and 2 belong to CCCH, SRB1, and SRB2, which leaves eight values for data bearers. A UE can hold eleven DRBs but give at most eight of them a logical channel from this range. Release 15 added a second field, logicalChannelIdentity-r15, with values 32 to 38, for UEs that report support for more DRBs (extendedNumberOfDRBs-r15). UE 70 reports Release 12 in frame 22, so it couldn't use them. Even if it could, they don't include 11.

Call 6 uses LCID 10, the last value in the range. The capture then shows what a seventh call would need. It ends at 113.3 s, just as UE 71 dials again (the INVITE is frame 3365). In the eNB's S1AP log, the MME asks for EPS bearer 13 for UE 70 3 ms after the radio log stops. By the capture's rule, that bearer would get DRB 9 on LCID 11, a value the reconfiguration can't encode.

The capture stops there and can't show what happened next. The srsRAN_4G issue the capture was attached to can. It is titled "eNB crahes for VoLTE call when E-RAB ID > 12", and the reporter writes that the eNB crashes "the moment i attempt 7th call". A later log in the same issue shows the eNB failing to encode a DL-DCCH message. The fix, commit "rrc_bearer_cfg: replace fixed E-RAB to DRB mapping", removed the fixed link between the two numbers. Nothing on the air required the climb: a free LCID was available on every call.

What never happens

Some of this connection's most telling RRC messages are the ones it doesn't contain:

• No RRCConnectionRelease. UE 70 enters RRC_CONNECTED at frame 3 and is still there when the capture ends, 113 s later. The S1AP log has no UE Context Release either.
• No Measurement Report, no handover. The measConfig in frame 24 has no measurement ID, so there is nothing to report.
• No re-establishment, no paging. The connection never fails, and the network never has to page a phone that is already connected.
• No transaction identifier other than 0. The eNB runs one procedure at a time, start to finish.

The last RRC message is frame 3288, the NAS accept for call 6's release, 11 s before the capture ends.

Takeaways

1. One connection carries the whole session. Setup, security, and capabilities take under half a second. Everything after that is reconfiguration.
2. A reconfiguration is a delta. Frame 24 adds an SRB, a DRB, and a measurement configuration. The twelve call reconfigurations each change exactly one DRB.
3. RRC carries NAS without reading it. NAS rides in Information Transfer messages on their own, or bundled into the reconfiguration that builds the bearer the NAS message announces.
4. Integrity starts with the Security Mode Command itself. Its MAC-I is the first non-zero tag on SRB1.
5. Identity spaces are small. A DRB gets one of eight LCIDs. An implementation that never reuses them runs out on the seventh call, even with only three bearers in use.

Where this sits in the stack

• An LTE Attach and a VoLTE Call on the Air Interface: the full walkthrough this page is a slice of, with every layer on one timeline.
• RLC-LTE Acknowledged and Unacknowledged Mode: what runs on DRB 2 and DRB 3 once these reconfigurations create them.
• SIP: IMS Registration and the VoLTE Call: the call signaling that triggers each voice bearer add and release.
• S1AP: Attach, E-RABs, and Six VoLTE Calls: the eNB's side toward the MME, including the E-RAB 13 request at the very end.
• NR-RRC in a Real 5G Capture: the same layer in 5G, where the connection is released and comes back.