Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Computer or peripheral device
Reexamination Certificate
1998-12-01
2001-02-06
Teska, Kevin J. (Department: 2763)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Computer or peripheral device
C703S017000, C703S022000, C370S242000
Reexamination Certificate
active
06185519
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention generally relates to telecommunications and, more particularly, to feature interaction in the AIN (Advanced Intelligent Network) Framework.
Telecommunications software continues to evolve and add features. For example, in a telephone network, a feature is an add-on functionality to standard telephone service (e.g., call forwarding). The correct operation of a feature depends on a number of assumptions about its execution environment and available resources. Individual features are usually developed in isolation from each other and/or over a long period of time. When a set of features is put together, they might compete for limited system resources, and some of the underlying assumptions of a feature might be invalidated because of the execution of other features. As a result, a set of features might interfere with one another and exhibit unexpected and/or undesirable behaviors. This is the well-known “feature interaction” problem in telecommunications software engineering, which is further described in “
The Feature Interaction Problem in Telecommunication Systems
” by Bowen, T. F. et al., In Proceedings of the 7
th
International Conference on Software Engineering for Telecommunication Switching Systems, pp. 59-62, July 1989.
It is important to detect and resolve interactions among features before they are packaged for commercial offerings. Revenues are at stake if customers are baffled by the unexpected behavior of the set of features they subscribe to from a service provider. However, detecting and resolving interactions among features is a very difficult task. First, the logic of some of the features can be very complicated: it is not unusual for the documentation of a complex feature to run close to a hundred pages. Extracting the right amount of information from a document for interaction analysis requires a keen insight into feature design. Second, it is not unusual for a switching system to have hundreds of features. In addition, pairwise feature interaction analysis is not sufficient to uncover all the interactions among a set of features. As a result, even if one has access to all the information on the features developed for one's own products, one has to deal potentially with an exponential number of cases in the analysis.
The feature interaction problem has become even more complicated with the advent of the Advanced Intelligent Network (AIN) and the government deregulation in the telecommunications industry. In the AIN architecture, service logic can be stored at a Service Control Point (SCP), while the switching functions are provided in the Service Switching Point (SSP). The SSP is further described in TR-NWT001284
: “Advanced Intelligent Network
(
AIN
)
Switching Systems Generic Requiremeits
(Release 0.1)” by Bellcore, August 1992. Similarly, the SCP is a computing system containing processing logic and is further described in TR-NWT001285
: “Advanced Intelligent Network
(
AIN
) 0.1
Switch
-
Service Control Point
(
SCP
)
Application Protocol Interface Generic Requirements
” by Bellcore, August 1992. In addition, AIN provides a set of well-defined interfaces between the SSP and the SCP to allow service logic programs in the SCP to be invoked by the SSP and to influence call processing in the SSP. The separation of service logic fiom switching functions allows service providers to develop features independent of switch vendors.
The passing of the Telecommunications Act of 1996 requires Incumbent Local Exchange Carriers (ILECs) to unbundle “dial tones” to third party service providers (i.e. other Competing LECs or CLECs). The unbundling of ILECs' networks can create the scenario in which ILECs may have to provide mediated access to features developed by third party service providers due to future FCC or state mandates. In this context, features can be classified into two categories: (1) “switch-based features,” which usually come from the switch vendors and reside on the switches; and (2) “AIN features,” which are usually developed by operating phone companies and third party service providers. Due to competition among third party service providers and between third party service providers and operating phone companies, only limited input/output behaviors are publicly available for each feature. Consequently, the operating phone companies face the challenge of providing mediated access for third party features without knowing the internal logic of these features.
Feature Interaction Problem in AIN Release 0.1
FIG. 1
shows two service SSPs
102
in an AIN 0.1 environment. The SSPs
102
are connected across a network
106
that may contain other SSPs switching points and various nodes between the end points. The SSPs
102
shown in the figure are also each connected to a SCP
104
.
At the heart of AIN is the “basic call model” (BCM), which is a finite state machine residing on an SSP
102
that models the progress of a call. For a typical call, there is an “originating” basic call model (OBCM)
108
at the SSP
102
of the caller side
112
and a “terminating” basic call model (TBCM) at the SSP
102
of the callee side
114
.
FIGS. 2
a
and
2
b
show graphical representations of the OBCM
108
and TBCM
110
, respectively. The BCMs shown in the
FIGS. 2
a
and
2
b
are standard for AIN Release 0.1. Each basic call model defines a set of “points in call” (PICs) which correspond to the important states in a call. Associated with each PIC is a set of “detection points” (DPs) which are used to detect an event during a call. A DP is associated with a set of “triggers” each of which specifies the conditions under which an AIN feature can be invoked.
AIN features are implemented by service logic programs residing on the SCP
104
. Each AIN feature is associated with a set of triggers that specify at which PICs in the basic call model and under what conditions the feature can be invoked by the SSP
102
during a call. Typically, an AIN feature is invoked during a call if the following four conditions are satisfied: (1) the user has subscribed to this feature; (2) the user has activated this feature; (3) the call is at a PIC that the trigger of this feature is associated with; (4) the trigger condition is true. Note that even though an AIN feature, in general, can have more than one trigger, it can only be activated by one trigger at any instance during a call. In the following description, AIN features associated with a single trigger are considered, but the analysis extends to multiple triggers as well.
FIG. 3
shows a conceptual model of feature interaction in AIN Release 0.1. AIN is based on the SS7 Signaling Network Architecture, which is further described in Beninger, Toni, “SS7 Basics,” Telephony Div. Intertec Publishing Corp. ISBN:0-917845-16-1. The SSP
102
communicates with the SCP
104
via TCAP messages
302
. TCAP (Transaction Capabilities Application Part) is an SS7 application protocol which provides non-circuit related information transfer capabilities and generic services to applications, yet remains independent of the application. For feature interaction detection, the focus is on call-related TCAP messages
302
, i.e., those that affect the processing of a call. Each TCAP message
302
carries a set of call variables (as TCAP parameters), which are used to exchange call-related information between an SSP
102
and an SCP
104
. When an AIN feature
304
is invoked, the SSP
102
sends a query message with a set of call variable values to the SCP
104
to start the execution of the feature on the SCP
104
. Upon the receipt of the query message, the SCP
104
executes the service logic program according to the type of message and the call variable values in the message. The SCP
104
then informs the SSP
102
of the next action to take by sending a response message back the SSP with a set of call variables whose values may have been generated or modified by the SCP. The SSP
102
uses these call variable values received in the response message to influence the call processing. There
Ghosh Abhrajit
Lin Fuchun Joseph
Liu Hong
Choi Kyle J.
Giordano Joseph
Telcordia Technologies Inc.
Teska Kevin J.
LandOfFree
Method and system for feature interaction detection in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for feature interaction detection in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for feature interaction detection in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2589744