CRC

Cyclic Redundancy Check

Physical Layer →
Introduced in R99 Also in: Services

CRC is an error-detecting code that appends a short check value to data, calculated from the data bits, to detect accidental changes and ensure data integrity across 3GPP radio interfaces and protocols.

Category
Physical Layer
Introduced
R99
Where
Radio Access Network › NG-RAN (5G)
Also touches
1 segments
Specifications
60 specs
CRC Description Purpose Related Classification Detected Changes Specifications

Description

The Cyclic Redundancy Check (CRC) is a non-secure hash function designed to detect accidental errors in digital data. It operates by treating the message (data block) as a large binary number, which is divided by a predetermined generator polynomial. The remainder from this polynomial division becomes the CRC checksum, which is appended to the original data block before transmission. At the receiver, the same calculation is performed on the received data (including the appended CRC). If the calculated remainder is zero, the data is assumed to be error-free; a non-zero remainder indicates that one or more bits have been corrupted during transmission. This process is a form of binary polynomial arithmetic performed modulo-2, typically implemented efficiently in hardware using linear feedback shift registers (LFSRs).

In 3GPP systems, CRC is applied at multiple layers and for various channel types. For instance, in the physical layer of LTE and NR, a CRC is attached to transport blocks (TB CRC) before channel coding (like LDPC or Polar codes) to detect errors after decoding. Separate CRCs are also attached to code block segments when a transport block is large, forming Code Block Groups (CBGs) for more efficient retransmissions in NR. The length of the CRC (e.g., 24 bits, 16 bits, 8 bits) is chosen based on the required error detection probability and the size of the data block. Common polynomials defined in 3GPP specs include CRC24A, CRC24B, CRC24C, CRC16, and CRC8.

The role of CRC extends beyond mere error detection. It is integral to the Hybrid Automatic Repeat Request (HARQ) process. The receiver uses the CRC check to generate an ACK (positive acknowledgment) or NACK (negative acknowledgment), triggering retransmissions if errors are detected. Furthermore, CRC is used for in-band control signaling. For example, the Downlink Control Information (DCI) in the PDCCH carries its own CRC, which is then scrambled with a Radio Network Temporary Identifier (RNTI). This allows the UE to verify if the control message is intended for it, as a successful CRC check after descrambling with its assigned RNTI confirms address validity.

Architecturally, CRC calculation is a mandatory step in the processing chains of both the User Plane and Control Plane. It is specified in detail for physical channels (PDSCH, PUSCH, PDCCH), transport channels (DL-SCH, UL-SCH), and logical channels. Its implementation is a critical factor in achieving the high reliability and low latency targets of 5G NR, especially for Ultra-Reliable Low-Latency Communication (URLLC) services, where undetected errors could have severe consequences.

Purpose & Motivation

CRC exists to provide a reliable, lightweight mechanism for detecting random bit errors introduced during data transmission over noisy communication channels. In wireless systems, signals are susceptible to interference, fading, and noise, making error detection paramount. Without such a mechanism, corrupted data would be passed to higher layers, leading to corrupted content, failed procedures, and system instability. CRC solves this by providing a high-probability detection capability for burst errors common in radio environments.

The motivation for its use in 3GPP, dating back to Release 99, stems from its excellent balance of detection capability, computational simplicity, and low overhead. Compared to simpler checksums like parity bits, CRC polynomials can be designed to detect all single-bit errors, all double-bit errors, any odd number of errors, and any burst error shorter than the CRC length itself. This makes it vastly superior for protecting packet data in UMTS, LTE, and NR. Its hardware-friendly implementation using LFSRs allows for high-speed, low-latency processing, which is essential for meeting the tight timing requirements of radio frame processing.

Prior to standardized CRC application, systems relied on less robust error detection or more complex forward error correction (FEC) alone. CRC complements FEC schemes (like Turbo or LDPC codes) by detecting residual errors that the FEC decoder fails to correct. This hybrid approach—FEC for correction, CRC for detection—forms the backbone of modern link adaptation and HARQ, enabling efficient use of radio resources by triggering retransmissions only when necessary. Its creation and standardization were driven by the need for a universally applicable, robust error detection layer to ensure end-to-end data integrity in evolving mobile broadband systems.

Classification

Part ofHARQ
Specific typesFCSHEC
Related approachesRNTI

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 1 change

In Release 15, a correction was made to the CRC assumption for the procedures involving multi-CSI resource selection and CSI report(s) selection. This update specifically addressed the handling of the Cyclic Redundancy Check within these combined selection mechanisms.

  • Correction on CRC assumption for multi-CSI resource selection and CSI report(s) selection TS 38.213CR0041

Explore further

Broader topics and technologies where CRC plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.107 vj00 UMTS QoS Framework Rel-19
TS 23.207 vj00 End-to-End QoS Framework for GPRS Rel-19
TS 25.212 vj00 UTRA FDD Layer 1 Multiplexing & Channel Coding Rel-19
TS 25.214 vj00 UTRA FDD Physical Layer Procedures Rel-19
TS 25.222 vj00 UTRA TDD Multiplexing & Channel Coding Rel-19
TS 25.224 vj00 UTRA TDD Physical Layer Procedures Rel-19
TS 25.225 vj00 UTRA TDD Physical Layer Measurements Rel-19
TS 25.301 vj00 UE-UTRAN Radio Interface Protocol Architecture Rel-19
TS 25.302 vj00 UTRA Physical Layer Services Rel-19
TS 25.321 vj00 MAC Protocol Specification for UTRAN Rel-19
TS 25.322 vj00 RLC Protocol Specification Rel-19
TS 25.425 vj00 UTRAN Iur Interface User Plane Protocols Rel-19
TS 25.427 vj00 UTRAN Iub/Iur User Plane Protocols Rel-19
TS 25.435 vj00 UTRAN Iub Interface User Plane Protocols Rel-19
TS 25.766 vd10 Network-Assisted Interference Cancellation for UMTS Rel-13
TS 25.800 vc10 UMTS Heterogeneous Networks Study Rel-12
TR 25.903 vj00 Continuous Connectivity for Packet Data Users Rel-19
TR 25.912 vj00 Evolved UTRA and UTRAN Technical Report Rel-19
TR 25.914 vj00 3G UE Radio Performance Test Methods Rel-19
TR 25.927 ve00 Energy Saving Solutions for UMTS Node B Rel-14
TR 25.929 vj00 Continuous Connectivity for Packet Data Users Rel-19
TS 26.091 vj00 AMR Error Concealment Procedure Rel-19
TS 26.101 vj00 Generic frame format for AMR and GSM-EFR speech codecs Rel-19
TS 26.191 vj00 AMR-WB Error Concealment Procedure Rel-19
TS 26.201 vj00 AMR-WB Speech Codec Frame Format Rel-19
TS 26.267 vj00 eCall In-band Modem Specification Rel-19
TS 26.268 vj00 eCall In-band Modem ANSI-C Code Rel-19
TS 26.269 vj00 eCall In-band Modem Conformance Testing Rel-19
TR 26.935 vj00 Speech Codec Performance for Packet Switched Multimedia Rel-19
TR 26.969 vj00 eCall In-band Modem Performance Characterization Rel-19
TR 26.975 vj00 AMR Speech Codec Performance Background Rel-19
TR 26.978 vj00 AMR Noise Suppression Selection Phase Technical Report Rel-19
TS 29.333 vj00 MRFC-MRFP Mp Interface Protocol Rel-19
TS 32.425 vj00 E-UTRAN Performance Measurements Rel-19
TS 34.114 vc20 Radiated Performance Test Procedure for UE/MS Rel-12
TS 36.104 vj10 Base Station (BS) radio transmission and reception Rel-19
TS 36.116 vj00 E-UTRA Relay RF Requirements Rel-19
TS 36.117 vj00 E-UTRA Relay RF Test Methods & Requirements Rel-19
TS 36.201 vj00 LTE Physical Layer General Description Rel-19
TS 36.213 vj10 LTE Physical Layer Procedures Rel-19
TS 36.216 vj00 LTE Relay Node Physical Layer Rel-19
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.302 vj00 E-UTRA Physical Layer Services Rel-19
TS 37.141 vj10 RF Test Methods for Multi-Standard Radio Base Stations Rel-19
TS 37.145 vj10 AAS Base Station Conducted Conformance Testing Rel-19
TS 37.462 vj00 Iuant Interface Data Link Layer for RETAP/TMAAP Rel-19
TS 37.544 vg70 UE Radiated Performance Test Procedures Rel-16
TS 37.802 va10 MSR BS RF Requirements for Non-Contiguous Spectrum Rel-10
TR 37.900 vj00 Multi-Standard Radio (MSR) Base Station Requirements Rel-19
TR 37.901 vf10 UE Application Layer Data Throughput Performance Rel-15
TS 38.202 vj00 5G NR Physical Layer Services Rel-19
TS 38.212 vj10 NR Multiplexing and Channel Coding Rel-19
TS 38.213 vj10 NR Physical Layer Control Procedures Rel-19
TS 38.214 vj10 NR Physical Layer Procedures for Data Rel-19
TS 38.291 vj20 Ambient IoT Physical Layer Specification Rel-19
TR 38.869 vi00 Study on low-power wake up signal and receiver for NR Rel-18
TR 38.889 vg00 NR-based access to unlicensed spectrum study Rel-16
TS 46.055 vj00 GSM Enhanced Full Rate Speech Codec Performance Rel-19
TS 46.061 vj00 GSM EFR Frame Substitution and Muting Procedure Rel-19
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.