Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

CUPS Session Creation and Data Flow with Junos Multi-Access User Plane

With the introduction of CUPS, it’s useful to illustrate how an end-user session is created, how data flows during the session, and how the session is terminated with Junos Multi-Access User Plane.

CUPS Session Creation

Note:

Before a CUPS session can be created, the control plane function (SAEGW-C, SGW-C, PGW-C) must create an Sx association with the user plane function (SAEGW-U, SGW-U, PGW–U). The control plane sends an Sx Association Setup Request​ message and the user plane responds with an Sx Association Setup Response message to create the association. Once this is done, the control plane can create Sx sessions on the user plane.

When an end user wants to access the network, a CUPS session must be created. Figure 1 illustrates this process once an Sx association is established between an SAEGW-C and an SAEGW-U.

Figure 1: CUPS Session Creation for SAEGW-C and SAEGW-UCUPS Session Creation for SAEGW-C and SAEGW-U
  1. The user equipment (UE) sends an Attach Request to the eNodeB, which forwards the message to the mobility management entity (MME). The request includes the APN.
  2. The MME sends a Create Session Request to the SAEGW-C.
  3. The SAEGW-C performs the following actions:

    • Validates information elements received in the request.

    • Validates the APN requested by the subscriber.

    • Sends a Sxab Session Establishment Request to the routing engine (RE) of the MX SAEGW-U.

    Note:

    Sx session establishment is the SAEGW-C messaging the SAEGW-U control parameters on how to behave when the SAEGW-U encounters certain traffic. The minimum control parameters for Sx session establishment are one packet detection rule (PDR) and one forwarding action rule (FAR) The Sx session establishment effectively logs in the subscriber.

  4. The RE of the SAEGW-U performs the following actions:

    • Identifies the IP address for the session.

    • Selects and anchor PFE to use for the session.

    • Allocates the bearer GTP-U tunnel IDs.

    • Adds the session to the anchor PFE.

    • Sends a Sxab Session Establishment Response back to the SAEGW-C.

  5. The SAEGW-C sends a Create Session Response back to the MME.
  6. The MME sends an Attach Accept message to the UE, which responds with an Attach Complete message.
  7. The MME sends a Modify Bearer request to the SAEGW-C, which sends an Sxab Session Modification Request to the RE on the SAEGW-U. The RE updates the session IP address and tunnel ID of the eNodeB. Finally, a Modify Bearer Response is routed back to the MME.
    Note:

    Sx Session Modification Request is the SAEGW-C messaging the SAEGW-U to modify any of the following four rules:

    • Packet Detection Rule (PDR): contains information describing which packets should receive which treatment (for example, forwarding and other types of enforcement)

    • Forwarding Action Rule (FAR): contains information on whether forwarding, dropping, or buffering is applied to a packet

    • Usage Reporting Rule (URR): contains information that defines a certain measurement to make on user traffic and how that measurement shall be reported

    • Quality Enforcement Rule (QER): contains information related to QoS enforcement of traffic

    Junos Multi-Access User Plane does not support Buffering Action Rules (BARs).
  8. The default bearer is now active and subscriber data traffic can pass back and forth between the UE through the eNodeB to the SAEGW-U and then the core network.

CUPS Session Data Flow

Once the session is established, the SAEGW-C is no longer directly involved for data flow. Data flows directly back and forth from the UE through the eNodeB to the SAEGW-U and then the core network. See Figure 2.

Figure 2: CUPS Session Data FlowCUPS Session Data Flow
  1. The UE sends data to the eNodeB, which encodes the data as a GTP-U packet and forwards that packet to the anchor PFE on the SAEGW-U by way of the S1-U interface.
  2. The anchor PFE of the SAEGW-U performs the following actions:

    • Decapsulates the GTP-U packet.

    • Performs PCC rule lookup to apply QoS and reporting actions.

    • Forwards the decapulated IPv4 packet to the core network over the SGi interface.

  3. The SAEGW-U receives a downlink IPv4 packet from the core network.
  4. The anchor PFE performs the following actions:

    • Performs PCC rule lookup to determine the bearer GTP-U tunnel.

    • Applies QoS and reporting actions.

    • Encapsulates the IPv4 packet in GTP-U.

    • Forwards the GTP-U packet to the eNodeB, which decapsulates the packet and forwards the data to the UE.

  5. The SAEGW-U also creates a usage report for the session and sends the report to the SAEGW-C over the Sxab interface.

Charging and Usage Reports

Junos Multi Access User Plane supports charging and usage reports according to 3GPP TS 23.203, Policy and charging control architecture. Junos Multi Access User Plane supports the following usage reports:

  • Volume threshold only

  • Volume quota only

  • Volume threshold and volume quota

Junos Multi Access User Plane uses the following process to generate usage reports:

  1. The SAEGW-U creates a rating group for each bearer (default or dedicated). Routing groups can be created per session data flow (SDF) or for an entire bearer consisting of many SDFs.
  2. The SAEGW-C associates a Usage Reporting Rule (URR) ID with a PDR and sends the URR ID over the Sx interface.
  3. The SAEGW-U associates the URR ID with a rating group.
  4. The SAEGW-C also messages what type of report needs to be generated for the URR ID (volume threshold only, volume quota only, volume threshold and quota).
  5. The default action when the volume quota is reached is to drop all traffic for the session data flow.
  6. When the subscriber session ends, the SAEGW-U generates and sends a final usage report to the SAEGW-C.
    Note:

    The SAEGW-U supports pausing charging measurements for any URR ID where the SAEGW-C sets the Inactive Measurement flag of the Measurement Information IE of the URR. The SAEGW-U also supports sending immediate reports to the SAEGW-C on a URR query or remove request from the SAEGW-C; the SAEGW-U sends the usage report in the Modify Response.

Handover between eNodeBs and no SGW or SAEGW Change

Starting with Junos OS 20.4R1, Junos Multi Access User Plane supports UE mobility.

Figure 3 shows the entire handover process when a UE switches from one eNodeB to another without requiring a SGW or SAEGW change (i.e., both eNodeBs are served by the same SGW). This is the simplest version of mobility handover.

Figure 3: Handover between eNodeBsHandover between eNodeBs

The following steps describe just the interactions between the control plane and user plane functions of the SGW and PGW (steps 15-17 in Figure 3).

Step 15: Target MME to Target SGW Modify Bearer Request

  1. SGW-C sends Sx Session Modification Request to MX SGW-U. The message includes F-TEIDu(s) corresponding to the new eNodeB. It may also instruct MX SGW-U to send “end marker” message towards the new eNodeB.
  2. If requested to do so, MX SGW-U sends “end marker” message on S1-U interface towards the old eNodeB for all bearers referred to by Sx Session Modification Message.
  3. MX SGW-U updates downlink peer F-TEID in the bearer(s) to F-TEIDu(s) received in the Sx Session Modification Request.
  4. MX SGW-U sends Sx Session Modification Response to SGW-C

Step 16: Target SGW to PGW Modify Bearer Request

Note:

This step doesn’t affect any F-TEIDu assignments on any of the bearers. It may however update other forwarding & charging parameters based on the new location of the UE.

  1. PGW-C sends Sx Session Modification Request to MX PGW-U.

  2. MX PGW-U updates corresponding bearers and sends Sx Session Modification Response to PGW-C.

Handover with SGW Change

Considering the CUPS model, there are two types of procedures involving SGW change:

  • Type 1: Only Create Session Request message is sent from MME/SGSN to SGW-C during SGW change.

  • Type 2: Create Session Request message followed by Modify Bearer Request message is sent from MME/SGSN to SGW-C during SGW change.

For the MX SGW-U, the main difference between these two types is that in the first, the new SGW-C is provided with both eNodeB and PGW F-TEIDu(s) within Create Session Request, while in the second, the eNodeB’s F-TEIDu(s) are provided in the Modify Bearer Request, which translates to one extra Sx Session Modify Request/Response exchange between SGW-C and SGW-U. Because Type 1 can be considered a subset of Type 2, we present here the process for Type 2 handover.

Figure 3 shows the entire handover process when a UE switches from one eNodeB to another with requiring a SGW change. The following steps describe just the interactions between the control plane and user plane functions of the SGW and PGW (steps 4,4a, 15-17 and 19 in Figure 3).

Step 4: Target MME to Target SGW Create Session Request

  1. The target SGW-C sends Sx Session Establishment Request to the target MX SGW-U. If PGW-U is a different physical node than the target SGW-U, the message includes F-TEIDu(s) of the PGW-U for every bearer of the session. It does not include local F-TEIDu(s) since MX SGW-U only supports UP function allocated local F-TEIDu.
  2. The target MX SGW-U creates a new session and allocates local F-TEIDu(s) for all bearers indicated in Sx Session Establishment Request. If the message included PGW-U’s F-TEIDs, we use them to set uplink peer F-TEIDu(s) for all referenced bearers.
  3. The target MX SGW-U sends Sx Session Establishment Response message to the target SGW-C.

Step 15: Target MME to Target SGW Modify Bearer Request

  1. The target SGW-C sends Sx Session Modification Request to the target MX SGW-U. The message includes F-TEIDu(s) for all bearers corresponding to the new eNodeB.

  2. The target MX SGW-U updates downlink peer F-TEID in the bearer(s) to F-TEIDu(s) received in the Sx Session Modification Request.

  3. MX SGW-U sends Sx Session Modification Response to SGW-C.

Step 16: Target SGW to PGW Modify Bearer Request

  1. PGW-C sends Sx Session Modification Request to MX PGW-U. The message includes F-TEIDu(s) of the target SGW-U for all bearers. It may also instruct MX PGW-U to send “end marker” message.

  2. If instructed to do so, MX PGW-U sends “end marker” message towards old SGW-U.

  3. MX PGW-U updates downlink peer F-TEID for all the referenced bearers to F-TEIDu(s) received in the Sx Modification Request Message

  4. MX PGW-U sends Sx Session Modification Response to the target SGW-C.

Step 19: Source MME to Source SGW Delete Session Request

  1. Source SGW-C sends Sx Session Delete Request to the source MX SGW-U.

  2. Source MX SGW-U deletes all bearers and the session.

  3. Source MX SGW-U sends Sx Session Delete Response to the source SGW-C.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
20.4R1
Starting with Junos OS 20.4R1, Junos Multi Access User Plane supports UE mobility.