Junos Multi-Access User Plane Overview
Introduction
The 3rd Generation Partnership Project (3GPP) introduced the Evolved Packet Core (EPC) for core network architecture. As Figure 1 shows, the four main EPC network elements are:
Serving Gateway
Packet Data Network (PDN) Gateway
Mobility Management Entity
Home Subscriber Server

User Equipment (UE) has control and data path connectivity to the EPC network elements over eNodeB base stations. The EPC provides data connectivity to external networks such as the Internet.
3GPP TS 29.244 Release 14 introduced CUPS. CUPS stands for Control and User Plane Separation, providing the architecture enhancements for the separation of functionality in the EPC’s serving gateway (SGW) and PDN gateway (PGW). As Figure 2 shows, both the serving gateway and the PDN gateway of the EPC can be separated into their control plane and user plane functions. CUPS introduces new interfaces, Sxa and Sxb, between the control plane and user plane functions of the SGW and PGW, respectively. CUPS enables control plane and user plane functions to be deployed, scaled and operated separately while integrated over a standard reference interface.

The control plane provides the following functionality:
Receives traffic rules and actions
Triggers accounting
Makes session level announcements
Receives usage information
Receives user plane status information
Northbound integration with the signaling plane
Configures and enables Lawful Intercept sessions
The user plane provides the following functionality:
Subscriber tunnel encapsulations (GTP-U)
Packet routing and forwarding
QoS and buffering
Policy enforcement
Statistics gathering and reporting
Enacts Lawful Intercept requests
Optional advanced services
With this functional separation, the control plane and user plane have very distinct deployment requirements and can be in different physical locations. While the control plane function is very complex, the user plane function requires high packet processing capability and rich policy enforcement. The user plane can be more distributed than the control plane and located closer to end-user access points, such as a radio access network (RAN), enabling higher bandwidth per user while delivering lower latency. Control plane and user plane separation provides the following benefits:
Independent scaling of the user and control planes.
Network architecture flexibility including:
Ability to deploy from the edge to the core.
Ability to segregate different traffic types and services across different user planes while maintaining a common or single control plane.
Operational flexibility
Easier migration path from 4G to 5G services. CUPS is optional for 4G, but is an integral part of the 5G network architecture.
For its initial release in Junos OS Release 19.4R1, Junos Multi-Access User Plane supports a combined SGW user plane (SGW-U) and PGW user plane (PGW-U) in a single MX series router (see Figure 3). The combined SGW-U/PGW-U is referred to as a SAEGW-U (System Architecture Evolution Gateway-User Plane). Juniper’s MX SAEGW-U can interoperate with a third-party combined SGW-C/PGW-C, hereafter referred to as SAEGW-C, through a combined Sxab interface. This initial release provided high-throughput 4G fixed-wireless access service.
Juniper’s MX SAEGW-U communicates with the third-party SAEGW-C over the Sxab interface through Packet Forwarding Control Protocol (PFCP) as specified in 3GPP TS 29.244.

Starting with Junos OS Release 20.4R1, Junos Multi-Access User Plane supports running an MX router as either a standalone SGW-U or a standalone PGW-U (while still supporting running an MX router as a SAEGW-U). Running an MX router as a standalone SGW-U enables high-throughput 4G mobility service (relocation of a UE to a new eNodeB, new SGW-U, or new SAEGW-U). This includes support for GTP-U based S5-U and S8-U interfaces, which provides links between SGW-U and PGW-U devices. Junos Multi-Access User Plane also provides tunnel relay functionality to forward user plane traffic between S1-U and S5-U/S8-U interfaces and between S5-U/S8-U and SGi interfaces.
Figure 4 shows the basic topology of running MX routers separately as and SGW-U and a PGW-U to enable mobility.

Logistics of UE handover, including SGW & PGW selection, are handled by SGW-C and PGW-C functions. The SGW-C and PGW-C participate in control protocol exchanges and update their SGW-U/PGW-U counterparts over Sxa and Sxb interfaces with any new or changed attributes of the UE session and bearers.
We support the following mobility scenarios:
Handover with eNodeB and no SGW change
Handover with SGW change (direct forwarding)
Handover with SGW change (indirect forwarding)
In summary, starting with Junos OS Release 20.4R1, Junos Multi-Access User Plane supports three different modes of operation on a singel MX router:
SGW-U, where the MX router acts as an SGW-U for all sessions and connects to a third-party SGW-C over a single Sxa interface and Juniper or thirdparty PGW-Us over multiple S5/8-U interfaces.
PGW-U, where the MX router acts as a PGW-U for all sessions and connects to a third-party PGW-C over a single Sxb interface and Juniper or third-party SGW-Us over multiple S5/8-U interfaces.
Combined SGW/PGW-U (SAEGW-U), where depending on the UE location, the MX router acts as an SGW-U for some sessions, a PGW-U for another set of sessions and SAEGW-U for the remaining sessions. In this mode, the SAEGW-U connects to an SAEGW-C over a single Sxab interface and to other Juniper or third-party SGW-Us and PGW-Us over multiple S5/8-U interfaces.
Only a single type of Sx association is supported at a time: Sxa, Sxb or combined Sxab.
3GPP TS 29.244 Release 15 Support
Starting with Junos OS Release 20.4R1, Junos Multi-Access User Plane supports elements of 3GPP TS 29.244 Release 15, including support for the following functionality:
-
PDI Optimization Support—Packet Detection Information (PDI) optimization is an optional feature that enables the control plane function (CPF) to optimize the signalling towards the UPF by combining the information that is common to multiple Packet Detection Rules (PDRs) as a Traffic Endpoint with a Traffic Endpoint ID (TEID) and then referring to this Traffic Endpoint in messaging. The Traffic Endpoint ID is unique within a PFCP session.
-
GTP Path Management—GTP path management provides heartbeat and error indication over GTP-U interfaces. A GTP-U peer can send an echo request on a path to a GTP-U peer to find out if it is alive. Junos Multi-Access User Plane devices support responding to echo requests.
-
User ID Support—The user ID is an information element (IE) that can be present in a PFCP Session Establishment Request. This IE is useful for troubleshooting problems in the UPF affecting a subscriber. The IE is visible in the output for the
show services mobile-edge sessions extensive
command. The user ID is an optional, non-critical IE that can be any length up to 16 digits or 8 characters. -
Transport Level Marking—For EPC, transport level marking is performed on a per EPS bearer basis in the SGW and PGW. Transport level marking refers to the process of marking traffic with a DSCP value based on the locally configured mapping from the QoS Class Identifier (QCI) and optionally the Allocation and Retention Priority (ARP) level. The CPF can change the transport level marking by changing the Transport Level Marking IE in the related Forwarding Action Rule (FAR).
Note:Juniper Multi-access User Plane supports transport level marking per bearer for downlink data only.
-
DDOS Support—DDOS support is provided for PFCP and GTP path management. To configure DDOS for these protocols, see protocols (DDoS).
-
QoS control/enforcement at the bearer level—For QoS control/enforcement at the bearer level, the CPF must creat the necessary PRDs to represent the service data flow, bearer, or session. The CPF must also create QERs for the QoS enforcement fo the aggregate of the SDFs with the same bearer.
Junos Multi-Access User Plane supports QoS enforcement at either the service data flow (SDF) or the bearer level. If the MX router as UPF receives more than one QER for a bearer, it enforces QoS at the SDF level. If the MX router as UPF receives one QER for a bearer, it enforces QoS at the bearer level.
Hardware and Software Requirements
This section lists the MX Series hardware and software requirements needed to implement Junos Multi-Access User Plane.
Table 1 describes the hardware and software requirements for the Junos Multi-Access User Plane solution.
Junos OS Release |
Supported Platforms |
Line Cards Supporting Anchor PFE Interfaces |
Line Cards Supporting Signalling, Ingress, and Egress Interfaces |
Supported Routing Engines |
---|---|---|---|---|
Starting in Junos OS Release 19.4R1 |
|
|
|
|
Starting in Junos OS Release 20.2R1 |
|
MX10003-LC2103 |
MX10003-LC2103 |
|
Note:
One MPC7 line card contains up to two anchor PFE interfaces. Note:
MX204 routers do not support GRES or APFE redundancy. |
Useful Terminology
Table 2 provides lists some useful terminology to help you understand the Junos Multi Access User Plane.
Term |
Description |
---|---|
3GPP |
The 3rd Generation Partnership Project is an international standards organization that develops specifications and protocols for wireless telephony. |
APN |
The access point name identifies the packet data network (PDN), such as the Internet, that the subscriber wants to access. When a subscriber requests access, the UE passes the requested APN to the eNodeB, which sends it to the MME for authorization. If the subscriber does not request an APN, the MME can authorize a default APN. Each PDN that the user subscribes to has an APN and an associated SAEGW-U that the UE uses to access the PDN. The combination of APN and SAEGW-U is called a PDN subscription context. One context is the default APN, which always connects to a PDN such as the Internet unless the user activates another APN. The HSS maintains subscriber profiles, The MME uses the profile from the HSS to validate whether the subscriber is actually subscribed to the requested APN. You can also think of the APN as the set of service-level and connection parameters—such as QoS parameters—that is authorized for the UE. A given UE can access many APNs. An APN has two parts:
An APN that includes both a Network Identifier and an Operator Identifier corresponds to a DNS name for the SAEGW-U. The APN has the following format: network-id.mncmnc-number.mccmcc-number.gprs An APN can be a simple string or more complex, as shown in these examples:
|
Bearer |
An end-to-end bearer is the tunnel that connects the UE to a PDN through the SAEGW-U. A default bearer is established to a default SAEGW-U whenever the UE is activated. Activation means here that the UE is on and has performed authentication. A UE device has a default bearer for each SAEGW-U to which it connects. For example, if user equipment connects to the Internet through one SAEGW-U and a corporate intranet through another SAEGW-U, two default bearers will be active. Default bearers are best-effort. The UE can establish dedicated bearers to the SAEGW-U that can have different QoS requirements, such as a guaranteed bit rate (GBR). |
eNodeB |
The hardware (typically in a radio tower) that connects directly to the UE over the air and to the wireless network core. Also called evolved Node B or E-UTRAN Node B. Some of the eNodeB functions include:
|
GTP |
The GPRS tunneling protocol governs the creation and use of GTP tunnels that carry traffic between two GPRS support nodes (GSNs). Each GTP tunnel is identified by a TEID. The receiving end of a tunnel assigns locally the TEID that the transmitting side uses. The tunnel endpoints on the nodes exchange messages to communicate the TEID values to each other. |
GTP-C |
The GPRS tunneling protocol, control plane. GTP-C tunnels carry packet data units and signaling messages in the control plane from eNodeBs to MMEs to the SAEGW-C. |
GTP-U |
The GPRS tunneling protocol, user plane. GTP-U tunnels carry packet data units and signaling messages in the user (data) plane (S1-U interface) between tunnel endpoints on the eNodeB and the SAEGW-U. |
S11 |
The GTPv2-based control plane interface that connects the MME and the SAEGW-C. GTP-C tunnels carry control messages. An S11 interface can support multiple MMEs. |
S1-MME |
The GTPv2-based control plane interface that connects eNodeB and the MME. |
S1-U |
The GTPv1-based user plane interface that connects eNodeB and the SAEGW-U. S1-U is also called the data plane interface. GTP-U tunnels on the interface carry user payloads. An S1-U interface can support multiple eNodeBs. |
S5/8-U |
The GTPv1-based user plane interfaces that connects SGW-U and PGW-U. S5-U and S8-U interfaces are functionally the same; the S5-U connects an SGW-U in the home network to the PGW-U in the home network while the S8-U connects and SGW-U in a roaming network to the home PGW-U. |
SAEGW |
The System Architecture Evolution gateway that includes the functions of both the SGW and the PGW. |
TEID |
A tunnel endpoint identifier that uniquely identifies a GTP tunnel endpoint in the scope of a path. A fully qualified TEID consists of an IP address concatenated with a locally allocated identifier. Four TEIDs are defined, together they uniquely identify a default bearer session:
|
UE |
The user equipment that connects to the wireless network’s eNodeB and to the subscriber’s network. UE corresponds to what is called CPE in other contexts. In some cases, the UE consists of a SIM card and a residential gateway router (RG) that can host the SIM. In other cases the SIM might be in a separate device that connects to the RG. |