DCP

Downlink Control Information with CRC scrambled by PS-RNTI

Physical Layer →
Introduced in Rel-16

DCP is a type of Downlink Control Information in NR that schedules paging messages, identified by its CRC being scrambled with the PS-RNTI to allow idle or inactive UEs to monitor for paging efficiently.

Category
Physical Layer
Introduced
Rel-16
Where
Radio Access Network › NG-RAN (5G)
Specifications
5 specs
DCP Description Purpose Related Classification Detected Changes Specifications

Description

DCP is a critical physical layer signaling mechanism in 3GPP New Radio (NR). It refers to a Downlink Control Information (DCI) format whose Cyclic Redundancy Check (CRC) bits are scrambled (i.e., masked) by the Paging RNTI (PS-RNTI). The PS-RNTI is a fixed, predefined identifier (value: 0xFFFE) known to all User Equipments (UEs). This scrambling operation is fundamental to the paging procedure. When a UE is in a low-power state like RRC_IDLE or RRC_INACTIVE, it does not maintain a continuous connection to the network. Instead, it periodically wakes up to monitor specific time-frequency resources known as Paging Occasions (POs) within a Paging Frame (PF). During these POs, the UE blindly decodes the Physical Downlink Control Channel (PDCCH) for DCIs. It attempts to descramble the CRC of any detected DCI using the PS-RNTI. If the descrambling is successful, it confirms that the DCI is a DCP intended for paging. The DCP itself does not carry the paging message content. Instead, it contains scheduling assignment information, such as the modulation and coding scheme, resource block allocation, and transport format. This scheduling information points the UE to the specific resources on the Physical Downlink Shared Channel (PDSCH) where the actual paging message, encapsulated in a Paging MAC Control Element or RRC Paging message, is transmitted. The UE then decodes the PDSCH at the indicated location to receive the full paging information, which may contain its identity if it is being paged for an incoming call, SMS, or other mobile-terminated service. This two-step process (DCP on PDCCH, then message on PDSCH) is highly efficient. It allows the network to page multiple UEs simultaneously within the same paging message while enabling UEs to perform minimal processing—only decoding the full PDSCH payload if the DCP indicates a paging transmission is present. The specifications governing DCP, such as TS 38.212 for the physical channel processing and TS 38.331 for RRC procedures, detail the exact DCI format (e.g., DCI format 1_0) used and the associated scrambling and decoding processes.

Purpose & Motivation

The primary purpose of DCP is to enable efficient, network-initiated wake-up of UEs in power-saving states for mobile-terminated services. In cellular networks, a UE cannot be contacted unless the network knows its approximate location and can signal it. When a UE is idle, it conserves battery by turning off its receiver most of the time. The network groups UEs into paging groups based on their identifiers and configures them with a Discontinuous Reception (DRX) cycle. The DCP mechanism solves the problem of how to alert a specific UE within a group without requiring all UEs to constantly listen to the channel. By using a common PS-RNTI, any UE monitoring a given PO can efficiently identify control information meant for its paging group. The scheduling information within the DCP then directs only the UEs that need to decode the subsequent paging message, minimizing unnecessary PDSCH processing for UEs not being paged. This design is a direct evolution from LTE's paging procedure but is adapted for the more flexible NR frame structure. It addresses the fundamental trade-off between UE battery life and network accessibility. Without such a targeted signaling method, UEs would either need to remain in a connected state (draining battery) or the network would have to broadcast full paging messages more frequently (wasting radio resources). DCP provides the precise, low-overhead trigger that balances these demands.

Classification

Part ofDCI

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (6 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-16 2 changes

In Release 16, corrections were introduced to clarify the prioritization rules between monitoring for a Downlink Control Information with CRC scrambled by PS-RNTI (DCP) and monitoring for a Random Access Response addressed to C-RNTI, specifically for Contention-Free Random Access used for Beam Failure Recovery (CFRA BFR). These corrections ensured unambiguous UE behavior when these two procedures could occur simultaneously.

  • Correction on prioritization between DCP and RAR to C-RNTI for CFRA BFR TS 38.300CR0295
  • Correction on prioritization between DCP and RAR to C-RNTI for CFRA BFR – Option 2 TS 38.321CR0794
Rel-17 1 change

In Release 17, a correction was introduced for Channel State Information (CSI) reporting related to the Downlink Control Information with CRC scrambled by PS-RNTI (DCP) function. This update specifically addressed the procedure for when a UE is configured to monitor DCP for power saving in Multi-Radio Dual Connectivity (MR-DC) scenarios, such as NE-DC and NR-DC. The refinement ensured proper operation when DCP is monitored on either the PCell from a gNB Master Node or the PSCell from a gNB Secondary Node.

  • Correction on CSI reporting for DCP function TS 38.321CR1673
Rel-18 3 changes

In Release 18, corrections were made to the Downlink Control Information with CRC scrambled by PS-RNTI (DCP) function, specifically addressing gaps identified for Multi-SIM (MUSIM) operation. These corrections refine the procedures for monitoring DCP for power saving in MR-DC scenarios, such as when the Master Node is a gNB. The updates ensure proper DCP configuration and monitoring behavior on the PCell or PSCell in dual connectivity setups like NE-DC and NR-DC.

  • Corrections on DCP TS 38.300CR0985
  • Correction on DCP considering MUSIM gaps TS 38.300CR1026
  • Correction on DCP considering MUSIM gaps TS 38.321CR2109

Explore further

Broader topics and technologies where DCP plays a role.

Defining Specifications

3GPP specifications that define or reference DCP, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 37.340 vj00 Multi-Connectivity Operation Overview Rel-19
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 38.321 vj00 NR MAC Protocol Specification Rel-19
TS 38.331 vj00 NR Radio Resource Control (RRC) Protocol Specification Rel-19
TR 38.869 vi00 Study on low-power wake up signal and receiver for NR Rel-18
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.