| Internet-Draft | SCONE to 5G Realization | July 2025 |
| Jiang | Expires 4 January 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 application 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 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 4 January 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 & 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 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 SCONE packet as it transits the network element.¶
The 3GPP has defined the 5G architecture as in [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]¶
On the signalling path, a 3rd-party App Server (AS) may engage with the Application Function (AF), which 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 'throughput advices' that are applied by on-path network elements, and then transported to the server or AS as shown in the figure. 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-+ :
...........................................
As stated in the 5G Spec. [TS.23.501], 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). 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 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 would be 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, the 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 of 5G.¶
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 is named the service data flows or SDFs in 5G). The application granularity of 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].¶
In summary, when the SCONE is realized in the UPF network element in the 5G system, 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.¶