Internet-Draft | SCONE Applicability & Manageability | July 2025 |
Mishra, et al. | Expires 21 January 2026 | [Page] |
This document identifies applicability of SCONE signal in a mobile network and outlines operational considerations, or manageability of SCONE signal in the operator network. Importantly, this document also 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.¶
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 21 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.¶
This document describes applicablity and manageablity of SCONE protocol in the networks and applicaiton endpoints. It focuses on mobile networks, however, this document is also applicable to other access networks.¶
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.¶
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, termed as 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:¶
+-----+ Nudm/Nudr +---------+ | PCF +-------------+ UDM/UDR | +--+--+ +----+----+ | | Npcf | +-----+ |Nudm +------+ SMF +-------+ +--+--+ ___ __ | N4 ( )( ) +----+ +--------+ +--+--+ ( ) +------------------+ | UE |---| gNodeB |----| UPF |----( Internet )---| Content Provider | +----+ +--------+ N3 +- -+-+ N6 ( ) +------------------+ | N9 (__(___) +-+---+ | UPF | +-----+
The N3 interface is between the UPF and the 5G Base station.¶
The N4 interface is a connection between the UPF and the Session Management Function (SMF).¶
The N6 interface is between the UPF and the public data network or the Internet.¶
The N9 interface is between instances of UPFs.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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¶
UPF Routes Data to External Networks.¶
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.).¶
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.¶
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.¶
+-----+ | HSS | +-----+ | +-----+ +------+ | MME | | PCRF | /+-----+\ +------+ / \ | / \ | ___ __ / \ | / )( \ +----+ +-----+ +------+ +------+ ( ) +----------+ | UE |---| eNB |--------| S-GW |--| P-GW |----( Internet )---| Content | +----+ +-----+ S1u +------+ +------+ SGi ( _) | Provider | (__(___) +----------+
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 +----------+ +-----+
Similarly, the SCONE signal for 4G network is shown below. Please see [Mishra-2025] for a more complete version of this diagram.¶
+---------+ | 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 | +-----+ +------+
The sections below describe SCONE signal manageability.¶
In 3GPP networks (4G/5G), a User Equipment (UE) connects to the internet by establishing data sessions that traverse various network elements. The key process involves allocating an IP address to the UE and routing its data traffic through the mobile network's core to the external data networks including the internet. As this connection to the Internet is established and once the client App on the UE starts communicating with the application content provider, a hint for SCONE usage will allow UPF to then look for a SCONE packet for this specific user connection and avoid PGW/UPF any unnecessary CPU cycles for non-ABR video connections. The section below provides a more detailed information on the UE and the mobile network for connecting to the external network.¶
This is the logical connection established between the UE and the Packet Data Network Gateway (P-GW in 4G) or User Plane Function (UPF in 5G). It allows the UE to exchange IP packets with external networks. Each PDN Connection/PDU Session is associated with a specific Access Point Name (APN), which identifies the type of service or external network the UE wants to connect to (e.g., "internet" for general internet access).¶
During the establishment of a PDN Connection/PDU Session, the UE is allocated an IP address (IPv4, IPv6, or both). This IP address is used for communication with the internet.¶
Data traffic flows over bearers. A bearer defines the QoS (Quality of Service) characteristics for a specific data flow. For internet access, a default bearer is established first, and dedicated bearers can be set up for specific services requiring different QoS.¶
The network handles the UE's mobility (e.g., moving between cells or base stations) while maintaining the ongoing data connection.¶
As the network element capable of advising bit-rate limit, the network element also would need capabilities to measure conformance on the advised bit-rate.¶
Issue 35 [https://github.com/ietf-wg-scone/scone/issues/35] - Need to determine if the conformance is to be measured as an aggregate or on a per flow basis.¶
Presentation given at interim session 6 provides results based on experimentation that recommends a suitable size for time window to be 120 seconds. This value is compatible with existing VOD applications when ~2 mbps is the advised bitrate. - [https://datatracker.ietf.org/meeting/interim-2025-scone-06/materials/slides-interim-2025-scone-06-sessa-time-window-duration-for-bitrate-measurement-00.pdf]¶
In networks, for example - radio networks, the avaible capacity of the network can dynamically change for a persistance of time that, or there could be sudden increase of network users, these could result in change of throughput advice for a particular scone capable flow. These changes need to be dynamically and immidiately updated in the rate signal to avoid unnecesarry rate shaping or degradated QoE. This means the network elements need to be able to initiate the sending of the rate signal if there is not sufficient frequency of scone packets send for that particular flow.¶
SCONE signaling MUST NOT require changes to how a CSP determines its video policy for a given flow. That is there is MUST not be any dependency between a CSP's video policy and the SCONE protocol.¶
SCONE signal MUST be extensible to networks beyond 4G/5G network.¶
discussion on how the applications/receivers can adapt to the rate signals.¶
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.¶
This document has no IANA actions.¶
This document represents collaboration, comments, and inputs from others, including:¶