Mobile User Plane Evolution: 5G & 6G

1.1. Current User Plane in 5G

Mobile User Plane (MUP) in 5G [TS.23.501] has two distinct parts: the Access Network part between UE and gNB, and the Core Network part between gNB and UPF. As shown in the Figure 1, for the core network (CN) part, N3 interface extends the PDU layer from AN/gNB towards the PSA UPF, optionally through intermediate UPF or I-UPFs and in that case N9 interface is used between I-UPF and PSA UPF. Traditionally, UPFs are deployed at central locations and the N3/N9 tunnels extend the PDU layer to them. The N3/N9 interface uses GTP-U tunnels that are typically over a VPN over a transport infrastructure. The N6 interface connects 5GS CN directly to the transport network (TN) and further to the data network (DN).¶

        5G AN: Access Network      5G CN: Core Network
        TN:    Transport Network   DN:    Data Network
        PSA UPF: Anchor UPF        I-UPF: Intermediate UPF
              .................................
              :                               :
              :   [--  5GS AN/CN --]          :
              : /  |         | N4 \           :  /------------\
              N1   N2        |     \          :  |            |
             /:    |         |      \         :  |  Transport |
            / :    |         |      +-----+   :  | Network(TN)|
       +----+ : +---+ N3 +-----+ N9 | PSA |   :  |      :     |
       | UE |---|gNB|----|I-UPF|----| UPF +-(N6)-+    Data    |
       +----+ : +---\    +-----+    /-----+   :  | Network(DN)|
              :      \----(N3)-----/          :  |            |
              .................................  \------------/

At a gNB, relay is done between the radio layer and the GTP-U layer. At the PSA UPF, routing/switching is done for IP/Ethernet before GTP-U encapsulation (for downlink traffic) or after GTP-U decapsulation (for uplink traffic).¶

1.2. Distributed UPFs in 5G

5G has standardized some features, e.g., Multi-access Edge Computing or MEC, which has UPFs deployed closer to gNBs [TS.23.501]. In fact, even PSA UPFs could be distributed closer to gNBs and then the N3 interface becomes very simple – over a direct or short transport connection between gNB and UPF. On the other hand, since the UPF connects to DN (via TN as in Figure 1), the DN becomes a VPN (e.g., IP VPN in case of IP PDU sessions or EVPN in case of Ethernet PDU sessions) over a transport infrastructure, most likely the same transport infrastructure for the VPN supporting the (GTP-U based) N3/N9 tunneling in centralized PSA UPF case.¶

UEs may keep their persistent IP addresses even when they re-anchor from one PSA UPF to another. In that case, for downlink traffic to be sent to the right UPF, when a UE anchors at a UPF the UPF advertises a host route for the UE and when a UE de-anchors from a UPF the UPF withdraws the host route.¶

While this relies on host routes to direct to-UE traffic to the right UPF, it does not introduce additional scaling burden compared to centralized PSA UPF model, as the centralized UPFs need to maintain per-UE forwarding state (e.g., PDRs, FARs, etc. as shown in [TS.23.501]) and the number is the same as the number of host routes that a hub TN router need to maintain in the distributed PSA UPFs model. Since the host routes may be lighter-weighted than the PDRs/FARs, the total amount of state may be actually smaller in the distributed model.¶

For UE-UE traffic, the distributed PSA UPFs may maintain host routes that they learn from each other. With that the UE-UE traffic may take direct UPF-UPF path instead of going through a hub router in the transport network (TN). That is important in LAN-type services with the requirement of low delay. Alternatively, the distributed UPFs may maintain only a default route pointing to the hub router in TN (besides the host routes for locally anchored UEs). That way, they don't need to maintain many host routes though UPF-UPF traffic has to go through the hub router (and that is similar to all traffic going through a central PSA UPF).¶

The distributed UPFs must be able to advertise host routes in the TN. This should not be a problem since a UPF is essentially a router in that it routes traffic between TN and UEs (that are connected via PDU sessions).¶

Please reference the draft [I-D.dmm-mup-evolution] for more details as well as possible extensions for distributed UPFs.¶

2.1. Objectives of 6G UP Architecture

As specified in the 6G system architecture document [TR.23.801], the 6G user plane architecture strikes for improvements to support a more diverse set of applications and traffic patterns. Specifically, it targets at:¶

• Enhance the control-plane (CP) and the user-plane (UP) functional split and interaction for better multi-vendor operability.¶

• Enhance the UP flexilibty, resilience and scalability with the consideration of UP function capability and path performance between the (wireless 6G) core network and data network.¶

2.2. 6G Multi-vendor Interoperability

This multi-vendor interoperability objective focuses on the interaction between two 6G network functions, i.e., the 6G SMF and the 6G UPF. As we know, the same reference point in 5G is the N4 interface, with the PFCP as the base protocol for interactions (the 6G architecture is similar to the 5G's as in Figure 1). Currently there are some proprietary information that needs to be exchanged via PFCP between the 5G SMF and UPF, which has fundamentally laid down the requirement that both the 5G SMF and UPF are from the same vendor. The 6G system wants to disaggregate the proprietary-based NF coupling to achieve better multi-vendor interoperability.¶

The 6G architecture document [TR.23.801] identifies unnecessary options in PFCP, and proposes to remove them in CP (6G SMF)- UP (6G UPF) functional split. The specific options are:¶

• To NOT support the CP buffering in 6GS, but only in 6G UPF, for UE's downlink traffic. CP buffering involves more signalling than the UPF alternative.¶

• To NOT support the CP constructing the End Marker packets in 6GS, but only in 6G UPF. The "Sending of end marker" is a functionality to assist the reordering function in the RAN [TS.23.501], which was also discussed in the draft [I-D.dmm-5g-end-marker]. UPF constructing and sending the End-Marker packet upon request from SMF will be much simpler.¶

Evidently the removal of unnecessary options simplifies the CP-UP interactions and achieves better multi-vendor interoperability. For example, the IETF draft [I-D.dmm-mup-architecture] specifies a SRv6 based MUP architecture. The new functional-split proposal for 6GS can better help the deployment of MUP controller. When a MUP controller is applied to the 5G or 6G mobile architecture, the BGP signaling from the MUP Controller can replace the CP signaling (N4 signaling in 5G and similar signaling in 6G) from (5G/6G-) SMF. The same CP signaling is still used between the MUP Controller and SMF - from SMF's point of view, the existence of the MUP controller is transparent, and the SMF is just interacting with a traditional UPF as usual.¶

2.3. 6G UP Flexbility with UPF Distribution

In order to enhance the 6G UP flexilibty, resilience and scalability, the 6G architecture document [TR.23.801] has proposals to introduce four new network functions, consisting of two UP NFs, i.e., the 6G Serving UPF (S-UPF) and the Anchor UPF (A-UPF), and two corresponding CP NFs, i.e., the 6G Serving SMF (S-SMF) and the Anchor SMF (A-SMF). A 6G S-SMF manages the corresponding S-UPF and an A-SMF manages the corresponding A-UPF. The architecture is shown in the Figure 2.¶

         S-SMF: Serving SMF       A-SMF: Anchor SMF
         S-UPF: Serving UPF       A-UPF: Anchor UPF
                    +-------+       +-------+
                    | S-SMF |       | A-SMF |
                    +---:---+       +---:---+
                        :               :            transport   Data
                        v           +---v---+         Network   Network
                    +-------+       |       |          (TN)      (DN)
  Mobile  +-----+   |       | /-->>-+ A-UPF +--\      +-----+
   User---+ RAN +---+ S-UPF |/      |       |   \     |C-PE/|   +----+
   (UE)   +-----+   |       +       +-------+    +->>-+ PE  +---+ DN |
                    +-------+\                  /     +-----+   +----+
                              \                /
                               \=====>>>======/

The proposal has the following UP characteristics:¶

• S-UPF is deployed in the distributed way. A 6G UPF close to the UE will be selected as the S-UPF to enable UE access application service in an efficient way. It may support basic UP functionalities only. Comparably, an A-UPF is deployed toward the 6G core network. It can support more advanced functionalites (being specific services e.g., MoQ Relay functionality, CONNECT-UDP HTTP client, etc.).¶

• As shown in the Figure 2, both the 6G S-UPF and the 6G A-UPF can interface directly, via the transport network or TN (showing C-PE/PE in the figure), to the data network or DN. Further, to access application servers (AS'es) in DN that are deployed far away from UEs, a S-UPF may detect and forward the application service traffic to a selected A-UPF, which will switch the traffic further to AS'es.¶

2.4. 6G UP Scalability & Resilience

The 6G UP architecture intends to achieve both the scalabilty and resilience. Toward this purpose, an enhanced architecture has been introduced as shown in the Figure 3¶

                     Serving         Anchor
                     UPF Set         UPF Set
                                    +-------+        transport   Data
                    +-------+       |A-UPF-1|         Network   Network
                    |S-UPF-1|       |  ...  |          (TN)      (DN)
  Mobile  +-----+   |  ...  | /-->>-+A-UPF-y+--\      +-----+
   User---+ RAN +---+S-UPF-x|/      |  ...  |   \     |C-PE/|   +----+
   (UE)   +-----+   |  ...  +       |A-UPF-n|    +->>-+ PE  +---+ DN |
                    |S-UPF-m|\      +-------+   /     +-----+   +----+
                    +-------+ \                /
                               \=====>>>======/

• The concept 'UPF set' (or another name 'UPF virtual group') is defined in the 3GPP document [TR.23.801]. Basically, A UPF set is a set of functionally equivalent UPF(s) that have exactly the same capability/functionalities, and back-haul connection to RAN(s) and the same configuration of DNN(s), Slices(s) etc. Note that the concepts of DNN, Slices can be referenced in the 3GPP document [TS.23.501]¶

• The Figure 3 shows the serving-UPF set and the anchor-UPF set. A serving-UPF set is comprised of a group of serving-UPFs and an anchor-UPF set is comprised of a group of anchor-UPFs. For each PDU session, one S-UPF (close to UE) will be selected from the S-UPF set, and one A-UPF, if deemed necessary, is selected from the A-UPF set.¶

• Both the resilience and scalability are managed across the scope of a UPF-set, e.g., achieving load balancing across packet-processing UPF instances of the same UPF-set, with the high-availability (HA) settings Active/Standby and/or Active/Active.¶

2.5. IETF Impact to 6G UP Architecture

On one aspect, the 3GPP 6G document [TR.23.801] clearly emphasizes the agnostic requirement of the transport nework (or TN). It targets at avoiding the tight coupling between the 3GPP core network and the underlaying transport technologies. That is, the 6G UP does not restrict to specific IETF transport mechanisms, e.g., MPLS, SRv6, Metro Ethernet, etc.¶

On the other aspect, while the 3GPP 6G UP does NOT mandate how transport paths are computed or controlled and does NOT assume the presence of a centralized transport network (TN) controller, it does suggests considering the TN capabilities for transport path optimization in both access & core networks. The transport capabilities represent a set of transport properties that can be fulfilled by one or more transport paths, including e.g. latency, bandwidth, availability, or packet loss. Further, transport capabilities are NOT specific to any underlying transport technology (e.g. pure-IP routing, MPLS, SRv6, etc.).¶

We can use the Figure 3 to elucidate how the transport layer may reach path computation results for UP path optimization by considering those TN properties. Suppose the path performance measurements between S/A-UPFs and AS, e.g. bandwidth, loss, load, etc., are incorporated. Then, to take advantage of these metrics, the IETF CATS technology (https://datatracker.ietf.org/wg/cats/about/) can be applied to achieve the better service differentiation for diverse set of applications and traffic requirements. In term of the control plane interactions between the 6GS and the TN, the 5G-similar AF->NEF->PCF->SMF->UPF communication channel can be leveraged. Regardless, this type of integration is applicable to dedicated, decentralized, and hybrid TN control deployments as shown in [I-D.dmm-mts].¶

While the 5G specifies that all tunneling (e.g. N3/N9) use GTP-U, currently the 6G UP is considering alternative transport options for both access & core networks. For example, some proposals in [TR.23.801] prefer having the GTP-U transported over SRv6 (as overlay, instead of SRv6 replacing GTP), while others recommend to natively replace GTP with SRv6. The SRv6 tunnels, instead of GTP which has additional multi-layer encapsulation including IP header, UDP header and GTP header, bring in some prominent benefits, e.g., Traffic Engineering (TE) and Service Function Chaining (SFC) capability provided by SRv6, bandwidth savings because of the removal of UDP and GTP headers, etc.¶