ROHC Header Compression in NR PDCP

Quick facts

Contents

1. Introduction to ROHC Header Compression
2. What This Page Covers
3. Where ROHC Sits in the PDCP Function Chain
4. Supported ROHC Protocols and Profiles
5. ROHC Configuration in NR PDCP
6. ROHC Channel and Protocol Parameters
7. Header Compression Using ROHC
8. Header Decompression Using ROHC
9. Interspersed ROHC Feedback in PDCP
10. ROHC and DAPS Handover
11. ROHC Interaction With EHC
12. What This Page Does Not Cover in Detail
13. References
14. FAQ
15. Related PDCP Pages

Introduction to ROHC Header Compression

ROHC belongs to the PDCP user-plane header-compression view. It is not the full ROHC algorithm reference from the RFCs. Instead, this page keeps the focus on how ROHC appears inside PDCP: how it is configured, where it sits in the transmit and receive chain, how it relates to PDCP SN and COUNT, and how feedback is carried in PDCP Control PDUs.

This is the page to open when the question is “how does ROHC behave inside PDCP?” rather than “how does the full RFC algorithm work internally?” For Control PDU field structure, continue into PDU formats, SN, COUNT, and parameters.

What This Page Covers

Where ROHC Sits in the PDCP Function Chain

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

The DAPS case adds a useful complication: PDCP may need separate source-cell and target-cell ROHC handling, which is why DAPS appears again later as its own focused section.

Supported ROHC Protocols and Profiles

The PDCP specification references the ROHC framework and names the supported ROHC profile identifiers, but it does not become the full implementation guide for the ROHC framework itself. For this page, the useful reference view is simply which profile identifiers exist and what protocol family each one represents.

ROHC Configuration in NR PDCP

ROHC is an upper-layer configured PDCP behavior, mainly for user-plane PDCP entities. In practice, that means the reader should identify whether the PDCP entity belongs to a DRB, an MRB, or a sidelink DRB carrying IP SDUs, and then check whether ROHC was configured for that entity.

In traces and decoded configuration, this usually appears under RRCReconfiguration or the wider RRC configuration view rather than inside a PDCP PDU itself.

Example

A compact RRCReconfiguration dump is the clearest way to show how ROHC is configured by upper layers. The exact ASN.1 tree depends on the full bearer setup, but the ROHC-related knobs appear in the pdcp-Config branch rather than in PDCP runtime signaling.

RRCReconfiguration
  radioBearerConfig
    drb-ToAddModList
      DRB-ToAddMod
        drb-Identity = 4
        cnAssociation = sdap-Config
        pdcp-Config
          pdcp-SN-SizeUL = len18bits
          pdcp-SN-SizeDL = len18bits
          rohc
            maxCID = 15
            profiles = {
              profile0x0001,   -- RTP/UDP/IP
              profile0x0002,   -- UDP/IP
              profile0x0006    -- TCP/IP
            }
        reorderingTimer = ms50
        discardTimer = ms150
    securityConfig
      keyToUse = master

Read that dump as: this DRB is configured to use ROHC, the allowed ROHC context space is limited by maxCID, the supported ROHC profiles are named explicitly, and the same PDCP entity also carries its PDCP SN, reordering, discard, and security-side context from the surrounding RRC configuration.

ROHC Channel and Protocol Parameters

The ROHC channel model is one of the most important things to anchor early: the ROHC channel is unidirectional. From there, the key parameters are MAX_CID, LARGE_CIDS, and PROFILES, plus two useful boundary notes: FEEDBACK_FOR is not used directly here, and MRRU is not used because ROHC segmentation is not used.

Header Compression Using ROHC

On the transmit side, ROHC can produce two kinds of output: ROHC compressed packets that are associated with one PDCP SDU, and interspersed ROHC feedback that is not associated with a PDCP SDU. This distinction matters because the compressed-packet path keeps the same PDCP SN and COUNT as the related PDCP SDU, while the feedback path does not use a PDCP SN association.

Header Decompression Using ROHC

On receive, the key ordering point is simple: ROHC decompression is applied after deciphering. That makes ROHC a receive-side step inside the wider PDCP receive chain, not a separate path detached from PDCP security handling.

Interspersed ROHC Feedback in PDCP

Interspersed ROHC feedback is the most important Control-PDU-side ROHC topic. The feedback is carried as a PDCP Control PDU, submitted without PDCP SN association and without ciphering, then delivered on reception without deciphering.

If you need the field layout behind that behavior, continue into the PDCP format page. This page stays on the procedure meaning rather than duplicating the field map.

ROHC and DAPS Handover

DAPS is worth reading separately because ROHC behavior changes with the source-cell versus target-cell split. The transmit-side compressor selection follows the uplink data-switching point, while the receive side may keep up to two decompressor instances.

ROHC Interaction With EHC

When ROHC and EHC are both configured, the useful PDCP-side rule is short: the ROHC header is located after the EHC header in the PDCP Data PDU. For non-IP Ethernet packets, the EHC compressor or decompressor bypasses the ROHC compressor or decompressor.

This page keeps that interaction compact because the dedicated EHC page is not yet part of the site. For now, treat this section as the boundary note for simultaneous ROHC and EHC configuration.

What This Page Does Not Cover in Detail

References

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

FAQ

What is ROHC in NR PDCP?

ROHC in NR PDCP is the configured header-compression method used for IP traffic in user-plane PDCP entities when enabled by upper layers.

Which NR PDCP entities can use ROHC?

PDCP entities carrying user-plane data can use ROHC, including configured DRB and MRB cases, plus sidelink DRB cases for IP SDUs.

What ROHC profiles are supported?

The supported profile identifiers include no-compression, RTP/UDP/IP, UDP/IP, ESP/IP, IP, and TCP/IP profile identifiers listed in the PDCP specification.

Is the ROHC channel unidirectional?

Yes. The ROHC channel is unidirectional. When rohc is configured there is one channel for downlink and one for uplink, while uplinkOnlyROHC creates only one uplink channel.

Are interspersed ROHC feedback packets ciphered?

No. Interspersed ROHC feedback is sent as a PDCP Control PDU without PDCP SN association and without ciphering, and it is received without deciphering.

How does ROHC behave for DAPS bearers?

For DAPS bearers, ROHC uses source-cell or target-cell configuration depending on the transmission or reception side and the uplink data-switching state.

What happens when ROHC and EHC are both configured?

When ROHC and EHC are both configured, the ROHC header sits after the EHC header in the PDCP Data PDU, and non-IP Ethernet packets bypass the ROHC compressor and decompressor.

Related PDCP Pages