> SGSN Global Configuration Mode Commands
> The commands in this mode configure SGSN-specific parameters impact the entire SGSN and that are independent of the GPRS or the IuPS services.
> In this mode, your prompt will look similar to:
> [local]hostname(config-sgsn-global)#
> The SGSN Global configuration mode is a sub-mode derived from the Global configuration mode.
> aggregate-ipc-msg
> Enables/disables aggregation of inter-process communication (IPC) messages in the link manager (linkmgr) and session manager (sessmgr).
> Product
> SGSN, HNB-GW
> Privilege
> Security Administrator, Administrator
> Syntax
> aggregate-ipc-msg { linkmgr | sessmgr } { flush-frequency frequency | num-msgs number_msgs }
> default aggregate-ipc-msg { linkmgr | sessmgr }
> default
> Resets the managers to default values for flushing.
> linkmgr
> Selects the linkmgr to configure the number of IPC messages to be aggregated and frequency of flushing.
> sessmgr
> Selects the sessmgr to configure the number of IPC messages to be aggregated and frequency of flushing.
> flush-frequency frequency
> Configure the frequency, in 100-millisecond intervals, that the aggregated IPC messages will be flushed.
> frequency : Enter an integer from 1 to 3. Default is 1.
> num-msgs number_msgs
> Configure the number of IPC messages to aggregate before flushing.
> number_msgs : Enter the integer 1 (to disable aggregation) or an integer from 2 to 164 to define the number of messages. Default is 10.
> Usage
> Use this command to enable/disable aggregation of IPC messages in the linkmgr and/or the sessmgr. This command includes options to configure the frequency of aggregated message flushing and the number of packets to be buffered before the flush.
> At the HNB-GW node this command provides the solution to reduce the latency while sending the IPC messages towards core network (CN).
> In default scenario on HNB-GW the Link manager buffers the packets and then send it over SCCP link if there are events to be sent SCCP Connection Request (SCCP CR) towards Core node side. It aggregate packets for 100 msec and send it with whatever aggregation it has done in those 100 msecs.
> At the HNB-GW this command can be used to reduce the processing of sending every individual events out on the wire towards core node side from HNB-GW in following manner:

> • | If this aggregation is enabled, then there could be time delay seen on the wire for sending SCCP CR depending on configuration of HNB-GW.

> • | If this aggregation is reduced to 1 (that means as soon as there is event to send out namely SCCP CR is available to send out on the wire), it will be immediately seen on the wire and SCCP connection setup time is reduced because of immediate sending of SCCP CR and not waiting for aggregation.

> To view aggregate IPC message statistics, use command show config | grep aggregate-ipc-msg.
> Example
> Configure the linkmgr to buffer 45 messages before flushing the linkmgr IPC messages:
> aggregate-ipc-msg linkmgr flush-frequency 45
> On HNB-GW the following command configures the linkmgr to flush the IPC messages towards CN without aggregation:
> aggregate-ipc-msg linkmgr 1
> On HNB-GW the following command configures the sessmgr to flush the IPC messages towards CN without aggregation:
> aggregate-ipc-msg sessmgr 1
> apn-resolve-dns-query snaptr
> Enable/disable sending of SNAPTR DNS query to resolve an APN for a subscriber with an EPS (evolved packet system)-capable handset.
> Important: This command is no longer available in all 12.0 and 12.2 releases. If you do not see this command in your release, look for the apn-resolve-dns-query snaptr command in the APN Profile configuration mode to accomplish the same task.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] apn-resolve-dns-query snaptr
> default apn-resolve-dns-query
> default
> Resets the default, the ability to send SNAPTR DNS query is disabled.
> no
> Disables the ability to send SNAPTR DNS query.
> Usage
> By default, sending the SNAPTR DNS query is disabled. Use this command to send SNAPTR DNS query when resolving an APN for an EPS-capable subscriber.
> At PDP context activation, the SGSN will use the UE capabilitly as input to select either a GGSN or a P-GW for the EPS-capable subscriber. The SNAPTR DNS query will be used for P-GW resolution. Enabling this feature will give priority to P-GW selection for E-UTRAN-capable UEs.
> Example
> Use the following command to enable sending of SNAPTR DNS query for APN resolution:
> apn-resolve-dns-query
> Use the following command to disable the use of SNAPTR DNS query for APN resolution:
> no apn-resolve-dns-query
> bssgp-message ms-flow-control-from-unknown-ms
> This command determines the SGSN response to MS-Flow-Control messages received from an unknown MS.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> bssgp-message ms-flow-control-from-unknown-ms { discard-message | send-ack | send-status }
> default bssgp-message ms-flow-control-from-unknown-ms
> default
> Including default with the command configures the SGSN to use default behavior so that the SGSN sends BSSGP-Status messages whenever the SGSN receives an MS-Flow-Control message from an unknown MS.
> discard-message
> This keyword instructs the SGSN to discard the received BSSGP message. With this option, the SGSN does not send any response to the MS after discarding the received BSSGP message.
> send-ack
> This keyword instructs the SGSN to send an acknowledgement message (MS-Flow-Control-ACK) after receiving an MS-Flow-Control message.
> send-status
> Default
> This keyword instructs the SGSN to send a BSSGP-Status message to the MS whenever the SGSN receives an MS-Flow-Control message from an unknown MS.
> Usage
> This command allows the operator to specify the action the SGSN needs to take whenever the SGSN receives an MS-Flow-Control message from an unknown mobile station. This configuration determines the response for the SGSN globally.
> The list of possible actions are:

> • | send a BSSGP-Status response message

> • | send an ACK message (MS-Flow-Control-ACK)

> • | discard the BSSGP message

> To see the statistics for the number of MS-Flow-Control messages that have been discarded, use the show bssgp statistics command from the Exec mode.
> Example
> Change the default configuration and have the SGSN acknowledge receipt of the MS-Flow-Control message:
> bssgp-message ms-flow-control-from-unknown-ms send-ack
> bssgp-message ptp-bvc-reset
> This command determines the SGSN response, per BVCI, to receipt of a peer-to-peer BVC Reset.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> bssgp-message ptp-bvc-reset { frc-subscriber-standby | retain-current-state }
> default bssgp-message ptp-bvc-reset
> default
> Including default with the command configures the SGSN to use default behavior so that the SGSN continues with the current state once a peer-to-peer BVC Reset is received.
> frc-subscriber-standby
> This keyword instructs the SGSN to change the state of the subscribers to standby when the peer-to-peer BVC Reset is received.
> retain-current-state
> Default
> This keyword instructs the SGSN to continue the current state of the subscribers when the BVC Reset message is received.
> Usage
> This command allows the operator to specify the action the SGSN needs to take whenever the SGSN receives a peer-to-peer BVC Reset message for a specific BVCI.
> To confirm the configuration for the response to the BVC Reset, use the show sgsn-mode command from the Exec mode.
> Example
> Change the default configuration and have the SGSN change subscriber states to standby:
> bssgp-message ptp-bvc-reset frc-subscriber-standby
> bssgp-timer
> Configures the T2 and TH timers for the BVCs (BSSGP virtual connections) of the NSE (network service entities).
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> bssgp-timer { t2 T2_time | th TH_time }
> default bssgp-timer { t2 | th }
> default
> Resets the specified timers to default settings.
> t2 T2_time
> Configures the BVC reset guard timer (at the BSSGP layer) in units of 1 second.
> T2_time : Enter an integer from 1 to 120. Default is 30 seconds.
> th TH_time
> Configures, at the BSSGP layer, the MS flow control parameter validity timeouts in units of 1 second.
> TH_time : Enter an integer from 6 to 5999. Default is 500 seconds.
> Usage
> Use this command to configure timer timeout values for MS flow control and BVC reset timers that control BVCs for the NSEs.
> Example
> Set the TH timeout for 20 seconds:
> bssgp-timer th 20
> bvc-unblock
> This command enables (disabled by default) or disables the SGSN to unblock blocked BVCs based on the receipt of uplink packets from the BSC.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> bvc-unblock { data-or-flow-control | flow-control | ul-data }
> [ default | no ] bvc-unblock
> default
> Include default with the command to disable the function.
> no
> Include no with the command to disable this function.
> data-or-flow-control
> Enables the BVC-Unblock function when the SGSN receives either a FLOW-CONTROL-BVC packet or a UL-UNITDATA packet.
> flow-control
> Enables the BVC-Unblock function when the SGSN receives a FLOW-CONTROL-BVC packet.
> ul-data
> Enables the BVC-Unblock function when the SGSN receives a UL-UNITDATA packet.
> Usage
> Configurations defined with this command are common to all NSE defined for the SGSN.
> This command is useful if there is a BVC status mismatch across different SGSN managers (such as the sessmgr and the linkmgr) when the BSC sends BVC-Block (SGSN should move to BLOCKED) followed by a BVC-Reset (SGSN should move to UNBLOCKED). Such mismatches can easily occur, particularly on Gb-IP network connection, when one link receives the BVC-Block and a different link receives the BVC-Reset with little delay between the two.
> If BVC-Unblock function is enabled, the SGSN ensures that BVCs which are in the BLOCKED state move to the UNBLOCKED state upon receipt of the configured packet type(s).
> Example
> Instruct the SGSN to perform BVC-Unblock when a mismatch occurs and the SGSN receives a FLOW-CONTROL-BVC packet:
> bvc-unblock flow-control
> dscp-template
> Creates and/or deletes DSCP templates that can be configured for use for all GPRS services on the SGSN.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> dscp-template template_name [ -noconfirm ]
> no dscp-template template_name
> no
> Deletes the template instance from the SGSN Global configuration.
> template_name
> Enter 1 to 64 alphanumeric characters, including dots (.), dashes (-), and forward slashes (/). to identify a unique instance of a DSCP template.
> There is no known limit to the number of templates that can be created.
> Usage
> This command enables the operator to create or delete an instance of a DSCP template. The DSCP templates are used to define the DSCP configuration for control packets and data packets for the GPRS services.
> Related commands:

> • | This command provides access to the mode containing all the configuration commands used to define DSCP markings for the control packets and data packets for a particular GPRS service (see the DSCP Template Configuration Mode Commands section).

> • | To associated a specpific DSCP template with a specific GPRS service configuration, use the associate-dscp-template downlink documented in the GPRS Service Configuration Mode Commands section.

> • | To check the list of DSCP templates configured, use the show sgsn-mode command documented in the Exec Mode Commands section.

> Example
> Use a command similar to the following to create a DSCP template with ID dscp_london that can be used specifically for Gb/IP calls from subscribers in London:
> dscp-template dscp_london
> dual-address-pdp
> This command makes it possible for the operator to enable (default) / disable SGSN support for MS requests for dual PDP type (IPv4v6) addressing.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> [ default | no ] dual-address-pdp
> default
> Enables dual PDP type address support.
> no
> Disables the default behavior so that the SGSN does not honor requests for dual PDP type addresses.
> Usage
> With release 12.2 and in accordance with 3GPP Release 9.0 specifications, by default the SGSN honors the MS/UE request for dual PDP type addressing (IPv4v6) for PDP context association with one IPv4 address and one IPv6 address/prefix. This support can be disabled by configuration.
> Important: For the dual PDP addressing feature to function, common-flags must be enabled with the gptc send command in the SGTP service configuration mode prior to enabling the feature with the dual-address-pdp command.
> With this default behavior, the operator has multiple options to refine the level of support for dual PDP type addressing through the use of several related commands.

> • | dual-address-pdp command in the RNC configuration mode disables SGSN support for dual PDP type addressing for a specific RNC that either does or does not support this type of addressing..

> • | pdp-type-ipv4v6-override in the APN profile configuration mode allows the SGSN to override the MS/UE request for dual PDP type addressing.

> • | Using the dual-ipv4v6 keyword with the wildcard-apn pdp-type command in the APN remap table configuration mode enables the operator to configure a default APN with a wildcard subscription with PDP type IPv4v6.

> Example
> Use the following command to disable support for dual PDP type addressing (IPv4v6):
> no dual-address-pdp
> If dual PDP addressing has been disabled, to renable the feature, move to the SGTP service configuration mode, in the appropriate context, to perform the following as the first command needed to re-enable support for dual PDP type addressing in the configuration:
> gtpc send common-flags
> Now in the SGSN global configuration mode, use the following as the second command required to re-enable support for dual PDP type addressing in the configuration:
> dual-address-pdp
> end
> Exits the current mode and returns to the Exec Mode.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> end
> Usage
> Change the mode back to the Exec Mode.
> exit
> Exits the current mode and returns to the previous configuration mode.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> end
> Usage
> Change the mode to the Global Configuration Mode.
> gmm-message
> This command configures the SGSN to discard (drop) the Attach-Request message received with a random TLLI already in use.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> [ default ] gmm-message attach-with-tlli-in-use discard-message
> default
> Resets the default function allowing multiple MS, using the same random TLLI, to attempt to Attach simultaneously and disables discarding the Attach-Request message for random TLLI already in use.
> Usage
> Working with the two related commands (noted below), this command is part of a procedure for handling multiple MS Attaches all with the Same Random TLLI. Use this command to configure the SGSN to allow only one subscriber at a time to attach using a fixed random TLLI.
> Related Commands:

> • | The old-tlli invalidate tlli command configures a list of random TLLI to be invalidated from the GMM after the invalidate old-TLLI timer expires.

> • | The old-tlli hold-time command configures the old-TLLI expiry timer.

> Example
> Configure the SGSN to drop Attach Request containing TLLI already in use:
> gmm-message attach-with-tlli-in-use discard-message
> imsi-range
> Configure an IMSI range or a PLMN ID to associate with an Operator Policy.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> imsi-range mcc mcc_num mnc mnc_num { msin first start_number last stop_number [ operator-policy policy_name [ description description ] ] | plmnid plmn_id operator-policy policy_name [ description description ] } +
> no imsi-range mcc mcc_num mnc mnc_num { msin first start_number last stop_number | plmnid plmn_id }
> no
> Using no in the command deletes the definition from the SGSN Global configuration.
> mcc mcc_num
> mcc defines the mobile country code (MCC) of an IMSI.
> mcc_num: Enter a 3-digit number from 100 to 999 - 000 to 099 are reserved.
> mnc mnc_num
> mnc defines the mobile network code (MNC) of an IMSI.
> mnc_num: Enter a 2 or 3-digit number from 00 to 999.
> msin
> MSIN (mobile subscriber international number) portion of the IMSI.
> first start_num: Defines first MSIN prefix number in a range
> last stop_num: Defines the last or final MSIN prefix number in a range.
> operator-policy policy_name description description
> Identify the operator policy that the IMSI range definition and/or the PLMN-ID is to be associated.
> policy_name : Enter a string of 1 to 64 alphanumeric characters.
> description: Enter a string of 1 to 100 alphanumeric characters to provide range clarification for converted Release 9.0 configurations.
> If a PLMN-ID is to be included in the definition, enter the plmnid before entering the operator policy name.
> plmnid plmn_id
> The 5-6 digit PLMN-ID consists of the MCC (mobile country code) plus the MNC (mobile network code) to identify the public land mobile network (PLMN) for a specific operator. This keyword associates a specific PLMN with this specific SGSN operator policy.
> plmn_id : Enter 5 to 6 digits.
> +
> This symbol indicates that command can be repeated to create repeated definitions.
> Usage
> An IMSI = maximum of 15 digits. An IMSI consists of the MCC (3 digits) + the MNC (2 or 3 digits) + the MSIN (the remaining 10 or 9 digits depending on the length of the MNC ).
> MCC and MNC are the minimum amount of information required to identify a unique operator policy with IMSI filtering. The MCC and MNC combine uniquely to identify the country and the network operator, for example: Cingular Wireless in the United States = mcc 311 mnc 180
> To improve the granularity of call handling, an operator policy with additional IMSI filtering parameters can be defined, to include filtering based on the MSIN, by defining a MSIN range - first (or start-of-range) MSIN and last (or end-of-range) MSIN. The range numbers do not include the maximum allowed for the MSIN but should include a sufficient number to enable the operator policy to filter effectively.
> For the most efficient IMSI filter, the operator policy should include all of the above parameters and the PLMN ID which defines the current location of the MS -- this parameter is particularly useful for highlighting which calls are roaming.
> And if none of the operator policies contain useful filtering information, then the default operator policy will be applied as the information in this command is never defined for the default operator policy.
> The following table will illustrate how these filtering parameters determine which operator policy will govern a call:

> Operator Policy ID | MCC | MNC | MSINfirst | MSINlast | PLMN ID
> OpPol-1 | 123 | 45 | 67890 | 67898 |
> OpPol-2 | 123 | 45 |  |  |
> OpPol-3 | 123 | 45 | 67890 | 67898 | 23232
> OpPol-4 | 123 | 45 |  |  | 23232
> OpPol-5 | 123 | 45 | 6789012 | 6789019 |
> OpPol-6 | 123 | 45 | 6789012 | 6789019 | 23232
> default |  |  |  |  |

> ‌
> The filtering selects which operator policy will be used to determine how a call is handled - the operator policy that best matches the IMSI. So, a call with IMSI 123456789012345 PLMNID 23232 is best matched with OpPol-6.
> In most cases, the operator policy with the most information defined will be used as a combination of PLMNID and IMSI provides the best match. But OpPol-6 won’t always be the best match. Using the table above:
> OpPol-1 is the best match for IMSI 123456789011111
> OpPol-2 is the best match for IMSI 123456789099999
> OpPol-5 is the best match for IMSI 123456789012345 if the PLMNID is 12344
> Example
> The following associates operator policy oppol1 with country code 310, mobile network code of 33, and IMSI range 1231234 - 1231244:
> imsi-range mcc 310 mnc 33 msin first 1231234 last 1231244 operator-policy oppol1
> map-message
> This command instructs the SGSN to ignore the CAMEL subscription when there is no CAMEL service associated or in existence.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> map-message insert-subscriber-data csi-handling when-camel-not-associated ignore-subscription
> default map-message insert-subscriber-data csi-handling
> default
> Resets the SGSN’s default behavior. By default, the SGSN validates the CAMEL subscription and rejects an Attach Request when there is no CAMEL service association.
> Usage
> By default, the SGSN updates the the CAMEL subscription included in the INSERT-SUBSCRIBER-DATA (ISD) messages received from the HLR. While processing the ATTACH request from the CAMEL subscriber, the SGSN checks whether it has a CAMEL service associated with the corresponding service (either GPRS service or SGN service). It drops the ATTACH request if there is no CAMEL service associated with a corresponding service.
> Also by default, the SGSN does not allow establishment of a Direct Tunnel (DT) for a CAMEL subscriber. It strictly validates the subscriber against the CAMEL subscription during the Direct Tunnel setup procedure.
> This command enables the operator to control the behavior of the SGSN by configuring the SGSN to ignore the CAMEL subscription. This allows the SGSN to successfully complete an ATTACH procedure when there is an ATTACH Request from a CAMEL subscriber and there is no CAMEL service association in the SGSN. As well, during the Direct Tunnel establishment, validation of the CAMEL subscription is ignored to allow the DT to setup when there is no CAMEL service association in the SGSN.
> Example
> Instruct the SGSN to validate the CAMEL subscription:
> default map-message insert-subscriber-data csi-handling
> max-pending-attaches
> Configure the maximum length of the pending attach queue.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> max-pending-attaches limit
> default max-pending-attaches
> default
> Resets the SGSN’s Attach queue to a maximum pending value of 10,000.
> limit
> Set the a maximum limit to the pending Attach/RAU messages queue in the LinkMgr. When the limit is reached a message is sent to the IMSIMgr.
> limit : Enter an integer from 5000 - 50000. Default is 10000.
> Usage
> With this command, configure the maximum limit to the pending ATTACH/RAU messages queue in the LinkMgr. When the limit is reached, the LinkMgr sends the Query/Forward messages to the IMSIMgr.
> As the IMSIMgr gets busier and does not responded to Query/Forward requests, the response to the requests will get slower and slower and the queue size continues inflating if the incoming message rate is high. To avoid this situation, set the max-pending-attaches for the pending queue for Attach and RAU messages. All other messages from the HLR will be added to the queue as they cannot be dropped. High and low watermarks are set to the queue at 80% of max-pending-attaches ” and 60% of max-pending-attaches respectively.
> Once a high watermark is reached, the new Attach and RAU requests are dropped and relevant statistics are incremented. Once a low watermark is hit, the new Attach/RAU requests are accepted and added to the pending queue. The entries are added to the pending queue only when the window-size between IMSIMgr and LinkMgr becomes zero. This is a very rare occurrence and will not affect the current behavior in normal circumstances.
> Example
> Set the queue length to a maximum of 15000 requests:
> max-pending-attaches 15000
> old-tlli invalidate tlli
> This command configures a list of random TLLI to be invalidated (removed) from the GMM after the invalidate old-TLLI timer expires.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] old-tlli invalidate tlli < hexadecimal >
> no
> Removes a single random TLLI from the configured list.
> < hexadecimal >
> Identifies a single random TLLI to be removed from the GMM after the old-TLLI timer expires.
> Usage
> Use this command to create a list of up to 50 random TLLI to be dropped from the GMM after the old-TLLI timer expires. This command also starts the invalidate old-TLLI timer.
> Important: If the old-TLLI expiry timer is not configured with the old-tlli hold-time command, then the SGSN will only drop second Attach Requests using the same random TLLI already in use.
> Related Commands:

> • | The gmm-message configures the SGSN to discard (drop) the Attach-Request message received with a random TLLI already in use

> • | The old-tlli hold-time command configures the old-TLLI expiry timer.

> Example
> Add random TLLI 0x7f05a30a to the Invalidate List:
> old-tlli invalidate tlli 0x7f05a30a
> old-tlli hold-time
> This command configures the old-TLLI expiry timer to be started in GMM when anyone of the listed random TLLI are received.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> [ default ] old-tlli hold-time < seconds >
> default
> Resets the timer to 5 seconds
> < seconds >
> Sets the numbers of seconds before the timer expires; range 1 to 125.
> Usage
> Use this command to configure the old-TLLI expiry timer to be started in GMM when anyone of the listed random TLLI are received. If the timer expires prior to receiving Attach-Complete then the SGSN invalidates (removes) the TLLI from the GMM.
> Important: For this configuration to work, the list of random TLLI to be removed (invalidated) from the GMM must be defined with the old-tlli invalidate tlli command.
> Related Commands:

> • | The gmm-message configures the SGSN to discard (drop) the Attach-Request message received with a random TLLI already in use

> • | The old-tlli invalidate tlli command configures the random invalidate TLLI list.

> Example
> Set the timer for 2 seconds:
> old-tlli hold-time 2
> pdp-deactivation-rate
> Set the rate the SGSN deactivates PDP connections per second per SessMgr when GPT-C path failure is detected.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> pdp-deactivation-rate { connected-ready rate | idle-standby rate }
> default pdp-deactivation-rate { connected-ready | idle-standby }
> default
> If this keyword is used with the command, then the default deactivation rates are used.
> connected-ready rate
> Subscribers that are in the PMM-Connected / GPRS-Ready state and actively using the SGSN service need to be deactivated at a faster rate to facilitate the deactivation/re-activation process.
> rate -sets the number of subscribers to be deactivated per second per SessMgr and the valid range is 1 to 1000 and the default is 760 connected-ready subscribers deactivated per second.
> idle-standby rate
> Subscribers that are in the PMM-Idle / GPRS-Standby state are not actively using the SGSN service and can be deactivated at a slower rate. The deactivation process for idle-standby subscribers includes paging before the Deactivate Request is sent.
> rate - sets the number of subscribers to be deactivated per second per SessMgr and the valid range is 1 to 1000 and the default is 240 idle-standby subscribers deactivated per second.
> Usage
> Use this command to define a rate at which the SGSN processes PDP deactivations when a GTP-C path failure is detected (and confirmed according to the SGSN's default behavior). The operator can use this command to set a deactivation rate that ensures radio network congestion is avoided.
> Related commands:

> • | max-remote-restart-counter-change - allows the operator to set a maximum variance between stored and received values for restart counter changes coming from the GGSN. For details, refer to the SGSN Global configuration mode documentation.

> • | disable-remote-restart-counter-verification - allows the operator to disable the default behavior. For details, refer to this command in the SGSN Global configuration mode documentation.

> Example
> Use the following command to deactivate PDP connections for 600 PMM-Connected / GPRS-Ready subscribers per second:
> pdp-deactivation-rate connected-ready 600
> Use the following command to deactivate PDP connections for 320 PMM-Idle / GPRS-Standby subscribers per second:
> pdp-deactivation-rate idle-standby 320
> Use the following command to reset the default 760 per second deactivation rate for PMM-Connected / GPRS-Ready subscribers:
> default pdp-deactivation-rate connected-ready
> ranap excess-len ignore
> Configure the SGSN to ignore excess length of received RANAP messages.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> [ default | no ] ranap excess-len ignore
> default
> Resets the default behavior - a decode error is generated when received RANAP messages are more than an extra octet in length.
> no
> Disables the configuration to ignore overly long RANAP messages.
> Usage
> By default, the SGSN issues a decode error when the RANAP messages include extra octets. Use this command to ignore RANAP messages that have excess octets.
> Example
> Use the following command to enable the SGSN to ignore overly long RANAP messages:
> ranap excess-len ignore
> Use the following command to disable ignoring of RANAP messages that are excessive in length:
> no ranap excess-len ignore
> ran-information-management
> Enable/disable RAN information management (RIM) support for the SGSN.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> [ default | no ] ran-information-management
> default
> Resets the default so RIM is disabled.
> no
> Disables the RIM support in the configuration file.
> Usage
> By default, handling of RAN information management (RIM) messages is disabled. This command enables the SGSN to handle RIM messages. When this command is enabled and RIM message handling is enabled on the destination node, then RIM PDUs will be forwarded to the BSC/RNC. If RIM message handling is not enabled on both nodes, then the RIM PDUs will be dropped silently.
> Confirm RIM configuration with the show sgsn-mode command in the Exec mode.
> Example
> Use the following command to enable RIM support:
> ran-information-management
> Use the following command to disable RIM support that has been added to the configuration:
> no ran-information-management
> target-offloading
> Selects the subscriber offloading algorithm to be applied to the SessMgr and the IMSIMgr.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> target-offloading algorithm [ optimized-for-speed | optimized-for-target-count ]
> default target-offloading algorithm
> default
> Resets the configuration to default values.
> optimized-for-speed
> Enables faster algorithm to achieve the target count.
> optimized-for-target-count
> Enables a reliable algorithm to achieve the target count.
> Default.
> Usage
> With the SGSN’s distributed architecture, there are many SessMgrs and offloading will happen in parallel at all SessMgrs. This command enables the operator to control the total number of subscribers being offloaded.
> Important: The value for this command can not be altered once dynamic offloading has begun - refer to the command description for the sgsn-offload command in the Exec Mode chapter..
> Example
> Set the SGSN to use the faster algorithm for offloading:
> target-offloading algorithm optimized-for-speed
> tlli-cb-audit
> This command enable (default is disabled) or disables a periodic (hourly) audit of TLLI-CBs in the BSSGP� layer.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> tlli-cb-audit
> [ default | no ] tlli-cb-audit
> default
> Include default with the command to disable the audit function.
> no
> Include no with the command to disable the audit function.
> Usage
> This command is used to clean-up hanging or unassociated TLLI in the BSSGP layer. This configuration defined with this command will be common to all NSE configured for this SGSN.
> Independent of this command configuration, the SGSN triggers and audit when the number of TLLI-CBs reaches 35,000.
> Example
> Use the following command to enable the hourly audit for unassociated TLLl-CBs:
> tlli-cb-audit
> umts-aka-r99
> This command enables the operator to authenticate mobile equipment (MEs) with R99+ USIMs and capable of UMTS AKA.
> Product
> SGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> umts-aka-r99
> no umts-aka-r99
> no
> Including no with the command disables the authentication.
> Usage
> This command enables operators to authenticate MEs that are attempting to connect to a 2.5G network with R99+ USIMs if the MEs are UMTS AKA capable. For R99 mobiles, the SGSN will continue to perform GSM AKA even if quintuplets are received fromthe HLR.
> Example
> Use the following command to disable UMTS AKA authentication for MEs with R99+ USIMs:
> no umts-aka-r99

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883