RRC Overview in LTE 4G

Introduction

RRC is the Layer-3 control-plane protocol of the LTE-Uu air interface, defined in TS 36.331. It is a peer protocol: an RRC entity in the UE talks to an RRC entity in the eNB, and between them they configure every layer below — PDCP, RLC, MAC and the physical layer are all set up, reconfigured and torn down by RRC messages.

You meet RRC across the whole connection lifecycle. From power-on it broadcasts the system information a UE needs to camp; it pages an idle UE; it establishes and secures the RRC connection; it builds the signalling and data bearers; it configures measurements and commands handover; and it releases the connection back to idle. Every one of those jobs is a defined RRC procedure — usually a command/response or request/response pair of ASN.1 messages.

This page is the map. It lays out what RRC is responsible for, the bearers and channels its messages ride on, how those messages are encoded, and the two states a UE lives in. Each major job — states, procedures, system information — has its own detailed page; here you get the structure that ties them together.

Why RRC is needed

The radio link is dynamic and shared among many UEs, and the layers beneath RRC can only move bits — they cannot decide whose bits, with what security, over which bearers, on which cell. Something must publish the cell parameters so a UE can camp, admit a UE into the connected state, key the link so signalling and data are protected, assemble the bearers user traffic rides on, and move the UE between cells without dropping it. RRC is that single authority. Without it the physical layer is a bare pipe with no one deciding what flows through it.

What RRC Is

RRC (Radio Resource Control) is the top layer of the control plane over the LTE-Uu air interface. It runs as a peer entity in the UE and in the eNB, and it is the protocol that configures everything below it — PDCP, RLC, MAC and the physical layer are all set up and reconfigured by RRC messages. If a parameter governs how the UE behaves on the radio, chances are RRC put it there. RRC itself carries no user payload; it broadcasts, signals, configures, and transparently ferries NAS messages between the UE and the core network.

Services and Functions

TS 36.331 gives RRC a broad remit, but it is easiest to remember as a handful of jobs, roughly in the order a UE meets them from power-on. Each of these deserves — and gets — its own detailed treatment elsewhere; here is the complete map of what RRC is responsible for.

• Broadcast of system information — the MasterInformationBlock (on BCH) and the SystemInformationBlockType1 through SystemInformationBlockTypeN tell every UE in the cell the parameters it needs to camp, evaluate access, and reselect. SIB1 carries cell access and scheduling for the rest; the others are grouped into SystemInformation messages.
• Paging — the network reaches an idle UE by sending a Paging message on the PCCH, either to notify it of downlink data (triggering the UE to start an RRCConnectionRequest) or to signal that system information has changed or an ETWS/CMAS warning is present.
• RRC connection establishment, maintenance and release — bringing the UE from RRC_IDLE into RRC_CONNECTED, keeping that connection healthy (including re-establishment after radio-link failure), and tearing it down with RRCConnectionRelease.
• Security activation — turning on integrity protection and ciphering for signalling, and ciphering for user data, via the SecurityModeCommand / SecurityModeComplete exchange. RRC selects the algorithms and triggers derivation of the key hierarchy from K_eNB.
• Radio bearer control — establishing, modifying and releasing Signalling Radio Bearers (SRBs) and Data Radio Bearers (DRBs), including the PDCP, RLC, logical-channel and physical-layer configuration each one needs. This is delivered through radioResourceConfigDedicated.
• Mobility — controlling handover between cells while connected (the handover command is an RRCConnectionReconfiguration carrying mobilityControlInfo), and supplying the cell-reselection parameters an idle UE uses to move on its own.
• Measurement configuration and reporting — telling the UE what to measure (serving and neighbour cells, thresholds, events A1–A6/B1–B2) via measConfig, and collecting MeasurementReport messages that drive handover decisions.
• UE capability transfer — asking the UE what it supports with UECapabilityEnquiry and receiving UECapabilityInformation, so the eNB configures only features the UE can honour.
• NAS message transfer — carrying core-network (NAS) messages transparently, either piggybacked inside RRC messages or as standalone transfers, without RRC parsing them.

Signalling Radio Bearers

RRC messages do not float freely; each rides a Signalling Radio Bearer (SRB), which pins the message to a logical channel and an RLC mode. An SRB is just a radio bearer reserved for control-plane traffic. LTE defines a small, fixed set of them, each with a specific job and a specific moment in the connection's life at which it comes into existence.

• SRB0 — carries the very first messages, before the UE is known or secured. It maps to the Common Control Channel (CCCH) and uses RLC Transparent Mode (TM). This is where RRCConnectionRequest, RRCConnectionSetup and RRCConnectionReject live. No security is applied — there is no security context yet, and no logical way to apply one.
• SRB1 — the workhorse. It maps to the Dedicated Control Channel (DCCH) in RLC Acknowledged Mode (AM) and carries most RRC signalling, including NAS messages piggybacked on RRC. It is created by RRCConnectionSetup and is integrity-protected and ciphered once the SecurityModeCommand completes.
• SRB1bis — a special variant used only for the Control-Plane Cellular IoT (CIoT) EPS optimisation. It is effectively SRB1 without PDCP (no ciphering, no integrity), used to carry NAS data over the control plane before security is set up in that reduced-signalling mode. On a normal connection you never see it; it exists so a narrowband IoT device can exchange a few packets with minimal overhead.
• SRB2 — a lower-priority dedicated bearer, also on DCCH in AM, dedicated to standalone NAS messages (those sent in DLInformationTransfer / ULInformationTransfer). It is established only after security is activated, and it always has lower priority than SRB1 so that pure RRC control never gets stuck behind bulk NAS traffic.

Message Transport over Logical Channels

Above the SRBs, RRC messages are sorted onto logical channels — the MAC layer's abstraction for "what kind of traffic is this". Each RRC message type is defined to travel on exactly one logical channel, and the choice of channel tells you a lot about the message: whether it is broadcast to all UEs or dedicated to one, and whether it flows before or after a connection exists. There are four logical channels that carry RRC.

• BCCH (Broadcast Control Channel) — downlink only, one-to-many. It carries system information: the MasterInformationBlock reaches it via the BCH transport channel and the physical PBCH, while the SIBs reach it via DL-SCH. Every UE in the cell reads the same content, secured only by the fact that it is public by design.
• PCCH (Paging Control Channel) — downlink only, one-to-many. It carries the Paging message to UEs whose exact cell the network does not know, so it is addressed by paging identities rather than a dedicated bearer. A UE monitors it only at its paging occasions to save power.
• CCCH (Common Control Channel) — bidirectional, used when the UE has no dedicated resources yet. This is the home of SRB0. Because the UE is not yet uniquely addressable on a dedicated channel, contention resolution (in MAC) sorts out which UE a common-channel message belongs to.
• DCCH (Dedicated Control Channel) — bidirectional, point-to-point. It carries SRB1 and SRB2 once the UE is connected and individually addressable by its C-RNTI. All secured dedicated signalling lives here.

The mapping is deliberately rigid: MasterInformationBlock and the SIBs go on BCCH; Paging goes on PCCH; the connection-bootstrap messages go on CCCH; everything dedicated goes on DCCH. From the logical channel, MAC multiplexes onto transport channels (BCH, PCH, DL-SCH, UL-SCH) and the physical layer carries them across the air. A single fact ties the picture together: the direction and the addressing of an RRC message are decided the moment its logical channel is chosen.

ASN.1 and PER Encoding

Every RRC message is formally defined in ASN.1 (Abstract Syntax Notation One). TS 36.331 does not describe messages in prose; it publishes an ASN.1 module where each message and each Information Element is a precisely typed structure — sequences, choices, enumerations, bit strings, optional fields and value ranges. This abstract definition is what makes "the measConfig IE" or "the dedicatedInfoNAS field" an exact, machine-checkable thing rather than a loose label.

On the wire, those abstract structures are serialised using PER (Packed Encoding Rules), specifically the unaligned variant. PER is chosen because it is extremely compact: it spends no bytes on field tags or delimiters, encodes each value in the minimum number of bits implied by its declared range, and emits optional-field presence as single bits gathered into a bitmap at the front of a sequence. On a scarce, expensive radio link this density matters — an integer constrained to 0–7 costs three bits, not a whole octet.

The extension mechanism is worth its own note. ASN.1 uses an extension marker (written ... inside a definition) to fence off the fields that existed in the original release from those added later. A decoder built for an early release can skip fields it does not understand rather than failing, which is exactly how the same message name survives many 3GPP releases while quietly gaining new IEs. This forward-compatibility is why RRC could grow from Release 8 through carrier aggregation, dual connectivity, and NB-IoT without renaming its core messages.

How RRC Signalling Looks in Practice

Almost every RRC interaction is a request/response pair of ASN.1 messages, exchanged over the SRBs and logical channels described above. A few you will meet constantly, in the order a fresh connection assembles itself:

• The UE opens with RRCConnectionRequest on SRB0/CCCH; the eNB replies with RRCConnectionSetup, which builds SRB1; the UE confirms with RRCConnectionSetupComplete on SRB1, piggybacking its first NAS message (typically the Attach Request or Service Request) in dedicatedInfoNAS.
• Once the eNB has a security context from the MME, security is switched on with SecurityModeCommand → SecurityModeComplete. From this point SRB1 is protected and SRB2/DRBs may be added.
• Capabilities are learned with UECapabilityEnquiry → UECapabilityInformation so the eNB configures only supported features.
• Bearers, measurements and mobility are added or changed with RRCConnectionReconfiguration → RRCConnectionReconfigurationComplete — this single message does the heavy lifting for DRB setup, handover, and measurement configuration.
• The connection is finally torn down with RRCConnectionRelease, which returns the UE to RRC_IDLE and may include redirection or idle-mode mobility information.

Because RRCConnectionReconfiguration can carry a mobilityControlInfo IE (the handover command), a radioResourceConfigDedicated IE (bearers), and a measConfig IE (measurements) all at once, a single reconfiguration is often where mobility, bearer control and measurement setup meet in one message. Understanding that one message unlocks most of what happens after connection setup.

Every procedure that expects a response also runs a guard timer on the initiating side, and knowing the timer is how you reason about a stall. The UE starts T300 when it sends RRCConnectionRequest and abandons setup if RRCConnectionSetup does not arrive before it expires; T301 guards RRCConnectionReestablishmentRequest; T304 guards the handover commanded in mobilityControlInfo, and its expiry is handover failure. On the maintenance side, the UE declares radio-link failure when T310 (started on N310 consecutive out-of-sync indications from the physical layer) expires without recovery, then starts T311 while it searches for a suitable cell to re-establish on; if T311 expires first the UE falls all the way back to RRC_IDLE.

The Two RRC States

In LTE, RRC has exactly two states, and which one the UE is in decides who controls its mobility and whether it has a connection at all. This is only the map — the states and the procedures that move between them get their own dedicated page.

• RRC_IDLE — no RRC connection and no UE context in the eNB. The UE camps on a cell, monitors Paging on the PCCH at its paging occasions, reads system information on the BCCH, and moves between cells on its own using cell reselection rules broadcast by the network. To send or receive data it must first establish a connection over SRB0.
• RRC_CONNECTED — an RRC connection exists, the eNB holds a UE context, SRB1 (and usually SRB2 plus DRBs) are set up, and mobility is network-controlled via measurement-driven handover. This is where user data flows.

The transition RRC_IDLE → RRC_CONNECTED happens through the RRC connection establishment procedure; the reverse happens through RRCConnectionRelease. The dividing line is simple: in RRC_IDLE the UE decides where to go, and in RRC_CONNECTED the network decides. The two states also differ in where the UE's context lives: in idle it is held only in the core (the MME keeps the EMM/ECM context and the UE is tracked at Tracking-Area granularity), while in connected the eNB additionally holds the full AS context — keys, bearers, measurement configuration and the C-RNTI.

Summary

RRC (TS 36.331) is the Layer-3 control-plane protocol that configures everything beneath it on the LTE air interface. Its jobs are a short, memorable list: broadcast system information, page idle UEs, establish/maintain/release the RRC connection, activate security, control radio bearers, steer mobility, configure measurements, transfer UE capability, and relay NAS transparently.

Its messages ride three SRBs (SRB0 unsecured on CCCH/TM, SRB1 and SRB2 secured on DCCH/AM) over four logical channels (BCCH, PCCH, CCCH, DCCH), and are defined in ASN.1 and encoded with compact unaligned PER. Almost every procedure is a command/complete or request/response pair guarded by a timer (T300, T301, T304, T310/T311). And it all resolves into two states: RRC_IDLE, where the UE controls its own mobility, and RRC_CONNECTED, where the network does — the dividing line under everything RRC arranges.

Quick Q&A