EDC

Error Detection Code byte

Physical Layer →
Introduced in Rel-4 Also in: Core Network

EDC is a single byte containing a checksum that is used in 3GPP protocols to verify data integrity and enable the receiver to detect transmission errors.

Category
Physical Layer
Introduced
Rel-4
Where
Services
Also touches
1 segments
Specifications
5 specs
EDC Description Purpose Related Classification Detected Changes Specifications

Description

The Error Detection Code (EDC) byte is a fundamental component of the data link layer and physical layer protocols within 3GPP systems, primarily used in GSM and early UMTS specifications. It is an 8-bit field appended to a data block or frame before transmission. The value of this byte is calculated by applying a specific cyclic redundancy check (CRC) polynomial to the information bits of the block. Common polynomials, such as CRC-8, are used to generate a checksum that is a function of all the data bits. Upon reception, the receiving entity independently recalculates the EDC based on the received data bits and compares it to the received EDC byte. A mismatch indicates that one or more bits have been corrupted during transmission, triggering procedures like Automatic Repeat reQuest (ARQ) for retransmission or discarding the erroneous frame.

Architecturally, the EDC insertion and verification are handled by the Layer 2 protocol stack, often within the Radio Link Control (RLC) or Medium Access Control (MAC) sublayers, depending on the specific channel and technology (e.g., GSM data channels, GPRS, or early UMTS transport channels). Its role is integral to the error detection function, which operates before more complex error correction techniques like Forward Error Correction (FEC). While FEC can correct some errors, the EDC provides a definitive, lightweight check for uncorrectable errors, ensuring that higher layers are not presented with corrupted data.

The EDC's simplicity is its key strength; it adds minimal overhead (just one byte) while providing a high probability of detecting random and burst errors typical in radio environments. Its effectiveness is quantified by its Hamming distance, which determines the minimum number of bit errors required to go undetected. In practice, for short blocks, it is highly effective. However, for larger data blocks or in environments requiring extremely high reliability, more robust schemes like longer CRC fields (e.g., CRC-16, CRC-24) are employed in later technologies like LTE and 5G NR. Thus, the EDC byte represents a foundational, efficient error detection mechanism in legacy 3GPP systems.

Purpose & Motivation

The EDC byte was created to address the inherent unreliability of the radio transmission medium. Wireless channels are susceptible to noise, interference, and fading, which can flip bits during data transfer. Without a mechanism to detect these errors, corrupted data would be passed up to higher-layer applications, causing malfunctions, corrupted files, or misinterpreted signaling messages. The primary purpose of the EDC is to provide a first line of defense by enabling the receiver to identify corrupted frames with high confidence.

Historically, it was introduced as a standard, low-overhead method within GSM and early 3G data services to improve the reliability of data services over circuit-switched and initial packet-switched connections. It solved the problem of silent data corruption, where errors go unnoticed. By detecting errors, the protocol can initiate corrective actions, such as discarding the bad frame or requesting its retransmission, thereby ensuring data integrity. This was a critical step in making wireless data services viable for applications beyond voice, where bit-error tolerance is extremely low.

The motivation stemmed from the need for a balanced approach between overhead and reliability. More complex error correction adds significant redundancy and processing complexity. The EDC byte offers a compromise: it adds only 8 bits of overhead, which is negligible for the block sizes used, yet provides sufficient detection capability for the error characteristics of 2G and 3G channels. It laid the groundwork for the more sophisticated hybrid ARQ (HARQ) and advanced CRC schemes used in later generations.

Classification

Part ofFEC
Related approachesCRCARQ

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-17 4 changes

In Release 17, the standardization of the Error Detection Code (EDC) function was enhanced through clarifications and new parameter definitions. Specifically, the release introduced a new parameter for EDC policy indication and clarified the usage of EDC-related PCO parameters as well as the procedure for indicating EDC support to the network. These changes were accompanied by necessary corrections to the EDC functionality description to ensure precise implementation.

  • EDC related PCO parameters usage TS 24.501CR3848
  • Adding new parameter for EDC policy indication TS 27.007CR0758
  • Corrections of EDC functionality description TS 23.548CR0051
  • Clarification on indicating the EDC support to network TS 24.501CR4492
Rel-18 1 change

In Release 18, the EDC function was updated through enhancements to the +CGDCONT command. This change specifically introduced support for an indicator related to SDNAEPC alongside the EDC functionality.

  • Updates to +CGDCONT for EDC and SDNAEPC support indicator TS 27.007CR0832

Explore further

Broader topics and technologies where EDC plays a role.

Defining Specifications

3GPP specifications that define or reference EDC, 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.548 vj50 5G System Edge Computing Enhancements Rel-19
TS 23.700 vk00 XR Services Application Enablement Layer Rel-20
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 27.007 vj40 AT Command Set for UE 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.