Realization of SCONE in the 5G Scenario
draft-jiang-scone-realization-5gcase-00
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Tianji Jiang | ||
| Last updated | 2025-07-03 | ||
| RFC stream | (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-00
SCONE Working Group T. Jiang
Internet-Draft China Mobile
Intended status: Informational 3 July 2025
Expires: 4 January 2026
Realization of SCONE in the 5G Scenario
draft-jiang-scone-realization-5gcase-00
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 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.
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 4 January 2026.
Copyright Notice
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.
Jiang Expires 4 January 2026 [Page 1]
Internet-Draft SCONE to 5G Realization July 2025
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 & 5GS . . . . . . . . . . . . . . . . . . 2
2. Realization of SCONE in 5G Scenario . . . . . . . . . . . . . 4
2.1. SCONE Packet Processing at UPF . . . . . . . . . . . . . 5
2.2. Achieve Dynamic SCONE Setting & Provisioning . . . . . . 5
2.3. Achieve SCONE Per-flow granularity . . . . . . . . . . . 6
2.4. Effective SCONE Feedback Mechanism in 5G . . . . . . . . 7
3. Advantages of SCONE Realization of 5G . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction: SCONE & 5GS
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).
Jiang Expires 4 January 2026 [Page 2]
Internet-Draft SCONE to 5G Realization July 2025
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-+ :
...........................................
Figure 1: The 5G System Architecture
Jiang Expires 4 January 2026 [Page 3]
Internet-Draft SCONE to 5G Realization July 2025
2. Realization of SCONE in 5G Scenario
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 -/ /
\................................./
Figure 2: A 5G PDU session w/ multiple QoS Flows
Jiang Expires 4 January 2026 [Page 4]
Internet-Draft SCONE to 5G Realization July 2025
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.
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):
* SCONE traffic detection: requiring the identification and
classification matching filters to be configured at the NE.
* SCONE policy or 'throughput advice' applied: 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
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).
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.
Jiang Expires 4 January 2026 [Page 5]
Internet-Draft SCONE to 5G Realization July 2025
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.
* 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 communication 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.
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.
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 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.
Jiang Expires 4 January 2026 [Page 6]
Internet-Draft SCONE to 5G Realization July 2025
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].
3. Advantages of SCONE Realization of 5G
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:
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: the 5G UPF having 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.
5. IANA Considerations
This document makes no request of IANA.
Jiang Expires 4 January 2026 [Page 7]
Internet-Draft SCONE to 5G Realization July 2025
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
Author's Address
Tianji Jiang
China Mobile
Email: tianjijiang@yahoo.com
Jiang Expires 4 January 2026 [Page 8]