Applicability & Realization of SCONE in 5G Scenario
draft-jiang-scone-realization-5gcase-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tianji Jiang , Tina Tsou (Ting ZOU) | ||
| Last updated | 2025-09-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jiang-scone-realization-5gcase-01
SCONE Working Group T. Jiang
Internet-Draft China Mobile
Intended status: Informational T. Tsou
Expires: 20 March 2026 TikTok
16 September 2025
Applicability & Realization of SCONE in 5G Scenario
draft-jiang-scone-realization-5gcase-01
Abstract
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.
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 20 March 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jiang & Tsou Expires 20 March 2026 [Page 1]
Internet-Draft SCONE applicability & Realization of 5G September 2025
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: SCONE and 5G System . . . . . . . . . . . . . . 2
2. Applicability & Realization of SCONE in 5G Scenario . . . . . 4
2.1. SCONE Packet Processing at UPF . . . . . . . . . . . . . 5
2.2. Achieve Dynamic SCONE Setting & Provisioning . . . . . . 6
2.3. Achieve SCONE Per-flow granularity . . . . . . . . . . . 7
2.4. Effective SCONE Feedback Mechanism in 5G . . . . . . . . 7
2.5. Symmetrical Realization on both Directions: UL and DL . . 7
3. Advantages of SCONE Applicability to 5G . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction: SCONE and 5G System
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.
Jiang & Tsou Expires 20 March 2026 [Page 2]
Internet-Draft SCONE applicability & Realization of 5G September 2025
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.
Jiang & Tsou Expires 20 March 2026 [Page 3]
Internet-Draft SCONE applicability & Realization of 5G September 2025
..........................................
: +-----+ +-----+ : +-------+
: | 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-+ :
...........................................
Figure 1: The 5G System Architecture
2. Applicability & Realization of SCONE in 5G Scenario
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.
Jiang & Tsou Expires 20 March 2026 [Page 4]
Internet-Draft SCONE applicability & Realization of 5G September 2025
|<-- PDU session w/ multi. QoS flows -->|
/.................................\
/ \
/ (PDR/QER/FAR) \
/ +-------+ \
: +--+ +------+ N3 | UPF/ | : +--------+
:-|TE|----|(R)AN |-------| I-UPF |-----(N6)---| Data |
: +--+ +------+ +-------+ : | Network|
\ ^ ^ / +--------+
\ \ / /
\ \<-multi. QoS flows->/ /
\................................./
Figure 2: A 5G PDU session w/ multiple 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.
2.1. SCONE Packet Processing at UPF
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):
* Detection of SCONE traffic: requiring the identification and
classification matching filters to be configured at the NE.
* Application of SCONE policy or 'throughput advice': requiring the
policy to be provisioned and 'advice' to be set in the SCONE
packet header at the 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
Jiang & Tsou Expires 20 March 2026 [Page 5]
Internet-Draft SCONE applicability & Realization of 5G September 2025
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).
2.2. Achieve Dynamic SCONE Setting & Provisioning
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.
* Dynamic provisioning: The explanation is based on the Figure 1.
The SCONE traffic fitlers and policy settings can be provisioned
by a third-party AS, either statically-defined or dynamically-
generated at the AS. These SCONE related information, e.g.,
identification, classification, marking, etc., is transmitted via
an AF (application function) to the 5GS. The path would be
AF->(NEF)->PCF->SMF, and then to UPF. Further, the AS-supplied
policies can also be provided to end devices registered to the 5G
network. This is a fully dynamic signalling process.
* On-demand throughput value/advice settings: Once a UPF receives
the updated PDRs, QERs and FARs, etc., [TS.23.501], it can apply
the new throughput advice and value settings to the detected SCONE
packets dynamically.
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.
Jiang & Tsou Expires 20 March 2026 [Page 6]
Internet-Draft SCONE applicability & Realization of 5G September 2025
2.3. Achieve SCONE Per-flow granularity
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.
2.4. Effective SCONE Feedback Mechanism in 5G
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].
2.5. Symmetrical Realization on both Directions: UL and DL
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.
Jiang & Tsou Expires 20 March 2026 [Page 7]
Internet-Draft SCONE applicability & Realization of 5G September 2025
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.
* SCONE packets with or without header mark setting (e.g., network
elements with SCONE processing enabled in the external DN off the
N6 interface may have already applied the marking of SCONE
throughput advice): UPF will process normally once receive.
* SCONE policy: 5GS may have different ways to provision SCONE
policies, e.g., dynamic policy via PCF (or possibly from AF),
local config in SMF, static config via subscription policy, etc.
These provivioning ways are similar for both UL and DL directions,
and the DL has no difference upon applying policy when compared to
the UL.
* SCONE feedback mechanism at UE Application clients being SCONE
receivers: The applicability of SCONE in UE AppClients indicates
that there is fundamentally no UE impact, which does not cause
concerns to mobile equipment vendors. Therefore, this makes it
more acceptable to deploy SCONE in mobile network, like in the 5G
scenario.
3. Advantages of SCONE Applicability to 5G
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:
1. Controllable implementation & better field deployment, especially
for the initial trial of the SCONE in the greenfield: So, the 5G
network is an excellent use-case scenario.
2. Capabilities of achieving dynamic provisioning & realization at
network elements: a 5G UPF has the flexibility, extensibility,
etc., acting as the anchor point to satisfy all the demands.
3. High granularity, particularly best if target at achieving the
per-flow SCONE throughput advice. Note that while the per-flow
requirement can be sort of challenging in the traditional public
Internet, a 5G system with UPF features the support effectively.
4. Security Considerations
Generally, this function will not incur additional security issues.
Jiang & Tsou Expires 20 March 2026 [Page 8]
Internet-Draft SCONE applicability & Realization of 5G September 2025
5. IANA Considerations
This document makes no request of IANA.
6. References
6.1. Normative References
[IETF-Draft-SCONE-Protocol]
Thomson, M., et al., "Standard Communication with Network
Elements (SCONE) Protocol", draft-ietf-scone-protocol,
May 2025.
[TS.23.501]
"3GPP TS 23.501: System Architecture for the 5G System
(5GS)", 3GPP TS 23.501, June 2025.
[TS.23.502]
"3GPP TS 23.502: Procedures for the 5G System
(5GS)", 3GPP TS 23.502, June 2025.
[TS.23.503]
"3GPP TS 23.503: Policy and charging control framework for
the 5G System (5GS); Stage 2", 3GPP TS 23.503, June 2025.
6.2. Informative References
Authors' Addresses
Tianji Jiang
China Mobile
Email: tianjijiang@yahoo.com
Tina Tsou
TikTok
Email: tinatsou6@gmail.com
Jiang & Tsou Expires 20 March 2026 [Page 9]