| Internet-Draft | SCHC for 6G | October 2026 |
| Ramos & Dumay | Expires 22 April 2027 | [Page] |
TODO Abstract¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ramos-schc-for-6g/.¶
Discussion of this document takes place on the schc Working Group mailing list (mailto:schc@ietf.org), which is archived at https://example.com/WG. Subscribe at https://www.ietf.org/mailman/listinfo/schc/.¶
Source for this draft and an issue tracker can be found at https://github.com/mdumay/schcfor6g.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In the 6G timeframe, the number and heterogeneity of devices per cell are expected to be higher than in 5G, and many verticals will require cost effective, energy efficient, long-lived connectivity integrated into the 6G framework.¶
6G is expected to contribute to sustainability and spectrum efficiency targets. Key challenges therefore include minimizing radio resource usage per message, improving spectrum efficiency and cell capacity, and enhancing device side energy efficiency.¶
Header compression is a critical component of the radio access network (RAN) protocol stack. In current 3GPP systems (LTE and NR), Robust Header Compression (RoHC) [RFC 3095, RFC 5795] is integrated at the Packet Data Convergence Protocol (PDCP) layer [TS 36.323, TS 38.323] to reduce the overhead introduced by IP and transport layer headers over the radio segment. This document examines the shortcomings of RoHC considering 6G requirements and proposes that RAN2 initiate a study to evaluate the need for complementary or enhanced header compression mechanisms.¶
RoHC has been a successful header compression mechanism for LTE and NR, providing significant benefits for simple, regular header patterns and long-lived, continuous traffic flows. However, emerging 6G requirements present scenarios where RoHC limitations become critical:¶
context initialization overhead is not suitable for certain applications (mobile, high-speed scenarios) and over lossy, constrained links;¶
energy efficiency targets require optimization beyond RoHC's current design;¶
diverse traffic patterns and hetereogeneous/complex headers challenge RoHC's context model;¶
non-terrestrial networks require compression mechanisms suitable for high-latency, asymmetric links.¶
While RoHC will likely remain suitable for many 6G scenarios, complementary or enhanced mechanisms are needed to address identified gaps.¶
Static Context Header Compression (SCHC) [RFC 8724] provides a generic compression/decompression and fragmentation framework for headers. Its characteristics make it a strong candidate for integration into the 6G design :¶
Static context: compression rules are pre provisioned and synchronized at both ends; there is no dynamic learning phase.¶
Field by field compression: simple matching and transformation actions are applied per header field.¶
Generic compression/decompression using simple actions: adaptability and high degree of configurability for different scenarios/protocols.¶
Multi layer capability: multiple protocol layers (e.g. IP/UDP/CoAP, IP/UDP/MQTT) can be compressed together or separately.¶
Independent compression: compression of a packet does not depend on previous packets.¶
Effectiveness from the first packet: full compression is available immediately, assuming an appropriate static context exists.¶
Robustness to packet loss: no error propagation tied to missing packets, since there is no dynamic context evolution.¶
This document provides two architectural approaches for integrating the SCHC compression/decompression mechanism into the 6G system architecture (fragmentation is out of scope) and one approach for context provisioning and management.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
These terms originate from 5G architecture and refer to equivalent functions in 6G architecture.¶
UE (User Equipment): A device used by an end user to communicate over a mobile network. Examples include a smartphone, sensor, or other connected device.¶
gNB (next-generation Node B): Base station that provides radio access between a UE and the 6G Core.¶
UPF (User Plane Function): A 6G Core function that handles user-plane traffic, including forwarding packets between the UE and a Data Network.¶
PDU (Protocol Data Unit): A unit of data exchanged between protocol entities at a given protocol layer. In 6G, a PDU Session provides connectivity between a UE and a Data Network.¶
RAN (Radio Access Network): The part of a mobile network that provides radio connectivity between UE and the core network.¶
PDCP layer (Packet Data Convergence Protocol layer): A layer in the 3GPP radio protocol stack that provides functions such as header compression, ciphering, and packet reordering.¶
Data Network (DN): A network that provides services or connectivity to a UE and is reachable through the 6G Core, typically via a UPF. Examples include the Internet, an operator's service network, or a third-party network.¶
Introducing SCHC to mobile cellular networks can be implemented in two possible ways. The first follows the same implementation as RoHC where the implementation is in the PDCP (Packet Data Convergence Protocol) layer which resides in the base station (gNB or equivalent 6G RAN node). The second option is to integrate SCHC within the Protocol Data Unit (PDU) session tunnel which is implemented in the User Plane Function (UPF) node, making SCHC transparent to the RAN.¶
The main difference between both approaches is the location of the SCHC compressor/decompressor. In the first approach, it is implemented in what is called the radio access network (RAN), which means that SCHC is implemented in every base station and that the active base station serving a given UE has to know the appropriate context. This must be taken into account during a handover (the transfer of an ongoing communication session from one cell or access point to another). In the second approach, the SCHC compressor/decompressor is located in what is called the core network, more specifically in the UPF nodes (or subfuction). This approach natively supports mobility.¶
In both cases, the compression/decompression process applies to the same portion of the protocol stack, i.e., to the same headers. Performance on the radio link is therefore identical. The second option has the advantage of extending compression into the core network all the way to the UPF.¶
gNB (Base Station) +------------------+ | User Plane | +------------------+ | SDAP | SDAP: QoS Flow mapping for 6G services. +-----------+------+ | PDCP | SCHC | PDCP: Header compression, security, packet reordering. +-----------+------+ | RLC | RLC: Segmentation, retransmissions. +------------------+ | MAC | MAC: Scheduling, multiplexing, HARQ. +------------------+ | PHY | PHY: Modulation, coding, MIMO, beamforming, OFDM. +------------------+
+-------------------+
| Data Network |
| (Internet/App) |
+---------+---------+
|
| N6 N6: Interface from UPF to external
| data networks
|
+--------------------------------------------------+
| UPF (5G Core) |
| |
| +---------------------------------------------+ |
| | Packet Processing | |
| | - PDU Session Handling | |
| | - QoS Enforcement | |
| | - Traffic Steering | |
| | - Usage Reporting | |
| | - SCHC header compression/decompression | |
| +---------------------------------------------+ |
| |
| +--------------------------------------------+ | GTP-U: Encapsulation
| | GTP-U | | of user packets
| +--------------------------------------------+ | in the 6G core
| | UDP | |
| +--------------------------------------------+ |
| | IP | |
| +--------------------------------------------+ |
| | Ethernet | |
| +--------------------------------------------+ |
+--------------------------------------------------+
|
N3 N3: User-plane tunnel between gNB and UPF
| using GTP-U.
+---------+---------+
| gNB |
+---------+---------+
|
NR Air
|
+---------+---------+
| UE |
+-------------------+
The SCHC context must be known both at the compressor and the decompressor side, and must remain synchronized between the two ends of the communication at all times.¶
A set of management functionalities is necessary for the system to function and could be provided by a new network function or entity: the Context Management Function (CMF).¶
The CMF provides the following functionalities:¶
Storage and management of contexts (creation, update, deletion);¶
Lookup and distribution of associated contexts (e.g., to the gNB or UPF);¶
Optional versioning and synchronization mechanisms.¶
The CMF can be requested through standard service-based interfaces, for example for external service providers in order to provision and update contexts, and for in-network distribution (to install a specific context on the compressor/decompressor in the network). A publish/subscribe interface allows for entities to subscribes for context changes through notifications.¶
SCHC contexts may be pre-provisioned on UEs in order to prevent the context from being sent over the radio channel. The contexts may be identified in the CMF using identifiers known be UEs, so they can use them to specify the context they want to use when enabling SCHC for a given communication.¶
+-------------------------------------+ |6G Core Network | | | | +------+ +-----+ | | | NEF | | AF | | | +---|--+ +--|--+ | | | | | | ---|------|-----|------|-----|-- | | | | | | | +---|--+ +---|--+ +------+ | | | AMF | | SMF | | CMF | | | +------+ +------+ +------+ | | | | | | | +--+ +----+ |N4 | | | | +------+ N6 | +-----+ | |N1 N2| | UPF |-----------------| DN | | | | +------+ | +-----+ | | | | | +--|---------|------|-----------------+ | | | +--|--+ +---|--+ |N3 | UE |--| RAN |---+ +-----+ +------+
The device is required to signal support for SCHC, which requires RRC to inform the gNB of the support.¶
In the PDU session establishment request, the UE can signal support for Static Context Header Compression, and provide the possible parameters to enable the compression.¶
TODO: Context creation in the CMF, update, notifications, etc.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶