Gate-Delete State-Machine Enhancement

Table Of Contents

Cisco BTS 10200 Softswitch Gate-Delete State Machine Enhancement , Release 6.0.3

Contents

Overview

Feature Operation

Race Condition

Preventing Race Conditions

Feature Provisioning

Additional References

Related Documents

Standards

Cisco BTS 10200 Softswitch Gate-Delete State Machine Enhancement , Release 6.0.3

---

Last Updated: August 10, 2011

The Cisco BTS 10200 Softswitch Gate-Delete State Machine Enhancement feature enables BTS 10200 to address an interoperability issue with some Cable Modem Termination System (CMTS) vendor equipment. This interoperability issue results in a call failure, when a call originated by a Network-based Call Signaling (NCS) end-point is forwarded to a forwarding number.

Note This enhancement is applicable to call flows such as CFNA and CT.

For more information on the interoperability issue, see the "Race Condition" section.

Contents

•Overview

•Feature Operation

–Race Condition

–Preventing Race Conditions

•Feature Provisioning

•Additional References

Overview

For more information on the gate coordination functions in BTS 10200, see the Cisco BTS 10200 Softswitch PacketCable Guide at the website:

http://www.cisco.com/en/US/docs/voice_ip_comm/bts/6.0.3/packetcable/guide/pktcb603.html#wp77584

Gates are created for each call segment of a CFNA call setup. The first gate is created when a caller initiates a call towards a CFNA subscriber's terminal. The second gate is created (for the call originator) when the call is forwarded to a forwarding number or a voicemail.

Currently, the first gate is deleted immediately by BTS 10200 using the Gate-Delete message while forwarding the call, which results in interoperability issues. With this feature enhancement BTS 10200 does not delete the first gate immediately; instead, it waits for a provisioned time period before deleting the gate. This time-period can be set using the GATE_CLOSE_TIMER token in the AGGR_PROFILE table.

Note This feature enhancement is applicable to those features in BTS 10200 where an old gate needs to be deleted, and a new gate is to be setup.

Feature Operation

This section describes how the Gate-Delete State Machine enhancement is implemented.

Currently, during a CFNA call, a gate is created when an NCS subscriber A calls subscriber B, and B's terminal is ringing. When the call remains unanswered and is forwarded to subscriber C, a new gate is created between A and C. The old gate (between A and B) is deleted. This immediate deletion of old gate causes race condition on certain CMTS vendor equipment resulting in failure of the CFNA call setup. The race condition is described in the "Race Condition" section.

A successful CFNA call flow (without any race condition) is described below:

---

Step 1 When a call is originated by a NCS subscriber, the BTS 10200 creates a new gate with ID, Gate-1.

Step 2 During the forwarding call segment of CFNA, the BTS 10200 sends a new gate (with Gate ID, Gate-2) to an multimedia terminal adapter (MTA) using the Modify Connection (MDCX) message.

Step 3 The MTA sends a Dynamic Service Change (DSC) request to the CMTS to change the service flow of the call.

Step 4 The CMTS moves the service flow from Gate-1 to Gate-2, and responds to the MTA with a DSC response message. At this point the resources associated with Gate-1 are completely cleared, and the CMTS sends a Gate-Close message for Gate-1 to the BTS 10200.

Step 5 After receiving the DSC response from the CMTS, the MTA sends a standard successful 200 OK message for the MDCX message received from the BTS 10200, and a DSC acknowledgement message to the CMTS.

Step 6 Call forwarding is successful without any failures.

Here, the resources are completely moved from Gate-1 to Gate-2 before sending a DSC response to the MTA. Therefore, even if the BTS sends a Gate-Delete message after receiving the 200 OK message for the MDCX, the CFNA call setup is not affected.

---

Race Condition

A race condition occurs when the CMTS has not completely moved the service flow from Gate-1 to Gate-2, and responds with a DSC response to the MTA. At this point the resources associated with Gate-1 are not completely cleared, and the CMTS is waiting for a DSC acknowledgement from the MTA for further action.

On receiving the DSC Response from the CMTS, the MTA sends a successful 200 OK acknowledgement () for the MDCX issued by BTS 10200 and a DSC acknowledgement to the CMTS. However, before receiving the DSC acknowledgement, if a Gate-Delete message is sent by BTS 10200 towards the CMTS, before the resources are completely moved by the CMTS, the gate-delete message deletes Gate-1 and the resources associated with it.

This triggers a Dynamic Service Delete (DSD) Request from the CMTS to the MTA, which in turn sends a Delete Connection (DLCX) to the BTS 10200, resulting in tearing up of the call and call forwarding failure.

Preventing Race Conditions

To prevent the race condition occurring at the CMTS vendor equipment, a token called OLD_GATE_TIMED_DELETE is introduced in the AGGR_PROFILE table of BTS 10200. The default value of this token is N.

Before sending a Gate-Delete message to the CMTS, the BTS 10200 checks the value of this token in the AGGR_PROFILE table. When set to Y, the BTS 10200 does not delete the first gate immediately during a CFNA call setup; instead, it waits for a specified time period set using the GATE_CLOSE_TIMER token in the AGGR_PROFILE table. During this period, the CMTS (upon completely moving the service-flow and receiving the DSC acknowledgment from MTA) sends a Gate-Close message to BTS 10200.

After receiving the Gate-Close message from the CMTS, the BTS 10200 stops the Gate-Close timer for the old gate. The call forwarding feature, which is running in parallel with the creation of the new gate, does not fail, and is successfully completed.

Note The GATE_CLOSE_TIMER is set in the AGGR_PROFILE table, and the default value of this timer is 5 seconds. For more information on this token, see the Cisco BTS 10200 Softswitch CLI Database. at the following website: http://www.cisco.com/en/US/docs/voice_ip_comm/bts/6.0.3/BTS603_Mainpage.html Additionally, in a CFNA call setup, the BTS 10200 waits for the GATE_CLOSE_TIMER to expire before sending a Gate-Delete message to the CMTS.

Feature Provisioning

This section explains how to provision the feature.

Note The commands shown in this section are only examples; you need to enter values that are appropriate for your network and service requirements. The CLI syntax allows you to use commands in uppercase or lowercase. It also allows you to enter hyphens (-) or underscores (_) interchangeably. (Exceptions, if any, are noted in the procedures.) For a complete list of tokens for each CLI table, as well as the allowed values, default values, and detailed descriptions for each token, see the Cisco BTS 10200 Softswitch CLI Database at this website: http://www.cisco.com/en/US/docs/voice_ip_comm/bts/6.0.3/BTS603_Mainpage.html

To enable this feature, a new token called OLD_GATE_TIMED_DELETE is introduced in the AGGR-PROFILE table. When this token is set to Y, the BTS 10200 starts a Gate-Close timer and waits for the Gate-Close message from the CMTS for the first gate. The default value of this token is N.

If the OLD_GATE_TIMED_DELETE token is set to N, the BTS 10200 initiates a Gate-Delete message for the first gate in a CFNA flow. For more information, see the CFNA call flow information in the "Feature Operation" section.

SUMMARY STEPS

•add aggr_profile

DETAILED STEPS

Command	Purpose
add aggr_profile id=c7246-227-77; DQOS_SUPP=Y; ES_EVENT_SUPP=Y; OLD_GATE_TIMED_DELETE=Y;	Sets the OLD_GATE_TIMED_DELETE token to Y.

Additional References

Related Documents

Related Topic	Document Title
Summary of features and usage guidelines for this release	Cisco BTS 10200 Softswitch Release Notes
Reference listing of all CLI tables and tokens	Cisco BTS 10200 Softswitch CLI Database
Gate Coordination Functions	Cisco BTS 10200 Softswitch Packetcable Guide

Standards

Standard	Title
PacketCable Dynamic Quality-of-Service Specification	[DQoS] DQoS: PacketCable Dynamic Quality-of-Service Specification, PKT-SP-DQOS1.5-I03-070412, April 12, 2007.
The Common Open Policy Service Protocol	[COPS] COPS: The Common Open Policy Service Protocol, IETF RFC 2748, January 2000.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2011 Cisco Systems, Inc. All rights reserved.