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

• P-GW receives a Create Session Request message including an APN, on the S5/S8 interface.

• P-GW-C initiates an Sx establishment request on Sxb interface towards selected P-GW-U with PRDs, FARs information to establish the data path. PGW-C does not support TEID (Tunnel Identifier) allocation; it is allocated by PGW-U.

• Once the resources are allocated (TEID and so on), P-GW-U sends an Sx establish response message towards P-GW-C.

• P-GW responds to the S-GW with a Create Session Response message including the assigned address, TEID, and additional information.

• The S5/S8 data plane tunnel is established and the PGW-U can forward and receive packets to and from the PDN.

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

• P-GW receives a Create Session Request message including an APN, on the S5/S8 interface.

• P-GW-C initiates an Sx establishment request on Sxb interface towards selected P-GW-U with PRDs, FARs information to establish the data path. PGW-C does not support TEID (Tunnel Identifier) allocation; it is allocated by PGW-U.

• Once the resources are allocated (TEID and so on), P-GW-U sends an Sx establish response message towards P-GW-C.

• P-GW responds to the S-GW with a Create Session Response message including the assigned address, TEID, and additional information.

• The S5/S8 data plane tunnel is established and the PGW-U can forward and receive packets to and from the PDN.

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

• On S11 interface, S-GW-C receives a Create Session Request message including an Access Point Name (APN) from MME.

• S-GW-C initiated the Sx establishment request on the Sxa interface towards the selected S-GW-U with PDRs, FARs information to establish data path. Here, the S-GW-C does not support the TEID (Tunnel Identifier) allocation. It is allocated by the S-GW-U.

• After allocation of resources such as egree TEID and so on, S-GW-U sends the Sx establishment response message towards the S-GW-C.

• The S-GW-C initiates the Create Session Request towards the selected P-GW-C.

• P-GW-C responds with the Create Session Response with the IP address and default bearer related information.

• SGW-C initiates Sx Modification Request message towards SGW-U to update FAR (Forwarding action) information for the existing session.

• SGW-U provides Sx Modification Response with success after updating information.

• SGW-C sends Create Session Response with all necessary information for Default Bearer towards MME.

• MME initiates Modify Bearer Request message towards SGW-C, once it received eNodeB's F-TEID information.

• SGW-C initiates Sx Modification Request towards SGW-U for updating FAR information on eNodeB's F-TEID.

• After successfully updating, Sx Modification Response is sent to SGW-C.

• SGW-C inturn will send Modification Response message towards MME to complete attach procedure.

• SGW-U has established S1U side data tunnel towards eNodeB and S5/S8 side data tunnel towards PGW-U. Now, SGW-U can forward and receive packets to/from PGW as well eNodeB.

• The S5/S8 data plane tunnel is established and the PGW-U can forward and receive packets to/from the PDN.

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

• Once Delete Session Request is received from MME, SGW initiate Sx Delete Request message towards SGW-U.

• SGW-U clears all allocated User-Plane resources and responds back with Cause Success to SGW-C.

• SGW-C responds back to MME with Delete Session Response message.

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.

For Pure-S calls, Idle Session timeout is not supported.

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".

• User plane module supports the storage of a list of URRs received as part of session establishment request.

• Each PDR is associated with one or more URRs.

• A particular URR is linked to another URR.

• Each URR contains the measurement method (time or volume), and reporting triggers that indicates the event on which the user plane has to send usage report.

• The URR have both volume-quota and volume-threshold present for the Gy-URRs.

This message sent from the User Plane is in response to a session deletion request from control plane. This results in the termination of the Sx session at User plane. Usage Report is included as part of Sx Delete Session Response.

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.

This section 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

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.

• 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.

• User plane module supports the storage of a list of URRs received as part of session establishment request.

• Each PDR is associated with one or more URRs.

• A particular URR is linked to another URR.

• Each URR contains the measurement method (time or volume), and reporting triggers that indicates the event on which the user plane has to send usage report.

This message sent from the User Plane is in response to a session deletion request from control plane. This results in the termination of the Sx session at User plane. Usage Report is included as part of SX Delete Session Response.