Troubleshooting Guide
Appendix B - System Usage of MGW Keepalive Parameters
Downloads: This chapterpdf (PDF - 1.02MB) The complete bookPDF (PDF - 10.87MB) | Feedback

System Usage of MGW Keepalive Parameters, Release 5.0

Table Of Contents

System Usage of MGW Keepalive Parameters, Release 5.0

Introduction

How to Use this Document

Keepalive for Release 5.0 Prior to Maintenance Release 1.1

Provisionable Parameters

Definitions and Additional Parameters

Examples of Successful MGCP Message Transmissions

Initial Transmission Waiting Period (mgcp-t-tran)

Scenarios with AUEP Message Retransmissions and ACK Received

Scenarios with AUEP Message Retransmissions and No ACK

MGCP-RTO-MAX

MGCP-MAX2-RETRIES, MGCP-T-MAX and 2*MGCP-T-HIST

Keepalive Process

Scenario 1—MGW Reachable

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

Scenario 3—MGW Unreachable

Keepalive for Release 5.0 Maintenance Release 1.1 and Later

Provisionable Parameters

Definitions and Additional Parameters

Examples of Successful MGCP Message Transmissions

Initial Transmission Waiting Period (mgcp-t-tran)

Scenarios with AUEP Message Retransmissions and ACK Received

Scenarios with AUEP Message Retransmissions and No ACK

MGCP-RTO-MAX

MGCP-MAX2-RETRIES and MGCP-T-MAX

Keepalive Process

Scenario 1—MGW Reachable

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

Scenario 3—MGW Unreachable


System Usage of MGW Keepalive Parameters, Release 5.0


Revised: July 22, 2009, OL-8723-19

Introduction

This appendix explains how the Cisco BTS 10200 Softswitch determines the connectivity status between itself and a media gateway (MGW). The BTS 10200 executes a keepalive (KA) process that includes the transmission of audit-endpoint (AUEP) messages to MGCP, TGCP, and NCS based MGWs.

This appendix also describes a special set of provisionable parameters that you can adjust if there are network bandwidth or reliability issues, or if a MGW is slow in responding to commands from the Call Agent.

How to Use this Document

The keepalive functions were modified in BTS 10200 Release 5.0, Maintenance Release 1.1 (MR1.1). Therefore this document is divided into two parts:

Keepalive for Release 5.0 Prior to Maintenance Release 1.1

Keepalive for Release 5.0 Maintenance Release 1.1 and Later

The primary change in MR1.1 is that the parameter mgcp-t-hist, which was used prior to MR1.1, is not used in the keepalive process for MR1.1 and later. This change affects several different system keepalive behaviors.


Caution Be sure to use the part of this document that matches the Release and Maintenance Release that is present on your BTS 10200.

Keepalive for Release 5.0 Prior to Maintenance Release 1.1

Use this section of the document if you are running BTS 10200 Release 5.0 with a Maintenance Release prior to 1.1.

Provisionable Parameters

The following tokens are involved in KA process:

In the mgw-profile table:

keepalive-method (default = AUEP)

mgcp-keepalive-retries (default = 3)

mgcp-max1-retries (default = 2)

mgcp-max2-retries (default = 3)

mgcp-keepalive-interval (default = 60 seconds)

mgcp-max-keepalive-interval (default = 600 seconds)

mgcp-t-tran (default = 400 milliseconds)

In the call-agent table:

mgw-monitoring-enabled (default=Y)

In the ca-config table:

mgcp-t-max (default = 20 seconds)

mgcp-t-hist (default = 30 seconds)

mgcp-rto-max (default = 4 seconds)

The system behavior described in this document assumes that all of the tokens in the above list are set to their default values. This has the following effect:

Enabling the KA process—Using the default values of mgw-monitoring-enabled (Y) and keepalive-method (AUEP) enables the sending of AUEP messages from the BTS 10200 to the MGW.


Note We recommend that you keep these tokens set to their default values (which enables the KA process) unless you have some other method of determining MGW connectivity status.


Tuning the KA process—The other mgw-profile tokens in the above list have numerical values, and the default values typically work well for most systems. The interaction among these tokens is described in this document. We do not recommend that you modify these values unless you experience problems with bandwidth, reliability, or response times in your network.


Caution Before modifying any of these numerical values (using values different than the factory default settings), thoroughly read and understand the contents of this document. If you have questions, contact your Cisco account team or Cisco TAC.

Definitions and Additional Parameters

This section defines some of the terms used to describe the KA process.

KA procedure—A series of transmissions and retransmissions of AUEP messages used to determine the MGCP connectivity status between the BTS 10200 and the MGW. If there is a loss of connectivity, the BTS 10200 retries the series of AUEP transmissions up to a specified number of retries (defined by mgcp-keepalive-retries) before declaring the MGW to be in down status.

KA attempt—The transmission of an AUEP message, with a defined number of retransmissions of the same AUEP message, until an ACK message is received or the defined number of retransmissions has been reached. This can include retransmissions to additional IP addresses if provisioned to do so. A KA attempt is defined as successful if an ACK is received from the MGW, and failed if no ACK is received after the defined number of AUEP retransmissions. A KA attempt is also called an AUEP transaction.

KA retries—Subsequent KA attempts, sent only if the initial KA attempt fails.

MGW in working status—A KA attempt to this MGW is successful (an ACK is received).

MGW in down status—After a defined number of KA retry failures, the BTS 10200 declares this MGW to be in down status, and continues to perform the KA procedure.


Note To learn more about the MGW operational states reported by the BTS 10200, see the MGW table in the Cisco BTS 10200 Softswitch CLI Database.


The system uses the parameters mgcp-max1-retries and mgcp-max2-retries to limit the number of retransmissions of the same AUEP. You can adjust the parameters mgcp-max1-retries and mgcp-max2-retries, if necessary, to improve response if there are network bandwidth or reliability issues, or if a MGW is slow in responding to commands from the Call Agent. These parameters are based on the description in RFC 3435, Section 4.3, and are defined as follows:

mgcp-max1-retries = Number of AUEP retransmissions sent to a single IP address before selecting the next IP address for this MGW listed in the DNS server (default = 2).

mgcp-max2-retries = Number of AUEP retransmissions sent to the last IP address for this MGW listed in the DNS server (default = 3).

The following parameters are also related to MGW connection status, but are not discussed in detail in this appendix. For additional details, see the BTS 10200 Command Line Reference Guide.

Long transaction (applicable to NCS endpoints)—The mgcp-t-longtran field in the mgw-profile table specifies the initial MGCP transaction timeout (in seconds) after receiving a provisional response (return code 100) from the MGW. The range is 1-10 (default = 5).

Return code action—The endpoint action (ep-action) field in the Media Gateway Control Protocol Return Code Action (mgcp-retcode-action) table specifies what action to take when an MGCP message is received from an MGW.

Examples of Successful MGCP Message Transmissions

This section illustrates several scenarios with successful MGCP message transmissions.


Note This section describes how the system sends AUEP messages. This discussion can be applied to the sending of any MGCP messages (including AUEP).


Initial Transmission Waiting Period (mgcp-t-tran)

The initial transmission waiting period (the period that the system waits after sending an initial AUEP transmission before repeating it) is equal to the greater of the following:

The average response time between the sending of an MGCP message, and receiving a response.

A specified lower limit, provisioned as mgcp-t-tran (default 400 milliseconds) in the mgw-profile table.

In a typical network, the average response time is much less than 400 milliseconds. Therefore, in this section, the drawings show the initial waiting period as mgcp-t-tran.


Note The drawings in this section are not to scale.


Scenarios with AUEP Message Retransmissions and ACK Received

Figure B-1 is applicable when one IP address is provisioned for the MGW in the DNS server. It illustrates the scenario in which the initial AUEP transmission does not receive an ACK message, but an ACK is received in response to retransmissions.

Figure B-1 One IP Address in DNS, ACK Received after Retransmissions


Note See the additional information about mgcp-t-tran in the "Initial Transmission Waiting Period (mgcp-t-tran)" section.


Figure B-2 is applicable when two IP addresses are provisioned for the MGW in the DNS server. It illustrates the scenario in which the initial AUEP transmission does not receive an ACK message, but an ACK is received in response to retransmissions.

Figure B-2 Two IP Addresses in DNS, ACK Received after Retransmissions


Note The system attempts up to four different IP addresses for any single MGW listed in the DNS server. (This maximum number of IP addresses is not provisionable.)


Scenarios with AUEP Message Retransmissions and No ACK

This section explains how the system handles MGCP message retransmissions and takes action when no ACK is received from the MGW.

MGCP-RTO-MAX

Figure B-3 shows how the system repeats the same AUEP message if an ACK is not received. The period between subsequent retransmissions increases by a factor of two, but is limited to a maximum of mgcp-rto-max.


Tip Terminology—Note that the first transmission is called the initial transmission. The second transmission of the same AUEP message is called the first retransmission (or the first retransmission).


Figure B-3 Example of Retransmission Timing (Upper Limit = mgcp-rto-max)


Note See the additional information about mgcp-t-tran in the "Initial Transmission Waiting Period (mgcp-t-tran)" section.


MGCP-MAX2-RETRIES, MGCP-T-MAX and 2*MGCP-T-HIST

The BTS 10200 limits retransmissions of the AUEP message to mgcp-max2-retries or a total duration of mgcp-t-max (default = 20 seconds), whichever occurs first.

If the system does not receive an ACK before the expiration of 2*mgcp-t-hist (two times the provisioned value for mgcp-t-hist), it abandons the transaction and takes one of the following additional actions:

If keepalive functionality is enabled on the system (mgw-monitoring-enabled=Y and keepalive-method=AUEP as described in the "Provisionable Parameters" section), the system expedites the KA process (as described in the "Keepalive Process" section) without immediately declaring the termination to be unreachable. However, if the KA process also fails, the system declares the MGW and all associated terminations to be unreachable. The operational status of each of the terminations is marked as TERM_UNREACH.

If keepalive functionality is disabled on the system, the system marks the operational status of each of the terminations as UNKNOWN.

Figure B-4 shows how the system handles AUEP retransmissions and takes action if no ACK is received. In this example, mgcp-max2-keepalive attempts are completed before the expiration of mgcp-t-max. In general, the system stops retransmissions when mgcp-max2-keepalive attempts are completed or at the expiration of mgcp-t-max, whichever occurs first.

Figure B-4 Timeout Limitations When No ACK Is Received

Keepalive Process

This section describes the keepalive (KA) process. The BTS 10200 performs KA attempts to determine whether a MGW should be considered to be in working status or down status.

There are three KA scenarios covered in this section:

Scenario 1—MGW Reachable

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

Scenario 3—MGW Unreachable


Note The following sections refer to two types of MGWs, residential gateways (RGWs) and trunking gateways (TGWs). A MGW is identified as either a RGW or TGW according to the provisioning of the type token in the mgw table (type=rgw or type=tgw).


Scenario 1—MGW Reachable

This scenario applies to the following types of MGWs (when the MGWs are reachable):

Trunking gateways (TGWs), with or without stable calls in progress

Residential gateways (RGWs) with more than 16 endpoints, with or without stable calls in progress

RGWs with 16 or fewer endpoints and with stable call(s) in progress

Three variations of this scenario are described in this section:

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Basic Scenario

The basic scenario is shown in Figure B-5. The MGW is reachable (an ACK is received during each KA attempt) and has stable calls, but no MGCP messages have been exchanged between the BTS 10200 and the MGW for a time interval equal to the provisioned value of mgcp-keepalive-interval (default 60 seconds) in the mgw-profile table.


Note The legend in this drawing explains how successful and unsuccessful keepalive attempts are illustrated throughout this document.


Figure B-5 KA Attempts—MGW Reachable with Stable Calls


Note For detailed examples of successful KA attempts, see Figure B-1 and Figure B-2.


The system takes the following actions in the scenario shown in Figure B-5:

If KA attempts are successful, and stable calls exist: The system continues this pattern of KA attempts (Scenario 1—MGW Reachable).

For RGWs with 16 or fewer endpoints—If KA attempts are successful, and no stable calls exist: The system implements the KA pattern shown in Scenario 2. (See Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress.)


Note For TGWs and RGWs with more than 16 endpoints—If a KA attempt is successful, the system continues to implement Scenario 1 regardless of whether there are stable calls or not.


If a KA attempt is unsuccessful: The system implements the KA pattern shown in Scenario 3. (See Scenario 3—MGW Unreachable.)

MGCP Message Sent and Is Unsuccessful

If the BTS 10200 sends an MGCP message to the MGW, and the message is unsuccessful (no ACK received), the KA process is expedited even though the next KA attempt is scheduled for a later time. This condition is shown in Figure B-6.

Figure B-6 MGW Reachable with Stable Calls, and MGCP Message Unsuccessful

MGCP Message Sent and Is Successful

If the BTS 10200 sends an MGCP message to the MGW, and the message is successful (an ACK is received), the system restarts the keepalive timer. This condition is shown in Figure B-7.

Figure B-7 MGW Reachable with Stable Calls, and MGCP Message Successful

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

This scenario is applicable to RGWs with 16 or fewer endpoints, but not to TGWs or RGWs with more than 16 endpoints. (The BTS 10200 always uses Scenario 1—MGW Reachable procedures for reachable TGWs and reachable RGWs with more than 16 endpoints, regardless of whether there are stable calls or not.)

Three variations of this scenario are described in this section:

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Basic Scenario

The basic scenario is shown in Figure B-8. The MGW is reachable (an ACK is received during each KA attempt) and has no stable calls, and no MGCP messages have been exchanged between the BTS 10200 and the MGW for a time interval equal to the provisioned value of mgcp-keepalive-interval (default 60 seconds) in the mgw-profile table.

Figure B-8 KA Attempts—MGW Reachable with No Stable Calls


Note For detailed examples of successful KA attempts, see Figure B-1 and Figure B-2.


The system takes the following actions in the scenario shown in Figure B-21:

If KA attempts are successful, and stable calls exist: The system implements the KA pattern shown in Scenario 1. (See Scenario 1—MGW Reachable.)

If KA attempts are successful, and no stable calls exist: The system continues this pattern of KA attempts (Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress).

If a KA attempt is unsuccessful: The system implements the KA pattern shown in Scenario 3. (See Scenario 3—MGW Unreachable.)

MGCP Message Sent and Is Unsuccessful

If the BTS 10200 sends an MGCP message to the MGW, and the message is unsuccessful (no ACK received), the KA process is expedited even though the next KA attempt is scheduled for a later time. This condition is shown in Figure B-9.

Figure B-9 MGW Reachable with No Stable Calls, and MGCP Message Unsuccessful

MGCP Message Sent and Is Successful

If the BTS 10200 sends an MGCP message to the MGW, and the message is successful (an ACK is received), the system restarts the keepalive timer. This condition is shown in Figure B-10.

Figure B-10 MGW Reachable with No Stable Calls, and MGCP Message Successful

Scenario 3—MGW Unreachable

This scenario applies to residential gateways (RGWs) and trunking gateways (TGWs). The following conditions are described:

KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present

KA Attempts Unsuccessful, MGW Unreachable, and No Stable Calls Present

MGW Unreachable, New Call Termination Attempt Occurs

KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present

If no ACK is received during any KA attempt, and no MGCP messages have been exchanged between the BTS 10200 and the MGW for a specified time interval (see the time interval description in the drawing), the system performs a specified number of KA retries before declaring the MGW to be unreachable. This condition is shown in Figure B-11 for the case with stable call(s) present.

Figure B-11 KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present

Notes for Figure B-11

The keepalive attempts labeled KA 1-2, KA 1-3, and KA 1-4 represent retries of the original keepalive attempt KA 1-1. The number of retries is provisioned as mgcp-keepalive-retries.

The keepalive attempts labeled KA 2-1, KA 3-1, and further, represent new attempts spaced according to the provisioned value of mgcp-keepalive-interval.

Each keepalive attempt, KA 1-1, KA 1-2, ... KA 2-1, KA 3-1, and further, has a unique MGCP transaction ID.


Note For detailed examples of successful KA attempts, see Figure B-1 and Figure B-2.


The system takes the following actions in the scenario shown in Figure B-24:

If a KA attempt is successful, and stable calls exist: The system implements the KA pattern shown in Scenario 1. (See Scenario 1—MGW Reachable.)

For RGWs with 16 or fewer endpoints—If a KA attempt is successful, and no stable calls exist: The system implements the KA pattern shown in Scenario 2. (See Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress.)


Note For TGWs and RGWs with more than 16 endpoints—If a KA attempt is successful, the system implements Scenario 1—MGW Reachable regardless of whether there are stable calls or not.


If a KA attempt is unsuccessful: The system raises one or more alarms and continues this pattern of KA attempts (Scenario 3—MGW Unreachable). For any stable calls on this MGW, the system takes the action specified in the spare1-supp token in the mgw-profile table.

Typical alarms for this condition include:

SIGNALING (36)—Trunk locally blocked (applicable to CAS, ISDN, and SS7 trunks).

SIGNALING (79)—Trunking Gateway unreachable.

SIGNALING (171)—Residential Gateway unreachable.

Typical informational events for this condition include:

SIGNALING (152)—Termination transient error received. This event is applicable when the keepalive functionality is enabled.

SIGNALING (76)—Timeout on remote instance. This event is applicable when the keepalive functionality is disabled.

If all KA attempts are unsuccessful through mgcp-keepalive-retries, the system declares the MGW unreachable.

KA Attempts Unsuccessful, MGW Unreachable, and No Stable Calls Present

This condition is similar to the condition described in "KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present" section. However, the intervals that occur after the KA attempt failure are different. This condition, with no stable calls present, is shown in Figure B-12.

Figure B-12 KA Attempts Unsuccessful, MGW Unreachable, and No Stable Calls Present

MGW Unreachable, New Call Termination Attempt Occurs

If the MGW is in down status, and a new call termination attempt is made on any termination on that MGW, the KA process is expedited even though the next keepalive attempt is scheduled for a later time. If the MGW is still in down status, the KA attempts continue. This condition is shown in Figure B-13.


Note In this case, the BTS 10200 fails the call immediately after receiving the call termination attempt, without sending any MGCP message to the MGW.


Figure B-13 MGW Unreachable, New Call Termination Attempt Occurs

Keepalive for Release 5.0 Maintenance Release 1.1 and Later

Use this section of the document if you are running BTS 10200 Release 5.0 MR1.1 or later.

Provisionable Parameters

The following tokens are involved in KA process:

In the mgw-profile table:

keepalive-method (default = AUEP)

mgcp-keepalive-retries (default = 3)

mgcp-max1-retries (default = 2)

mgcp-max2-retries (default = 3)

mgcp-keepalive-interval (default = 60 seconds)

mgcp-max-keepalive-interval (default = 600 seconds)

mgcp-t-tran (default = 400 milliseconds)

In the call-agent table:

mgw-monitoring-enabled (default=Y)

In the ca-config table:

mgcp-t-max (default = 20 seconds)

mgcp-rto-max (default = 4 seconds)

The system behavior described in this document assumes that all of the tokens in the above list are set to their default values. This has the following effect:

Enabling the KA process—Using the default values of mgw-monitoring-enabled (Y) and keepalive-method (AUEP) enables the sending of AUEP messages from the BTS 10200 to the MGW.


Note We recommend that you keep these tokens set to their default values (which enables the KA process) unless you have some other method of determining MGW connectivity status.


Tuning the KA process—The other mgw-profile tokens in the above list have numerical values, and the default values typically work well for most systems. The interaction among these tokens is described in this document. We do not recommend that you modify these values unless you experience problems with bandwidth, reliability, or response times in your network.


Caution Before modifying any of these numerical values (using values different than the factory default settings), thoroughly read and understand the contents of this document. If you have questions, contact your Cisco account team or Cisco TAC.

Definitions and Additional Parameters

This section defines some of the terms used to describe the KA process.

KA procedure—A series of transmissions and retransmissions of AUEP messages used to determine the MGCP connectivity status between the BTS 10200 and the MGW. If there is a loss of connectivity, the BTS 10200 retries the series of AUEP transmissions up to a specified number of retries (defined by mgcp-keepalive-retries) before declaring the MGW to be in down status.

KA attempt—The transmission of an AUEP message, with a defined number of retransmissions of the same AUEP message, until an ACK message is received or the defined number of retransmissions has been reached. This can include retransmissions to additional IP addresses if provisioned to do so. A KA attempt is defined as successful if an ACK is received from the MGW, and failed if no ACK is received after the defined number of AUEP retransmissions. A KA attempt is also called an AUEP transaction.

KA retries—Subsequent KA attempts, sent only if the initial KA attempt fails.

MGW in working status—A KA attempt to this MGW is successful (an ACK is received).

MGW in down status—After a defined number of KA retry failures, the BTS 10200 declares this MGW to be in down status, and continues to perform the KA procedure.


Note To learn more about the MGW operational states reported by the BTS 10200, see the MGW table in the Cisco BTS 10200 Softswitch CLI Database.


The system uses the parameters mgcp-max1-retries and mgcp-max2-retries to limit the number of retransmissions of the same AUEP. You can adjust the parameters mgcp-max1-retries and mgcp-max2-retries, if necessary, to improve response if there are network bandwidth or reliability issues, or if a MGW is slow in responding to commands from the Call Agent. These parameters are based on the description in RFC 3435, Section 4.3, and are defined as follows:

mgcp-max1-retries = Number of AUEP retransmissions sent to a single IP address before selecting the next IP address for this MGW listed in the DNS server (default = 2).

mgcp-max2-retries = Number of AUEP retransmissions sent to the last IP address for this MGW listed in the DNS server (default = 3).

The following parameters are also related to MGW connection status, but are not discussed in detail in this appendix. For additional details, see the BTS 10200 Command Line Reference Guide.

Long transaction (applicable to NCS endpoints)—The mgcp-t-longtran field in the mgw-profile table specifies the initial MGCP transaction timeout (in seconds) after receiving a provisional response (return code 100) from the MGW. The range is 1-10 (default = 5).

Return code action—The endpoint action (ep-action) field in the Media Gateway Control Protocol Return Code Action (mgcp-retcode-action) table specifies what action to take when an MGCP message is received from an MGW.

Examples of Successful MGCP Message Transmissions

This section illustrates several scenarios with successful MGCP message transmissions.


Note This section describes how the system sends AUEP messages. This discussion can be applied to the sending of any MGCP messages (including AUEP).


Initial Transmission Waiting Period (mgcp-t-tran)

The initial transmission waiting period (the period that the system waits after sending an initial AUEP transmission before repeating it) is equal to the greater of the following:

The average response time between the sending of an MGCP message, and receiving a response.

A specified lower limit, provisioned as mgcp-t-tran (default 400 milliseconds) in the mgw-profile table.

In a typical network, the average response time is much less than 400 milliseconds. Therefore, in this section, the drawings show the initial waiting period as mgcp-t-tran.


Note The drawings in this section are not to scale.


Scenarios with AUEP Message Retransmissions and ACK Received

Figure B-14 is applicable when one IP address is provisioned for the MGW in the DNS server. It illustrates the scenario in which the initial AUEP transmission does not receive an ACK message, but an ACK is received in response to retransmissions.

Figure B-14 One IP Address in DNS, ACK Received after Retransmissions


Note See the additional information about mgcp-t-tran in the "Initial Transmission Waiting Period (mgcp-t-tran)" section.


Figure B-15 is applicable when two IP addresses are provisioned for the MGW in the DNS server. It illustrates the scenario in which the initial AUEP transmission does not receive an ACK message, but an ACK is received in response to retransmissions.

Figure B-15 Two IP Addresses in DNS, ACK Received after Retransmissions


Note The system attempts up to four different IP addresses for any single MGW listed in the DNS server. (This maximum number of IP addresses is not provisionable.)


Scenarios with AUEP Message Retransmissions and No ACK

This section explains how the system handles MGCP message retransmissions and takes action when no ACK is received from the MGW.

MGCP-RTO-MAX

Figure B-16 shows how the system repeats the same AUEP message if an ACK is not received. The period between subsequent retransmissions increases by a factor of two, but is limited to a maximum of mgcp-rto-max.


Tip Terminology—Note that the first transmission is called the initial transmission. The second transmission of the same AUEP message is called the first retransmission (or the first retransmission).


Figure B-16 Example of Retransmission Timing (Upper Limit = mgcp-rto-max)


Note See the additional information about mgcp-t-tran in the "Initial Transmission Waiting Period (mgcp-t-tran)" section.


MGCP-MAX2-RETRIES and MGCP-T-MAX

The BTS 10200 limits retransmissions of the AUEP message to mgcp-max2-retries or a total duration of mgcp-t-max (default = 20 seconds), whichever occurs first. If the system has not received an ACK at this point, it takes the following actions:

It stops all retransmissions and abandons the transaction.

If keepalive functionality is enabled on the system (mgw-monitoring-enabled=Y and keepalive-method=AUEP as described in the "Provisionable Parameters" section), the system expedites the KA process (as described in the "Keepalive Process" section) without immediately declaring the termination to be unreachable. However, if the KA process also fails, the system declares the MGW and all associated terminations to be unreachable. The operational status of each of the terminations is marked as TERM_UNREACH.

If keepalive functionality is disabled on the system, the system marks the operational status of each of the terminations as UNKNOWN.

Figure B-17 shows how the system handles AUEP retransmissions and takes action if no ACK is received. In this example, mgcp-max2-keepalive attempts are completed before the expiration of mgcp-t-max. In general, the system stops retransmissions when mgcp-max2-keepalive attempts are completed or at the expiration of mgcp-t-max, whichever occurs first.

Figure B-17 Timeout Limitations When No ACK Is Received

Keepalive Process

This section describes the keepalive (KA) process. The BTS 10200 performs KA attempts to determine whether a MGW should be considered to be in working status or down status.

There are three KA scenarios covered in this section:

Scenario 1—MGW Reachable

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

Scenario 3—MGW Unreachable


Note The following sections refer to two types of MGWs, residential gateways (RGWs) and trunking gateways (TGWs). A MGW is identified as either a RGW or TGW according to the provisioning of the type token in the mgw table (type=rgw or type=tgw).


Scenario 1—MGW Reachable

This scenario applies to the following types of MGWs (when the MGWs are reachable):

Trunking gateways (TGWs), with or without stable calls in progress

Residential gateways (RGWs) with more than 16 endpoints, with or without stable calls in progress

RGWs with 16 or fewer endpoints and with stable call(s) in progress

Three variations of this scenario are described in this section:

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Basic Scenario

The basic scenario is shown in Figure B-18. The MGW is reachable (an ACK is received during each KA attempt) and has stable calls, but no MGCP messages have been exchanged between the BTS 10200 and the MGW for a time interval equal to the provisioned value of mgcp-keepalive-interval (default 60 seconds) in the mgw-profile table.


Note The legend in this drawing explains how successful and unsuccessful keepalive attempts are illustrated throughout this document.


Figure B-18 KA Attempts—MGW Reachable with Stable Calls


Note For detailed examples of successful KA attempts, see Figure B-14 and Figure B-15.


The system takes the following actions in the scenario shown in Figure B-18:

If KA attempts are successful, and stable calls exist: The system continues this pattern of KA attempts (Scenario 1—MGW Reachable).

For RGWs with 16 or fewer endpoints—If KA attempts are successful, and no stable calls exist: The system implements the KA pattern shown in Scenario 2. (See Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress.)


Note For TGWs and RGWs with more than 16 endpoints—If a KA attempt is successful, the system continues to implement Scenario 1 regardless of whether there are stable calls or not.


If a KA attempt is unsuccessful: The system implements the KA pattern shown in Scenario 3. (See Scenario 3—MGW Unreachable.)

MGCP Message Sent and Is Unsuccessful

If the BTS 10200 sends an MGCP message to the MGW, and the message is unsuccessful (no ACK received), the KA process is expedited even though the next KA attempt is scheduled for a later time. This condition is shown in Figure B-19.

Figure B-19 MGW Reachable with Stable Calls, and MGCP Message Unsuccessful

MGCP Message Sent and Is Successful

If the BTS 10200 sends an MGCP message to the MGW, and the message is successful (an ACK is received), the system restarts the keepalive timer. This condition is shown in Figure B-20.

Figure B-20 MGW Reachable with Stable Calls, and MGCP Message Successful

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

This scenario is applicable to RGWs with 16 or fewer endpoints, but not to TGWs or RGWs with more than 16 endpoints. (The BTS 10200 always uses Scenario 1—MGW Reachable procedures for reachable TGWs and reachable RGWs with more than 16 endpoints, regardless of whether there are stable calls or not.)

Three variations of this scenario are described in this section:

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Basic Scenario

The basic scenario is shown in Figure B-21. The MGW is reachable (an ACK is received during each KA attempt) and has no stable calls, and no MGCP messages have been exchanged between the BTS 10200 and the MGW for a time interval equal to the provisioned value of mgcp-keepalive-interval (default 60 seconds) in the mgw-profile table.

Figure B-21 KA Attempts—MGW Reachable with No Stable Calls


Note For detailed examples of successful KA attempts, see Figure B-14 and Figure B-15.


The system takes the following actions in the scenario shown in Figure B-21:

If KA attempts are successful, and stable calls exist: The system implements the KA pattern shown in Scenario 1. (See Scenario 1—MGW Reachable.)

If KA attempts are successful, and no stable calls exist: The system continues this pattern of KA attempts (Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress).

If a KA attempt is unsuccessful: The system implements the KA pattern shown in Scenario 3. (See Scenario 3—MGW Unreachable.)

MGCP Message Sent and Is Unsuccessful

If the BTS 10200 sends an MGCP message to the MGW, and the message is unsuccessful (no ACK received), the KA process is expedited even though the next KA attempt is scheduled for a later time. This condition is shown in Figure B-22.

Figure B-22 MGW Reachable with No Stable Calls, and MGCP Message Unsuccessful

MGCP Message Sent and Is Successful

If the BTS 10200 sends an MGCP message to the MGW, and the message is successful (an ACK is received), the system restarts the keepalive timer. This condition is shown in Figure B-23.

Figure B-23 MGW Reachable with No Stable Calls, and MGCP Message Successful

Scenario 3—MGW Unreachable

This scenario applies to residential gateways (RGWs) and trunking gateways (TGWs). The following conditions are described:

KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present

KA Attempts Unsuccessful, MGW Unreachable, and No Stable Calls Present

MGW Unreachable, New Call Termination Attempt Occurs

KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present

If no ACK is received during any KA attempt, and no MGCP messages have been exchanged between the BTS 10200 and the MGW for a specified time interval (see the time interval description in the drawing), the system performs a specified number of KA retries before declaring the MGW to be unreachable. This condition is shown in Figure B-24 for the case with stable call(s) present.

Figure B-24 KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present

Notes for Figure B-24

The keepalive attempts labeled KA 1-2, KA 1-3, and KA 1-4 represent retries of the original keepalive attempt KA 1-1. The number of retries is provisioned as mgcp-keepalive-retries.

The keepalive attempts labeled KA 2-1, KA 3-1, and further, represent new attempts spaced according to the provisioned value of mgcp-keepalive-interval.

Each keepalive attempt, KA 1-1, KA 1-2, ... KA 2-1, KA 3-1, and further, has a unique MGCP transaction ID.


Note For detailed examples of successful KA attempts, see Figure B-14 and Figure B-15.


The system takes the following actions in the scenario shown in Figure B-24:

If a KA attempt is successful, and stable calls exist: The system implements the KA pattern shown in Scenario 1. (See Scenario 1—MGW Reachable.)

For RGWs with 16 or fewer endpoints—If a KA attempt is successful, and no stable calls exist: The system implements the KA pattern shown in Scenario 2. (See Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress.)


Note For TGWs and RGWs with more than 16 endpoints—If a KA attempt is successful, the system implements Scenario 1—MGW Reachable regardless of whether there are stable calls or not.


If a KA attempt is unsuccessful: The system raises one or more alarms and continues this pattern of KA attempts (Scenario 3—MGW Unreachable). For any stable calls on this MGW, the system takes the action specified in the spare1-supp token in the mgw-profile table.

Typical alarms for this condition include:

SIGNALING (36)—Trunk locally blocked (applicable to CAS, ISDN, and SS7 trunks).

SIGNALING (79)—Trunking Gateway unreachable.

SIGNALING (171)—Residential Gateway unreachable.

Typical informational events for this condition include:

SIGNALING (152)—Termination transient error received. This event is applicable when the keepalive functionality is enabled.

SIGNALING (76)—Timeout on remote instance. This event is applicable when the keepalive functionality is disabled.

If all KA attempts are unsuccessful through mgcp-keepalive-retries, the system declares the MGW unreachable.

KA Attempts Unsuccessful, MGW Unreachable, and No Stable Calls Present

This condition is similar to the condition described in "KA Attempts Unsuccessful, MGW Unreachable, and Stable Call Is Present" section. However, the intervals that occur after the KA attempt failure are different. This condition, with no stable calls present, is shown in Figure B-25.

Figure B-25 KA Attempts Unsuccessful, MGW Unreachable, and No Stable Calls Present

MGW Unreachable, New Call Termination Attempt Occurs

If the MGW is in down status, and a new call termination attempt is made on any termination on that MGW, the KA process is expedited even though the next keepalive attempt is scheduled for a later time. If the MGW is still in down status, the KA attempts continue. This condition is shown in Figure B-26.


Note In this case, the BTS 10200 fails the call immediately after receiving the call termination attempt, without sending any MGCP message to the MGW.


Figure B-26 MGW Unreachable, New Call Termination Attempt Occurs