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.
Key Features
- Detects random and burst errors with very high probability
- Implemented via binary polynomial division using Linear Feedback Shift Registers (LFSRs)
- Supports multiple polynomial lengths (e.g., 24, 16, 8 bits) for different channels and data sizes
- Integral to HARQ process for generating ACK/NACK feedback
- Used for UE identification by scrambling CRC with RNTI in control channels
- Enables Code Block Group (CBG) based retransmissions in 5G NR for reduced latency
Evolution Across Releases
Introduced as the fundamental error detection mechanism for UMTS (WCDMA). Specified for transport channels (TrCHs) and physical channels. Used CRC lengths like 24, 16, 12, and 8 bits attached to transport blocks before Turbo coding. Integral to the initial HARQ processes for packet data convergence.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 23.107 | 3GPP TS 23.107 |
| TS 23.207 | 3GPP TS 23.207 |
| TS 25.212 | 3GPP TS 25.212 |
| TS 25.214 | 3GPP TS 25.214 |
| TS 25.222 | 3GPP TS 25.222 |
| TS 25.224 | 3GPP TS 25.224 |
| TS 25.225 | 3GPP TS 25.225 |
| TS 25.301 | 3GPP TS 25.301 |
| TS 25.302 | 3GPP TS 25.302 |
| TS 25.321 | 3GPP TS 25.321 |
| TS 25.322 | 3GPP TS 25.322 |
| TS 25.425 | 3GPP TS 25.425 |
| TS 25.427 | 3GPP TS 25.427 |
| TS 25.435 | 3GPP TS 25.435 |
| TS 25.766 | 3GPP TS 25.766 |
| TS 25.800 | 3GPP TS 25.800 |
| TS 25.903 | 3GPP TS 25.903 |
| TS 25.912 | 3GPP TS 25.912 |
| TS 25.914 | 3GPP TS 25.914 |
| TS 25.927 | 3GPP TS 25.927 |
| TS 25.929 | 3GPP TS 25.929 |
| TS 26.091 | 3GPP TS 26.091 |
| TS 26.101 | 3GPP TS 26.101 |
| TS 26.191 | 3GPP TS 26.191 |
| TS 26.201 | 3GPP TS 26.201 |
| TS 26.267 | 3GPP TS 26.267 |
| TS 26.268 | 3GPP TS 26.268 |
| TS 26.269 | 3GPP TS 26.269 |
| TS 26.935 | 3GPP TS 26.935 |
| TS 26.969 | 3GPP TS 26.969 |
| TS 26.975 | 3GPP TS 26.975 |
| TS 26.978 | 3GPP TS 26.978 |
| TS 29.333 | 3GPP TS 29.333 |
| TS 32.425 | 3GPP TR 32.425 |
| TS 34.114 | 3GPP TR 34.114 |
| TS 36.104 | 3GPP TR 36.104 |
| TS 36.116 | 3GPP TR 36.116 |
| TS 36.117 | 3GPP TR 36.117 |
| TS 36.201 | 3GPP TR 36.201 |
| TS 36.213 | 3GPP TR 36.213 |
| TS 36.216 | 3GPP TR 36.216 |
| TS 36.300 | 3GPP TR 36.300 |
| TS 36.302 | 3GPP TR 36.302 |
| TS 37.141 | 3GPP TR 37.141 |
| TS 37.145 | 3GPP TR 37.145 |
| TS 37.462 | 3GPP TR 37.462 |
| TS 37.544 | 3GPP TR 37.544 |
| TS 37.802 | 3GPP TR 37.802 |
| TS 37.900 | 3GPP TR 37.900 |
| TS 37.901 | 3GPP TR 37.901 |
| TS 38.202 | 3GPP TR 38.202 |
| TS 38.212 | 3GPP TR 38.212 |
| TS 38.213 | 3GPP TR 38.213 |
| TS 38.214 | 3GPP TR 38.214 |
| TS 38.291 | 3GPP TR 38.291 |
| TS 38.869 | 3GPP TR 38.869 |
| TS 38.889 | 3GPP TR 38.889 |
| TS 46.055 | 3GPP TR 46.055 |
| TS 46.061 | 3GPP TR 46.061 |