dmm T. Jiang Internet-Draft CMCC Intended status: Informational Z. Zhang Expires: 7 January 2027 HP Enterprise 6 July 2026 Mobile User Plane Evolution: 5G & 6G draft-jz-dmm-mup-evolution-00 Abstract This document starts from the description of the 5G mobile user plane, including distributed User Plane Functions (UPFs). Then, based on the 3GPP proposals for 6G UP architecture evolution, the draft describes some potential enhancements revolving around the support of the 6G UP flexiblity, scalability & resilience. The draft also discusses the potential IETF work upon integrating the proposed enhancements of the 6G UP architecture. 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 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Jiang & Zhang Expires 7 January 2027 [Page 1] Internet-Draft MUP Evolution July 2026 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. Table of Contents 1. 5G MUP Evolution & Distributed UPFs . . . . . . . . . . . . . 2 1.1. Current User Plane in 5G . . . . . . . . . . . . . . . . 2 1.2. Distributed UPFs in 5G . . . . . . . . . . . . . . . . . 3 2. MUP Evolution for 6G . . . . . . . . . . . . . . . . . . . . 4 2.1. Objectives of 6G UP Architecture . . . . . . . . . . . . 4 2.2. 6G Multi-vendor Interoperability . . . . . . . . . . . . 5 2.3. 6G UP Flexbility with UPF Distribution . . . . . . . . . 6 2.4. 6G UP Scalability & Resilience . . . . . . . . . . . . . 7 2.5. IETF Impact to 6G UP Architecture . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5. Informative References . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. 5G MUP Evolution & Distributed UPFs 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). Jiang & Zhang Expires 7 January 2027 [Page 2] Internet-Draft MUP Evolution July 2026 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)-----/ : | | ................................. \------------/ Figure 1: 5G Architecture w/ DN & TN 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 Jiang & Zhang Expires 7 January 2027 [Page 3] Internet-Draft MUP Evolution July 2026 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. MUP Evolution for 6G This section talks about the current proposals for the 6G UP architecture enhancement. It mainly targets at the user plane evolution revolving around the support of the UP flexiblity, scalability & resilience. The latter part of the section also discusses the possible IETF work upon integrating the proposed enhancements for 6G UP architecture. 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. Jiang & Zhang Expires 7 January 2027 [Page 4] Internet-Draft MUP Evolution July 2026 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. Jiang & Zhang Expires 7 January 2027 [Page 5] Internet-Draft MUP Evolution July 2026 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 | +-------+\ / +-----+ +----+ \ / \=====>>>======/ Figure 2: 6G Flexible Architecture w/ Distributed UPF 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. Jiang & Zhang Expires 7 January 2027 [Page 6] Internet-Draft MUP Evolution July 2026 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|\ +-------+ / +-----+ +----+ +-------+ \ / \=====>>>======/ Figure 3: 6G Flexible Architecture w/ S/A-UPF Set. * 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. Jiang & Zhang Expires 7 January 2027 [Page 7] Internet-Draft MUP Evolution July 2026 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. Jiang & Zhang Expires 7 January 2027 [Page 8] Internet-Draft MUP Evolution July 2026 3. Security Considerations To be provided. 4. Acknowledgements To be provided. 5. Informative References [I-D.dmm-5g-end-marker] Zhang, J., Liebsch, M., and T. Jiang, "Mobile Traffic Steering", Work in Progress, Internet-Draft, draft-zzhang- dmm-5gdn-end-marker-01, August 2024, . [I-D.dmm-mts] Liebsch, M., Mutikainen, J., Zhang, J., and T. Jiang, "Mobile Traffic Steering", Work in Progress, Internet- Draft, draft-ietf-dmm-mts-01, 2 March 2026, . [I-D.dmm-mup-architecture] Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo, P., Horn, J., Voyer, D., Zadok, S., Meilik, I., Agrawal, A., and K. Perumal, "Mobile User Plane Architecture using Segment Routing for Distributed Mobility Management", Work in Progress, Internet-Draft, draft-dmm-mup-architecture- 01, 20 October 2025, . [I-D.dmm-mup-evolution] Zhang, J. and E. al., "Mobile Traffic Steering", Work in Progress, Internet-Draft, draft-zzhang-dmm-5gdn-end- marker-01, July 2024, . 6. Normative References [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, . Jiang & Zhang Expires 7 January 2027 [Page 9] Internet-Draft MUP Evolution July 2026 [TR.23.801] "3GPP TS 23.801: Study on Architecture for 6G System; Stage 2", 3GPP TR 23.801, June 2026. [TS.23.501] "3GPP TS 23.501: System Architecture for 5G System; Stage 2", 3GPP TS 23.501, June 2026. Authors' Addresses Tianji Jiang CMCC Email: tianjijiang2012@gmail.com Zhaohui Zhang HP Enterprise Email: zzhang@juniper.net Jiang & Zhang Expires 7 January 2027 [Page 10]