Ethernet Header Compression (EHC) in NR PDCP

Quick facts

Contents

1. Introduction to EHC
2. What This Page Covers
3. Where EHC Sits in the PDCP Function Chain
4. EHC Framework and Applicability
5. Configuration of EHC in NR PDCP
6. Configuration Examples
7. EHC Protocol Parameters
8. Header Compression Using EHC
9. Packet Examples
10. Header Decompression Using EHC
11. Compression / Decompression Flow Example
12. EHC Feedback in PDCP
13. EHC Feedback PDU Example
14. Simultaneous Configuration of ROHC and EHC
15. ROHC + EHC Coexistence Example
16. What Should Stay Off This Page
17. References
18. FAQ
19. Related PDCP Pages

Introduction to EHC

EHC belongs to the Ethernet-oriented PDCP header-compression view. It is not the full EHC framework reference from the annex. This page stays on the PDCP-facing behavior: where EHC applies, how it is configured, what the key parameter means, how compression and decompression sit in the PDCP chain, and how feedback is carried.

This is the page to open when the question is “how does EHC behave inside PDCP?” rather than “what does the full compression framework do internally?” For Control PDU field layout and general PDCP SN and COUNT reading, continue into PDU formats, SN, COUNT, and parameters.

What This Page Covers

Where EHC Sits in the PDCP Function Chain

From the PDCP point of view, header compression is a transmit-side function and header decompression is the corresponding receive-side function. That means EHC should be read in the same chain as ciphering, deciphering, and integrity verification, PDCP header handling, and delivery toward upper layers.

This also makes the later ROHC-EHC coexistence section easier to read, because both header-compression methods sit in the same larger PDCP function chain.

EHC Framework and Applicability

EHC is the Ethernet-oriented PDCP header-compression method. It targets Ethernet-based user-plane traffic and should be read as distinct from the IP-oriented ROHC path and from other compression families.

Configuration of EHC in NR PDCP

EHC is an upper-layer configured PDCP behavior for relevant user-plane PDCP entities. In practice, the reader should identify whether the entity belongs to a DRB or MRB carrying the right traffic, then check whether EHC was enabled for that entity.

In decoded configuration, this usually appears under the wider RRC configuration view rather than inside PDCP runtime signaling.

Configuration Examples

These examples are illustrative configuration shapes, not ASN.1-exact RRC dumps. They are here to show how EHC enablement and the key parameter are usually represented conceptually.

Example 1: Basic DRB with EHC enabled

bearerType: DRB
userPlaneData: true
headerCompression:
  protocol: EHC
  maxCID-EHC-UL: <configured by upper layers>
notes:
  - one CID is reserved for uncompressed flows
  - one EHC compressor instance per PDCP entity
  - one EHC decompressor instance per PDCP entity

Example 2: MRB with EHC enabled

bearerType: MRB
userPlaneData: true
headerCompression:
  protocol: EHC
  maxCID-EHC-UL: <configured by upper layers>
result:
  - EHC full header packets may be generated
  - EHC compressed header packets may be generated
  - EHC feedback may be generated as standalone packets

Example 3: Editorial reading note

Use these examples to understand configuration shape and behavior. Keep them illustrative rather than treating them as exact ASN.1 syntax.

EHC Protocol Parameters

The EHC parameter view is intentionally small. The most important item is MAX_CID_EHC_UL, plus the rule that one CID is reserved for uncompressed flows.

Header Compression Using EHC

On the transmit side, EHC can produce three useful output types for this page: EHC full header packets, EHC compressed header packets, and EHC feedback as standalone output. The important PDCP-side rule is that an EHC-compressed packet keeps the same PDCP SN and COUNT as the related PDCP SDU.

Packet Examples

Example 1: EHC full header packet

Original PDCP SDU
[ Ethernet header ][ payload ]

Illustrative EHC FH packet
[ F/C = FH ][ CID if present ][ Ethernet header ][ payload (+pad) ]

Example 2: EHC compressed header packet

Original PDCP SDU
[ Ethernet header ][ payload ]

Illustrative EHC CH packet
[ F/C = CH ][ CID if present ][ payload (+pad) ]

Example 3: EHC feedback packet

Illustrative EHC feedback packet
[ R ][ CID if present ]

Read those packet examples with one practical rule in mind: an EHC-compressed packet keeps the same PDCP SN and COUNT as the related PDCP SDU, while EHC feedback is not associated with a PDCP SDU or PDCP SN.

Header Decompression Using EHC

On receive, the ordering point is simple and important: deciphering and integrity verification happen before EHC decompression. That makes EHC decompression a receive-side PDCP step inside the larger secured receive chain rather than a separate path.

Compression / Decompression Flow Example

The value of this example is the processing order. It makes the transmit and receive sequence visible without forcing the reader into the full implementation detail of the compression framework.

Transmit side
PDCP SDU with Ethernet payload
→ EHC compression
→ PDCP Data PDU creation
→ lower-layer transmission

Receive side
PDCP Data PDU reception
→ deciphering
→ integrity verification
→ EHC decompression
→ delivery of recovered payload upward

EHC Feedback in PDCP

EHC feedback is the main Control-PDU-side EHC topic. The feedback is carried as a PDCP Control PDU, sent without PDCP SN association, and sent without ciphering or integrity protection. On reception, it is delivered to the EHC protocol without deciphering or integrity verification.

EHC Feedback PDU Example

Example feedback flow

Step 1: Receiver detects that EHC context needs feedback.
Step 2: Receiver generates EHC feedback.
Step 3: PDCP sends a PDCP Control PDU carrying one EHC feedback item.
Step 4: No PDCP SN is assigned.
Step 5: The Control PDU is sent without ciphering or integrity protection.
Step 6: Peer PDCP delivers the feedback directly to the EHC protocol.

Mini format example

Illustrative PDCP Control PDU
[ PDCP Control PDU ][ one EHC feedback ]

Simultaneous Configuration of ROHC and EHC

ROHC and EHC can both be configured together. The useful PDCP-side rule is short: if both are configured for a DRB or MRB, the ROHC header is located after the EHC header in the PDCP Data PDU.

This page keeps that coexistence point compact and uses the dedicated ROHC page for the larger ROHC procedure view.

ROHC + EHC Coexistence Example

Example ordering

Illustrative PDCP Data PDU header ordering
[ EHC header ][ ROHC header ][ remaining payload ]

Non-IP Ethernet packet case

If the packet is non-IP Ethernet traffic,
the EHC compressor/decompressor bypasses
the ROHC compressor/decompressor.

What Should Stay Off This Page

References

• ETSI TS 138 323 V18.5.0, NR PDCP specification
• 3GPP TS 38.331 V18.5.1, NR RRC configuration context for EHC-related PDCP settings

FAQ

What is EHC in NR PDCP?

EHC in NR PDCP is the Ethernet Header Compression method used for Ethernet-oriented user-plane traffic when configured by upper layers.

Which PDCP entities can use EHC?

PDCP entities carrying user-plane data and associated with DRBs or MRBs can use EHC when configured by upper layers.

What is MAX_CID_EHC_UL?

MAX_CID_EHC_UL is the upper-layer configured EHC context-space parameter for the PDCP entity, and one CID is reserved for uncompressed flows.

Are EHC feedback packets associated with a PDCP SN?

No. EHC feedback packets are not associated with a PDCP SN.

Is EHC feedback ciphered or integrity protected?

No. EHC feedback is sent without ciphering or integrity protection and is received without deciphering or integrity verification.

When both ROHC and EHC are configured, which header comes first?

When both are configured, the EHC header comes first and the ROHC header is located after the EHC header in the PDCP Data PDU.

Related PDCP Pages