The following flow describes how APN is used as a key for selecting a particular User Plane group.

     APN → Associated IP Pool → Associated User Plane Profile ID → User Plane Profile 

Every APN is configured with both the associated IPv4 and IPv6 pools. Also, all configured IP pools under APN configuration are associated with the same User Plane group, which contains information related to User Plane IP address and User Plane capabilities. In case Control Plane has to communicate with the same User Plane for all APNs, the IPv4 and IPv6 Pool configuration under APN configuration is not required.

NOTES:

• Control Plane can be configured to communicate with multiple User Planes.

• There is 1-n mapping between the User Plane and APN.

• Multiple APNs can be reached through the same User Plane but for every APN, there can be only one associated User Plane.

The following flow describes how APN is used as key for selecting a particular User Plane group. The APN profile must be configured with associated User Plane group, which contains information related to User Plane IP address and User Plane capabilities.

     APN Profile → Associated User Plane Profile ID → User Plane Group 

The following call flow illustrates, at a high-level, the initial attach procedure for a Pure-P PDN.

1. For CUPS SAEGW Pure-P call, SAEGW-PGW-C does the following:

   • After Gx interaction, performs Gx communication (CCR-I and CCA-I).

   • Performs User Plane selection based on user-plane-profile configured with IP Pool (APN associated with IP Pool).

   • Establishes GTP-U session (required for RA/RS, in case of IPv6/IPv4v6 PDN).

   • Performs Sxb interaction with selected User Plane.

2. Sx Establishment Request contains the following information:

   • Create PDR/FAR/URR information for Uplink and Downlink data path: For dynamic/pre-defined/static rules.

   • Create PDR/FAR for RA/RS: Required for IPv6/IPv4v6 PDN Type.

   Important

   Create Uplink PDR is sent with "Outer Header Removal" based on IP address information in "S5/S8-U S-GW F-TEID". Create Downlink FAR is sent with "Outer Header Creation" as "S5/S8-U S-GW F-TEID".

   • Additionally, Control Plane requests User Plane to allocate F-TEID for P-GW Ingress PDR "S5/S8-U P-GW F-TEID"

3. User Plane provides following information as part of Sx Session Establishment Response:

   • Created PDR: P-GW Ingress PDR "S5/S8-U P-GW F-TEID"

4. On receipt of Sx Session Establishment Response, the SAEGW-PGW-C sends Create Session Response toward S-GW with "S5/S8-U P-GW F-TEID"

Following call flow illustrates, at a high-level, the initial attach procedure for a Pure-S PDN.

1. For CUPS SAEGW Pure-S call, the SAEGW-SGW-C does the following:

   • Performs User Plane selection based on APN profile.

   • Performs Sxa interaction with selected User Plane.

   • No GTP-U interaction (Note that it is required for non-CUPS behavior).

2. Sx Session Establishment Request contains following information:

   • Create PDR/FAR for S-GW Uplink and Downlink data path.

   • Aditionally, Control Plane requests User Plane to allocate F-TEID for:

     • S-GW Ingress PDR "S1-U S-GW F-TEID"

     • S-GW Egress PDR "S5/S8-U S-GW F-TEID"

3. User Plane provides following information as part of Sx Session Establishment Response:

   • Created PDR: S-GW Ingress PDR "S1-U S-GW F-TEID"

   • Created PDR: S-GW Egress PDR "S5/S8-U S-GW F-TEID"

4. On receipt of Sx Session Establishment Response, the SAEGW-SGW-C sends Create Session Request toward P-GW with "S5/S8-U S-GW F-TEID"

5. On receipt of Create Session Response, the SAEGW-SGW-C does the following:

   • Trigger Sx Session Modification Request:

     • To update Uplink FAR with "Outer Header Creation" as "S5/S8-U P-GW F-TEID".

     • To update Downlink PDR with "Outer Header Removal" based on IP address information in "S5/S8-U P-GW F-TEID".

6. On receipt of Sx Session Modification Response, the SAEGW-SGW-C sends Create Session Response toward MME with "S1-U S-GW F-TEID" and "S5/S8-U P-GW F-TEID".

7. On receipt of Modify Bearer Request (MBR), the SAEGW-SGW-C does the following:

   • MBR is consumed by S-GW node. No GTP signaling toward P-GW node.

   • Trigger Sx Session Modification Request:

     • To update Downlink FAR with "Outer Header Creation" as "S1 eNodeB F-TEID".

     • To update Uplink PDR with "Outer Header Removal" based on IP address information in "S1 eNodeB F-TEID".

8. On receipt of Sx Session Modification Response, the SAEGW-SGW-C sends MBR with "S1-U S-GW F-TEID".

The following call flow illustrates, at a high-level, the initial attach procedure for Collapsed PDN.

1. For CUPS SAEGW collapsed call, SAEGW-C does the following:

   • After Gx interaction, performs Gx communication (CCR-I and CCA-I).

   • Performs User Plane selection based on user-plane-profile configured with IP Pool (APN associated with IP Pool).

   • Establishes GTP-U session (required for RA/RS, in case of IPv6/IPv4v6 PDN).

   • Performs Sxab interaction with selected User Plane.

2. Sx Establishment Request contains the following information:

   • Create PDR/FAR information for S-GW Uplink and Downlink data path (Sxa Type PDR).

   • Create PDR/FAR/URR information for Uplink and Downlink data path (Sxb Type PDR): For dynamic/pre-defined/static rules.

   • Create PDR/FAR for RA/RS (Sxb Type PDR): Required for IPv6/IPv4v6 PDN Type.

   • Additionally, Control Plane requests User Plane to allocate F-TEID for:

     • S-GW Ingress "S1-U S-GW F-TEID",

     • S-GW Egress "S5/S8-U S-GW F-TEID", and

     • P-GW Ingress PDR "S5/S8-U P-GW F-TEID"

3. User Plane provides following information as part of Sx Session Establishment Response:

   • Created PDR: S-GW Ingress PDR "S1-U S-GW F-TEID",

   • Created PDR: S-GW Egress PDR "S5/S8-U S-GW F-TEID", and

   • Created PDR: P-GW Ingress PDR "S5/S8-U P-GW F-TEID"

4. On receipt of successful Sx Session Establishment Response, the Control Plane triggers Sx Modification Request with the following information:

   • To update P-GW (Sxb) "Uplink PDR" with "Outer Header Removal" based on IP address information in "S5/S8-U S-GW F-TEID"

   • To update P-GW (Sxb) "Downlink FAR" with "Outer Header Creation" as "S5/S8-U S-GW F-TEID"

   • To update S-GW (Sxa) "Uplink FAR" with "Outer Header Creation" as "S5/S8-U P-GW F-TEID"

   • To update S-GW (Sxa) "Downlink PDR" with "Outer Header Removal" based on IP address information in "S5/S8-U P-GW F-TEID"

5. On receipt of Sx Session Modification Response, the SAEGW-C sends Create Session Response toward MME with "S1-U S-GW F-TEID" and "S5/S8-U P-GW F-TEID".

6. On receipt of Modify Bearer Request (MBR), the SAEGW-C does the following:

   • Trigger Sx Session Modification Request:

     • To update Downlink FAR with "Outer Header Creation" as "S1 eNodeB F-TEID".

     • To update Uplink PDR with "Outer Header Removal" based on IP address information in "S1 eNodeB F-TEID".

7. On receipt of Sx Session Modification Response, the SAEGW-SGW-C sends MBR with "S1-U S-GW F-TEID".

Following call flow illustrates, at a high-level, the detach procedure for UE initiated Pure-P PDN.

1. On receipt of Delete Session Request , the SAE-GW-C performs Sxab interaction to update FAR with the Apply Action as "DROP" for both Uplink and Downlink data path.

2. On receipt of Sx Session Modification Response, SAE-GW-C sends Delete Session Response towards MME.

3. For CUPS SAEGW Pure-P call, the SAEGW-PGW-C does the following:

   • Removes GTP-U session (required for RA/RS in case of IPv6/IPv4v6 PDN).

   • Performs Sxb interaction with the selected User Plane.

4. On receipt of Sx Session Deletion Response, the SAEGW-PGW-C does the following:

   • Performs Gx communication (CCR-T and CCA-T).

   • Generates CDR (Gz) based on URR information received.

Following call flow illustrates, at a high-level, the detach procedure for network initiated Pure-P PDN.

1. On receipt of the Delete Bearer Request (RAR initiated or by the clear sub all CLI, the SAEGW-PGW-C performs Sxb interaction to update FAR with the Apply Action as "DROP" for both Uplink and Downlink data path.

2. On receipt of Sx Session Modification Response, SAEGW-PGW-C sends the Delete Bearer Request toward SGW.

3. For CUPS SAEGW Pure-P call, the SAEGW-PGW-C does the following:

   • Removes GTP-U session (required for RA/RS in case of IPv6/IPv4v6 PDN).

   • Performs Sxb interaction with the selected User Plane.

4. On receipt of Sx Session Deletion Response, the SAEGW-PGW-C does the following:

   • Performs Gx communication (CCR-T and CCA-T).

   • Generates CDR (Gz) based on URR information received.

Following call flow illustrates, at a high-level, the detach procedure for UE initiated Pure-S PDN.

1. On receipt of Delete Session Request, the SAEGW-SGW-C performs Sxa interaction to "Update FAR" with Apply Action as "DROP" for both Uplink and Downlink data path.

2. On receipt of Sx Session Modification Response, the SAEGW-SGW-C sends Delete Session Request toward the P-GW.

3. On receipt of Delete Session Response, the SAEGW-SGW-C performs Sxa interaction to delete Sx session.

4. On receipt of Sx Session Deletion Response, the SAEGW-SGW-C sends Delete Session Response toward the MME.

Following call flow illustrates, at a high-level, the detach procedure for network initiated Pure-S PDN.

1. On receipt of Delete Bearer Request, the SAEGW-SGW-C performs Sxa interaction to "Update FAR" with Apply Action as "DROP" for both Uplink and Downlink data path.

2. On receipt of Sx Session Modification Response, the SAEGW-SGW-C sends Delete Bearer Request toward the MME.

3. On receipt of Delete Session Response from MME, the SAEGW-SGW-C performs Sxa interaction to delete Sx session.

4. On receipt of Sx Session Deletion Response, the SAEGW-SGW-C sends Delete Bearer Response toward the P-GW.

Following call flow illustrates, at a high-level, the detach procedure for UE initiated Collapsed PDN.

1. On receipt of Delete Session Request, the SAEGW-C performs Sxab interaction to update FAR with Apply Action as "DROP" for both Uplink and Downlink data path.

2. On receipt of Sx Session modification Response, SAEGW-C sends Delete Session Response towards MME.

3. For CUPS SAEGW Collapsed call, the SAEGW-C does the following:

   • Removes GTP-U session (required for RA/RS in case of IPv6/IPv4v6 PDN).

   • Performs Sxab interaction with the selected User Plane.

4. On receipt of Sx Session Deletion Response, the SAEGW-C does the following:

   • Performs Gx communication (CCR-T and CCA-T).

   • Generates CDR (Gz) based on URR information received.

Following call flow illustrates, at a high-level, the detach procedure for network initiated Collapsed PDN.

1. On receipt of Delete Bearer Request (RAR initiated or by the clear sub all CLI), SAEGW-C performs Sxab interaction to update FAR with Apply Action as "DROP" for both Uplink and Downlink data path.

2. On receipt of Sx Session Modification Response, SAEGW-C sends Delete Bearer Request toward MME.

3. For CUPS SAEGW Collapsed call, the SAEGW-C does the following:

   • Removes GTP-U session (required for RA/RS in case of IPv6/IPv4v6 PDN).

   • Performs Sxab interaction with the selected User Plane.

4. On receipt of Sx Session Deletion Response, the SAEGW-C does the following:

   • Performs Gx communication (CCR-T and CCA-T).

   • Generates CDR (Gz) based on URR information received.

1. UE initiates an attach procedure through the first PDN. S-GW forwards the Create Session Request with IMSI, APN, EBI, and APN AMBR UL/DL along with other mandatory parameters to PGW-C to establish a PDN connection.

2. PGW-C sends a Credit-Control-Request (Initial) to PCRF.

3. PCRF responds with Credit-Control-Answer (Initial) to PGW-C with APN AMBR UL/DL and install dynamic/predefined rule with QCI ARP different from default QoS.

4. On receiving Credit-Control-Answer (Initial) from PCRF, PGW-C initiates a Sx Session Establishment Request to PGW-U with Create PDR for default bearers with choose ID - x, and Create PDR for dedicated bearer with choose ID - y.

5. P-GW-U responds with Sx Session Establishment Response to PGW-C with list of created PDR’s and the PGW-U local FTEID’s.

6. P-GW-C sends Create Session Response to S-GW for first PDN connection setup.

7. P-GW sends Create Bearer Request to S-GW with the P-GW’s Data FTEID filled in the bearer Context.

8. S-GW sends Create Bearer Response with Remote data FTEID. On receiving the same, Sx modify request is initiated towards UP function, to send update FAR for all downlink FAR’s, with the remote F-TEID’s.

9. P-GW-U responds with an Sx Session Modification Response to P-GW-C.

Following call flow illustrates, at a high level, bearer creation due to MBR/MCmd/CCA-U and RAR:

1. On receiving Credit-Control-Answer (Update) or Re-Authorization Request from PCRF, P-GW-C initiates Sx Session Modification Request to P-GW-U with Create PDR for default bearer with choose ID - x, and Create PDR for dedicated bearer with choose ID - y.

2. P-GW-U responds with Sx Session Modification Response to P-GW-C with list of created PDR’s and the P-GW-U local FTEID’s.

3. P-GW sends Create Bearer Request to S-GW with the P-GW’s Data FTEID filled in bearer Context.

4. S-GW sends Create Bearer Response with Remote data FTEID. On receiving the same, Sx modify request is initiated towards UP function, to send update FAR for all downlink FAR’s, with the remote F-TEID’s.

5. P-GW-U responds with an Sx Modification Response to P-GW-C.

Following call flow illustrates, at a high level, bearer creation for collapsed call:

1. UE initiates attach procedure through first PDN.SGW-C forwards the Create Session Request with IMSI, APN, EBI, and APNAMBR UL/DL along with other mandatory parameters to PGW-C to establish a PDN connection.

2. PGW-C sends Credit-Control-Request (Initial) to PCRF.

3. PCRF responds with Credit-Control-Answer (Initial) to PGW-C with APN AMBR UL/DL and install dynamic/predefined rule with QCI ARP different from default QoS.

4. On receiving Credit-Control-Answer (Initial) from PCRF, PGW-C initiates Sx Session Establishment Request to SAEGW-U with Create PDR for default bearer with choose ID x and Create PDR for dedicated bearer with choose ID y.

5. SAEGW-U responds with Sx Session Establishment Response to PGW-C with list of created PDR’s and the PGW-U local FTEID’s.

6. SAEGW-U responds with Sx Session Establishment Response to PGW-C with list of created PDR’s and the PGW-U local FTEID’s.

7. PGW-C sends Create Session Response to SGW-C for first PDN connection setup.

8. PGW-C sends Create Bearer Request to SGW-C with the PGW’s Data FTEID filled in bearer Context.

9. SGW-C receives Modify bearer request with eNodeB TEID’s for which Sx transaction is initiated.

10. SGW-C receives Create Bearer Response with Remote data FTEID. On receiving the same, Sx modify request is initiated towards UP function, to send update FAR for all downlink FAR’s, with the remote F-TEID’s.

11. SAEGW-U responds with Sx Session Modification Response to PGW-C.

Following call flow illustrates, at a high level, bearer creation with piggybacking enabled for a collapsed call:

1. UE initiates attach procedure through first PDN.SGW-C forwards the Create Session Request with IMSI, APN, EBI, and APNAMBR UL/DL along with other mandatory parameters to PGW-C to establish a PDN connection.

2. PGW-C sends Credit-Control-Request (Initial) to PCRF.

3. PCRF responds with Credit-Control-Answer (Initial) to PGW-C with APN AMBR UL/DL and install dynamic/predefined rule with QCI ARP different from default QoS.

4. On receiving Credit-Control-Answer (Initial) from PCRF, PGW-C initiates Sx Session Establishment Request to SAEGW-U with Create PDR for default bearer with choose ID x and Create PDR for dedicated bearer with choose ID y.

5. SAEGW-U responds with Sx Session Establishment Response to PGW-C with list of created PDR’s and the PGW-U local FTEID’s.

6. Sx modification request is triggered to update the PDR and FAR for both default and dedicated bearers.

7. PGW-C sends Create Session Response to SGW-C for first PDN connection setup.

8. PGW-C sends Create Bearer Request to SGW-C with the PGW’s Data FTEID filled in bearer Context, which is buffered at SGW-C until PDN is fully connected.

9. SGW-C receives Modify bearer request with eNodeB TEID’s for which Sx transaction is initiated.

10. SGW-C received Create Bearer Response with Remote data FTEID. On receiving the same, Sx modify request is initiated towards UP function, to send update FAR for all downlink FAR’s, with the remote F-TEID’s.

11. SAEGW-U responds with Sx Session Establishment Response to PGW-C.

Following call flow illustrates, at a high level, command call flow for a Pure P call:

1. UE initiates detach procedure through first PDN.SGW-C forwards the Delete Bearer Command to PGW-C to delete set of dedicated bearers.

2. PGW-C sends an Sx modification Request with All Update FAR for dedicated bearer’s with apply action as DROP.

3. PGW-U responds with Sx Session modification Response to PGW-C.

4. PGW-C Sends Delete Bearer Request to access side and on receiving Delete Bearer Response, Sx modification request is triggered to remove the PDR and FAR for dedicated bearers.

Following call flow illustrates, at a high level, Clear Subscriber EBI for a Pure P call:

1. PGW-C initiates detach procedure through first PDN.

2. PGW-C sends a Sx modification Request with All Update FAR for dedicated bearer’s with apply action as DROP.

3. PGW-U responds with Sx Session modification Response to PGW-C.

4. PGW-C Sends Delete Bearer Request to access side and on receiving Delete Bearer Response, Sx modification request is triggered to remove the PDR and FAR for dedicated bearers.

Following call flow illustrates, at a high level, PCRF initiated delete for a Pure P call:

1. PCRF performs Rule-removal, which leads to dedicated bearer deletion.

2. PGW-C initiates Sx modification Request with All Update FAR for dedicated bearer’s with apply action as DROP.

3. PGW-U responds with Sx Session modification Response to PGW-C.

4. PGW-C Sends Delete Bearer Request to access side and on receiving Delete Bearer Response, Sx modification request is triggered to remove the PDR and FAR for dedicated bearers.

Dedicated Bearer Creation and Deletion and Modification (updating) has the following limitations:

• Dedicated bearer creation for Pure S call is not supported.

• During collision scenarios session clean-up is triggered when events/operations are requested for a bearer, for which deletion is already in progress. For example, a CCA-U/RAR (EBI = 6) is received during an on going DELETE_BEARER_COMMAND (EBI = 6).

Addition, Deletion and Updation of Dedicated Bearers for Pure-S calls is supported in the CUPS architecture.

The following functionality is added in support of this feature:

• SAEGW-CP supports Create Bearer Request for dedicated bearer for Pure-S Call.

• SAEGW -CP supports multiple bearer contexts in single Create Bearer Request.

• SAEGW-CP supports multiple Create Bearer request in parallel for different PDN; these PDN can be Pure-S PDN or Collapsed and Pure-S combinations.

• SAEGW-UP creates uplink and downlink bearer stream at VPP for Pure-S call per bearer. Number of streams per direction depends on the GTP-U Service IP address.

• SAEGW-CP supports Release Access Bearer Request (RAB) with dedicated bearer, all FAR corresponding to all bearer is modified.

• SAEGW-CP supports Modify Bearer Request (Idle mode, Connected mode) with dedicated bearer.

• SAEGW-CP supports Create Bearer Response Failure handling from MME.

• SAEGW-CP and SAEGW-UP supports DSCP marking for default and dedicated bearer with VPP.

• SAEGW-CP and SAEGW-UP supports Delete Bearer Request for dedicated bearer. SAEGW-UP removes bearer stream and TEP entries belonging to those bearers.

• SAEGW-CP supports Pure-S Dedicated Bearer Creation when call is in IDLE state.

• SAEGW-CP supports Pure-S Dedicated Bearer S-GW Relocation (both X2 and S1-based).

• SAEGW-CP supports Pure-S Dedicated Bearer Update success scenarios.

• SAEGW-CP supports Piggybacking of Create Bearer Request for dedicated bearer for Pure-S call along with Create Session Response.

• SAEGW-CP supports Piggybacking of Create Bearer Response for dedicated bearer for Pure-S call with Modify Bearer Request.

• SAEGW-CP supports Pure-S Dedicated Bearer Creation if P-GW receives bearer creation as part of CCA-I, where P-GW does not send Piggyback request, which results in Create Session Response followed by Create Bearer Request.

• SAEGW-CP supports Session Recovery and ICSR with Pure-S dedicated bearer.

• SAEGW-CP supports Create Bearer Request and Delete Bearer Request (default bearer) collision.

• SAEGW-CP supports Create Bearer Request and Delete Session Request collision.

• SAEGW-CP supports Create Bearer Response and Delete Bearer Request (default bearer) collision.

• SAEGW-CP supports Create Bearer Response and Delete Session Request collision.

• SAEGW-CP supports End Marker with Pure-S default and dedicated bearer.

• SAEGW-UP supports Session Recovery with Pure-S default and dedicated bearer.

• SAEGW-UP supports movement of IP transport from IPv4 to IPv6, or IPv6 to IPv4, during IDLE->Active and Handover procedure on S1U interface. Transport selected on S1U at the time of Attach is supported. For example, eNode handover from IPv4 eNodeB to IPv6 eNodeB will work.

• SAEGW-CP supports CBRsp with Cause Partially Accepted and Context Not Found.

• SAEGW-CP supports Downlink Data Notification for Pure-S Call, so when UE moves to IDLE state for Pure-S call, FAR action is set as BUFFER.

• SAEGW-CP supports Update Bearer Response with cause PARTIALLY_ACCEPTED and context not Found.

• SAEGW-CP supports the Error and Failure handling from other peer nodes including User Plane node.

This section covers S-GW relocation call flows for X2 based handover, when OI is set to 1.

This section covers S-GW relocation call flows for S1 based handover, when OI is set to 0.

• Control Plane function sends a list of URRs in the Sx Session Establishment request, along with their references in corresponding PDRs.

• The CCR/CCA-I message exchange happenes by the time the Sx-Session-Establishment request is generated by the CP, and the quota for the Dynamic-Rules and Pre-emptive MSCCs is received from the OCS.

• When a Rule-Modification/install occurs from PCRF in mid-session, then the Sx Session Modification request is used to provision the PDRs and URRs. When creating the URR in the mid-session, if the Quota information is not present in the OCS, then the “Start-of-Packet” trigger is set along with the Measurement Methods: Time & Volume.

• On the arrival of the first packet, the "Start-of-Packet" trigger is sent to the Control Plane for packet-detection, and the Control Plane initiates the Quota negotiation with the OCS server.

• The P-GW User Plane sends the URR information as part of Sx Session Delete Response.

• The P-GW Control Plane does the mapping of these URRs to corresponding MSCC buckets and uses existing framework to send the Credit-Control-Messages on the Gy/Ro interface.

• P-GW User Plane sends the URR information as part of the Sx Delete Response.

• PGW Control Plane maps these URRs to the corresponding MSCC buckets and use the existing framework to send the Credit-Control-Messages on the Gy/Ro interface.

P-GW User Plane sends the Usage report for triggers like volume, time-quota, threshold, validity-time, quota-hold-time and so on. P-GW Control Plane maps the URRs to the corresponding charging buckets (MSCC). It initiates the Credit-Control-Request Update for the respective MSCCs.

The URR reporting results in Credit-Control-Request-Update generation, depending on the trigger that is sent by the P-GW User Plane.

• When User Plane reports a URR for any trigger, it is first mapped to the MSCC bucket at the Control Plane. The values are updated in the MSCC data-structure.

• After the URR buckets are processed in the current reporting, the Control Plane analyzes the MSCC buckets that are being updated. It initiates the Credit-Control-Request Update request containing all the MSCC-buckets.

  Important

  For this release, the single MSCC-per-update feature is not supported.

The Failure-Handling configuration is to specify the action to be taken when a failure occurs during communication with the OCS server. The possible Failure-Handling configurations are Continue, Terminate, Retry, and Terminate. The Terminate and Retry-Terminate are solely at the Control Plane. For Continue, the following actions are performed:

• When the CCFH Continue action is applied, all the Gy URRs are disassociated and removed from the PDRs, so that no further reporting/charging occurs for the Online Charging.

• The "removeURR" IE is provisioned for all the Gy URRs to the User Plane, and the User Plane clears all the references to the URR and does the removal internally.

• Handling of MSCC level Error-Result-Codes is supported excluding the following mscc-result-codes: 4010, 4012, 5003, 5012, and 5031.

When the RAR request comes from the OCS server, the Control Plane sends the "QueryURR" for the required Charging-Buckets to the User Plane. When the User Plane sends back the URR report to the Control Plane, the Control Plane sends the CCR-Update for the FORCED_REAUTHORIZATION trigger.

When the Quota-Validity-Time is received for an MSCC bucket, the same is sent to the User Plane. Since there is no specific IE that can be used directly, the QVT value is filled in the Time-Quota IE, and URR is sent to the User Plane. The lesser QVT or Time-Quota is set in the Time-Quota IE. And, the Usage-Reporting from the User Plane for the Time-Quota trigger, the interpretation is made and the CCR-Update for the Validity-Timeout is generated.

The Server-Unreachable (SU) mechanism is configured on the Control-Plane (CP), for the Gy interface in order to resolve issues that are encountered on the Online Charging System (OCS) or with the connectivity between Policy and Charging Enforcement Function (PCEF) and OCS. The SU configuration provides the options to continue the session even after a failure by providing the option to use configurable interim quota (volume and/or time) and configurable server retries before a session is converted to offline or terminated.

A new Usage Reporting Rule (URR) bucket is created, which contains the SU quota when a Gy session goes into the SU state. The ID for the new URR is generated dynamically when the SU URR is allocated.

In a CUPS User Plane (UP) node, the existing Vector Packet Processor (VPP) streams are modified with a new LC record, which contains the updated SU URR bucket along with the existing set of charging buckets.

When the VPP streams are in the SU state, two quota rows are available, GyURR and SU URR. When GyURR is in the SU state with linked-usage-reporting trigger set, the quota row for the SU URR is linked to the VPP streams.

The following diagram describes the SU call flow in CUPS.

New Behavior in CUPS

The new SU mechanism in CUPS, are as follows:

• In a non CUPS architecture, where a single node (P-GW) processes the Gy session state and the data-traffic, an SU URR is created without any messaging delay. However, in the CUPS mode, the CP forms an additional node, which maintains information about the session state and handles any URR requests from the User Plane (UP). Only the CP can associate a Gy session with an SU URR. This messaging between UP and CP causes a delay and the data packets are treated according to the Pending-Traffic-Treatment configuration to complete the communication.

• In a non CUPS architecture, the SU state timer is processed in a different manner compared to the Time-Quota timer. After an SU quota is exhausted, the retry attempt to OCS occurs and a new next-interim-time-quota is started. However, in the CUPS mode, when the SU Time Quota is used and it is reported to CP for the Quota Exhaust, and if the session goes into Server-Unreachable state again, the time elapsed from the last Usage-Report is accounted in the usage.

• It's not recommended to use the servers-unreachable after-timer-expiry timeout_period CLI command in CUPS. Instead, use the servers-unreachable after-interim-time timeout_period server-retries retry_count to achieve similar behavior but with a single retry (set retry_count to 1).

Limit-reached-post-processing is a non-3GPP, proprietary behavior supported in both CUPS and non-CUPS architecture. This feature allows redirection or restriction operation implemented when the quota is exhausted for the charging-bucket, however, the OCS server is unable to grant the FUI-Redirect or FUI-Restrict. When using this feature, the operator can combine all the rule-matching criteria that are available—for example, to enable IMSI-based matching criteria, and so on—to selectively apply different handling for different subscribers/traffic. Use the following CLI commands to enable the feature.

configure 
   active-charging service service_name 
      rulebase rulebase_name 
         post-processing policy always 
         end 

Also, rule-application post-processing CLI command must be configured as limit-reached under ACS Ruledef configuration mode.

This feature allows the subscriber to use the network while waiting for the response from OCS. The Limited-Pass configuration allows to specify the Volume which the subscriber can consume while waiting for the quota-response from OCS. The usage is accounted in the respective charging bucket and are adjusted against the next-quota allocation.

Use the following CLI commands to enable the feature:

configure 
   active-charging service service_name 
      credit-control 
         pending-traffic-treatment noquota limited-pass volume volume 
         end 

Limited Pass Volume is used only for noquota case (Rating Group (RG) seeking quota for the first time) and not for quota-exhausted . Limited Pass Volume isn't used for subsequent credit requests.

The traffic is allowed to pass until the Limited-Pass Volume gets exhausted. The usage is counted in the respected charging-bucket and adjusted against the "Quota" granted. If the "Quota" allocation is less than the actual usage, immediate reporting towards OCS with the usage-report occurs requesting for more quota allocation. The subsequent incoming packets are handled as per the "quota-exhausted" PTT configuration.

If the Limited Pass Volume is NOT exhausted before the OCS responds with denial of quota, traffic is blocked after the OCS response. The gateway reports usage on Limited-Pass Volume even in for CCR-U (FINAL) (in non-CUPS) or CCR-T (for CUPS) until the OCS responds.

If the Limited Pass Volume is exhausted before the OCS responds, then the subsequent incoming packets for the session are dropped until quota is granted from OCS.

The default pending-traffic-treatment for noquota is Drop. The default pending-traffic-treatment noquota command removes any Limited Pass Volume size configured.

Pending-Traffic-Treatment (PTT) Quota-Exhausted Limited-Pass in CUPS architecture is an alternative to the Buffering option. The Buffering option has practical limitations in the high-speed network. Buffering requires packet buffering for large number of packets at the gateway, causing the risk to run out of memory and affecting the bandwidth speed. The PTT Quota-Exhausted Limited Pass allows the traffic to pass through until it reaches the configured limit on the Quota-Exhaust scenarios.

The PTT allows the traffic until the Limited-Pass volume exhausts. The PTT counts and adjusts the usage in the respected charging-bucket against the granted "Quota". If the "Quota" allocation is less than the actual usage, there’s immediate reporting towards OCS with the usage-report and asking for more quota allocation.

If the Limited-Pass Volume doesn’t exhaust before the OCS responds with denial of quota, there’s traffic blockage after the OCS response. Gateway reports the usage in CCR-U (FINAL).

If the Limited-Pass Volume exhausts before the OCS responds, then further incoming packets for the session are dropped until quota is granted from OCS.

The default behavior of pending-traffic-treatment for quota-exhausted is Drop. The default pending-traffic-treatment quota-exhausted CLI command removes any configured Limited-Pass Volume size.

Use the following CLI command to enable the feature:

configure 
   active-charging service service_name 
      credit-control 
         pending-traffic-treatment quota-exhausted limited-pass volume volume 
         end 

Note	The above CLI command is applicable only in CUPS architecture.

NOTES:

• limited-pass : Enables limited access to subscriber when OCS is unreachable.

• volume volume : Enables limited volume access to subscriber when OCS is unreachable. volume specifies the Default Quota size (in bytes) and must be an integer from 1 through 4294967295

• Only CCR/CCA-I , CCR/CCA-U and CCR/CCA-T, RAR/RAA messages are supported.

• Dynamic Rules with Online Enabled is supported; both at Session-Setup and Mid-Session.

• Predefined Rules (dynamic-only) is supported; both at Session-Setup and Mid-Session. No restriction on configuring the "preemptively request".

• Static-rules with Online Charging are supported.

• Ignore-service-id is supported.

• Volume-Quota/Volume-Threshold mechanisms are supported.

• Event-Triggers (through which the Query URR occurs), and sending of usage information to the OCS is supported.

  Important

  RAT-change functionality is not validated for this release.

• The "updateURR" procedure, through the Sx-Session-Modification procedure where the OCS grants a fresh Quota, is supported.

• Bearer-Level Gy and Subscriber-Level Gy is supported.

• Pending-Traffic-Treatment (PTT) Drop/Pass is supported with following limitations:

  • The scenarios supported for now are no-quota and quota-exhausted.

  • The trigger/re-authorization scenarios are not supported.

  • The PTT action (Forward/Drop) is considered after the quota-get is exhausted.

• Failure scenarios are qualified, which includes:

  • Failure-Handling Terminate, Continue and Retry, and Terminate: With CC-Group/FHT

  • Handling for the Error-Result-Codes (both at MSCC and Command level) is supported.

• Wall-Clock time-quota mechanism is supported.

• Other Time Quota Mechanisms (Discrete Time Period and Continuous-Time-Period) are not supported.

• Final-Unit-Indication Terminate mechanism is supported.

• FUI-Restrict is not supported.

• Mid-Session Rule Installation/Removal/Modification is supported.

• RAR mechanism is supported.

• Server-Unreachable (SU) mechanism is now supported with minor change in behavior compared to non-CUPS P-GW.

  • When an URR needs quota at UP, the usage-report is generated to CP and until the CP responds with the linked SU_URR, the packets matching this URR are treated with Pending-Traffic-Treatment configuration.

  • When the SU Time Quota is used and it's reported to CP for the Quota Exhaust, and if the session goes into Server-Unreachable state again, the time elapsed from the last Usage-Report is accounted in the usage.

• Pending-Traffic-Treatment Buffer mechanism is not supported.

• The “send-ccri on traffic-start” is supported.

• Quota-Hold-Time is supported.

• Quota-Consumption-Time mechanism is not supported.

• Quota-Validity-Time is supported.

• Triggering Gz records from Gy, when any event in Gy occurs, is supported; Gy-Gz sync is not supported.

• Triggering Rf records from Gy, when any event in Gy occurs, is not supported.

• Configuring different "rating-group" value other than the "content-id" is supported.

  • The RG 0 is not supported.

• Trigger to PCRF for the Out-of-Credit, Reallocation-of-Credit events are not qualified.

  Important

  Event-trigger Out-of-Credit towards PCRF is validated with a limitation of having only one time Grant-Quota (Keeping Total Volume and Granted Volume at same value).

• The delayed response from OCS for the CCR-I is supported.

• Service-Specific-Units are not supported.

• Tariff-Time change is supported as per 3GPP specification.

• Quota-Retry Timer is supported.

• The diameter mscc-final-unit-action terminate session CLI command under Credit Control Configuration mode is supported.

• FUI-Redirect is supported with following limitations:

  • Redirection for HTTPs is not supported.

  • The FUI-Redirect with Filter-IDs/Filter-Rules are not supported.

  • The WSP Protocol is not supported.

  • In accordance with 3GPP specification, the Redirected-Traffic also gets redirected if it hits the rule that is in FUI-Redirect. There is no provision to allow the redirected-traffic to pass through.

    • In accordance with 3GPP specification, the CUPS architecture adheres to no diameter fui-redirected-flow allow CLI command behavior.

  • The redirect-require-user-agent CLI command is not supported; the redirection continues to work even if the user-agent is not present.

  • Appending the original URL is not supported.

  • The diameter redirect-validity-timer immediate CLI command is supported. However, diameter redirect-validity-timer traffic-start CLI command is not supported.

  • Token based mechanism, to come out of Redirection, is not supported. To end the redirection in CUPS, OCS sends Redirect Validity-Time or RAR.

  • FUI-Redirection is supported only for the URL, similar to the behavior in non-CUPS architecture.

• Rulebase change from PCRF/OCS is supported.

• The URR information will be sent by PGW User-Plane as part of Sx Session Delete Response.

• P-GW Control Plane maps these URRs to the corresponding charging buckets and then use the existing framework to send the charging records on the respective interfaces like Gz, Gy, and so on.

P-GW User plane sends the Usage Report for triggers like Volume or Time-Threshold. P-GW Control Plane maps the URRs to the corresponding charging buckets.

URR reporting results in LOSDV bucket creation and P-GW CDR generation depending on the trigger sent by the P-GW User-Plane.

• If the bearer level URR is received, it results in generating the P-GW CDR for corresponding sub-session/bearer, along with reporting any existing LOSDV containers and the ones getting created as part of current report request. It is assumed that, when bearer level URR is received, User-Plane has sent all the SDF level URRs as well.

• When the SDF level URRs are received, they are stored as LOSDV containers. In this case the fbc_bucket is created with necessary counts or timestamps from the URR.