ATSSS

Starting from 3GPP 5G rel-15 specifications, it was proposed to enable an optional non-3GPP access to the Core Network (CN), alternative to the 3GPP one. 3GPP access refers to the nominal UU New Radio (NR-Uu) interface with the RAN of a 5G network; non-3GPP access instead opens to the possibility of connecting a UE to the 5G CN via different access technologies, and in particular WiFi (WLAN). For further details of possible non-3GPP access configurations, please refer to our dedicated article on N3IWF, TNGF, TWIF and W-AGF.

Once in a 5G network the optional non-3GPP access is enabled, it is possible to access to native 5G services using exclusively the non-3GPP access (i.e., a public WiFi access point at the airport). On the other hand, since rel-16 [1], it is possible also to enable the optional feature called Access Traffic Steering-Switching-Splitting (ATSSS), in which both 3GPP access and non-3GPP access are used simultaneously. In ATSSS, “steering” refers to the possibility of selecting for user-plane traffic, according to the service (QoS-type for a data flow), the best link to use, “switching” describes the possibility of performing handover without service interruption to the other link when necessary, “splitting” means the simultaneous use (bonding) of the two links.

ATSSS can be enabled in particular in the “untrusted” configuration (N3IWF) and in some of the “trusted” scenarios (TNGF and W-AGF) of non-3GPP access. As an example, in Figure 1 it is reported a simplified user-plane architecture showing  a UE with WiFi and NR accessing the same CN through an ATSSS-enabled CN.

Figure 1: ATSSS simplified architecture (user plane)

The optional ATSSS support is enabled by dedicated user-plane functions distributed in UE and UPF, and new policy rules at the control-plane required to enforce traffic management on the two links by enabling a Multi-Access (MA) PDU layer (N3), as shown in the following simplified architecture (i.e., a rel-16 ATSSS capable CN).

Figure 2: ATSSS simplified control and data planes between UE and UPF for an ATSSS capable CN and UE

More in details, Policy and Charging Configuration (PCC) rules generated by the ATSSS-enabled Policy Control Function (PCF) for each Service Data Flow (SDF) type are translated by the ATSSS-enabled Session Management Function (SMF) both into N4 rules for the UPF including together with routing and QoS information (FAR, PDR, etc.) also dedicated Multi Access Rules (MAR) and ATSSS rules delivered via the Access and Mobility Management Function (AMF) to the UE, together with the UE Route Selection Policy (URSP) rules via NAS (N1).

The ATSSS functions in the UE are in charge of managing the uplink traffic (from UE to DN), while the ATSSS functions in the UPF are in charge of managing the downlink traffic, by enabling a combination of MPTCP (higher layer) [2] and/or lower layer multi-link technology, called in general ATSSS-LL.

A “Multi Access (MA) PDU Request” in the UL NAS Transport message indicates to the CN that it is required to establish a new MA PDU Session and to apply the ATSSS-LL functionality, or the MPTCP functionality (or both) to implementing a multi-access PDU session. The multi-access session will be governed by a specific set of possible ATSSS rules, which in short are:

  • Selection on whether use Multipath-TCP (MP-TCP) or ATSSS-LL for each matching SDF
  • The indication of a steering mode, selected from:
    • Active-Standby: mark one of the two links as Master and the other as Slave. The traffic is always sent via the master link unless it becomes (temporarily) unavailable. This is the only steering mode available for Guaranteed Bit Rate (GBR) traffic sessions (SDF)
    • Smallest delay: use the link which, at the moment of session initiation, shows the lowest RTT. If, during the session life, that link becomes unavailable, then the other one shall be used (in a similar fashion as the Active-Standby)
    • Load Balancing: a % of share between the two links can be specified. If one of the two links becomes unavailable, the balancing shall go all in favor of the other link (100%)
    • Priority based: the traffic is sent initially only to the link marked with higher priority, until it results congested. Determination of congestion is left free to the implementer. At that moment, the traffic starts to be split on both links. If the high priority link becomes unavailable, the traffic is steered to the low priority link.

Some examples of ATSSS rules for the UE are described in rel-16 and reported in the following quoted text:

  •  “Traffic Descriptor: UDP, DestAddr 1.2.3.4”, “Steering Mode: Active-Standby, Active=3GPP, Standby=non-3GPP”: This rule means “steer UDP traffic with destination IP address 1.2.3.4 to the active access (3GPP), if available. If the active access is not available, use the standby access (non-3GPP)”.
  • “Traffic Descriptor: TCP, DestPort 8080”, “Steering Mode: Smallest Delay”: This rule means “steer TCP traffic with destination port 8080 to the access with the smallest delay”. The UE needs to measure the RTT over both accesses, in order to determine which access has the smallest delay.
  • “Traffic Descriptor: Application-1”, “Steering Mode: Load-Balancing, 3GPP=20%, non-3GPP=80%”, “Steering Functionality: MPTCP”: This rule means “send 20% of the traffic of Application-1 to 3GPP access and 80% to non-3GPP access by using the MPTCP functionality”.

Eventually, an ATSSS rule with a “match all” Traffic Descriptor may be provided, which matches all SDFs. This rule is applied the last and determines the default behaviour for all the traffic not matching previous rules.

MPTCP

A larger number of solutions for multipath and link aggregation at L4 involves modifications to TCP. Currently, the MultiPath TCP (MPTCP) [2] is a common approach for bandwidth aggregation at the transport layer; it is currently under standardization by the MPTCP working group in IETF and it is available for Linux kernels since version 3.10 and in Apple smart devices since iOS 7.

MPTCP requires a session layer established by both endpoints, otherwise the sender will establish a regular TCP connection over a single link. One of the main design goals behind MPTCP was to be completely transparent to both the application and the network. The application interacts with the transport layer through regular socket APIs while the MPTCP, as a middle layer, manages the communication by establishing multiple TCP flows with the endpoint, if supported.

MPTCP can be configured according to two main strategies (i.e. path manager): channel bonding or link failover. With the first approach the end-user will experience high data rates thanks to the exploitation of multiple links; the latter is used to ensure service continuity in case of a link failure. Outgoing data is then scheduled on the links according to a policy (i.e., scheduler) and according to a simple congestion control scheme or a dedicated multipath one (such as OLIA). Incoming data from all TCP sub-flows received is reordered to maintain the in-order byte stream abstraction of TCP as seen by the application.

To establish a MPTCP connection, at the beginning a regular 3-way handshake is started by between the two end-nodes (hosts). The MP_CAPABLE option present in the SYN (for the client) and SYN+ACK (for the server) messages notifies that the endpoint supports MPTCP. In case both parties are MPTCP capable, additional TCP sub-flows can be added to the established connection: for each sub-flow a handshake is required using a token exchanged by the parties in the initial messages.

Currently MPTCP is available in Linux kernel space only (even if few user-space implementations exist, they are poorly maintained). The latest MPTCP version (v0.95) is based on the Linux Kernel v4.19, but it can be included as well in some of the newer Linux kernels versions v5.x. Nonetheless, its support is not available by default in Linux distributions, and it shall be compiled or explicitly enabled to work.

Being MPTCP designed to establish directly an end-to-end connection between one source and one destination over the IP layer, if one of the endpoints don’t support it, dedicated middleboxes (proxy) shall be considered. To this aim, IETF specified in the RFC8803 [3] the “0-RTT TCP Convert Protocol”, an application proxy intended to convert MPTCP communication (or other types of TCP communications) to standard TCP. “TCP Convert” is the mandatory approach defined by 3GPP rel 16 to support MPTCP ATSSS, which must be supported natively by the UE. It is worth nothing that no additional delay is envisaged during the conversion (i.e., the reference to 0-RTT in RFC8803). Note also that this protocol does not require any encapsulation (i.e., tunnels or affinity methods) and it will not impact on the end-to-end secure connection (TLS).

To provide an indication of the benefits in enabling MPTCP as a tunnel between UE and UPF, we propose the results of a test derived from [4] in which the non-3GPP access is assumed to be a 50 Mbit/s high latency satellite link, and the 3GPP access is limited to 10 Mbit/s. The traffic is splitted between the two links, offering from the application point of view an aggregated throughput which is the sum of the throughputs on the individual links. At the UPF side, the MPTCP conversation is converted by a proxy to standard TCP, to reach a server on the Internet. Please note that, in case of link failure, the communication continues on the link left available (at about 15 s only the satellite links remains).

Figure 3: Example of MPTCP aggregation and failover response

ATSSS-LL and PMF

ATSSS-LL is meant to define a layer-2 Multi-Access mechanism at the user plane of the 5G CN, between UE(s) and UPF(s). In the case of Ethernet PDU, it is the only mechanism available in ATSSS, whereas if PDU is IP v4/v6, ATSSS-LL complements MPTCP by managing the traffic which is not making use of MPTCP.

While MP-TCP implementation is well known and available, with a MP-TCP proxy implementation required for ATSSS which must be based on TCP-Convert RFCs, the ATSSS-LL implementation is left open (but subject to a set of requirements), as by the following excerpt from Rel-16 3GPP specs:

“The ATSSS-LL functionality in the UE does not apply a specific protocol. It is a data switching function, which decides how to steer, switch and split the uplink traffic across 3GPP and non-3GPP accesses, based on the provisioned ATSSS rules and local conditions (e.g. signal loss conditions). […] The ATSSS-LL functionality is mandatory in the UE for MA PDU Session of type Ethernet. When the UE does not support the MPTCP functionality, the ATSSS-LL functionality is mandatory in the UE for an MA PDU Session of type IP. When the UE supports the MPTCP functionality, the ATSSS-LL functionality with Active-Standby Steering Mode is mandatory in the UE […] to support non-MPTCP traffic. The network (i.e., UPF) shall also support the ATSSS-LL functionality as defined for the UE.”

Concerning the “local conditions” mentioned in 3GPP Rel-16 specifications, an additional Performance Measurement Function (PMF) component for ATSSS, leveraging the PMF Protocol (PMFP), shall be included both in UEs and UPFs. While MPTCP is able to perform self-evaluation on link availability and status (even though external inputs can be considered in light of the possible steering modes), explicit measures of latency and load are required to enforce ATSSS-LL operations. As an example, see the second ATSSS example rule described before, in which the link with the smallest delay shall be selected. PMF’s main goal is therefore to provide real-time metrics at both ends (UE and UPF), useful to enforce low-level local traffic management on the basis of the status of each link. PMF is able to evaluate the values of interest by implementing an UDP-based server-client protocol called PMF Protocol (PMFP), whose packets share the same PDU layer available for the user-plane data. In this way, the RTT and load measures inferred by the PMF will reflect the actual conditions of traffic on the whole data path between UE and UPF.

PMFP is based on RFC8972 (STAMP) standard – previously RFC8762, based on RFC5357 (TWAMP) which in turn is based on RFC4656 (OWAMP). While some STAMP/TWAMP implementations exist [5] [6] [7] fully compliant PMFP implementations are not available in the Open-Source landscape. STAMP, as a simplification, can be considered a client-server version of the baseline ICMP/Ping application “on steroids”.

We are not aware of any 5G compliant ATSSS-LL Open-Source solution including PMF, or suggested guidelines for its implementation at the link layer, and RomARS is at present performing R&D activities in this topic. An indication on how to achieve a transport-layer-independent ATSSS functionality for IP PDUs (i.e. for non TCP traffic or for applications not using MPTCP) is to use QUIC tunnels as also proposed in [8] (even if at the moment this draft has expired). Please note that this approach was proposed and studied during the ESA VIBeS project and in fact is alternative to MPTCP. As output of this project, RomARS has some prototypes of QUIC terminations as Docker instances suitable to perform ATSSS.

In addition to the QUIC based approach for ATSSS-LL, other layer-2 mechanisms can be considered, as described in the work by RomARS in [9]. We refer in particular to possible tunnelling approaches (i.e., GRE, GRE over VPN) leveraging the bonding capabilities of Linux [10], which supports natively the Active-standby (called active-backup) configuration, among many others. In the first instance, anyhow, these types of “layer 2” approaches should not offer significant benefits with regard to QUIC-based ones.

References

[1] System Architecture for the 5G System (3GPP TS 23.501 version 16.6.0 Release 16)
[2] Paasch and O. Bonaventure, “Multipath TCP Communications of the ACM”, 57(4):51-57. 2014
[3] Bonaventure , M. Boucadair, S. Gundavelli, S-H. Seo, and B. Hesmans, “0-RTT TCP Convert Protocol”, RFC 8803
[4] Abdelsalam, M. Luglio, C. Roseti and F. Zampognaro, “Linux MP-TCP performance evaluation in a combined terrestrial-satellite access”, 2019 International Conference on Wireless Technologies, Embedded and Intelligent Systems (WITS)
[5] https://github.com/nokia/twampy
[6] https://github.com/tcaine/twamp
[7] https://github.com/emirica/twamp-protocol
[8] M. Boucadair et al., “3GPP Access Traffic Steering Switching and Splitting (ATSSS) – Overview for IETF Participants”, proposed RFC “draft-bonaventure-quic-atsss-overview”
[9] Abdelsalam, A., et al. “Analysis of bandwidth aggregation techniques for combined use of satellite and xDSL broadband links.” International Journal of Satellite Communications and Networking 37.2 (2019): 76-90
[10] Linux Ethernet Bonding Driver, https://www.kernel.org/doc/Documentation/networking/bonding.txt

 

© RomARS – Francesco Zampognaro