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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (122 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, specific corrections and clarifications were made to the CRC function's application within several NR procedures. These included a correction on the CRC assumption for the multi-CSI resource and report selection process, and a clarification regarding the RNTI used for scrambling the CRC of a PUSCH transmission scheduled by a Random Access Response uplink grant. Additionally, corrections addressed the handling of the CRC for dynamic and Type-1 HARQ-ACK codebooks.
- CR on inclusion of TC-RNTI for monitored RNTI for UL-SCH and inclusion of monitoring PDCCH ordering PRACH on SCell TS 38.202CR0007
- Correction to dynamic HARQ codebook in NR TS 38.213CR0014
- CR on missing case for DCI format 1_1 with CS-RNTI TS 38.213CR0035
- Correction on CRC assumption for multi-CSI resource selection and CSI report(s) selection TS 38.213CR0041
- Correction on the timeline condition of multiplexing two HARQ-ACK information in one slot TS 38.213CR0043
- CR on Type-1 HARQ-ACK codebook determination TS 38.213CR0044
+ 7 more changes
In Release 16, the CRC function itself was not the primary focus of the listed changes. The modifications primarily concerned enhancements and corrections to the HARQ-ACK codebook procedures, including Type-1, Type-2, and Type-3 codebook constructions, and their application for scenarios like PDSCH repetition and multi-TRP transmissions. These updates also addressed specific HARQ-ACK processing for dormancy indication and clarified multiplexing timelines and codebook size definitions.
- Addition of PUR RNTI in E-UTRA related UE identities TS 36.300CR1297
- Alignment of RRC parameter ps-RNTI TS 38.212CR0050
- Correction on HARQ-ACK codebook RRC parameter TS 38.212CR0069
- Type-3 CSS monitoring with PS-RNTI on primary cell TS 38.213CR0129
- CR to 38.213 on HARQ-ACK processing timeline for DCI format 1_1 with Scell dormancy indication without scheduling PDSCH TS 38.213CR0135
- Correction of NRU HARQ procedure in the presence of SPS PDSCH TS 38.213CR0163
+ 33 more changes
In Release 17, the CRC function's role in HARQ-ACK feedback was refined through several specific corrections and enhancements. These included updates to HARQ-ACK codebook generation for scenarios like PUCCH cell switching, UL BWP switching, and when spatial or time bundling are configured. Furthermore, the release introduced clarifications and support for multiplexing dynamic multicast HARQ-ACK with SPS unicast HARQ-ACK and adjusted procedures for determining PUCCH resources for multicast feedback.
- CR on DCI size for Rel-17 NTN HARQ in 38.212 TS 38.212CR0116
- Correction to support up to 32 HARQ process numbers for FR2-2 TS 38.212CR0126
- CR on number of HARQ-ACK codebooks configurable for multicast TS 38.212CR0129
- CR on aligning DCI sizes when configuring two HARQ-ACK codebooks for multicast TS 38.212CR0135
- Corrections of redundancy version for SDT TS 38.213CR0338
- CR on the description about HARQ-feedbackEnablingforSPSactive in 38.213 TS 38.213CR0340
+ 47 more changes
In Release 18, the primary enhancements for the CRC function centered on refining HARQ-ACK multiplexing, particularly for repetitions on a PUSCH and for multi-cell scheduling scenarios. The release introduced corrections and clarifications to both Type-1 and Type-2 HARQ-ACK codebook procedures, especially when feedback is carried on a PUSCH. These updates also addressed specific cases like multicast HARQ-ACK and HARQ-ACK for MsgB PDSCH to improve reliability and alignment with new scheduling mechanisms.
- Introduction of multiplexing in a PUSCH with repetitions HARQ-ACK associated with DL assignments received after an UL grant for the PUSCH [HARQ-ACK MUX on PUSCH] TS 38.213CR0568
- Correction on Type-2 HARQ-ACK codebook and DL BWP change TS 38.213CR0632
- Correction on multiplexing HARQ-ACK in a PUSCH transmission TS 38.213CR0636
- Correction on HARQ-ACK multiplexing on a PUSCH repetition [HARQ-ACK MUX on PUSCH] TS 38.213CR0646
- Correction on HARQ-ACK skipping for Rel-18 multi-cell scheduling TS 38.213CR0673
- Correction on the rate matching when HARQ-ACK multiplexed with CG-PUSCH TS 38.212CR0158
+ 10 more changes
In Release 19, the primary update related to CRC was the introduction of support for 32 Hybrid Automatic Repeat Request (HARQ) process numbers, as indicated by the Change Request title. This enhancement builds upon the existing framework where Radio Network Temporary Identifiers, such as the C-RNTI and G-RNTI, are used for UE identification and contention resolution within the RLC/MAC layers. The change specifically increases the capacity for HARQ processes, which are integral to the error-checking and retransmission mechanisms managed by the CRC function.
- Introduction of 32 HARQ process numbers in Rel-19 [TN32HARQ] TS 38.212CR0222
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.
| Specification | Title | Release |
|---|---|---|
| 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 |