Cisco GGSN Release 8.0 Configuration Guide, Cisco IOS Release 12.4(15)XQ

Configuring GTP Services on the GGSN

This chapter describes how to configure a gateway GPRS service node (GGSN) and how to configure GPRS tunneling protocol (GTP) options.

For a complete description of the GGSN commands in this chapter, refer to the Cisco GGSN Command Reference for the Cisco GGSN release you are using.

To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. See the "Related Documents" section for a list of the other Cisco IOS software documentation that might be helpful while configuring the GGSN.

This chapter includes the following sections:

•GTP Overview

•Configuring GGSN Services

•Configuring Echo Timing on a GGSN

•Customizing the GGSN Configuration

•Using the Service-Mode Function

•Monitoring and Maintaining GTP on the GGSN

•Configuration Examples

GTP Overview

GTP is the protocol used to tunnel multi-protocol packets through the general packet radio service/Universal Mobile Telecommunication System (GPRS/UMTS) network. It is defined on the Gn interface as the protocol between GSNs in the GPRS/UMTS backbone network.

The Cisco GGSN simultaneously supports both GTP Version 0 (GTP v0) and GTP Version 1 (GTP v1). GPRS R97/R98 uses GTP Version 0, and UMTS R99 uses GTP v1.

The GGSN automatically selects the GTP version to use according to the capabilities of the SGSN.

Configuring GGSN Services

The Cisco GGSN software uses a logical interface called a virtual template interface to configure an instance of Cisco IOS software running on a Cisco Service and Application Module for IP (SAMI) processor as a GGSN.

This section describes the primary tasks you need to complete when configuring for GGSN services. The subsequent configuration tasks describe how to establish connectivity from the GGSN to the serving GPRS support node (SGSN) and public data networks (PDNs) once the Cisco IOS instance on the Cisco SAMI processor has been configured as a GGSN.

The following requirements must be met when configuring a GGSN:

•Configure only a single GGSN entity per instance of Cisco IOS software, using the service gprs ggsn global configuration command. Up to six GGSNs can be configured on one Cisco SAMI—one GGSN per processor.

•On each GGSN, configure only a single virtual template interface (as virtual template number 1) with GTP encapsulation.

•Ensure that the memory protection threshold has been configured appropriately, according to the router and memory size. For information on configuring the memory protection threshold, see "Configuring the GGSN Memory Threshold" section.

GGSN Services Configuration Task List

To configure a Cisco SAMI processor that is running an instance of Cisco IOS GGSN software for GGSN services, perform the following tasks:

•Enabling GGSN Services

•Creating a Loopback Interface

•Creating a Virtual Template Interface for GGSN

•Enabling CEF Switching

Enabling GGSN Services

Using the service gprs ggsn global configuration command, configure only a single GGSN entity per Cisco SAMI processor.

To enable GGSN services, use the following command in global configuration mode:

Creating a Loopback Interface

Rather than directly configuring an IP address on the virtual template, we recommend that you create a loopback interface and then associate the loopback interface IP address to the virtual template used for GTP encapsulation using the ip unnumbered loopback interface configuration command.

Note If the IP address of the loopback interface is not assigned to the virtual template interface using the ip unnumbered loopback command, packets will not be CEF-switched and performance will be affected.

A loopback interface is a software-only interface that emulates an interface that is always up. It is a virtual interface that is supported on all platforms. The interface number is the number of the loopback interface that you want to create or configure. There is no limit to the number of loopback interfaces that you can create. A GGSN uses loopback interfaces to support the configuration of several different features.

To create a loopback interface, use the following commands in global configuration mode:

Creating a Virtual Template Interface for GGSN

Configure only a single virtual template interface (as virtual template number 1) with GTP encapsulation on a GGSN.

To create a virtual template interface for GGSN, use the following command, beginning in global configuration mode:

Enabling CEF Switching

CEF switching uses a forwarding information base (FIB) table and an adjacency table to accomplish packet switching. The adjacency table is indexed by Layer 3 network addresses and contains the corresponding Layer 2 information to forward a packet.

CEF switching eliminates the use of the route-cache table, and the overhead that is required in aging out its table entries and repopulating the table. The FIB table mirrors the entire contents of the IP routing table, which eliminates the need for a route-cache table.

For more information about switching paths, refer to the Cisco IOS Switching Services Configuration Guide.

When you enable CEF switching globally on the GGSN, all interfaces on the GGSN are automatically enabled for CEF switching.

Note To ensure that CEF switching functions properly, wait a short period of time before enabling CEF switching after it has been disabled using the no ip cef command.

To enable CEF switching on the GGSN, use the following commands beginning in global configuration mode:

Configuring Echo Timing on a GGSN

GGSN uses echo timing to determine whether an SGSN or external charging gateway is active.

For a GTP path to be active, the SGSN needs to be active. To determine that an SGSN is active, the GGSN and SGSN exchange echo messages. Although the GGSN supports different methods of echo message timing, the basic echo flow begins when the GGSN sends an echo request message to the SGSN. The SGSN sends a corresponding echo response message back to the GGSN.

If the GGSN does not receive a response after a certain number of retries (a configurable value), the GGSN assumes that the SGSN is not active. This indicates a GTP path failure, and the GGSN clears all PDP context requests associated with that path.

This section describes the different methods of echo timing that are supported on the GGSN and how to configure them. It includes the following topics:

•Overview of the Echo Timing on the GGSN

•Echo Timing Configuration Task List

•Verifying the Echo Timing Configuration

•Dynamic Echo Timer Configuration Example

Overview of the Echo Timing on the GGSN

The GGSN supports two different means of echo timing—the default echo timer and the dynamic echo timer. Only a single timer can be in use at any time on the GGSN. The following sections describe these two timers:

•Overview of the Default Echo Timer

•Overview of the Dynamic Echo Timer

Note For simplicity, this document describes the operation of echo timing between the GGSN and an SGSN. If an external charging gateway is in use in the GPRS/UMTS network, the GGSN uses the same type of echo timers to maintain the charging gateway path.

Overview of the Default Echo Timer

The default echo timer is enabled on the GGSN automatically. However, you can choose to enable the dynamic echo timing method as an alternative.

When you are using the default echo timer on the GGSN, the following commands apply:

•gprs gtp n3-requests—Specifies the maximum number of times that the GGSN attempts to send a echo-request message. The default is 5 times.

•gprs gtp path-echo-interval—Specifies the number of seconds that the GGSN waits for a response from an SGSN or external charging gateway, and, after receiving a response, the number of seconds the GGSN waits before sending the next echo-request message. The default is 60 seconds.

•gprs gtp t3-response—Specifies the initial number of seconds that the GGSN waits before resending a signaling request message when a response to a request has not been received. This time is doubled for every retry. The default is 1 second.

Figure 3-1 shows the default echo request sequence when a response is successfully received within the specified path echo interval. If the GGSN receives the echo response within the path echo interval (as specified in the gprs gtp path-echo-interval command; the default is 60 seconds), it sends another echo request message after 60 seconds (or whatever time was configured in the gprs gtp path-echo-interval command). This message flow continues as long as the GGSN receives an echo response message from the SGSN within the specified path echo interval.

Figure 3-1 Default GTP Path Echo Interval Request Sequence in Path Success Mode

Figure 3-2 shows the default echo request sequence when the GGSN fails to receive a response to its echo request within the specified path echo interval. If the GGSN fails to receive an echo response message from the SGSN within the path echo interval, it resends echo request messages until the N3-requests counter is reached (as specified by the gprs gtp n3-requests command; the default is 5). Because the initial request message is included in the N3-requests counter, the total number of retries is N3 - 1. The T3 timer increases by a factor of 2 for each retry (the factor value is not configurable).

Figure 3-2 Default Echo Timing Request Sequence in Path Failure Mode

For example, if N3 is set to the default of 5, and T3 is set to the default of 1 second, the GGSN will resend 4 echo request messages (the initial request + 4 retries= 5). If the GGSN does not receive an echo response from the SGSN during the 60-second path echo interval, then the GGSN immediately sends the first echo request retry message upon expiration of the path echo interval. The T3 time increases for each additional echo request, by a factor of 2 seconds, as long as the GGSN does not receive an echo response. So, the GGSN resends another message in 2 seconds, 4 seconds, and 8 seconds. After the 5th message, the GGSN waits for a final period of 16 seconds for an echo response.

If the GGSN fails to receive an echo response message from the SGSN within the time period of the N3-requests counter, it deletes all of the PDP contexts and clears the GTP path. For this example, the total elapsed time from when the first request message is sent to when PDP contexts are cleared is

60 + 2 + 4 + 8 + 16 = 90 seconds

where 60 is the initial value of the path echo interval, and the remaining 4 time periods are the increments of the T3 timer for the subsequent retries. The path is cleared after another 60-second period, or 150 seconds.

If the GGSN receives an echo response within the N3 x T3 transmission period, it goes back to success mode for its echo request sequences.

Figure 3-3 shows the GGSN receiving an echo response message within N3 x T3 retransmissions of an echo request. In this scenario, the GGSN sent an initial echo request followed by 4 retries for a total of 5 requests, according to the default setting of 5 N3 requests. The GGSN receives the echo response after the 5th and final retry, within the remaining 16 seconds. Now the GGSN is back in success mode, and it waits 60 seconds (the value of the gprs gtp path-echo-interval command) before sending the next echo request message.

Figure 3-3 Default Echo Timing with Echo Response Received Within N3 x T3 Retransmissions

Overview of the Dynamic Echo Timer

Because the GGSN's default echo timer cannot be configured to accommodate network congestion, the GTP path could be cleared prematurely. The dynamic echo timer feature enables the GGSN to better manage the GTP path during periods of network congestion. Use the gprs gtp echo-timer dynamic enable command to enable the GGSN to perform dynamic echo timing.

The dynamic echo timer is different from the default echo timer because it uses a calculated round-trip time (RTT), as well as a configurable factor or multiplier to be applied to the RTT statistic. Different paths can each have a different RTT, so the dynamic echo timer can vary for different paths.

When you are using the dynamic echo timer on the GGSN, the following commands apply:

•gprs gtp echo-timer dynamic enable—Enables the dynamic echo timer on the GGSN.

•gprs gtp echo-timer dynamic minimum—Specifies the minimum time period (in seconds) for the dynamic echo timer. If the RTT multiplied by the smooth factor is less than this value, the GGSN uses the value set in this command. The default is 5 seconds.

•gprs gtp echo-timer dynamic smooth-factor—Specifies the multiplier that the dynamic echo timer uses when calculating the time to wait to send retries, when it has not received a response from the SGSN within the path echo interval. The default is 2.

•gprs gtp n3-requests—Specifies the maximum number of times that the GGSN attempts to send an echo-request message. The default is 5 times.

•gprs gtp path-echo-interval—Specifies the number of seconds that the GGSN waits, after receiving a response from an SGSN or external charging gateway, before sending the next echo-request message. The default is 60 seconds.

Figure 3-4 shows the dynamic echo request sequence when a response is successfully received within the specified path echo interval. Just as in the default echo timing method, if the GGSN receives the echo response within the path echo interval (as specified in the gprs gtp path-echo-interval command; the default is 60 seconds), it sends another echo request message after 60 seconds (or whatever time was configured in the gprs gtp path-echo-interval command). This message flow continues as long as the GGSN receives an echo response message from the SGSN within the specified path echo interval.

Figure 3-4 Dynamic GTP Path Echo Interval Request Sequence in Path Success Mode

The GGSN calculates the RTT statistic for use by the dynamic echo timer. The RTT is the amount of time between sending a particular echo request message and receiving the corresponding echo response message. RTT is calculated for the first echo response received (see Figure 3-5); the GGSN records this statistic. Because the RTT value might be a very small number, there is a minimum time for the dynamic echo timer to use. This value is configured using the gprs gtp echo-timer dynamic minimum command.

Figure 3-5 Dynamic Echo Timing Request Sequence RTT Calculation

Figure 3-6 shows the dynamic echo timing request sequence in path failure mode. If the GGSN fails to receive an echo response message from the SGSN within the path echo interval, it goes into retransmission, or path failure mode. During path failure mode, the GGSN uses a value referred to as the T-dynamic. The T-dynamic is the greater of either the dynamic minimum, or the RTT statistic multiplied by the smooth factor.

Figure 3-6 Dynamic Echo Timing Request Sequence in Path Failure Mode

The T-dynamic essentially replaces the use of the gprs gtp t3-response command, which is used in the default echo timer method on the GGSN. The T-dynamic timer increases by a factor of 2 for each retry (again, this factor is not configurable), until the N3-requests counter is reached (the N3-requests counter includes the initial request message).

For example, if the RTT is 6 seconds, the dynamic minimum is 5 seconds, N3 is set to 5, and the smooth factor is set to 3, then the GGSN will resend up to 4 echo request messages (initial request + 4 retries = 5) in path failure mode. If the GGSN does not receive an echo response from the SGSN during the 60-second path echo interval, then the GGSN immediately sends the first echo request retry message upon expiration of the path echo interval. The RTT x smooth factor equals 18 seconds (6 x 3), which is greater than the dynamic minimum of 5 seconds, so the dynamic minimum value is not used. The T-dynamic value is 18 (RTT x smooth factor), so the GGSN sends another retry echo request message in 36 seconds (18 x 2), 72 seconds (18 x 4), and 144 seconds (18 x 8). After the fifth message, the GGSN waits for a final period of 288 seconds (18 x 16) for an echo response.

If the GGSN fails to receive an echo response message from the SGSN in this time period, it clears the GTP path and deletes all PDP contexts. The total elapsed time, from when the first request message is sent, to when the PDP contexts are cleared, is

60 + 36 + 72 + 144 + 288 = 600 seconds

where 60 is the initial value of the path echo interval, and the remaining 4 time periods are the increments of the T-dynamic for the subsequent retries. The path is cleared after another 60-second period, or 660 seconds.

If the GGSN receives an echo response within the N3 x T-dynamic transmission period, it goes back to success mode for its echo request sequences. In success mode, the GGSN begins echo requests and awaits responses according to the specified path echo interval as shown in Figure 3-4.

Sequence Numbering for Retransmissions

The GGSN does not increment the sequence number of an echo request message during retransmissions. Therefore, during the period when an echo response has not been received by the GGSN, the GGSN continues to use the same sequence number for all echo request retries until the N3 requests limit has been reached, or until a response has been received. When a response is received, the sequence number of the next echo request message is incremented by 1.

If the GGSN has sent an echo request message with a higher sequence number, but still receives echo responses for sequence numbers lower than the current echo request message, the response is ignored.

Echo Timing Configuration Task List

This section describes the tasks required to customize the default echo timing method, or to enable and configure the dynamic echo timing method on the GGSN. By default, the GGSN activates the default echo timing method.

To configure echo timing on the GGSN, perform the following tasks:

•Customizing the Default Echo Timer (Recommended, if used)

•Configuring the Dynamic Echo Timer (Optional)

•Disabling the Echo Timer (Optional)

Customizing the Default Echo Timer

The default echo timing method is enabled automatically on the GGSN. If you want to use the default echo timer, Cisco recommends that you modify the following commands to optimize your network as necessary.

To customize the default echo timing method on the GGSN, use the following commands beginning in global configuration mode:

Configuring the Dynamic Echo Timer

To activate the dynamic echo timing method on the GGSN, you must enable the dynamic echo timer. After you activate the dynamic echo timer, you can modify the corresponding options to optimize the timing parameters for your network.

To configure the dynamic echo timing method on the GGSN, use the following commands beginning in global configuration mode:

Disabling the Echo Timer

If for some reason you need to disable the GGSN from performing echo processing with an SGSN or external charging gateway, you can specify 0 seconds for the path echo interval.

To disable the echo timer, use the following command in global configuration mode:

Verifying the Echo Timing Configuration

This section describes how to verify the echo timing method on the GGSN. It includes the following topics:

•Verifying Echo Timing Parameters

•Verifying the Dynamic Echo Timer by GTP Path

Verifying Echo Timing Parameters

To verify the parameters in use by the GGSN for echo timing, you can use the show gprs gtp parameters or show running-config privileged EXEC command.

The GGSN automatically sets default values for the parameters applicable to the dynamic echo timer, even when the dynamic echo timer is not enabled. Therefore, the show gprs gtp parameters command does not indicate which echo timing method is currently activated.

Verifying Default Echo Timing Parameters

To verify the parameters in use by the default echo timer, use the show gprs gtp parameters privileged EXEC command, and observe the following parameters shown in bold text below:

Router# show gprs gtp parameters

    GTP path echo interval                        = 60                

    GTP signal max wait time T3_response          = 1                

    GTP max retry N3_request                      = 5                

    GTP dynamic echo-timer minimum                = 5                

    GTP dynamic echo-timer smooth factor          = 2                

    GTP buffer size for receiving N3_buffer       = 8192                

    GTP max pdp context                           = 45000 

Verifying Dynamic Echo Timing Parameters

To verify the parameters in use by the dynamic echo timer, use the show gprs gtp parameters privileged EXEC command, and observe the parameters shown in bold text below:

Router# show gprs gtp parameters

    GTP path echo interval                        = 60                

    GTP signal max wait time T3_response          = 1                

    GTP max retry N3_request                      = 5                

    GTP dynamic echo-timer minimum                = 5                

    GTP dynamic echo-timer smooth factor          = 2                

    GTP buffer size for receiving N3_buffer       = 8192                

    GTP max pdp context                           = 45000 

Verifying the Dynamic Echo Timer by GTP Path

You can use the show running-config privileged EXEC command to verify whether the dynamic echo timer is enabled.

The value of the dynamic echo timer varies for each GTP path on the GGSN. To verify whether the dynamic echo timer is enabled on the GGSN, and to verify the value (in seconds) of the dynamic echo timer (T-dynamic), use the show gprs gtp path privileged EXEC command.

If the dynamic echo timer is not activated, the word "Disabled" appears beside the corresponding path in the dynamic echo timer output field.

Step 1 To verify that the dynamic echo timer is enabled, use the show running-config command, and verify that the gprs gtp dynamic echo-timer enable command appears as shown in bold text toward the end of the following sample output:

Router# show running-config

Current configuration : 6769 bytes

!

version 12.2

no service pad

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

service internal

service gprs ggsn

!

ip cef

!

. . . 

!

interface loopback 1

 ip address 10.41.41.1 255.255.255.0

!

interface Virtual-Template1

 ip unnumber loopback 1

 encapsulation gtp

 gprs access-point-list gprs

!

. . .

!

gprs access-point-list gprs

  access-point 1

   access-point-name gprs.cisco.com

   exit

   !

  access-point 2

   access-point-name gprt.cisco.com

   access-mode non-transparent

   aaa-group authentication test2

   aaa-group accounting test2

   ip-address-pool dhcp-proxy-client

   dhcp-server 10.65.0.1

   dhcp-gateway-address 10.65.0.1       

   exit

   !

!

gprs ms-address exclude-range 10.21.1.0 10.21.1.5

gprs gtp echo-timer dynamic enable

gprs gtp echo-timer dynamic smooth-factor 5

gprs gtp echo-timer dynamic minimum 10

gprs gtp response-message wait-accounting

!

. . .

!

end

Step 2 To verify the T-dynamic values for the corresponding GTP paths, use the show gprs gtp path all privileged EXEC command.

The following example indicates that the dynamic echo timer is enabled on the GGSN and that the T-dynamic values of 5 seconds and 2 seconds are in use for the corresponding paths:

Router# show gprs gtp path all

         Total number of path : 2 

Local address           Remote address          GTP version    Dynamic echo timer

10.41.41.1(3386)        10.18.18.200(3386)      0              5

10.10.10.1(2123)        10.10.10.4(2123)        1              2

Customizing the GGSN Configuration

This section describes some of the options that you can configure on the GGSN to further customize the default configuration.

For information about configuring GPRS/UMTS charging options, see the "Customizing the Charging Gateway" section.

This section includes the following topics:

•Configuring GTP Signaling Options

•Configuring the Maximum Number of PDP Contexts on the GGSN

•Controlling Sessions on the GGSN

•Configuring Flow Control for GTP Error Messages

•Configuring the GGSN to Maintain a History for Deleted SGSN Paths

•Suppressing Echo Requests per SGSN

Configuring GTP Signaling Options

In addition to the commands used to configure the instance of Cisco IOS software for GGSN support, the GGSN feature supports several optional commands that you can use to customize your GTP configuration.

For certain GTP processing options, the default values represent recommended values. Other optional commands also are set to default values, but Cisco recommends modifying these commands to optimize your network as necessary, or according to your hardware. This section describes some of the commands that you should consider using to optimize GTP signaling.

To optimize your GTP signaling configuration, use the following commands, beginning in global configuration mode:

Note These GTP signaling commands are also used to support echo timing on the GGSN. For more information about echo timing on the GGSN, see the "Configuring Echo Timing on a GGSN" section.

Configuring Other GTP Signaling Options

This section describes some other GTP signaling options that you can modify as needed to support your network needs.

To configure other GTP signaling options, use the following commands, beginning in global configuration mode:

Configuring the Maximum Number of PDP Contexts on the GGSN

The practical upper limit for the maximum number of PDP contexts supported on a GGSN depends on the memory and platform in use and on the GGSN configuration (for example, whether or not a method of PPP has been configured to forward packets beyond the terminal equipment and mobile termination, whether Dynamic Feedback Protocol [DFP] is being used or the memory protection feature is enabled, and the rate of PDP context creation to be supported).

Note DFP weighs PPP PDPs against IP PDPs, with one PPP PDP equal to eight IPv4 PDPs. One IPv6 PDP equals eight IPv4 PDPs.

Table 3-1 lists the maximum number of PDP contexts the Cisco SAMI with the 1 GB memory option can support. Table 3-2 lists the maximum number the Cisco SAMI with the 2 GB memory option can support.

Note Table 3-1 and Table 3-2 list the maximum number of PDPs supported when the no virtual-template subinterface global configuration command is not configured on the GGSN.

With Cisco GGSN Release 8.0 and later, PDPs regenerated to a PPP session run on software interface description blocks (IDBs), which increases the number of sessions the GGSN can support. The GTP virtual template is a subinterface. If the no virtual-template subinterface command is configured in global configuration mode, PDPs regenerated to a PPP session run on hardware IDBs instead. When sessions are running on hardware IDBs, the GGSN supports fewer sessions.

Note When the maximum allowable number of PDP contexts is reached, the GGSN refuses new PDP contexts until sessions are available.

To configure the maximum number of PDP contexts on the GGSN, use the following command, beginning in global configuration mode:

Configuring the Maximum Number of PDP Contexts When Using DFP with Load Balancing

If you use DFP with GPRS/UMTS load balancing, you must also specify a maximum number of PDP contexts for each GGSN. Do not accept the default value of 10000 PDP contexts; a value of 45000 is recommended. Significantly lower values can affect performance in a GPRS/UMTS load-balancing environment.

Note For more information about configuring GPRS/UMTS load balancing, see the IOS Server Load Balancing, 12.1(9)E documentation located at Cisco.com at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121e/121e9/index.htm

To configure the maximum number of PDP contexts on the GGSN for DFP, use the following command, beginning in global configuration mode:

Controlling Sessions on the GGSN

GPRS/UMTS provides always-on services for mobile users. The GGSN can support only a certain number of PDP contexts. The number of PDP contexts supported depends upon the configuration and memory resources of the platform.

Sessions can be established with the GGSN that provide network connectivity, even though no activity might be occurring over that session. After a PDP context is established on the GGSN, whether there is activity over the session or not, resources are being used by the GGSN. Therefore, you might want to configure a session timer that controls the amount of time that a session can remain established on the GGSN before the PDP context (or contexts) is cleared.

Additionally, when performing certain maintenance functions (for example, modifying an APN configuration), you can manually delete PDP contexts.

This section includes the following topics:

•Configuring Session Timers

•Deleting Sessions on the GGSN

Configuring Session Timers

This section describes how you can configure the session idle time and absolute session time on the GGSN to control when the GGSN deletes a session. The section includes the following topics:

•Overview of the Session Idle Timer and the Absolute Session Timer on the GGSN

•Configuring the Session Idle Timer (Optional)

•Configuring the Absolute Session Timer (Optional)

•Disabling the Session Idle Timer on the GGSN

•Verifying the Timer Configuration

Overview of the Session Idle Timer and the Absolute Session Timer on the GGSN

The GGSN allows you to control the clearing of PDP contexts by configuring durations for a session idle timer (RADIUS attribute 28) and an absolute session timer (RADIUS attribute 27). The session idle timer and absolute session timer specify the amount of time that the GGSN waits before purging a mobile session.

The duration specified for the session idle time is the same for all of the PDP contexts belonging to a session (a GTPv1 mobile session can have multiple PDP contexts), but an individual timer is started for each PDP context of that session. Therefore, the session idle timer is per-PDP, but the timer duration is per-session. The absolute session timer is session-based and controls the absolute duration of a session (active or inactive). When the absolute session timer is exceeded, the GGSN deletes all PDP contexts of the session (those with the same IMSI or MS address).

Note The session idle timeout (RADIUS Attribute 28) support applies to IP PDPs, PPP PDPs terminated at the GGSN, and PPP regenerated PDPs (not PPP L2TP PDPs). The absolute session timeout (Attribute 27) support applies to IP PDPs and PPP PDPs terminated at the GGSN (not PPP Regen or PPP L2TP PDPs). If configured, a session idle timer is started on every PDP context; an absolute session timer is started on the session.

You can configure the timers globally on the GGSN for sessions occurring on all access points, and you can configure timers for a particular access point. In addition to the session idle timer and the absolute session timer that you can configure on the GGSN, RADIUS servers can also specify session timeout attributes.

The following list gives the order in which the GGSN implements the timers:

1. RADIUS server—If the access point is configured for non-transparent access mode and the RADIUS server returns a timeout attribute, then the GGSN sets the timeout value based on the attribute sent from the RADIUS server. The RADIUS server timeout attribute is given in seconds. If the value returned by the RADIUS server is less than 30 seconds, the GGSN sets the timeout value to 30 seconds. If the value is greater than 30 seconds, the GGSN sets the timeout value to the same value returned by the RADIUS server.

2. Access-point—If the access point is configured for transparent access mode, or is in non-transparent access mode and the RADIUS server does not return a timeout value, then the GGSN uses the value that you specified for the gtp pdp-context timeout session or gtp pdp-context timeout idle commands.

3. Global timer—If the GGSN does not receive a timeout value from the RADIUS server or the access point, then it uses the value that you specified for the gprs gtp pdp-context timeout session or gprs gtp pdp-context timeout idle commands.

In summary, the timeout values from the RADIUS server take precedence over the timer configurations on the GGSN, and the timers for a particular access point takes precedence over the globally configured timers.

The values for the gtp pdp-context timeout session and gtp pdp-context timeout idle commands override the values for the gprs gtp pdp-context timeout session or gprs gtp pdp-context timeout idle commands.

Note When you enable a session timer (idle or absolute), any GGSN CDRs (G-CDRs) triggered for the termination of a PDP context because a timer expires will have a cause value of "managementIntervention."

Configuring the Session Idle Timer

GGSN supports the RADIUS Idle-Timeout (Attribute 28) field. The GGSN stores the attribute 28 value if it is present in the access request packets sent by the AAA server. When a PDP context is idle for an amount of time that exceeds the duration specified with this command, the GGSN terminates the context.

The duration specified for the timer applies to all PDP contexts of a session, however, a timer is started for each PDP context.

The session idle timer can be configured globally and at the APN. The values configured at the APN level override those configured globally.

Note The session idle timer started for a PDP context is reset by TPDU traffic and GTP signaling messages for that PDP context. For example, if an Update PDP Context request is received, the session idle timer is reset for that PDP context.

Configuring the Session Idle Timer Globally on the GGSN

To configure the amount of time that the GGSN allows a PDP context to remain idle on any access point before purging the context, use the following command, beginning in global configuration mode:

Note Alternately, you can configure the session idle timer globally using the gprs idle-pdp-context purge-timer hours global configuration command, however, the two methods cannot be configured at the same time.

Configuring the Session Idle Timer on an Access Point on the GGSN

To configure the amount of time that the GGSN allows a PDP context to remain idle for a particular access point before purging the context, use the following command, beginning in access-point configuration mode:

Note Alternately, you can configure the session idle timer on an access-point using the session idle-time hours access-point configuration command, however, the two methods cannot be configured at the same time.

Disabling the Session Idle Timer on the GGSN

By default, for all access points, the GGSN purges the idle PDP contexts of a session after 72 hours. If you want to allow PDP contexts to remain idle for an indefinite period of time, you can disable the timer for a particular user by configuring 0 as the session idle time duration in the user profile on the RADIUS server. If the user is not authenticated by RADIUS, the session idle timer cannot be disabled.

Configuring the Absolute Session Timer

GGSN supports the RADIUS Session-Timeout (Attribute 27) field. When you enable the absolute session timer, the GGSN stores the attribute 27 value if it is present in the access request packets sent by the AAA server. When the duration of a session exceeds the value specified with this command, the GGSN terminates all PDP contexts belonging to the session (those with the same IMSI or MS address).

The absolute session timer can be configured globally and at the APN. The values configured at the APN level override those configured globally.

By default, the absolute session timer is disabled.

Note The GGSN absolute session timer requires that you have enabled the GGSN to include the Session-Timeout (Attribute 27) in RADIUS requests using the gprs radius attribute session-timeout global configuration command.

Configuring the Absolute Session Timer Globally on the GGSN

To configure the amount of time that the GGSN allows a session to exist for any access point before ending the session and purging all PDP contexts belonging to the session, use the following command in global configuration mode:

Configuring the Absolute Session Timer on an Access Point on the GGSN

To configure the amount of time that the GGSN allows a session to exist on a particular access point before ending the session and purging all PDP contexts belonging to the session, use the following command in access-point configuration mode:

Disabling the Absolute Session Timer on the GGSN

By default, the absolute session timer is disabled on the GGSN. To return to the default configuration after enabling the absolute session timer, use the no form of the global or access-point configuration commands (no gprs gtp pdp-context timeout session or no gtp pdp-context timeout session).

Verifying the Timer Configuration

To display timer information for a particular PDP context, you can use the show gprs gtp pdp-context command, using the tid or imsi keywords. The following example shows sample output for the show gprs gtp pdp-context tid command for a PDP context with an session idle timer set at the value of 200 hours (720000 seconds) and an absolute session timer set at 24 hours (86400 seconds). The timer values are displayed in the session timeout and idle timeout fields shown in bold:

Router#show gprs gtp pdp-context tid 1111111111111111

TID              MS Addr         Source  SGSN Addr       APN

1111111111111111 10.1.1.1        Radius  10.8.8.1        dns.com

    current time :Mar 18 2002 11:24:36

    user_name (IMSI):1111111111111111   MS address:10.1.1.1

    MS International PSTN/ISDN Number (MSISDN):ABC

    sgsn_addr_signal:10.8.8.1           sgsn_addr_data:10.8.0.1

    control teid local: 0x63493E0C

    control teid remove: 0x00000121

    data teid local:  0x63483E10

    data teid remote:  0x00000121

    primary pdp: Y      nsapi: 0

    signal_sequence: 0                  seq_tpdu_up:     0

    seq_tpdu_down:   0

    upstream_signal_flow:  1            upstream_data_flow:  2

    downstream_signal_flow:14           downstream_data_flow:12

    RAupdate_flow:         0

    pdp_create_time:  Mar 18 2002 09:58:39

    last_access_time: Mar 18 2002 09:58:39

    mnrgflag:         0                tos mask map:00

    session timeout: 86400

    idle timeout: 720000

    gprs qos_req:091101               canonical Qos class(req.):01

    gprs qos_neg:25131F               canonical Qos class(neg.):01

    effective bandwidth:0.0

    rcv_pkt_count:     0              rcv_byte_count:  0

    send_pkt_count:    0              send_byte_count: 0

    cef_up_pkt:        0              cef_up_byte:    0

    cef_down_pkt:      0              cef_down_byte:  0

    cef_drop:           0             out-sequence pkt: 0

    Src addr violation:            2 paks,     1024 bytes

    Dest addr violation:           2 paks,     1024 bytes

    Redirected mobile-to-mobile traffic:  2 paks,     1024 bytes

    charging_id:        29160231

    visitor: No        roamer: No

    charging characteristics: 0

    charging characteristics received: 0

    pdp reference count:2

    primary dns:        2.2.2.2

    secondary dns:      4.4.4.4

    primary nbns:       3.3.3.3

    secondary nbns:     5.5.5.5

    ntwk_init_pdp:      0

    Framed_route 5.5.5.0 mask 255.255.255.0

    ** Network Init Information **

    MNRG Flag: 0                PDU Discard Flag: 0

    SGSN Addr: 172.16.44.1      NIP State:        NIP_STATE_WAIT_PDP_ACTIVATION

    Buf.Bytes: 500

Deleting Sessions on the GGSN

If necessary, you can manually delete PDP contexts using the clear gprs gtp pdp-context privilege EXEC command.

You can delete PDP contexts by TID, IMSI value, or by access point (by IP version or all active PDPs on that access-point).

As defined by 3GPP standards, by default, the GGSN sends a delete PDP context request to the SGSN, and waits for a response from the SGSN before deleting the PDP context. Also, only a certain number of PDP contexts can be deleted at one time when multiple PDP contexts are being deleted.

If an SGSN is not responding to the GGSN's delete PDP context requests, a long delay might occur before the task is completed. You can use the Fast PDP Delete feature (the no-wait-sgsn and local-delete access point keyword options) to eliminate this delay. The Fast PDP Delete feature enables you to delete PDP contexts within an APN without the GGSN waiting for a response from the SGSN, or delete PDP contexts locally without the GGSN sending a delete PDP context request to the SGSN at all.

When using the Fast PDP Delete feature, note the following:

•The Fast PDP Delete feature can be used only when an APN or the GGSN is in maintenance mode. Therefore, the no-wait-sgsn and local-delete keyword options are available only when the APN or GGSN is in maintenance mode.

•When the no-wait-sgsn and local-delete keyword options are specified, and the command entered, the GGSN prompts you with the following caution:

Deleting all PDPs without successful acknowledgements from the SGSN will result in the 
SGSN and GGSN going out of sync. Do you want to proceed ? [n]:

The default is no. To cancel the delete, type n and press enter. To proceed with the delete, type y and press enter.

•When processing service-aware PDPs, while the GGSN does not wait for a response from the SGSN when the Fast PDP Delete feature is used, the GGSN must wait for a response from the Cisco CSG and Diameter server. Therefore, the Fast PDP Delete feature is not as useful for service-aware PDPs.

•If a delete PDP context requests is lost, the SGSN will not be able to delete the PDP context. This condition might result in inconsistent CDRs generated by the GGSN and the SGSN.

•When the no-wait-sgsn keyword option is specified, the GGSN does not throttle the delete PDP context requests to the SGSN, and therefore, the GGSN might flood the SGSN with delete PDP context requests.

•The Fast PDP Delete feature applies only to PDP deletion initiated by the clear gprs gtp-context privilege EXEC command. PDP deletion due to other circumstances, such as PDP deletion during a failure condition, is not impacted.

To manually delete PDP contexts, use the following command in privilege EXEC mode:

Router(config-access-point)# clear gprs gtp 
pdp-context {tid tunnel-id | imsi imsi_value | 
path ip-address [remote_port_num] | access-point 
access-point-index [no-wait-sgsn | local-delete] | 
pdp-type {ipv6 | ipv4} | all}

For more information about placing an APN in maintenance mode, see "Configuring APN Maintenance Mode" section.

Configuring Flow Control for GTP Error Messages

GTP error indication messages are sent by the GGSN to the SGSN when the SGSN sends data for PDP context the GGSN cannot locate. The error indication message informs the SGSN that the PDP context cannot be located so that the SGSN can clean up the PDP context on its end.

By default, the GGSN disables flow control for GTP error messages.

You can enable flow control for transmission of GTP error messages by using the gprs gtp error-indication-throttle global configuration command. This command sets the initial value of a counter which is decremented each time an error indication message is sent. When the counter reaches zero, the GGSN stops transmitting error indication messages. The GGSN resets this counter to the configured throttle value after one second.

To configure flow control for GTP error messages, use the following command in global configuration mode:

Configuring the GGSN to Maintain a History for Deleted SGSN Paths

The Cisco GGSN can be configured to store statistics collected for deleted SGSN paths.

To configure the maximum number of deleted SGSN paths entries for which you want the GGSN to store a history of statistics, use the following command in global configuration mode:

Note If the number of entries is changed to a lower value, the older values are deleted.

Suppressing Echo Requests per SGSN

Using the gprs gtp path sgsn global configuration command, operators can selectively disable echo requests for GSNs that might not have the capability to respond to echo requests from the GGSN while keeping the echo requests intact for the other SGSNs. Additionally, echo requests can be disabled for a specific port of a GSN.

When a new path is created, the GGSN checks to see if the path parameters, namely the destination address and port, matches any of the conditions configured when suppressing echo requests using the gprs gtp path command. If the parameters match, the GGSN sets the path echo interval to 0 for that path. Otherwise, the global path echo interval configuration is used to send echo requests.

You can disable echo requests for a range of IP addresses, or a single IP address, with an optional port number.

To suppress echo requests, use the following command in global configuration mode:

Router(config)# gprs gtp path sgsn start-ip-address 
[end-ip-address] [UDP port] echo 0

The following example disables echo requests for one SGSN:

Router(config)# gprs gtp path sgsn 10.10.10.10 echo 0

The following example disables echo request for one SGSN for port 4000 only:

Router(config)# gprs gtp path sgsn 10.10.10.10 4000 echo 0

Configuring Support for GGSN-Initiated Update PDP Context Requests

Note GGSN-initiated Update PDP Context Requests are supported for GTPv1 PDP contexts.

With Cisco GGSN Release 8.0 and later, a Cisco GGSN can send an Update PDP Context Request (as defined in 3GPP TR 29.060 v7.5.1, section 7.3.3) to an SGSN to negotiate the QoS of a PDP context.

An external entity, such as the Cisco Content Services Gateway (CSG) in an Gx environment, can push a new QoS profile to the GGSN to apply on a particular PDP context. The GGSN then pushes the changes to the RAN in an Update PDP Context Request to the SGSN.

Additionally, when a direct tunnel is being used for a PDP context, the GGSN sends an Update PDP Context Request to an SGSN in response to an error indication message from a Radio Network Controller (RNC).

The GGSN includes the following Information Elements (IEs) in the Update PDP Context Request:

•Recovery

•NSAPI

•QoS profile

•Direct tunnel flags, if the update request is initiated due to a direct tunnel error indication received from the RNC.

Once the QoS has been renegotiated, the SGSN returns an Update PDP Context Response to the GGSN to complete the process. If the Cause value in the Update PDP Context Response from the SGSN is "Request Accepted," one of the following actions will occur:

•If the Update PDP Context Request was initiated by an error indication message from the RNC, the PDP context is preserved.

•If the Update PDP Context Request was initiated by a CoA containing new QoS, then an Interim-Acct-Update message is sent to communicate the new QoS (the QoS values supplied in the Update PDP Context Request might have been negotiated downwards by the SGSN). The GGSN will inform the same in an Acct-Update message.

If the Cause value in the Update PDP Context Response is anything other than "Request Accepted," then one of the following actions will occur:

•If the Update PDP Context Request was initiated due to an error indication from the RNC, the PDP is locally deleted.

•If the Update PDP Context Request was initiated by a CoA, then:

–If the gprs gtp update qos-fail delete global configuration command or the gtp update qos-fail delete access-point configuration commands are configured, the GGSN will delete the PDP context and send notification of the update failure in an Acct-Stop message.

–If the gprs gtp update qos-fail delete global configuration command or the gtp update qos-fail delete access-point configuration command are not configured, the GGSN will retain the PDP context and generate an accounting interim record with the negotiated QoS value.

–In all cases of failure, an error message is logged to indicate the failure.

Note There is no error message syslog generated for direct tunnel update PDP context request failure.

To enable GGSN-initiated Update PDP Context Requests globally, issue the following command while in global configuration mode:

To enable GGSN-initiated Update PDP Context Requests on an APN, issue the following command while in access-point configuration mode:

Using the Service-Mode Function

The GGSN service-mode function enables you to make configuration changes and test calls without affecting all active sessions on a GGSN. You can configure the service-mode state globally, on an access-point, and for the GGSN charging function. There are two service-mode states: operational and maintenance. The default mode is operational.

Configuring Global Maintenance Mode

When a GGSN is placed in global maintenance mode, it rejects all new Create PDP Context requests. Therefore, no new PDP contexts are activated for an entire GGSN while it is in global maintenance mode.

The following sections provide examples of how to use global maintenance mode:

Adding a New GGSN

1. Enable GGSN services and place the GGSN in maintenance mode.

Router(config)# service ggsn

Router(config)# gprs service-mode maintenance

2. Configure the GGSN for your network.

3. Place the GGSN in operational mode.

Router(config)# gprs service-mode operational

Modifying a GGSN

1. Place the GGSN in maintenance mode.

Router(config)# gprs service-mode maintenance

Wait for existing PDPs for all APNs to be released normally (average session time is approximately 1 hour) and for buffered CDRs to be sent to the charging gateway. If it is not possible for CDRs to be sent to the CG because there is not an active charging gateway, manually clear the CDRs by placing the charging function in maintenance mode using the gprs charging service-mode command and issuing the clear gprs charging cdr all no-transfer command. For more information on placing the charging function in maintenance mode, see the "Configuring Charging Maintenance Mode" section.

2. Modify the GGSN configuration as desired.

3. Return the GGSN to operational mode.

Router(config)# gprs service-mode operational

Deactivating a GGSN

1. Place the GGSN in maintenance mode.

Router(config)# gprs service-mode maintenance

Wait for existing PDPs for all APNs to be released normally (average session time is approximately 1 hour) and for buffered CDRs to be sent to the charging gateway. If it is not possible for CDRs to be sent to the CG because there is not an active charging gateway, manually clear the CDRs by placing the charging function in maintenance mode using the gprs charging service-mode command and issuing the clear gprs charging cdr all no-transfer command. For more information on placing the charging function in maintenance mode, see the "Configuring Charging Maintenance Mode" section.

2. Remove the GGSN from service.

Router(config)# no service gprs ggsn

To configure the global service-mode state of the GGSN, use the following global configuration command:

Note When the GGSN is in global maintenance mode, all APNs are placed in maintenance mode as well.

Configuring APN Maintenance Mode

The service-mode state of an APN can be configured to enable you to add a new APN or modify an existing APN without affecting sessions for other APNs in the GGSN.

When an APN is in maintenance mode, it does not accept Create PDP Context requests. Once active PDP contexts are released (or manually cleared using the clear gprs gtp pdp-context access-point command), all APN-related parameters can be configured or modified and the APN set to operational mode.

Additionally, once you have added and configured an APN, you can verify the configuration using the gprs service-mode test imsi global configuration command to set up a test user (one per GGSN) and performing a PDP context creation.

Note The GGSN must be in operational mode (gprs service-mode operational command) to test a PDP context creation from a test user using the gprs service-mode test imsi command.

To delete an APN, change the APN service-mode state to maintenance mode, wait for all existing PDPs to be released, and then remove the APN using the no access-point-name command.

To configure the service-mode state of an APN, use the following access-point configuration command:

The following sections provide examples of how to use APN maintenance mode:

Adding a new APN

1. Add a new APN and place it in maintenance mode (by default, an APN is in operational mode).

Router(config-access-point)# access-point-name apn-num

Router(config-access-point)# service-mode maintenance

2. Configure the APN.

3. Create a PDP context to test the APN configuration.

Router(config)# gprs service-mode test imsi imsi-value

4. Place the APN in operational mode.

Router(config-access-point)# service-mode operational

Modifying an APN

1. Place the APN in maintenance mode.

Router(config-access-point)# service-mode maintenance

Wait for PDP contexts to be released or clear them manually using the clear gprs gtp pdp-contexts access-point command.

2. Modify the APN.

3. Create a PDP context to test the APN configuration.

Router(config)# gprs service-mode test imsi imsi-value

4. Place the APN in operational mode.

Router(config-access-point)# service-mode operational

Deleting an APN:

1. Place the APN in maintenance mode.

Router(config-access-point)# service-mode maintenance

Wait for PDP contexts to be released or clear them manually using the clear gprs gtp pdp-contexts access-point command.

2. Delete the APN.

Router(config-access-point)# no access-point-name apn-num

Configuring Charging Maintenance Mode

The charging function of a GGSN primarily consists of collecting call detail records (CDRs) and transmitting CDRs to charging gateways. The service mode state of the GGSN charging function does not impact the collection of CDRs. However, when the charging function is placed in maintenance service-mode state, CDRs are not transmitted to the charging gateway (CG).

When the charging function is in maintenance mode, you can add, delete, or modify CGs (for example, change the IP address of the CGs, their priority, and number). If a new primary charging gateway is configured while the charging function is in maintenance mode, when the charging function of the GGSN is placed back in operational mode, all accumulated CDRs are sent to the new CG.

When in maintenance mode, all collected CDRs, and those in the pending queue, are stored on the GGSN. If desired, these stored CDRs can be cleared using the clear gprs charging cdr all no-transfer command. When cleared, they will not be transmitted to the CG when the charging function is returned to operational mode.

The following charging function configuration commands require the charging function to be in maintenance mode:

•gprs charging path-protocol

•gprs charging header short

•gprs charging map data tos

•gprs charging message transfer-request command-ie

•gprs charging message transfer-response number-responded

•gprs charging port

•gprs default charging-gateway

•gprs charging send-buffer

By default the charging function is in operational mode. To configure the service-mode state of the charging function, use the following global configuration command:

The following section provide example of how to use charging maintenance mode:

Modifying a Charging Gateway

1. Place the GGSN charging function in maintenance mode.

Router(config)# gprs charging service-mode maintenance

CDRs are collected but not transmitted. All collected and buffered CDRs are stored until the charging function is returned to operational mode. At that time, they are sent to the CG.

2. Modify the charging configuration (number of gateways, path protocol, order, etc.).

3. If desired, clear all stored and pending CDRs so that they will not be sent to the CG once the charging function is returned to operational mode.

Router(config)# clear gprs charging cdr all no-transfer

4. Return the charging function to operational mode.

Router(config)# gprs charging service-mode operational

To manually clear all CDRs stored on the GGSN, including those in the pending queue, use the following global configuration command:

Note To clear CDRs, the GGSN must be in global maintenance mode (using the gprs service-mode maintenance command) and charging maintenance mode (using the gprs charging service-mode maintenance command.

Note When the GGSN is in charging and global maintenance mode, the GGSN no longer creates CDRs for existing PDPs.

Monitoring and Maintaining GTP on the GGSN

This section provides a summary list of the show commands that you can use to monitor GTP on the GGSN.

The following privileged EXEC commands are used to monitor and maintain GTP on the GGSN:

Router# show gprs gtp ms {imsi imsi | 
access-point access-point-index | all}

Router# show gprs gtp status

Router# show gprs service-mode

Configuration Examples

This section includes the following examples:

•GGSN Configuration Example

•Dynamic Echo Timer Configuration Example

GGSN Configuration Example

The following example shows part of a sample GGSN configuration with some of the commands that you use to configure basic GGSN GTP services:

Router# show running-config

Current configuration : 3521 bytes

!

version 12.2

no service single-slot-reload-enable

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

! Enables GGSN services

!

service gprs ggsn

!

ip cef

!

! Configures a loopback interface

!

interface loopback 1

 ip address 10.40.40.3 255.255.255.0

!

! Defines the virtual-template interface

! with GTP encapsulation

!

interface Virtual-Template1

 ip unnumber loopback 1

 encapsulation gtp

 gprs access-point-list gprs

!

. . .

!

gprs access-point-list gprs

!

  access-point 1

   access-point-name gprs.cisco.com

   exit

!

  access-point 2

   access-point-name gprt.cisco.com

   exit

   !

  access-point 3

   access-point-name gpru.cisco.com

   access-mode non-transparent

   aaa-group authentication abc

   exit

!

! Configures GTP parameters

!

gprs maximum-pdp-context-allowed 90000

gprs gtp path-echo-interval 0

gprs default charging-gateway 10.15.15.1

!

! Enables the memory protection feature to become active if the memory threshold falls 
! below 50 MB

!

gprs memory threshold 512

!

. . .

. . .

!

end

Dynamic Echo Timer Configuration Example

The following example shows part of a sample GGSN configuration for the dynamic echo timer. In this example, the dynamic echo timer is enabled, the smooth factor is changed from the default value of 2 to the value 5, and the dynamic minimum value is changed from the default value of 5 seconds to the value 10 seconds:

Router# show running-config

Current configuration : 6769 bytes

!

version 12.2

no service pad

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

service internal

service gprs ggsn

!

ip cef

!

. . .

!

interface loopback 1

 ip address 10.41.41.1 255.255.255.0

!

interface Virtual-Template1

 ip unnumber loopback 1

 encapsulation gtp

 gprs access-point-list gprs

!

. . .

!

gprs access-point-list gprs

  access-point 1

   access-point-name gprs.cisco.com

   exit

   !

  access-point 2

   access-point-name gprt.cisco.com

   access-mode non-transparent

   aaa-group authentication test2

   aaa-group accounting test2

   ip-address-pool dhcp-proxy-client

   dhcp-server 10.65.0.1

   dhcp-gateway-address 10.65.0.1       

   exit

!

! Enables the dynamic echo timer

!

gprs gtp echo-timer dynamic enable

! 

! Configures a smooth factor of 5

!

gprs gtp echo-timer dynamic smooth-factor 5

!

! Configures the dynamic minimum as 10 seconds

!

gprs gtp echo-timer dynamic minimum 10

gprs gtp response-message wait-accounting

!

end