GGSN in CUPS

Revision History


Note

Revision history details are not provided for features introduced before release 21.24.

Revision Details

Release

First introduced

Pre 21.24

Feature Description

The Gateway GPRS Support Node (GGSN) performs the following functions:

  • Establish and maintain subscriber Internet Protocol (IP) or Point-to-Point Protocol (PPP) type Packet Data Protocol (PDP) contexts originated by either the mobile or the network

  • Provide charging detail records (CDRs) to the charging gateway (CG, also known as the Charging Gateway Function (CGF))

  • Route data traffic between the subscriber's Mobile Station (MS) and a Packet Data Networks (PDNs) such as the Internet or an intranet

PDNs are associated with Access Point Names (APNs) configured on the system. Each APN consists of a set of parameters that dictate how subscriber authentication and IP address assignment is to be handled for that APN.

GGSN is an existing StarOS application that runs on Cisco ASR 5500 and virtualized platforms. With this release, GGSN is supported in CUPS architecture.

For additional information on GGSN, refer the StarOS GGSN Administration Guide.

Supported Functionality

The following functionality are supported by GGSN in CUPS architecture:

  • Initial Attach and Detach with Gx, Gy, and Gz

  • Access side update procedures

  • GGSN and QoS interaction scenarios

  • 3G handoffs in GGSN

  • GnGp inter-RAT handoff (Pure-P)

  • GnGp inter-RAT handoff (Collapsed)

  • PCRF initiated delete

  • Direct Tunnel

  • GGSN with RADIUS Authentication and Accounting

  • GGSN with S6b interface

  • Sx failure and GTP-C failure

  • GTP-U path failure, GTP error indication

  • Lawful Interception

  • GGSN Statistics

  • Idle timeout

  • Session recovery and ICSR

  • Support for context replacement

  • Traffic End Point

  • MS Information Change Procedure

  • GGSN 2G support on CUPS

Standards Compliance

The GGSN in CUPS complies with the following 3GPP standards:

  • 3GPP TS 23.060 release 16.0.0: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2

  • 3GPP TS 29.060 release 15.5.0: 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface

  • 3GPP TS 23.214 release 14.0 - Universal Mobile Telecommunications System (UMTS); LTE; Architecture enhancements for control and user plane separation of EPC nodes.

  • 3GPP TS 29.244 release 14.0 - LTE; Interface between the Control Plane and the User Plane of EPC Nodes.

How it Works

The following sections describes the various call flows related to the Gateway GPRS Support Node (GGSN) for CUPS.

Initial Attach GnGp

The following call flow describes the Create PDP Context (CPC) procedure during GnGp initial attach which is applicable for both EUTRAN (3G) and GERAN (2G).

Figure 1. Initial Attach (GnGp)
Table 1. Initial Attach (GnGp) Call Flow
Step Description
1

The User Equipment (UE) initiates a General Packet Radio Service (GPRS) IP-CAN session establishment request to the Serving GPRS Support Nodes (SGSNs). The SGSN sends Establish IP-CAN Session (PDP context activation) Request to the SAEGW(GGSN)-C.

2a

The SAEGW(GGSN)-C sends the access request to AAA-interaction to query about the User-Name, calling-station-id, called-station-id, NAS-IPAddress, and RAT Type.

2b

The SAEGW(GGSN)-C sends the request to AAA-interaction to query about the s6b-AAR details:

AAR {Session-ID, MIP6-Agent-Info (PGW-FQDN ), User Name (IMSI-NAI), APN, RAT-Type} framed-ip-address

3a

The AAA interacts with GGSN for Access-Accept of:

User-name, calling-station-id, called-station-id, framed-ip-address, nas-ipaddress
3b

The AAA interacts with GGSN for s6b-AAA details.
4 The SAEGW(GGSN)-C sends CCR-I to PCRF for IP-CAN session establishment procedure.
5 The PCRF responds with CCA-I for IP-CAN session establishment to SAEGW(GGSN)-C.
6a The SAEGW(GGSN)-C sends the CCR-I request to OCS.
6b The OCS responds with the CCA-I to SAEGW(GGSN)-C.
7

After Gx, Gy, interaction 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 for establishing GTP-U path with SGSN.

SAEGW(GGSN)-C sends Sx Session Establishment Request to SAEGW-U:

  • UL-PDR – PDI {src=access, local-fteid: ch=1, UEIPAddress}, outer-header-removal)

  • DL-PDR (PDI with UEIPAddress, Rulebase)

  • UL-FAR (applyaction=forward, params=core, apn)

  • DL-FAR (applyaction=forward, params=access, outer-header-creation gtpu-teid, gtpu-ipaddress)

  • QER (correlation-id, mbr, gate-status)

  • URR (measurement-method, reporting-trigger,volume/time thresholds)

Note

 

  • Create Uplink PDR is sent with "Outer Header Removal" based on IP address information in "Tunnel ID Data I" and "GSN Address" for Data.

  • Create Downlink FAR is sent with "Outer Header Creation" as "Tunnel ID Data I" and "GSN Address" for Data.
8

The SAEGW(GGSN)-U sends Sx Session Establishment Response (Created-PDR, local-FTEID) to SAEGW-C.

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

  • Created PDR/Created Traffic End Point: GGSN Ingress F-TEID to be used as "Tunnel ID Data I" and "GSN Address" for Data.
9 On receipt of Sx Session Establishment Response, the SAEGW(GGSN)-C sends Create PDP Context Response toward SGSN with "Tunnel ID Data I" and "GSN Address" for Data from the information received in Sx Session Establishment Response.

Detach (GnGp)

The following call flow describes the Delete PDP Context (DPC) procedure during GnGp detach.

Figure 2. Detach (GnGp)
Table 2. Detach (GnGp) Call Flow
Step Description
1

he SGSN sends a delete PDP Context Request (TEID, NSAPI, Teardown Ind) message to the SAEGW(GGSN)-C. If the MS in the Deactivate PDP Context Request message includes Teardown Ind, then the SGSN deactivates all PDP contexts associated with this PDP address by including Teardown Ind in the Delete PDP Context Request message.

2

On receipt of the Delete PDP Context Request from SGSN, the SAEGW(GGSN)-C does the following:

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

  • Performs Sxb interaction and sends Sx Session Deletion Request to remove the Sx session context of an existing IP-CAN session.
3

The SAEGW-U responds with the Sx Session Deletion Response to SAEGW(GGSN)-C.

On receipt of Sx Session Deletion Response, the SAEGW(GGSN)-C does the following:

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

  • Generates CDR (Gz) based on URR information received.
4 The GGSN-Initiated IP-CAN Session Termination: The SAEGW(GGSN)-C sends a CC Request (CCR) message with CC-Request-Type AVP set to TERMINATION_REQUEST.
5 The PCRF responds with CC Answer (CCA) message.
6 The SAEGW(GGSN)-C sends CCR-Terminate request to OCS.
7 The OCS responds with CCA-Terminate.
8 The SAEGW(GGSN)-C sends CDR to Gz server.
9 The SAEGW(GGSN)-C sends Stop-Accounting to AAA.
10

The SAEGW(GGSN)-C removes the PDP context(s) and returns a Delete PDP Context Response (TEID) message to the SGSN.

Context Replacement

When Context replacement occurs, the previous session in UP is deleted with Sxb interaction by exchanging Sx Session Deletion Request and Sx Session Deleting Response.

All CDRs of previous context are closed after receiving Sx Session Deletion Response.

NOTE: Rest of the Call flow remains same as Initial Attach.

Update Procedure and QoS Interaction

The following call flow describes the Update procedure and QoS interaction.

Figure 3. Update Procedure and QoS Interaction
Table 3. Update Procedure and QoS Interaction Call Flow
Step Description
1

The SGSN sends an Update PDP Ctx Request to SAEGW(GGSN)-C.
2 The SAEGW(GGSN)-C sends CC Request (CCR-U) message to PCRF.
3 The PCRF responds with CCA-U message, if the Result-Code is DIAMETER_SUCCESS.
4a The SAEGW(GGSN)-C sends CCR-U to OCS.
4b The OCS responds with CCA-U to SAEGW(GGSN)-C.
5

The SAEGW(GGSN)-C sends Sx Session Modification Request to SAEGW-U:

  • UL-Update-PDR (outer-header-removal)

  • DL-Update-PDR (fowrd-action, outer-hedae-creation, gtpu-address)
6 The SAEGW-U sends the Sx Session Modification Response to the SAEGW(GGSN)-C.
7

The SAEGW(GGSN)-C sends the Update PDP Ctx Response to SGSN.

Access side Update Procedure

QoS change received from Access-side, after being approved from PCRF, triggers:

  • Update QER for APNAMBR/MBR changes

  • Update FAR for any QCI/ARP changes for DSCP marking corresponding to new QoS

Gx Update Procedures

Following is the behavior of Gx update procedure through CCA-U or RAR:

  • Common FAR is used for the PDRs if FAR attributes are the same.

  • Rule installation triggers Create PDR and Create QER (SDF level), and may or may not have Create FAR and Create URR (rule can reuse FAR and URR of other rules).

  • Rule modification for a flow status/rating group triggers Update QER/Update URR and may or may not have Update PDR (that is, no TFT/QoS change).

  • Rule modification for TFT/QoS triggers Update PDR and may or may not have Update QER/Update URR (no QER/URR change).

  • In case of update of (only) flow status/rating group, Update QER/URR is sent. That is, no Update PDR is sent in such cases.

  • APN-AMBR change received from PCRF triggers Update QER.

  • The default-eps-bearer-qos change, received from PCRF, triggers Update FAR if there is a change in DSCP marking corresponding to the new QoS.

PGW to GGSN Handoff

The following call flow describes the P-GW to GGSN Handoff procedure.

Figure 4. P-GW to GGSN Handoff
Table 4. P-GW to GGSN Handoff Call Flow
Step Description
1

The target SGSN sends update PDP context request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS negotiated, serving network identity, RAT type, MS Info Change Reporting support indication) to the SAEGW.

2 The SAEGW(GGSN)-C sends CCR-U to the PCRF.
3 The PCRF responds with CCA-U if the Result-Code is DIAMETER_SUCCESS for the IP can session modification.
4a The SAEGW(GGSN)-C conditionally sends a CCR-U to the OCS if Online Charging is enabled.
4b The OCS responds with a CCA-U to the SAEGW(GGSN)-C.
5

The SAEGW-C sends Sx Session Modify Request to SAEGW-U:

  • DL: Update the FAR for Target SGSN, update the URR, QER if modified

  • UL: Update PDR for Target SGSN IP Type, update the URR, QER if modified.
6 The SAEGW-U sends Sx Session Modify Response to SAEGW(GGSN)-C.
7

The SAEGW(GGSN)-C updates its PDP context fields and returns an Update PDP Context Response (TEID, Prohibit Payload Compression, APN Restriction, CGI/SAI/RAI change report required, BCM) message to the SGSN.

GGSN to PGW Handoff

The following call flow describes the GGSN to P-GW Handoff procedure.

Figure 5. GGSN to PGW Handoff
Table 5. GGSN to PGW Handoff Call Flow
Step Description
1

The S-GW/MME sends a Modify Bearer Request (Sender F-TEID for Control Plane, Bearer Contexts to be modified [EBI, S5/S8-U SGW F-TEID], [UE-TZ]) to the SAEGW(PGW)-C.

2 The SAEGW(GGSN)-C sends CCR-U to the PCRF.
3 The PCRF responds with CCA for the IP can session modification.
4a The SAEGW conditionally sends a CCR-U to the OCS if Online Charging is enabled.
4b The OCS responds with a CCA-U to the SAEGW(GGSN)-C.
5

The SAEGW(GGSN)-C sends the Sx Modify Request to SAEGW-U:

  • DL: Update the FAR for Target S-GW/eNB, update the URR, QER if modified

  • UL: Update PDR depending S-GW/eNB IP Type, update the URR, QER if modified
6

The SAEGW-U responds with the Sx Modify Response to SAEGW(GGSN)-C with cause Success.
7

The SAEGW responds with Modify Bearer Response (Cause, MSISDN, Bearer Contexts Modified [EBI, Cause]) to the S-GW/MME.

Inter-SGSN Handoff Iu 3G to Iu 3G

An inter-SGSN, inter-system change from Iu mode to A/Gb mode takes place when an MS in PMM IDLE or PMM CONNECTED state changes from UTRAN or GERAN Iu mode to A/Gb mode and the A/Gb mode radio access node serving the MS is served by a different SGSN. In this case, the RA changes. Therefore, the MS initiates an A/Gb mode RA update procedure. The RA update procedure is either combined RA/LA update or only RA update. The MS or RAN decides to perform an inter-system change, which makes the MS switch to a new cell, where A/Gb mode must be used and stops transmission to the network.

The following call flow describes the GPRS Inter-SGSN Handoff procedure.

Figure 6. Inter-SGSN Handoff – Iu (3G) to Iu (3G)
Table 6. Inter-SGSN Handoff – Iu (3G) to Iu (3G) Call Flow
Step Description
1 The new SGSN sends an update PDP Context Request message to each SAEGW(GGSN)-C concerned.
2 The SAEGW(GGSN)-C conditionally sends CCR-U to the PCRF if RAT Type triggers are enabled.
3 PCRF responds with CCA-U for the IP can session.
4a The GGSN conditionally sends a CCR-U to the OCS.
4b The OCS responds with a CCA-U to the SAEGW(GGSN)-C.
5

The SAEGW(GGSN)-C sends the Sx Session Modify Request to SAEGW-U to update RNC IP and TEID that is received:

  • DL: Update the FAR for Target SGSN, update the URR, QER if modified

  • UL: Update PDR for Target SGSN IP Type, update the URR, QER if modified.
6 The SAEGW-U responds with the Sx Session Modify Response to SAEGW(GGSN)-C with cause-accept.
7 SAEGW(GGSN)-C sends Update PDP Ctx Response to new SGSN.

Inter SGSN Handoff for AGb 2G to Iu 3G

The call flow for Inter-SGSN Handoff 2G to 3G remains the same as Inter-SGSN Handoff – Iu (3G) to Iu (3G) with the difference being SAEGW(GGSN)-C remains and UE moves from 2G SGSN to 3G SGSN.

Inter SGSN Handoff for Iu 3G to AGb 2G

The call flow for Inter-SGSN Handoff 3G to 2G remains the same as Inter-SGSN Handoff – Iu (3G) to Iu (3G) with the difference being SAEGW(GGSN)-C remains and UE moves from 3G SGSN to 2G SGSN.

Direct Tunnel

The following call flow describes about the various nodes and interfaces for the Direct Tunnel.

Figure 7. Direct Tunnel
Table 7. Direct Tunnel Call Flow
Step Description
1 After the call is established, if SGSN supports Direct Tunnel feature, SGSN will send Update PDP Context Request to GGSN including the DT IE with the DT Flag set to “1” along with RNC TEID and RNC IP in the SGSN Data TEID and SGSN Data IP fields respectively, to ensure data is directly forwarded to RNC and a direct tunnel between GGSN and RNC is established.
2 The SAEGW(GGSN)-C sends CCR-U to the PCRF.
3 The PCRF responds with CCA-U message.
4a SAEGW(GGSN)-C sends CCR-U to OCS.
4b OCS responds with the CCA-U to SAEGW(GGSN)-C.
5

The SAEGW(GGSN)-C sends the Sx Session Modify Request to SAEGW-U to update RNC IP and TEID that is received:

  • UL-Update-PDR (outer-header-removal)

  • DL-Update-FAR (Outer-header-creation)
6 The SAEGW-U responds with the Sx Session Modify Response to SAEGW(GGSN)-C with cause-accept.
7 SAEGW(GGSN)-C sends Update PDP Ctx Response to SGSN.

PCRF-initiated Deletion of Session

The following call flow describes about the various nodes and its related interfaces for PCRF-initiated deletion of session.

Figure 8. PCRF-initiated Deletion of Session
Table 8. PCRF-initiated Deletion of Session Call Flow
Step Description
1 The PCRF sends a diameter Re-Authentication Request (RAR) to request that the SAEGW(GGSN)-C removes all the PCC rules previously installed for the IP CAN session and deactivates all the PCC rules previously activated for the IP CAN session.
2 The SAEGW(GGSN)-C respond with Re-Authentication Answer (RAA) message.
3 The SAEGW(GGSN)-C sends modification request to SAEGW-U and update FAR with Apply Action as “DROP” for both Uplink and Downlink data path.
4 The SAEGW-U responds with Sx Modification Response.
5

The SAEGW(GGSN)-C sends the Sx Delete Request to SAEGW-U.

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

  • Performs Sxb interaction and sends Sx Session Deletion Request to remove the Sx session context of an existing IP-CAN session.
6 The SAEGW(GGSN)-C sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind) message to the SGSN in parallel.
7

After getting Sx Session Delete Response from SAEGEW-U, SAEGW-C:

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

  • Generates CDR (Gz) based on URR information received.
8 The GGSN sends a CC Request (CCR) message with CC-Request-Type AVP set to TERMINATION_REQUEST.
9 The PCRF responds with CC Answer (CCA) message.
10 SAEGW(GGSN)-C generates CCR-Terminate on the Gy interface.
11 OCS responds with CCA-Terminate.
12 The SGSN removes the PDP context(s) and returns a Delete PDP Context Response (TEID) message to the SAEGW(GGSN)-C.

Admin Clear

The following call flow describes about the various nodes and its related interfaces for Admin Clear.

Figure 9. Admin Clear
Table 9. Admin Clear Call Flow
Step Description
1 Admin initiates session clearing using existing (non-CUPS CLI that is applicable in CUPS architecture) clear sub imsi CLI command.
2 The SAEGW(GGSN)-C sends modification request to SAEGW-U and update FAR with Apply Action as “DROP” for both Uplink and Downlink data path.
3 The SAEGW-U responds with Sx Modification Response.
4

The SAEGW(GGSN)-C sends Sx Delete Request to SAEGW-U:

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

  • Performs Sxb interaction and sends Sx Session Deletion Request to remove the Sx session context of an existing IP-CAN session.
5 The SAEGW(GGSN)-C sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind) message to the SGSN in parallel.
6

After getting Sx Session Delete Response from SAEGEW-U, the SAEGW(GGSN)-C:

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

  • Generates CDR (Gz) based on URR information received.
7 The SAEGW(GGSN)-C sends a CC Request (CCR) message with CC-Request-Type AVP set to TERMINATION_REQUEST.
8 The PCRF responds with CC Answer (CCA) message.
9 SAEGW(GGSN)-C generates CCR-Terminate on the Gy interface.
10 OCS responds with CCA-Terminate.
11 The SGSN removes the PDP context(s) and returns a Delete PDP Context Response (TEID) message to the SAEGW(GGSN)-C.

Network Failures

All possible network failure scenarios are also supported, which includes:

  • Sx failures

  • GTP failures – GTP-C Path Failure, GTP-U Path Failure, GTP Error Indication

  • Gx failures

  • Idle timeout and Bearer Inactivity Timeout

GGSN Session Reporting with Gy Interface

The session reporting functionality with Gy interface for GGSN is similar to P-GW. For details, refer the P-GW Session Reporting with Gy Interface section in the Ultra Packet Core CUPS Control Plane Administration Guide.

GGSN Session Reporting with Gz Interface

The session reporting functionality with Gz interface for GGSN is similar to P-GW. For details, refer the P-GW Session Reporting with Gz Interface section in the Ultra Packet Core CUPS Control Plane Administration Guide.

Secondary PDP Context Behavior

As secondary PDP context is not supported for GnGp GGSN CUPS, any request for Secondary PDP Context gets rejected as explained in the following scenarios:

SGSN Initiated Secondary PDP Context

The Create PDP Context (CPC) Request for Secondary PDP Context is rejected with cause as bearer handling not supported (230), as shown in the following call flow.

Figure 10. SGSN Initiated Secondary PDP Context
Table 10. SGSN Initiated Secondary PDP Context Call Flow
Step Description
1 The SGSN sends a GTP Create PDP Context for Secondary Bearer to GGSN.
2 The GGSN sends a GTP Create PDP Ctxt Response with cause set to “Bearer Handling Not Supported (230)”.

PCRF initiated Secondary PDP Context

The rule mapping to Secondary PDP Context is not activated and CCR-U is sent to PCRF indicating the failed rule, and Rule-Failure-Code is set to RESOURCE_ALLOCATION_FAILURE (10). The behavior is similar for such rule received in CCA-I, CCA-U or RAR as shown in the following call flow.

Figure 11. PCRF Initiated Secondary PDP Context
Table 11. PCRF Initiated Secondary PDP Context (Scenario 1)
Step Description
1 The UE initiates a GPRS IP-CAN session establishment request to the SGSN. The SGSN sends Establish IP-CAN Session (Primary PDP context activation) request to the GGSN.
2a The GGSN sends the access request to AAA-interaction to query about the User-Name, calling-station-id, called-station-id, NAS-IPAddress, and RAT Type.
2b

The GGSN sends the request to AAA-interaction to query about the s6b-AAR details:

AAR {Session-ID, MIP6-Agent-Info (PGW-FQDN), User Name (IMSI-NAI), APN, RAT-Type} framed-ip-address
3a

The AAA interacts with GGSN for Access-Acceptance of:

User-name, calling-station-id, called-station-id, framed-ip-address, nas-ipaddress
3b The AAA interacts with GGSN for s6b-AAA details.
4 The GGSN sends request to PCRF for IP-CAN session establishment procedure.
5 The PCRF responds with CCA for IP-CAN session establishment to GGSN.
6 The CCR-U contains the Charging-Rule-Report AVP with Charging rule name, with PCC-Rule-Status as INACTIVE and Rule-Failure-Code as “RESOURCE_ALLOCATION_FAILURE (10)”.
7 The PCRF respond with CCA-U to GGSN
8 The GGSN sends a GTP Create PDP Ctxt Response to SGSN.
Table 12. PCRF-initiated Secondary PDP Context (Scenario 2)
Step Description
1 The SGSN sends the Update PDP Ctx Request to GGSN.
2 The GGSN sends the access request to AAA-interaction.
3 The AAA interacts with GGSN for Access Request -Acceptance.
4 The GGSN sends CCR Request to the PCRF. The SGSN change may require GGSN – PCRF exchange to update QoS profile, based on RAT change, Lawful Intercept update, or other conditions. This exchange may be required to update MS profile and/or billing codes, for example, this profile information may overlap with QoS information received from the HLR through the vSGSN during PDP Context Request message, in such cases, any variance in overlap values, the PGW uses these PCRF (Gx) values.
5 The PCRF responds with CC Answer (CCA) Update message. A rule is also received for the secondary bearer creation, if the Result-Code is DIAMETER_SUCCESS.
6 The CCR-U contains the Charging-Rule-Report AVP with Charging rule name, with PCC-Rule-Status as INACTIVE and Rule-Failure-Code as “RESOURCE_ALLOCATION_FAILURE (10)”.
7 The PCRF respond with CCA for IP-CAN session establishment to GGSN
8 The GGSN sends a GTP Update PDP Ctxt Response to SGSN.
Table 13. PCRF-initiated Secondary PDP Context (Scenario 3)
Step Description
1 The RAR command is sent by the PCRF to the PCEF in order to provision PCC rules using the PUSH procedure to initiate the provision of unsolicited PCC rules. A rule is also received for the secondary bearer creation.
2 The RAA command is sent by the PCRF to the PCEF in order to provision PCC rules using the PUSH procedure initiate the provision of unsolicited PCC rules.
3 The CCR-U contains the Charging-Rule-Report AVP with Charging rule name, with PCC-Rule-Status as INACTIVE and Rule-Failure-Code as “RESOURCE_ALLOCATION_FAILURE (10)”.
4 The PCRF responds with CCA-U to GGSN.

Recovery and ICSR for GGSN in CUPS

Existing framework is extended to support GGSN in CUPS Recovery and ICSR. At GGSN in CUPS, complete session/PDN state is recovered in case of Recovery/ICSR.

NOTE: In this release, if ICSR Switchover is performed on GGSN in CUPS, then the show sx peers CLI commands does not show any associated peers on New Active chassis. However, there is no impact to functionality.

Limitations

In this release, the functionality listed in Supported Functionality section are supported for GGSN (GnGp) in CUPS.

The following features/functionality are not supported for GGSN in CUPS:

  • Custom Dictionaries – Only Standard Dictionaries are supported unless specifically mentioned.

  • Non-standard QCIs are not supported.

  • Custom CLI or features are not supported.


    Note

    Customer-specific CLI commands supported for GGSN in CUPS architecture are listed in Supported Custom CLI Commands.

  • The PDP Type PPP, RADIUS CoA, and Gi tunneling protocols are not supported.

Configuring GGSN in CUPS

This section describes the CLI commands that are available in support of this feature.

Enabling CUPS in GGSN Service

Use the following configuration to enable CUPS in GGSN service.

configure 
   context context_name 
      ggsn-service service_name 
         [ no ] cups-enabled 
         end

NOTES:

  • The following services should be in STARTED state, and associated under SAEGW service for SAEGW service to move to STARTED state:

  1. All eGTP-C services (of P-GW associated with GGSN service) should be configured with cups-enabled CLI command.

  2. All GGSN services should be configured with cups-enabled CLI command.

Enabling CUPS in GTPC Service for GGSN

Use the following configuration to enable CUPS in eGTP-C service of P-GW that is associated with GGSN.

configure 
   context context_name 
      egtp-service service_name 
         [ no ] cups-enabled 
         end

Verifying CUPS in GGSN Service for SAEGW

Use the following commands to verify if CUPS is enabled for GGSN Service:

  • show configuration

  • show configuration verbose

  • show egtp-service { all | name service_name }

  • show ggsn-service { all | name service_name }

Supported Custom CLI Commands

This section describes the customer-specific CLI commands supported for GGSN in CUPS.

The following GTP-C commands are supported for GGSN in CUPS architecture.

Command Description
gtpc support-earp This command enables Evolved ARP (e-ARP) support for GGSN service on the Gn-Gp interface.
gtpc support-access-side { traffic-class { downgrade } } This command allows Traffic Class to be downgraded by MS for Gn-Gp GGSN when Bearer Control Mode (BCM) is set as mixed.
gtpc bitrates-rounded-down-kbps This command enables or disables rounded down kbps value of bit rate on a GTP interface. By default, this command is disabled.
gtpc map-mbr-ambr This command maps the Maximum Bit Rate AVP received in Update PDP Context QoS message from SGSN to Aggregate Maximum Bit Rate attribute value (AMBR), if AMBR is not received in Update PDP Context QoS message from SGSN. This command is applicable for Gn-Gp GGSN mode only.
gtpc update-pdp-resp reject imsi-mismatch This command rejects the update PDP request message if the ULI is not part of the home PLMN session.
egtp gngp-modify-bearer-rsp-with-apn-ambr This command sends a Modify Bearer Response with APN-AMBR only for a Gn-Gp handoff.
gtpc peer-salvation This command enables peer salvation for inactive GTPv2 peers for an eGTP service.

The following GTPP commands are supported for GGSN in CUPS architecture.

Command Description
gtpp storage-server mode local This command configures the storage mode as local.
gtpp storage-server local file purge-processed-files [ purge-interval purge_interval ] This command configures the time interval in minutes between successive file purges.
no gtpp trigger time-limit This command disables the time-limit trigger for CDR.
gtpp attribute served-pdp-pdn-address-extension This command enables GGSN to include an optional field "Served PDP/ PDN Address extension" in the CDR.