Applicability & Realization of SCONE in 5G Scenario

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 . 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. The 3GPP SDO has defined the 5G architecture . 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 , 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. 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.

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.. The 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 , and the policies may provide the 'throughput advices' associated with SCONE.

| /.................................\ / \ / (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 applicability and realization of SCONE in the 5G scenario can be much more streamlined and practical.

The SCONE draft , 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. , 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 are enforced at the UPF to set in detected SCONE packet headers the 'throughput advices' that have been provisioned according to SCONE policies. The 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, 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 . 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., , 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.

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. , the per-flow provisioning & application granularity can be achieved based on the characteristics of PDU sessions. Please reference to the . 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.

In the SCONE IETF draft , 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 ). 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 .

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. 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.