| Internet-Draft | SCONE applicability & Realization of 5G | September 2025 |
| Jiang & Tsou | Expires 20 March 2026 | [Page] |
The SCONE protocol provides a scheme for network elements (NEs) to signal the maximally possible throughput limits to end devices, i.e., the flow senders with the assistance from the corresponding flow receivers, for UDP flows transitting thru the NEs. This kind of 'throughput advice' is applied on the per-(UDP)-flow basis. While the advice signaling scheme from NEs inside the traditional public IP network might be challenging, the applicability of the SCONE scheme to the 5G scenario can be more streamlined and practical. This draft discusses from many perspectives how the SCONE can be applied to and realized in the 5G scenario, along with additional advantages that a 5G system might provide to the SCONE.¶
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 20 March 2026.¶
Copyright (c) 2025 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.¶
The SCONE protocol provides a scheme for network elements (NEs) to signal to the end devices the maximum available sustained throughput, or rate limits, for flows of UDP datagrams that transit thru the NEs [IETF-Draft-SCONE-Protocol]. The ultimately targetted end device is actually the flow sender which gets the advice with the assistance from the corresponding flow receiver. This kind of 'throughput advice' is applied on the per-(UDP)-flow basis and the (pre-specified) rate limits are configured on on-path NEs. A SCONE signal is associated with and sent for a specific flow, i.e., targeting at achieving the policy control in the scope of the single-flow granularity.¶
SCONE related policies are provisioned at on-path network elements (NEs). A NE that has rate limiting policies configured can detect flows including SCONE packets. Once detection, the NE may indicate a maximum sustained throughput by modifying the header of a SCONE packet as it transits the network element.¶
The 3GPP SDO has defined the 5G architecture [TS.23.501]. A 5G system or 5GS is fundamentally comprised of three sections, i.e., the terminal equipment or TE, the radio access network or RAN, and the (wireless) core network or CN. Every section of the 5GS is comprised of functionalities from both the control plane (CP) and the user plane (UP).¶
As shown in the Figure 1, a 5G system (5GS) is comprised of TE, RAN and CN (consisting of many network functions or NFs). While the control plane or CP includes mainly the NFs like AMF, SMF, PCF, NEF, UDM, and more (not shown in the figure), the user plane or UP revolves around the network function named User Plane Function or UPF. The CP and UP along with all the NFs communicate with each other via various kinds of reference interfaces, e.g., N3, N4, N6, etc. [TS.23.501]¶
Regarding the signalling process, a 3rd-party Application Server (AS) may engage with the Application Function (AF) that can transmit the AS-provided control logics to the 5GS (possibly via NEF). Note that in the context of SCONE, these 'logics' can be the policies related to 'throughput advices' that are applied by on-path network elements. On the data path, a UPF (or I-UPF) behaves like a network element, which, upon the provision of SCONE logics, can detect SCONE packets and apply the 'throughput advice' by marking the SCONE bits in the QUIC datagram header. The UPF is connected to the external data network via the N6 interface. Data packets are sent from the TE to the data network (or DN) (via the RAN & UPF) in the uplink (UL) direction, and received by the TE (via the UPF & RAN) from the data network (or DN) in the downlink (DL) direction.¶
..........................................
: +-----+ +-----+ : +-------+
: | UDM | | NEF |------| AF/AS |
: +-----+ +-----+ : +-------+
: / \ | :
: N8 N10 | :
: +-----+ +------+ +-----+ :
: | AMF |-N11-| SMF |----| PCF | :
: +-----+ +------+ +-----+ :
: / | | :
: N1 N2 N4 :
: / | | :
+--------+ : / | +-------+ :
| Term. | + +--------+ N3 | UPF/ | N6 (UP) : +--------+
| Eq (TE)|--:--| (R)AN |--------| I-UPF |------------:--| Data |
+--------+ + +--------+ +-------+ : | Network|
: | | : +--------+
: +-N9-+ :
...........................................
In a 5G system, data packets as initiated by TEs or received from external DNs (off the N6 interface) are transmitted via a packet data unit (or PDU) session. In 5G, a PDU session is a logic connection established between a terminal equipment (TE or UE) and the data network (DN) via the RAN (i.e., gNB in 5G) and (one or more) UPFs. This connection provides the user plane connectivity to facilitate the UP data transfer. A PDU session involves many signalling procedures like establishment, update/modification, release, etc.[TS.23.502].¶
The Figure 2 shows the framework of a 5G PDU session. The PDU session is between the TE and the (anchor) UPF (with potential I-UPF in existence). Data packets are transmitted in either UL or DL direction. Also shown in the figure, multiple QoS flows may be provisioned in a PDU session, with each QoS flow possibly corresponding to an IP flow that can be identified and classified via SDF filter(s) [TS.23.501]. When a data packet, belonging to a QoS flow, is transmitted thru the UPF, the UPF would be able to, either staticly or dynamically, apply various pre-provisioined policies. The filters can be used to match the bit settings of the SCONE packet header as defined in [IETF-Draft-SCONE-Protocol], and the policies may provide the 'throughput advices' associated with SCONE.¶
|<-- PDU session w/ multi. QoS flows -->|
/.................................\
/ \
/ (PDR/QER/FAR) \
/ +-------+ \
: +--+ +------+ N3 | UPF/ | : +--------+
:-|TE|----|(R)AN |-------| I-UPF |-----(N6)---| Data |
: +--+ +------+ +-------+ : | Network|
\ ^ ^ / +--------+
\ \ / /
\ \<-multi. QoS flows->/ /
\................................./
Note that both the CP and the UP of a PDU session, along with those QoS flows inside the PDU session, are under the full-control of the corresponding mobile network operator (or MNO). All the control logics, including the SCONE-related ones, can be provided, provisioned and then enforced without much challenge. When compared to the public Internet that spans across multiple (administratively-independent) network domains, the applicability and realization of SCONE in the 5G scenario can be much more streamlined and practical.¶
The SCONE draft [IETF-Draft-SCONE-Protocol], Section# 7.1 states a network element requires logics to detect a SCONE packet by observing that the packet has a QUIC long header and one of the SCONE protocol versions. After the detection, the network element may conditionally replaces the Rate Signal field with values of the choosing at the network element. Here, there are two main requirements at a network element (or NE):¶
As elucidated previously, the 5G network function UPF behaves like a network element, which does indeed have all the logics to fulfill these two main requirements. As specified in the 5G architecture Spec. [TS.23.501], a UPF handles in-transit traffic, for both UL and DL directions, via the applications of the packet detection rule (PDR), qos enforcement rule (QER), forward action rule (FAR), along with other auxiliary rules. A PDR can accommodate advanced traffic identification and classification logics, e.g., IP-filters (applicable to SCONE UDP/QUIC datagram). Based on the PDR's results, the QER and FAR are enforced at the UPF to set in detected SCONE packet headers the 'throughput advices' that have been provisioned according to SCONE policies. The Figure 2 shows that the PDR, QER and FAR are applied at the UPF (and/or I-UPF).¶
Because of lacking the full-dynamic provisioning capabilities at the traditional network elements in the IP network, both the SCONE-related traffic filters and setting values (i.e., throughput advices) require in-advance configurations. This does post the challenges to achieve the desired flexibility at a SCONE-capable IP network element.¶
In comparison, a 5G UPF owns the necessary flexibilities to achieve the dynamic provisioning and the on-demand throughput value settings for detected SCONE packets.¶
Various functionalities, e.g., AAA, signaling exchange, etc., can be supported thru the coordination between the 5G mobile operator (or MNO) and the public network service provider. This coordindation might be based on the assumption of the existence of a pre-determined business agreement between the two parties to support the provisioning of SCONE logics.¶
The SCONE targets at flows of UDP datagrams (over the QUIC connection). While the per-flow traffic detection and value settings might be a challenge in the public IP network, this can be certainly accommodated by the IP PDU session in 5GS.¶
As shown in the 5G Spec. [TS.23.501], the per-flow provisioning & application granularity can be achieved based on the characteristics of PDU sessions. Please reference to the Figure 2. QoS flows in a PDU session reflect the nature of IP flows (which corresponds to the service data flows or SDFs in 5G). The granularity of applying the PDR, QER and FAR is of a QoS flow. So, the SCONE-related throughput advice can be achieved with the per-flow granularity by the UPF. This conforms to or even enhances what SCONE is targeting for.¶
In the SCONE IETF draft [IETF-Draft-SCONE-Protocol], the Section# 3.4 states that 'an endpoint might need to communicate the value it receives to its peer in order to ensure that the limit is respected". However, the same document does not define how that signaling occurs as it is specific to the application in use.¶
While it might be more challenging to achieve the objective on the normal public IP network, fortunately, the 5G system does indeed have the effective feedback mechanism for an receiving endpoint to send the received SCONE 'network throughput advice' to the corresponding sending peer. Simply put, a SCONE packet receiver, or AS, can process the packet and send the analytic results (in term of the 'throughput advice') to an application function or AF (see the Figure 1). The AF can then leverage the 5G communication path to transmit the advice to the App sender on the sending end device for the flow [TS.23.501].¶
It is evident that SCONE can be realized symmetrically in both the uplink and the downlink directions.¶
For the uplink or UL direction (i.e., client to server), the App client on TE will signal the SCONE settings in the QUIC datagram header. Upon a UPF receiving the datagram on the N3 (or possibly N9 for I-UPF) interface, how it may process has been extensively described in the draft.¶
As for the downlink or DL direction (i.e., server to client), while the draft has so far been focusing on how the SCONE can be applied on on the UL direction, the realization of SCONE in the 5G scenario is symmetric.¶
In summary, when the SCONE is applied to the 5G scenario and realized in the UPF network element, some additional advantages might be achieved when compared to the network elements in the traditional public network domain:¶
Generally, this function will not incur additional security issues.¶
This document makes no request of IANA.¶