Radio Bearers: SRB & DRB in 5G NR

Introduction

A radio bearer is the unit in which the NR air interface (the Uu interface) carries traffic between the UE and the gNB. It is not a physical object but a configured chain of protocol entities — at most one SDAP, exactly one PDCP, one or two RLC entities, and a logical channel — that together give one stream of data a defined security, reliability and priority treatment (TS 38.331, TS 38.323, TS 38.322, TS 38.321).

Bearers are established and torn down throughout the connection lifecycle: the very first RRC message travels on SRB0 before any UE context exists, SRB1 comes up at RRCSetup, SRB2 and the first DRBs appear only after AS security is activated, and each PDU session's DRBs are added when the core requests user-plane resources. If you can say which bearer a message rides on, you already know how it is protected, how reliably it is delivered, and how urgently it is scheduled.

This page treats a bearer as exactly what it is — a vertical slice through the stack — and walks the two families (SRB and DRB), the mapping down to the transport channel, the IEs that configure each half, and the split/duplication shapes that dual connectivity and carrier aggregation rely on.

Why radio bearers exist

Concretely, different flows have irreconcilable needs, so one pipe cannot serve them all. RRC connection setup must work before any security exists, so it needs an unprotected, context-free bearer. NAS and RRC signalling need a reliable, protected channel so nothing is lost or forged. User data needs QoS-differentiated, high-throughput pipes, and real-time media would rather drop a late packet than wait for a retransmission. Giving each flow its own bearer lets each get exactly the stack configuration it needs — the right security, the right RLC mode, the right priority — with no compromise.

What a Radio Bearer Is

Strip away the acronyms and a radio bearer is a promise about how one stream of data will be treated between the UE and the gNB over the Uu interface. That promise is realised physically as a chain of layer entities: at most one SDAP entity (data only), exactly one PDCP entity, one or two RLC entities, and a logical channel that the MAC schedules. Configure that chain and the bearer exists; tear the chain down and it is gone. There is no separate "bearer object" in the air interface — the bearer is the configured stack.

Two things distinguish one bearer type from another, and it is worth fixing them now because everything else follows. First, what sits above PDCP: a DRB has an SDAP entity that maps QoS flows onto it, an SRB has nothing above PDCP because RRC feeds PDCP directly. Second, the RLC mode and security: SRB0 is transparent and unprotected, SRB1–3 are acknowledged and (after security activation) protected, and DRBs are ciphered and use either acknowledged or unacknowledged mode depending on the service. Get those two axes straight and the whole SRB/DRB zoo becomes a small, orderly table.

Signalling Radio Bearers (SRB0–SRB3)

SRBs carry control-plane messages: RRC messages themselves, and NAS messages piggybacked inside RRC containers. There are four of them, and each exists because of a specific gap the others cannot fill (TS 38.331). They are identified by an srb-Identity in the range 1–3 for the configured SRBs; SRB0 has no identity because it is never configured — it exists implicitly.

• SRB0 — carries RRC on the CCCH logical channel using RLC-TM (transparent mode) with no security. It is the bootstrap bearer: it exists implicitly before any dedicated configuration and needs no configuring. It carries RRCSetupRequest/RRCSetup and RRCReestablishmentRequest/RRCReestablishment. Transparent mode is used because there is no UE context yet, so there is nothing to number, segment, or acknowledge against.
• SRB1 — carries RRC messages, and (until SRB2 exists) all NAS messages, on the DCCH using RLC-AM (acknowledged mode). It is created by RRCSetup and is the primary signalling bearer for the life of the connection. It carries RRCSetupComplete with the initial NAS Registration Request piggybacked inside its dedicatedNAS-Message, and every later RRCReconfiguration.
• SRB2 — carries NAS messages on the DCCH using RLC-AM, at lower priority than SRB1. It is set up after AS security is activated, in the RRCReconfiguration that follows SecurityModeCommand. Offloading bulky NAS traffic onto a lower-priority bearer stops it from starving urgent RRC signalling that must stay on SRB1.
• SRB3 — used only in dual connectivity (EN-DC / NR-DC). It lets the UE exchange certain RRC messages directly with the secondary node (SN) without routing through the master node, which speeds up SCG (secondary cell group) reconfiguration and measurement reporting for the secondary leg.

Data Radio Bearers and the SDAP Cross-Link

A DRB carries user-plane packets belonging to a PDU session. What makes it different from an SRB is the layer that sits on top of its PDCP entity: the SDAP (Service Data Adaptation Protocol) entity. There is one SDAP entity per PDU session, and its job is to map QoS flows — each identified by a QFI (QoS Flow Identifier, a 6-bit value, 0–63) — onto DRBs. This is the crucial cross-link between the core-network QoS model and the radio: the 5G core thinks in QoS flows, the air interface thinks in DRBs, and SDAP is the translator between them. Each DRB is identified by a drb-Identity in the range 1–32. See SDAP and 5G QoS Model.

The mapping is many-to-few in a controlled way: one PDU session can have several DRBs, and one DRB can carry several QoS flows, but a single QoS flow is mapped to exactly one DRB at a time. SDAP can prepend a small header carrying the QFI so the receiver knows which flow a packet belongs to (controlled by sdap-HeaderDL/sdap-HeaderUL), and it supports reflective QoS, where the UE derives the uplink flow-to-DRB mapping from the downlink packets it observes rather than needing explicit signalling. DRBs always use PDCP ciphering, may optionally use PDCP integrity protection, and choose RLC-AM for reliable services or RLC-UM (unacknowledged mode) for latency-sensitive real-time services such as voice, where a late retransmission is worse than a lost packet.

The Bearer as a Vertical Stack

Because a bearer is its configured chain of entities, the clearest way to see the SRB/DRB distinction is to draw the two stacks side by side. Both terminate in a shared MAC that multiplexes their logical channels onto one transport channel; the difference is entirely in the top of the stack.

The table below reads the DRB stack layer by layer, naming each entity and the one job it does for the bearer. Reading it top to bottom is the same as tracing a downlink packet from the core network down to the antenna.

Mapping Down to the Transport Channel

The single most useful sentence to memorise is the downward mapping chain. A radio bearer maps to one PDCP entity, which feeds one or more RLC entities, each tied to one logical channel with its own logicalChannelIdentity, which the MAC multiplexes onto one transport channel (UL-SCH or DL-SCH). For a DRB there is an SDAP entity above PDCP; for an SRB there is not. That chain never changes; only the number of RLC legs varies.

The logicalChannelIdentity (LCID) is the pivot of the whole scheme. It is the label the MAC writes into the subheader of each MAC SDU so the receiving MAC can demultiplex a transport block back into the right logical channels, and from there up the correct bearer stacks. Each logical channel also carries a priority (1–16, where a lower number means higher priority), a prioritised bit rate (prioritisedBitRate), and a logical channel group (logicalChannelGroup) — the three inputs to the MAC's Logical Channel Prioritisation (LCP) procedure that decides, slot by slot, how much of each bearer's data goes into the grant. SRB1 gets a high priority so signalling is served ahead of bulk data; SRB2 sits below it; DRBs are prioritised according to their QoS. Standard logical-channel types line up with bearer types: CCCH for SRB0, DCCH for the other SRBs, and DTCH for DRBs.

Configuration: radioBearerConfig and RLC-BearerConfig

Bearer configuration is deliberately split across two IEs inside RRCReconfiguration, mirroring the two halves of the mapping chain (TS 38.331). This split is not bureaucratic tidiness — it is what makes split bearers and dual connectivity expressible at all.

radioBearerConfig defines the upper half, per bearer:

• srb-ToAddModList — the SRBs to add or modify, each identified by its SRB identity, with optional PDCP settings and a reestablishPDCP/discardOnPDCP flag.
• drb-ToAddModList — the DRBs to add or modify. Each entry has a drb-Identity, a pdcp-Config (SN length, discardTimer, integrity/ciphering, and split-bearer parameters such as moreThanOneRLC and primaryPath), and an sdap-Config naming the pdu-Session, the mapped QFIs, and header presence.
• drb-ToReleaseList / srb3-ToRelease — the counterparts that tear bearers down.

CellGroupConfig defines the lower half, per logical channel, as a list of RLC-BearerConfig entries in rlc-BearerToAddModList. Each RLC-BearerConfig binds a bearer to a logical channel and its scheduling treatment:

The full set of top-level bearer-configuration IEs, and which part of the stack each one paints, is summarised below.

Split Bearers and PDCP Duplication

The phrase "one or more RLC entities" in the mapping rule is where the interesting cases live. Because a single PDCP entity may be associated with two RLC entities, a bearer can take one of two advanced shapes, both used in dual connectivity (DC) and carrier aggregation (CA).

A split bearer has its one PDCP entity routing PDUs down two legs — typically one RLC bearer in the MCG and one in the SCG. PDCP hands data to whichever leg has capacity, governed by ul-DataSplitThreshold and a primaryPath that says which leg to prefer for small volumes. Splitting aggregates the throughput of both legs onto one bearer, which is the point of NR-DC for data: a single DRB can be fed by two radios at once.

PDCP duplication uses the same two-RLC structure for the opposite goal: instead of splitting traffic, PDCP sends the same PDU down both legs, and the receiving PDCP discards the duplicate. Sending two copies over independent radio links buys diversity and drives the residual error rate down — the mechanism behind ultra-reliable low-latency (URLLC) transmission. Duplication can run across two carriers in CA (both RLC legs in the same cell group, different cells) or across MCG and SCG in DC, and it can be switched on and off dynamically by a MAC CE once configured. NR also allows duplication over up to four RLC legs in later releases for even stronger reliability. The enabling switch in configuration is moreThanOneRLC together with the pdcp-Duplication flag; the two legs are just two RLC-BearerConfig entries pointing at the same servedRadioBearer.

Summary

A radio bearer is a configured vertical slice through the Uu stack, not a separate object: one SDAP (DRBs only) → exactly one PDCP → one or two RLC entities → one logical channel per RLC → the shared MAC → one transport channel. Configure the chain and the bearer exists; release it and it is gone.

Two axes classify every bearer. What sits above PDCP separates SRBs (nothing — RRC feeds PDCP directly, LCIDs 0–3) from DRBs (an SDAP entity mapping QFI flows, drb-Identity 1–32). Security and RLC mode separate the unprotected transparent SRB0 from the acknowledged, protected SRB1–3, and mark DRBs as always-ciphered with RLC-AM or RLC-UM per service. Security ordering is strict: SRB2 and DRBs only appear after AS security is on.

Configuration is split on purpose — radioBearerConfig paints the SDAP/PDCP upper half per bearer, while RLC-BearerConfig in CellGroupConfig paints the RLC/logical-channel/MAC lower half per leg. That very split is what lets one PDCP entity feed two RLC legs, giving split bearers (different data, more throughput) and duplicated bearers (same data, more reliability).

Quick Q&A