top of page

5G NR PDCP & SDAP Layers

  • Writer: Venkateshu Kamarthi
    Venkateshu Kamarthi
  • 15 hours ago
  • 10 min read

1. Introduction

5G NR fundamentally redesigned the user-plane architecture by introducing SDAP (Service Data Adaptation Protocol) above PDCP (Packet Data Convergence Protocol).

  • LTE used a bearer-based QoS model.

  • 5G uses a flow-based QoS model.

This single architectural shift explains:

  • Why SDAP was introduced

  • Why PDCP evolved

  • Why 5G scales better than LTE

  • How URLLC, slicing, and dual connectivity are supported

This article provides:

  • Deep architectural explanation

  • LTE vs 5G comparison

  • SDAP + PDCP integration

  • Realistic call flow behavior

  • UE log interpretation perspective

  • Engineering-level insights

 

2. 5G User Plane Architecture

 

 Important:

  • SDAP exists only for user plane

  • Control plane bypasses SDAP

 

LTE vs 5G – Fundamental QoS Model Difference

LTE Model (Bearer-Based)

IP Flow → EPS Bearer → DRB

  • QoS tied to bearer

  • One bearer = One DRB

  • Mapping done in core network

  • No SDAP layer

5G Model (Flow-Based)

IP Flow → QoS Flow (QFI) → SDAP → DRB

  • Multiple QoS flows per DRB

  • Flexible mapping

  • Per-packet QoS identity

  • Scalable architecture

 

3. SDAP layer in 5G

In 5G:

Multiple QoS Flows  →  One DRB,

Because DRBs are expensive. Every DRB requires:

  • Separate PDCP entity

  • Separate RLC entity

  • Separate buffer management

  • Separate reordering window

  • Separate security context

  • Separate scheduling context

If each application flow had its own DRB:

  • UE memory usage increases

  • gNB context load increases

  • RRC signaling increases

  • Mobility becomes complex

  • Power consumption increases

For example, User is:

  • On VoNR call (5QI 1 – low latency)

  • Watching YouTube (5QI 9 – high throughput)

  • WhatsApp syncing in background (best effort)

These are three QoS flows.

But do we really need 3 DRBs? Not necessarily. If radio conditions are stable, scheduler can prioritize per packet.

Instead of:

  • 3 DRBs

  • 3 PDCP entities

  • 3 RLC buffers

We use:

  • 1 DRB

  • 3 QoS flows inside it

 

 

SDAP tags each packet with QFI. Scheduler applies priority based on QFI.

This reduces:

  • Control overhead

  • Memory usage

  • DRB setup delay

 

But once traffic reaches PDCP/RLC/MAC, those layers only know: DRB ID

They do NOT know:

  • 5QI

  • Packet delay budget

  • Priority

  • QoS flow ID

Therefore, SDAP inserts a lightweight header containing QFI, so the receiving side can:

  • Restore flow identity

  • Apply correct QoS handling

  • Maintain reflective QoS logic

 

LTE limitations:

  • Each QoS required new bearer

  • High signaling overhead

  • Limited flexibility

  • No slicing-native support

5G required:

  • Network slicing

  • URLLC reliability

  • Multi-flow applications

  • Edge computing

  • Massive IoT scaling

Thus, SDAP was introduced to:

✔ Decouple QoS from bearer✔ Allow multiple QoS flows per DRB✔ Reduce DRB count✔ Improve scalability

 

3.1 Core Responsibility

SDAP exists to preserve QoS Flow identity (QFI) across the radio interface.Since multiple QoS Flows can share the same DRB in 5G, the network must carry per-packet QoS identity over the air.

That identity is transported using the SDAP header.

SDAP maps: QoS Flow (QFI) → DRB

QoS Flow Identified By:

  • QFI (QoS Flow Identifier)

  • Associated with:

    • 5QI

    • Packet delay budget

    • Packet error rate

    • Priority

 

3.2 SDAP Header

Header presence is configurable via RRC. It is NOT always present.

SDAP header may include:

  • QFI (6 bits)

  • RQI (Reflective QoS Indicator)

 


Inserted on:

  • Uplink (if required)

  • Downlink (as configured)

 

QFI (QoS Flow Identifier – 6 Bits)

QFI uniquely identifies a QoS flow within a PDU session.

  • Length: 6 bits

  • Value range: 0–63

  • Assigned by 5G Core (SMF)

Each QFI corresponds to a QoS profile (5QI, delay budget, priority, etc.).

Why 6 Bits?

6 bits allow:

2^6 = 64 QoS flows per PDU session

This supports complex enterprise and slicing use cases.

 

Practical Example

Suppose:

QFI

Service Type

5QI

1

VoNR

1

5

Video

9

9

Background sync

9

When UE sends VoNR packet, SDAP inserts:

QFI = 1

When receiving side decodes SDAP header, it knows:

→ Apply QoS Flow 1 policy.

 

3.3 RQI (Reflective QoS Indicator – 1 Bit)

RQI tells the UE whether to apply Reflective QoS.

It is mainly relevant in downlink.

If: RQI = 1

It means: UE should learn this QFI mapping and mirror it in uplink.

If: RQI = 0

Reflective QoS not triggered.

  • UE learns QFI from downlink. Applies same QFI for uplink packets.

  • LTE did not support reflective QoS.

 

Uplink SDAP Header Insertion

Inserted When:

  • Multiple QoS flows share same DRB

  • RRC config mandates UL header presence

  • Reflective QoS active

  • DRB is default DRB carrying multiple flows

If only one QFI mapped to DRB:

→ Header may be omitted (to reduce overhead).

 

Uplink Flow Example

  1. Application generates IP packet

  2. SDAP identifies QFI

  3. SDAP checks RRC config

If header required:

Insert SDAP header:QFI = 5

Packet forwarded to PDCP.

 

UE Log Example

[SDAP][UL]Detected QFI=5Mapped to DRB1SDAP Header Inserted

 

Downlink SDAP Header Insertion

Configured by gNB via RRC:

sdap-HeaderDL = present / absent

Inserted When:

  • UE needs to know QFI

  • Reflective QoS enabled

  • Multiple QFIs mapped to DRB

  • Dynamic QoS handling required

If:

  • Only one QoS flow per DRB

  • No reflective QoS

→ gNB may omit header to reduce overhead.

Downlink Example

gNB sends packet:

QFI = 1RQI = 1

UE receives packet and:

  • Reads QFI

  • Applies QoS policy

  • If RQI=1 → updates reflective QoS mapping

 

Why Header May Be Omitted

If:

One DRB → One QFI

Then QFI is already known implicitly.

No need to send per-packet QFI.

This saves 1–2 bytes per packet.

This is important for:

  • URLLC small packets

  • Massive IoT

  • Power efficiency

 

RRC configuration

RRCReconfiguration

→ radioBearerConfig

→ drb-ToAddModList

→ DRB-ToAddMod

DRB-ToAddMod ::= {

drb-Identity,

sdap-Config,

It contains:

  • pdu-Session

  • mappedQoS-FlowsToAdd

  • mappedQoS-FlowsToRelease

  • defaultDRB

  • reflectiveQoS

  • ul-DataSplitThreshold (if applicable)

pdcp-Config,rlc-Config,...}

 

4. PDCP Layer in 5G

 

The Packet Data Convergence Protocol (PDCP) layer is part of the 5G NR protocol stack located between SDAP/RRC and the RLC layer. It provides critical services such as security, reliability, packet ordering, header compression, and mobility support.

PDCP operates for both:

  • Control Plane traffic (SRBs) – signaling messages like RRC

  • User Plane traffic (DRBs) – application data like VoNR, video, internet traffic

 

It acts as the service protection layer, ensuring that:

  • packets are secure,

  • delivered in order,

  • compressed efficiently,

  • and maintained across mobility events.

For control plane traffic, PDCP guarantees secure and reliable signaling.For user plane traffic, it ensures efficient, secure, and continuous data delivery across the 5G network.

 

 

PDCP provides:

  1. Sequence numbering

  2. Reordering

  3. Ciphering

  4. Integrity protection

  5. Header compression (ROHC)

  6. Duplication

  7. Handover forwarding

 

Each of these functions contributes to reliable, secure, and efficient data transfer over the 5G radio interface.

 

4.1. PDCP Sequence Numbering

PDCP SN Is Required to In-Order Delivery to Upper Layers

Wireless links cause:

  • Out-of-order packet arrival

  • Variable delay

  • Retransmissions

  • Duplication

Example:

Packets transmitted:

SN 100

SN 101

SN 102

Due to retransmissions, received as:

SN 100

SN 102

SN 101

PDCP reorders before delivering to IP layer.

Without PDCP SN:

  • TCP misinterprets reordering as congestion

  • Throughput collapses

  • VoNR jitter increases

 

5G supports:

  • 12-bit SN

  • 18-bit SN

Why 18-bit?

For high throughput (>10 Gbps), larger reordering window required.

Window size = 2^(SN-1)

18-bit SN → window size 131072

SN Used for:

  • Ciphering

  • Integrity

  • Replay protection

 

4.2. Ciphering & Integrity

Ciphering provides:

Confidentiality — preventing eavesdropping.

When UE sends data:

Plaintext → Ciphering Algorithm → Ciphertext

Only entities with correct key can decrypt.

Ciphering applies to:

  • User Plane (DRBs)

  • Control Plane (SRBs except SRB0)

Integrity ensures:

Data was not modified in transit.

It adds a Message Authentication Code (MAC-I) computed over:

COUNT + BEARER + DIRECTION + MESSAGE + KEY

Receiver recomputes and verifies.

  • Integrity is mandatory for:Control Plane

  • Optional for: User Plane (depending on configuration)

 

Ciphering algorithms:

  • NEA1 (SNOW3G)

  • NEA2 (AES)

  • NEA3 (ZUC)

Integrity algorithms:

  • NIA1

  • NIA2

  • NIA3

 

Why AES (NEA2/NIA2) Is Most Common

Because:

  • Hardware acceleration available

  • Well-studied cryptography

  • Strong industry support

  • Efficient at high throughput

SNOW3G and ZUC often used in specific markets.

 

User Plane

  • Ciphering mandatory

  • Integrity optional

Control Plane

  • Ciphering mandatory

  • Integrity mandatory

Why?

Control plane contains:

  • Security keys

  • Mobility commands

  • Configuration data

 

4.3. Header Compression (ROHC)

Header compression in 5G NR is performed at the PDCP layer using ROHC (Robust Header Compression).

ROHC exploits the fact that:

  • IP addresses do not change during a session

  • UDP ports remain constant

  • RTP fields change predictably (sequence number increments by 1)

Instead of transmitting full headers every time:

ROHC sends:

Context + small delta

After context is established, header can compress to:

2–4 bytes

Compression happens before:

  • Ciphering

  • Sequence numbering

So compressed header is also encrypted.

 

Example Compression Flow

Step 1: First Packet (Full Header)

IP Src: 10.0.0.1

IP Dst: 10.0.0.5

UDP Src Port: 5000

UDP Dst Port: 5004

RTP Seq: 1000

Full header transmitted.

Receiver builds compression context.

 

Step 2: Next Packet

RTP Seq becomes 1001.

Instead of sending full 40 bytes:

ROHC sends:

Compressed header = 3 bytes

Receiver reconstructs full header using stored context.

IP header = 40 bytesCompressed = 2–4 bytes

Critical for:

  • VoNR

  • Small payload traffic

  • Spectral efficiency

 

Real-World Example Calculation

Assume:

1000 UEs on VoNREach sending 50 packets per secondPacket size 60 bytes without ROHC

Total data:

1000 × 50 × 60 = 3,000,000 bytes/sec

With ROHC reducing header from 40 → 4 bytes:

New packet size:

4 + 20 = 24 bytes

New total:

1000 × 50 × 24 = 1,200,000 bytes/sec

60% reduction in air usage.

Massive improvement.

 

4.4. PDCP Reordering & Loss Handling

If packets arrive out of order:

SN10SN12SN11

PDCP:

  • Buffers SN12

  • Waits for SN11

  • Uses reordering timer

Without this:

  • TCP congestion collapse

  • VoNR jitter

  • Throughput degradation

 

4.5. PDCP Duplication (5G Enhancement)

PDCP duplication is one of the most important reliability enhancements introduced in 5G NR. It enables ultra-high reliability and low latency by transmitting the same PDCP PDU over multiple radio legs.

Duplication is performed at PDCP layer before RLC segmentation.

Both copies travel independently.

The receiver:

  • Accepts the first correctly received copy

  • Discards later duplicates 

 


 

Used for:

  • URLLC

  • Dual connectivity

  • High reliability 

Same PDCP PDU sent over:

  • MCG leg

  • SCG leg

First arrival accepted.Duplicate discarded.

LTE did not support this. 

Duplication is configured via RRC:

pdcp-Config:   pdcp-Duplication = enabled

Can be activated or deactivated dynamically.

Not all DRBs use duplication.

Typically applied to:

  • GBR flows

  • URLLC flows

  • High-priority slices 

RRCReconfiguration

→ radioBearerConfig

→ drb-ToAddModList

→ DRB-ToAddMod 

DRB-ToAddMod ::= {

drb-Identity,

sdap-Config,

pdcp-Config,

pdcp-Config ::= {

sn-SizeUL,

sn-SizeDL,

discardTimer,

t-Reordering,

headerCompression,

integrityProtection,

pdcp-Duplication = enabled...} 

rlc-Config,...}

How Receiver Removes Duplicates

Each duplicated packet carries the same SN.

Example:

Sender: SN = 1050,

Sent via MCG

Sent via SCG

Receiver behavior:

  1. First arrival:

    • SN=1050 not seen before

    • Deliver to upper layer

    • Mark SN=1050 as received

  2. Second arrival:

    • SN=1050 already delivered

    • Discard duplicate 

If both legs fail:

  • Packet considered lost

  • Reordering timer may expire

  • Upper layer handles loss (e.g., TCP retransmission)

Duplication reduces probability but does not eliminate loss entirely.

 

5. SDAP + PDCP Integration – End-to-End Flow

Scenario

UE has:

  • VoNR (QFI=1)

  • Video (QFI=5)

  • Sync (QFI=9)

All mapped to DRB1. 

5.1. DOWNLINK FLOW (gNB Perspective)

Direction: UPF → gNB → UE

 


1.      GTP-U Packet Received from UPF

UPF sends GTP-U packet over N3 interface.

Packet includes:

TEID (tunnel ID)

QFI (in GTP extension header)

gNB extracts:

PDU session ID

QFI

UE context 

2.      SDAP Processing (DL)

gNB SDAP checks QFI.

Uses RRC-configured mapping:

QFI → DRB

Selects appropriate DRB (e.g., DRB1).

If multiple QFIs share DRB:

Header insertion required. 

3.      SDAP Header Insertion (If Configured)

If sdap-HeaderDL = present:

SDAP inserts:

QFI (6 bits)

RQI (if reflective QoS enabled)

If single QFI per DRB:

Header may be omitted. 

4.      PDCP Processing (DL)

PDCP entity for selected DRB performs:

ROHC Compression (if enabled)

Compress IP/UDP/RTP headers.

Must occur before ciphering.

SN Assignment

Assign next PDCP Sequence Number.

Update COUNT:

COUNT is the full extended sequence number used for:

  • Ciphering

  • Integrity protection

  • Replay protection

COUNT = (HFN << SN_length) | SN

Where, HFN(Hyper Frame Number) is: A counter that increments every time SN wraps around.

Think of it as:

HFN = number of SN cycles completed

Example (12-bit SN):

  • SN goes 0 → 4095

  • SN wraps to 0

  • HFN increments by 1

Example, Assume:

  • SN = 10

  • HFN = 3

  • SN length = 12 bits

Then:

COUNT = (3 << 12) + 10       = (3 × 4096) + 10       = 12288 + 10       = 12298      

Ciphering

Encrypt payload using NEA algorithm.

Integrity Protection (if enabled)

Append MAC-I. 

5.      PDCP Duplication (If Enabled)

If duplication active:

Same PDCP PDU sent to:

MCG RLC

SCG RLC

Otherwise: Sent to single RLC entity. 

6.      RLC Processing

Depending on configuration:

AM mode → segmentation + retransmission control

UM mode → segmentation only

RLC produces RLC PDUs. 

7.      MAC Processing

Scheduler allocates PRBs.

Prioritization may consider:

  • DRB priority

  • Logical channel priority

  • QoS information

  • HARQ processes assigned. 

8.      PHY Transmission

Data modulated and transmitted over air.

 

5.2. UPLINK FLOW

Direction: UE → gNB → UPF

 


1.      PHY Reception

gNB receives PUSCH.

Demodulates and decodes transport block. 

2.      MAC Processing

HARQ combining (if needed).

Extract RLC PDUs.

Forward to RLC. 

3.      RLC Reassembly

Reassemble PDCP PDU from RLC segments.

Handle retransmissions (AM mode).

Deliver complete PDCP PDU upward. 

4.      PDCP Processing (UL)

Duplicate Detection (if duplication enabled)

Check PDCP SN.

If already received → discard.

If new → continue.

Deciphering

Use COUNT derived from SN.

Apply NEA algorithm.

Integrity Verification (if enabled)

Verify MAC-I.

If failure → discard.

Reordering

Ensure in-sequence delivery.

Buffer out-of-order packets.

Use reordering timer.

ROHC Decompression

Reconstruct original IP/UDP/RTP headers. 

5.      SDAP Processing (UL)

Extract QFI from SDAP header (if present).

Use QFI to:

Identify QoS Flow

Apply policy

Forward to correct GTP tunnel

If header absent:

QFI inferred from DRB mapping. 

6.      GTP-U Encapsulation

gNB encapsulates packet into GTP-U.

Inserts QFI in extension header.

Uses correct TEID for PDU session. 

7.      Forward to UPF (N3 Interface)

Packet transmitted over N3 toward UPF.

 

6. Realistic UE Log Interpretation

SDAP Log

[SDAP]

[UL]QFI=1 mapped to DRB1

ReflectiveQoS=Enabled

PDCP Log

[PDCP]

[DRB1]

[TX]SN=2048

HFN=2

COUNT=53248

Cipher=NEA2

ROHC=Enabled

Duplication=OFF

Reordering Case

[PDCP]

[RX]

Received SN=105

Expected=104

Buffering

ReorderingTimer=Start 

7. LTE vs 5G Summary Table

Feature

LTE

5G SDAP

QoS Unit

EPS Bearer

QoS Flow

Mapping Layer

NAS + Bearer setup

SDAP

Multiple QoS per DRB

No

Yes

Duplication

No

Yes

18-bit SN

No

Yes

Reflective QoS

No

Yes

Slice Native

No

Yes

 

Feature

LTE PDCP

5G PDCP Enhancement

Architecture

eNB centralized

CU/DU split

SN Size

up to 12 bits

up to 18 bits

QoS Mapping

EPS bearer

QoS Flow (via SDAP)

Multi-connectivity

Limited

Native

Packet Duplication

No

Yes

Split Bearers

Limited

Advanced

Mobility

Basic HO

Multi-node mobility

Throughput

up to ~1 Gbps

>20 Gbps

Security

LTE algorithms

Enhanced 5G security

Reordering

Single path

Multi-path aware

 8.Control Plane vs User Plane Processing

Feature

User Plane

Control Plane

SDAP

Yes

No

Ciphering

Yes

Yes

Integrity

Optional

Mandatory

ROHC

Yes

No

Duplication

Yes

Rare

 

9. Conclusion

5G separation of:

QoS intelligence (SDAP)Security & reliability (PDCP)

Enables:

  • Network slicing

  • Edge computing

  • Cloud RAN

  • AI-based scheduling

  • 6G extensibility

LTE tightly coupled QoS with bearer.5G decouples control from transport.

This is a scalable abstraction model. 

SDAP Provides

✔ Flexible QoS mapping

✔ Reduced DRB count

✔ Reflective QoS

✔ Slice compatibility

PDCP Provides

✔ Security

✔ Reliability

✔ Mobility continuity

✔ Duplication for URLLC

✔ High throughput scaling

Together they form:

The intelligence core of the 5G user plane.

 

10.References

1. 3GPP TS 38.323 – NR Packet Data Convergence Protocol (PDCP) Specificationhttps://www.3gpp.org/dynareport/38323.htm

2. 3GPP TS 37.324 – Service Data Adaptation Protocol (SDAP) Specificationhttps://www.3gpp.org/dynareport/37324.htm

3. RFC 3095 – Robust Header Compression (ROHC), https://www.rfc-editor.org/rfc/rfc4815.html

4. 3GPP TS 33.501 – Security Architecture and Procedures for 5G Systemhttps://www.3gpp.org/dynareport/33501.htm

5. 3GPP TS 37.340 – Multi-Radio Dual Connectivity (MR-DC) Architecturehttps://www.3gpp.org/dynareport/37340.htm

6. 3GPP TS 38.300 – NR Overall Description (URLLC Enhancements)https://www.3gpp.org/dynareport/38300.htm

 

 

 

 

Comments


 

bottom of page