]> Consultant

edgjramos@gmail.com

Orange Research

marion.dumay@orange.com

Internet Static Context Header Compression (schc) 6G architecture implementation TODO Abstract About This Document Status information for this document may be found at . Discussion of this document takes place on the schc Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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. 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.

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 when, and only when, they appear in all capitals, as shown here.

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. 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.

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.

Option 1: SCHC in the PDCP layer

Overview of the gNB network stack with SCHC in PDCP

Option 2: SCHC in the PDU Session

Overview of the UPF network stack with SCHC in the PDU session

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.

Overview of the CMF location in the 6G network

Implementation

PDCP option The device is required to signal support for SCHC, which requires RRC to inform the gNB of the support.

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.

Management Procedures TODO: Context creation in the CMF, update, notifications, etc.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT). This document has two parts: one normative part that specifies the use of SCHC over NB-IoT and one informational part that recommends some values if 3GPP wants to use SCHC inside their architectures.

Acknowledgments TODO acknowledge.