Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

Figure 1: 3GPP Evolved Packet Core Architecture3GPP Evolved Packet Core Architecture

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.

Figure 2: 3GPP Release 14 CUPS Architecture3GPP Release 14 CUPS Architecture

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.

Note:

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.

Figure 3: Junos Multi- Access User Plane SAEGW-UJunos Multi- Access User Plane SAEGW-U

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.

Figure 4: Junos Multi-Access User Plane SGW-U and PGW-UJunos Multi-Access User Plane SGW-U and PGW-U

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.

Note:

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.

Table 1: Junos Multi-Access User Plane Platform Support

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

  • MX240

  • MX480

  • MX960

  • MPC7

  • MPC2

  • MPC3

  • MPC4

  • MPC5

  • MPC7

  • RE-S-1800X4-32G-S

  • RE-S-X6-64G-S

  • RE-S-X6-128G

Starting in Junos OS Release 20.2R1

  • MX204

  • MX10003

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.

Table 2: Terminology for 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:

  • Network Identifier—This defines the external PDN that the user connects to through a SAEGW-U. This part of the APN is mandatory. It can be as simple as internet or have a more complicated structure such as example.net. The network identifier can optionally specify a requested subscriber service.

    Operator Identifier—(Optional) This defines the provider whose PDN the user connects to through a SAEGW-U. This part of the APN is often omitted. If present, it consists of the provider’s Mobile Network Code (MNC) and Mobile Country Code (MCC).

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:

  • fixed-wireless

  • web.example.net

  • internet.mnc99.mcc999.gprs

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:

  • Terminates the radio connection from the UE.

  • Locates the MME that authenticates the UE (SIM card) with information from the subscriber profile maintained on the HSS. Maintains S1-MME control plane connectivity.

  • Maintains the S1-U data plane interface with the SAEGW-U. An S1-U interface can support multiple eNodeBs.

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:

  • L-TEID-C and R-TEID-C consist of the IP addresses of the S11 endpoint interfaces and their respective allocated identifiers.

  • L-TEID-U and R-TEID-U consist of the IP addresses of the S1-U/S5-U/S8-U endpoint interfaces and their respective allocated identifiers.

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.

Release History Table
Release
Description
20.4R1
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.
20.4R1
Starting with Junos OS Release 20.4R1, Junos Multi-Access User Plane supports elements of 3GPP TS 29.244 Release 15.