Static Context Header Compression (schc) E. Ramos Internet-Draft Consultant Intended status: Standards Track M. Dumay Expires: 22 April 2027 Orange Research 19 October 2026 SCHC for 6G draft-ramos-schc-for-6g-00 Abstract TODO Abstract About This Document 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. Status of This Memo 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. Ramos & Dumay Expires 22 April 2027 [Page 1] Internet-Draft SCHC for 6G October 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Option 1: SCHC in the PDCP layer . . . . . . . . . . . . 5 4.2. Option 2: SCHC in the PDU Session . . . . . . . . . . . . 6 4.3. Context Provisioning and Management . . . . . . . . . . . 8 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. PDCP option . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. PDU session option . . . . . . . . . . . . . . . . . . . 9 5.3. Management Procedures . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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. Ramos & Dumay Expires 22 April 2027 [Page 2] Internet-Draft SCHC for 6G October 2026 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. Ramos & Dumay Expires 22 April 2027 [Page 3] Internet-Draft SCHC for 6G October 2026 * 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. 2. Requirements Language 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. 3. Terminology 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. Ramos & Dumay Expires 22 April 2027 [Page 4] Internet-Draft SCHC for 6G October 2026 *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. 4. Architecture 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. 4.1. Option 1: SCHC in the PDCP layer Ramos & Dumay Expires 22 April 2027 [Page 5] Internet-Draft SCHC for 6G October 2026 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. +------------------+ Figure 1: Overview of the gNB network stack with SCHC in PDCP 4.2. Option 2: SCHC in the PDU Session Ramos & Dumay Expires 22 April 2027 [Page 6] Internet-Draft SCHC for 6G October 2026 +-------------------+ | 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 | +-------------------+ Figure 2: Overview of the UPF network stack with SCHC in the PDU session Ramos & Dumay Expires 22 April 2027 [Page 7] Internet-Draft SCHC for 6G October 2026 4.3. Context Provisioning and Management 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. Ramos & Dumay Expires 22 April 2027 [Page 8] Internet-Draft SCHC for 6G October 2026 +-------------------------------------+ |6G Core Network | | | | +------+ +-----+ | | | NEF | | AF | | | +---|--+ +--|--+ | | | | | | ---|------|-----|------|-----|-- | | | | | | | +---|--+ +---|--+ +------+ | | | AMF | | SMF | | CMF | | | +------+ +------+ +------+ | | | | | | | +--+ +----+ |N4 | | | | +------+ N6 | +-----+ | |N1 N2| | UPF |-----------------| DN | | | | +------+ | +-----+ | | | | | +--|---------|------|-----------------+ | | | +--|--+ +---|--+ |N3 | UE |--| RAN |---+ +-----+ +------+ Figure 3: Overview of the CMF location in the 6G network 5. Implementation 5.1. PDCP option The device is required to signal support for SCHC, which requires RRC to inform the gNB of the support. 5.2. PDU session option 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. 5.3. Management Procedures TODO: Context creation in the CMF, update, notifications, etc. 6. Security Considerations TODO Security Ramos & Dumay Expires 22 April 2027 [Page 9] Internet-Draft SCHC for 6G October 2026 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . 8.2. Informative References [RFC9391] Ramos, E. and A. Minaburo, "Static Context Header Compression over Narrowband Internet of Things", RFC 9391, DOI 10.17487/RFC9391, April 2023, . Acknowledgments TODO acknowledge. Authors' Addresses Edgar Ramos Consultant Email: edgjramos@gmail.com Marion Dumay Orange Research Email: marion.dumay@orange.com Ramos & Dumay Expires 22 April 2027 [Page 10]