EHC

Ethernet Header Compression

Protocol →
Introduced in Rel-16 Also in: User Equipment

EHC is a 3GPP protocol that compresses Ethernet frame headers over the air interface to reduce overhead and improve spectral efficiency for services like industrial IoT.

Category
Protocol
Introduced
Rel-16
Where
Radio Access Network › NG-RAN (5G)
Also touches
1 segments
Specifications
9 specs
EHC Description Purpose Related Classification Detected Changes Specifications

Description

Ethernet Header Compression (EHC) is a protocol defined by 3GPP to efficiently transmit Ethernet frames over cellular radio access networks (RAN), specifically for NR (New Radio) and LTE. It operates by compressing the often-redundant fields within Ethernet frame headers before transmission over the Uu air interface between the User Equipment (UE) and the gNB (in 5G) or eNB (in LTE). The protocol is typically implemented in the Packet Data Convergence Protocol (PDCP) layer, which is responsible for header compression and ciphering. EHC works by establishing a context between the compressor (sender) and decompressor (receiver) for each data flow. This context contains static information about the Ethernet header fields, such as source and destination MAC addresses, VLAN tags, and EtherType. After an initial full header is sent to establish the context, subsequent packets transmit only a compressed header containing dynamic fields (like sequence numbers) and changes to static fields, significantly reducing the per-packet overhead.

The architecture involves EHC entities in both the UE and the base station (gNB/eNB). Compression and decompression are performed at the PDCP layer. The network configures EHC parameters via RRC (Radio Resource Control) signaling, specifying profiles and contexts. EHC supports multiple profiles to handle different Ethernet frame types, including those with and without VLAN tags. It uses robust header compression (ROHC) principles adapted for Ethernet, employing feedback mechanisms to ensure reliable context synchronization between compressor and decompressor, even in lossy radio conditions.

EHC's role is critical in the 5G system architecture for supporting Ethernet-based services that require low latency and high reliability, such as those defined for the 5G LAN-type service, industrial automation, and fronthaul/backhaul integration. By reducing header size, it decreases transmission time and increases effective data throughput, which is vital for meeting the stringent requirements of Ultra-Reliable Low-Latency Communication (URLLC) and enhanced Mobile Broadband (eMBB) use cases. It enables the 5G system to natively transport layer 2 Ethernet frames, facilitating integration with existing Ethernet-based industrial networks and supporting network slicing for isolated service segments.

Purpose & Motivation

EHC was introduced to address the inefficiency of transmitting standard Ethernet frames, which have a minimum header size of 14 bytes (plus optional VLAN tags), over the bandwidth-constrained and latency-sensitive air interface in 4G and 5G networks. Prior to EHC, transporting Ethernet traffic over cellular required tunneling protocols like GTP-U, which added further overhead, or transmitting uncompressed headers, wasting valuable radio resources. This was particularly problematic for new 5G use cases like industrial IoT, vehicle-to-everything (V2X), and mobile fronthaul, where many small, frequent Ethernet packets (e.g., for sensor data or control signals) are generated, making header overhead a significant portion of the total transmission.

The creation of EHC was motivated by the need to optimize radio resource utilization for Ethernet-based services, which are foundational in many vertical industries. 3GPP Release 16, which introduced enhanced support for vertical LAN services and time-sensitive networking, identified Ethernet transport as a key requirement. EHC directly supports these capabilities by minimizing air interface overhead, thereby improving spectral efficiency, reducing latency, and increasing capacity for Ethernet flows. It solves the problem of efficiently integrating layer 2 Ethernet networks with 3GPP cellular systems, enabling 5G to act as a seamless Ethernet bridge for industrial and enterprise applications.

Classification

Part ofROHC
Related approachesPDCP

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-16 5 changes

In Release 16, the Ethernet Header Compression (EHC) function was newly introduced for operation in LTE PDCP. This release added the support for Ethernet Header Compression itself and included specific corrections and refinements, such as defining the ciphering of the EHC header and restricting the number of downlink EHC contexts. Furthermore, it was specified that EHC cannot be configured simultaneously with a DAPS Handover and must be released by the source base station prior to the handover command.

  • Introducing EHC in LTE PDCP TS 36.323CR0278
  • Support of Ethernet Header Compression TS 38.463CR0478
  • Correction on receive operation when both EHC and out-of-order delivery are configured for a DRB TS 38.323CR0050
  • CR for the ciphering of EHC header TS 38.323CR0080
  • Restricting the number of DL EHC contexts TS 38.463CR0614
Rel-17 2 changes

In Release 17, the new work on Ethernet Header Compression (EHC) included a specific Correction on EHC parameters and a CR detailing EHC decompression procedures. The specification also explicitly clarified that EHC is one of the features, like CA and DC, that cannot be configured simultaneously with a DAPS Handover and must be released by the source base station before the handover command is sent.

Explore further

Broader topics and technologies where EHC plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.306 vj00 E-UTRA UE Radio Access Capability Parameters Rel-19
TS 36.323 vj00 PDCP Protocol Specification Rel-19
TS 37.483 vj10 E1 Application Protocol (E1AP) Rel-19
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 38.306 vj00 NR UE Radio Access Capability Parameters Rel-19
TS 38.323 vj00 Packet Data Convergence Protocol (PDCP) Rel-19
TS 38.463 vj00 E1 Application Protocol (E1AP) Rel-19
TS 38.523 vj20 5G NR UE Conformance Testing: Idle/Inactive 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.