A Use Case for SCONE Implementation
draft-mishra-scone-usecase-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 | Sanjay Mishra , Anoop Tomar , Khurram Abbas , Zaheduzzaman Sarker | ||
| Last updated | 2025-04-09 | ||
| 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-mishra-scone-usecase-01
SCONE S. Mishra
Internet-Draft Verizon
Intended status: Informational A. Tomar
Expires: 11 October 2025 Meta
K. Abbas
Verizon
Z. Sarker
Nokia
9 April 2025
A Use Case for SCONE Implementation
draft-mishra-scone-usecase-01
Abstract
This document describes 3GPP network elements that are capable of
rate-limiting a UDP 4-tuple to communicate an upper bound on
achievable bitrate termed "throughput advice" to implement SCONE
protocol.
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 11 October 2025.
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.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Mishra, et al. Expires 11 October 2025 [Page 1]
Internet-Draft SCONE Use Case April 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
3. Overview of User Plane Network Element in Mobile Packet
Core . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. N3 Interface . . . . . . . . . . . . . . . . . . . . . . 4
3.2. N4 Interface . . . . . . . . . . . . . . . . . . . . . . 4
3.3. N6 Interface . . . . . . . . . . . . . . . . . . . . . . 5
3.4. N9 Interface . . . . . . . . . . . . . . . . . . . . . . 5
4. User Plane Interface Between UPF and UE . . . . . . . . . . . 5
4.1. Significance of UPF from SCONE Perspective . . . . . . . 6
4.2. 4G Mobile Network Architecture . . . . . . . . . . . . . 6
5. Implementing SCONE In the Mobile Network . . . . . . . . . . 7
6. SCONE Signal Requirements for the mobile networks . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document describes utilizing the User Plane Function (UPF) in 5G
networks and packet data network gateway in 4G networks (PDN-GW or
P-GW and also referred as a PGW) to transport SCONE signal between
the client-application endpoint on a User Equipment (UE) and the
network element (UPF/PDN-GW) in the mobile networks. Specifically,
this use case focuses on using UPF and PDN-GW to exchange bi-
directional communications with client-application end-point on the
UE. The mechanism described focuses on mobile networks including 4G
and 5G but the mechanism is generic and applicable to other network
architectures.
2. Conventions and Definitions
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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Mishra, et al. Expires 11 October 2025 [Page 2]
Internet-Draft SCONE Use Case April 2025
3. Overview of User Plane Network Element in Mobile Packet Core
This section describes 5G mobile packet core to explain the role of
user-plane network element in mobile packet core and reasons why the
5G User Plane Function (UPF) and 4G P-GW as network elements can be
considered candidates for signaling the "throughput advice" to
client-application-endpoint. However, the applicability extends to
network architectures beyond 4G/5G networks.
The user plane network element in the 5G packet core is the UPF, as
shown in Figure 1. In the 4G packet core, the P-GW (as shown in
Figure 2) performs the same role as the UPF does in the 5G mobile
packet core.
The UPF is a fundamental component of the 3GPP's 5G packet core
network architecture. UPF is the data path between the end-user and
the Internet, has access to subscriber policy via standard 3GPP
interface and is responsible for routing and forwarding user data
packets. UPF is the anchor point between the mobile infrastructure
and the Packet Data Network. The UPF is responsible for functions
such as:
* Packet routing, forwarding, and interconnection to the Data
Network (Internet)
* Allocation of User Equipment (UE) IP Address/prefix, in
conjunction with Session Management Function (SMF)
* Quality of Service policy enforcement
* Handling of traffic filtering, steering and application detection
* Traffic usage reporting
Note: This is not an exhaustive list of UPF functions. For details
refer to [_5G-Arch].
To accomplish above mentioned functions, the UPF has four distinct
reference points (interfaces) as defined by the 3GPP and as shown in
the figure below:
Mishra, et al. Expires 11 October 2025 [Page 3]
Internet-Draft SCONE Use Case April 2025
+-----+ Nudm/Nudr +---------+
| PCF +-------------+ UDM/UDR |
+--+--+ +----+----+
| |
Npcf | +-----+ |Nudm
+------+ SMF +-------+
+--+--+ ___ __
| N4 ( )( )
+----+ +--------+ +--+--+ ( ) +------------------+
| UE |---| gNodeB |----| UPF |----( Internet )---| Content Provider |
+----+ +--------+ N3 +- -+-+ N6 ( ) +------------------+
| N9 (__(___)
+-+---+
| UPF |
+-----+
Figure 1: 5G Mobile Network Architecture
1. The N3 interface is between the UPF and the 5G Base station.
2. The N4 interface is a connection between the UPF and the Session
Management Function (SMF).
3. The N6 interface is between the UPF and the public data network
or the Internet.
4. The N9 interface is between instances of UPFs.
3.1. N3 Interface
The N3 interfaces transfers user plane traffic, that is, user data
packets between the gNodeB and the UPF. It uses GPRS Tunneling
Protocol - User Plane or GTP-U. It replaces the S1-U interfaces from
the 4G mobile packet core.
3.2. N4 Interface
The N4 interface connects the UPF and the 5G Session Management
Function (SMF). Through N4, the SMF informs the UPF about the
subscriber policy and data plans. Additionally, this interface is
used to manage session setup, modification, deletion, and for
configuring forwarding rules for user data. The N4 interface among
others uses Packet Forwarding Control Protocol (PFCP).
Note: SMF also interacts with Policy Control Function (PCF) for
functions such as QoS and Charging policy rules, Unified Data
Management (UDM) and Unified Data Repository (UDR) for functions such
as subscription data and policy plans.
Mishra, et al. Expires 11 October 2025 [Page 4]
Internet-Draft SCONE Use Case April 2025
3.3. N6 Interface
The N6 interface connects the UPF to external Data Networks, similar
to the SGi interface between the P-GW and the external Data Network
for access to services and applications. The interface supports
various trasnport protocols over IP.
3.4. N9 Interface
This interface interconnects two or more UPFs when used in a data
path. The interface uses GTP-U protocol for user traffic tunneling
including roaming.
Note: In the scenario of 2 or more UPFs in the data path, only one
UPF that has access to subscriber policy would send "throughput
advice" to the client-application-endpoint.
4. User Plane Interface Between UPF and UE
This section describes the N3 interface (between the UPF and gNodeB
or gNB) and the air interface between the gNB and UE. For purposes
of nomenclature, a Protocol Data Unit (PDU) session is a logical path
between a UE and UPF to carry packets belonging to one or more IP
flows between UE and DN. A PDU session within a 5G mobile network
consists of an air-interface between UE and gNB and GTP-U tunnel
between gNB and UPF (N3 interface). IP flows (aka service data flows
or SDFs) may belong to one or more services. All the service data
flows with the same QoS maps onto one PDU session. Below is an
example of data flow to/from a UE to the UPF.
1. Uplink Data Flow
* Apps that are hosted on UE that generate application packets
for communication (e.g. web brownsing, video streaming).
* These packets are transmitted to the gNB over the air
interface.
* N3 Encapsulation and Forwarding
1. The gNB then encapsulates this user-plane data using GTP-
U.
2. It then forwards the encapsulated packets over the N3
interface to the UPF in the 5G mobile packet core.
* UPF Routes Data to External Networks.
Mishra, et al. Expires 11 October 2025 [Page 5]
Internet-Draft SCONE Use Case April 2025
1. Within the UPF, UPF then removes the GTP-U header,
processes the packet, and routes it over the N6 interface
toward the destination (Internet, enterprise network,
cloud services, etc.).
2. Downlink Data Flow
* UPF receives incoming data in downlink direction at N6
interface (e.g. from the Internet).
* The UPF encapsulates incoming data using GTP-U and sends it
back over the N3 interface to the gNB.
* The gNB forwards the packets to the UE over the air-interface.
UE-side modem stack then transparently passes the application
packets to the app hosted on the UE.
In summary, the UPF is responsible for packet routing and forwarding,
packet inspection and filtering, subscriber policy enforcement,
inline services (NAT, firewall, DNS etc) and QoS handling.
4.1. Significance of UPF from SCONE Perspective
The UPF is a data path mobile packet core network element that routes
and forwards application packets between the gNodeB and the DN and it
has access to subscriber policy via standard 3GPP N3 interface.
As a result, UPF is in the best position to send the throughput
advice to client application over the data-path.
4.2. 4G Mobile Network Architecture
+-----+
| HSS |
+-----+
|
+-----+ +------+
| MME | | PCRF |
/+-----+\ +------+
/ \ |
/ \ | ___ __
/ \ | / )( \
+----+ +-----+ +------+ +------+ ( ) +----------+
| UE |---| eNB |--------| S-GW |--| P-GW |----( Internet )---| Content |
+----+ +-----+ S1u +------+ +------+ SGi ( _) | Provider |
(__(___) +----------+
Figure 2: 4G Mobile Network Architecture
Mishra, et al. Expires 11 October 2025 [Page 6]
Internet-Draft SCONE Use Case April 2025
5. Implementing SCONE In the Mobile Network
As described in sections above, UPF is the 3GPP on-path "network
element" that has access to subscriber policy and provides the data
pipe connectivity between UE and the Internet. UPF is a network
element that is capable of SCONE signaling over the data path.
Below is a high-level view of SCONE signal path in a 5G network.
Please see [Mishra-2025] for a more complete version of this diagram.
+---------+
| PCF |
+---------+
| Subscriber
V Policy Rules
+---------+
| SMF |
+----+----+
| Subscriber
v Policy Rules
+--------+ + +---------+-+
| Client |/--------------\ | SCONE | | __
| App |\--------------/ | Advisor | | __( )__
+--------+ SCONE | +---------+ | ( ) +----------+
| OS | (advised bit | +--( Internet )--+ Content |
+--------+ rate and | UPF | ( ) | Provider |
| Modem | other IEs) | | (__)(___) +----------+
+----+---+ +------+------+
| |
| +-----+ |
+---------+ gNB +----------+
+-----+
Figure 3: SCONE Integration with Video Policy in 5G SA N/W
Similarly, the SCONE signal for 4G network is shown below. Please
see [Mishra-2025] for a more complete version of this diagram.
Mishra, et al. Expires 11 October 2025 [Page 7]
Internet-Draft SCONE Use Case April 2025
+---------+
| PCRF |
+----+----+
| Subscriber
v Policy Rules
+--------+ + +---------+-+
| Client |/--------------\ | SCONE | | __
| App |\--------------/ | Advisor | | __( )__
+--------+ SCONE | +---------+ | ( ) +----------+
| OS | (advised bit | +--( Internet )--+ Content |
+--------+ rate and | P-GW | ( ) | Provider |
| Modem | other IEs) | | (__)(___) +----------+
+----+---+ +------+------+
| |
| +-----+ +--+---+
+---------+ eNB +-------+ S-GW |
+-----+ +------+
Figure 4: SCONE Integration with Vido Policy in 4G N/W
6. SCONE Signal Requirements for the mobile networks
* SCONE protocol(s) MUST be client-application endpoint initiated to
assist the network element with flow detection for any SCONE
compliant
* application traffic.
* Client-application endpoint MAY send acknowledgement receipt of
throughput advisory signal from the network element using the
SCONE signal.
* SCONE signaling MUST NOT require changes to how a CSP determintes
its video policy for a given flow. (No dependency between a CSP's
video policy and the SCONE protocol).
* Dynamic update - "throughput advice" MAY change during the ongoing
flow and UPF/PGW SHOULD be able to send "throughput advice" to
client-application-endpoint as soon as possible.
* Applications MAY self-adapt the video flow max bit-rate to
"throughput advice" value.
* SCONE signal MUST be extensible to networks beyond 4G/5G network.
Mishra, et al. Expires 11 October 2025 [Page 8]
Internet-Draft SCONE Use Case April 2025
7. Security Considerations
Security considerations are included separately in the SCONE protocol
documents. Specific to the use case description in this document,
there are no additional security considerations.
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
9.2. Informative References
[I-D.joras-scone-video-optimization-requirements]
Joras, M., Tomar, A., Tiwari, A., and A. Frindell, "SCONE
Video Optimization Requirements", Work in Progress,
Internet-Draft, draft-joras-scone-video-optimization-
requirements-00, 4 November 2024,
<https://datatracker.ietf.org/doc/html/draft-joras-scone-
video-optimization-requirements-00>.
[Mishra-2025]
Mishra, S., "Leveraging the user plane function for
network-side advisory signal", 6 February 2025,
<https://datatracker.ietf.org/meeting/interim-2025-scone-
01/materials/slides-interim-2025-scone-01-sessa-
leveraging-the-user-plane-function-for-network-side-
advisory-signal-00>.
[SCONE-Charter]
IETF, "SCONE Working Group Charter", 31 October 2024,
<https://datatracker.ietf.org/wg/scone/about/>.
Mishra, et al. Expires 11 October 2025 [Page 9]
Internet-Draft SCONE Use Case April 2025
[_5G-Arch] 3GPP, "System architecture for the 5G System (5GS)", 7
January 2025,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
Acknowledgments
This document represents collaboration, comments, and inputs from
others, including:
* Wesley Eddy
* Renjie Tang
Authors' Addresses
Sanjay Mishra
Verizon
Email: sanjay.mishra@verizon.com
Anoop Tomar
Meta
Email: anooptomar@meta.com
Khurram Abbas
Verizon
Email: khurram.abbas@verizonwireless.com
Zaheduzzaman Sarker
Nokia
Email: zaheduzzaman.sarker@nokia.com
Mishra, et al. Expires 11 October 2025 [Page 10]