Service package application and a service activation manager...

Details Service package application and a service activation manager... Service package application and a service activation manager...

1998-07-15

2003-04-29

Robinson, Greta L. (Department: 2177)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C379S221080, C379S221090

Reexamination Certificate

active

06556996

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates generally to telecommunications and, more particularly, to a service package application and a service activation manager for use with a service control point in an advanced intelligent network.
BACKGROUND OF THE INVENTION
In recent years, the advanced intelligent network (AIN) has become the preeminent telecommunications architecture. Under the AIN architecture, the control signals necessary to perform advanced call service processing and to route calls are communicated over a packet switched control signal network which is separate from the trunk lines used to transmit calls carrying voice and/or data signals. Separating the control signals from the voice and data signals (i.e., out-of-band signaling) has several advantages including freeing trunk lines for carrying calls by limiting or removing control signaling traffic therefrom; facilitating efficient call routing and network resource maximization by permitting mid-call re-routing of calls; decreasing call set-up times; and facilitating advanced call processing services such as call blocking, caller identification and call forwarding.
A portion of a typical advanced intelligent network (AIN) is schematically illustrated in FIG.
1
. The conventional AIN architecture includes a number of Signal Switching Points (SSPs)
2
, Signal Transfer Points (STPs)
4
and Service Control Points (SCPs)
6
. SSPs
2
are end offices which have been upgraded to operate under the Signaling System
7
(SS
7
) protocol and the AIN protocol. STPs
4
are digital packet switching devices which route control signals between SSPs
2
and SCPs
6
and traditionally perform certain control signal processing functions discussed below. SCPs
6
are computing devices containing extensive databases of customer information. SCPs
6
are programmed with a number of logic routines (commonly referred to as “services”) for providing various AIN services such as call screening to customers. The typical AIN includes a number of SCPs
6
(usually paired for failure protection via redundancy) assigned to service a particular geographic area of the network; a larger number of STPs
4
also assigned to service predefined geographic areas (typically smaller than the areas services by the SCPs); and an even larger number of SSPs
2
assigned to service a smaller, very specific geographic area of the network.
Under the typical, prior art scenario, when a caller
8
subscribing to an AIN service places a call (or when a subscriber
9
to an AIN service is called), an SSP
2
identifies the call as one requiring AIN servicing based on some predetermined trigger criteria type (such as Termination Attempt, Off-Hook Delay), and subsequently develops a query event message, e.g., an SS
7
message package containing a translation type number (TTN) and relevant call information. A TTN is a code, which identifies a classification of query to be routed to the SCP for processing the pending call. Currently, there are approximately twenty-seven different trigger criteria types that cause the SSPs to develop five different query classes. Each query event message contains only one trigger criteria type. The queries are formatted in accordance with the Transactional Capabilities Application Part (TCAP) protocol.
Under the conventional system, the SSP
2
transmits the query as an out-of-band signal to an STP
4
. The STP then processes the query by translating the TTN and other information within the query into a SSN (subsystem number) and a specific SCP to which to route to. The translated query, including the translated SSN, is then forwarded to an SCP
6
appropriate for processing the call in question, which responds by calling the service logic routine(s) specified by the SSN. The service logic routines process the call pursuant to the services subscribed to by the involved subscribers.
While the above approach provides excellent subscriber services, it suffers from certain inefficiencies from the service provider's point of view. For example, since in order to process a query, an STP
4
must translate a TTN in the query into a SSN for use by the SCP
6
, and since modifying or adding new services under the prior art approach often requires the addition of new TTNs and SSNs, modifying or adding new services typically requires updating the translations of all of the STPs
4
in the AIN. Since the STPs
4
are usually the second most numerous element in the AIN, this updating process is often time consuming and expensive.
By way of another example, under the prior art approach, the management software of the SCPs
6
is adapted to only call one service routine per query. In order to accommodate subscribers to multiple services, it is, therefore, necessary to write new combination service routines combining the multiple services subscribed to by the subscriber into a single logic routine. Since there are many different possible service combinations, the prior art approach requires the creation of many different combination service routines to enable the SCPs
6
to call any subscribed-to service combination as a single routine. Such an approach requires the expenditure of computer personnel time and efforts. This effort includes the creation of additional routines, allocation of additional TTNs, allocation of additional SSNs, as well as the updating of STPs
4
with translations of the new TTNs allocated for new service combinations. TTNs are a limited resource within the network. Each RBOC is allocated a range for which TTNs can be allocated locally, all others are allocated on a national level. It also taxes computer resources in that it requires the storage and processing of additional computer routines on both the SCPs
6
and the STPs
4
.
In addition, prior art systems are also disadvantageous in that every SCP
6
is required to include multiple service package application programs. A service package application (SPA) is the software required to run or execute a service on an SCP
6
. Prior art approaches provided one SPA for every service provisioned on an SCP
6
. In other words, if an SCP
6
is programmed to provide twenty services, under the prior art approach it is necessary to load twenty separate SPAs onto the SCP
6
; one SPA for each of the twenty services. Thus, under the prior art approach, every time a new service is added, a new SPA must be loaded onto the SCP
6
. If multiple SCPs
6
are present, multiple copies of the SPAs must be loaded.
Not only does the presence of multiple SPAs on an SCP
6
deplete system resources, but requiring the addition of a new or modified SPA for ever new or modified service is also costly in terms of both personnel and computer time. More specifically, the source code of an SPA is typically written in service script logic (SSL) language. SSL is not directly usable by SCPs
6
. Therefore, in order to provision an SCP
6
with a new or modified SPA, it is necessary to compile the SSL source code into object code and deliver the object code to the SCPs. Then a service package field update (SPFU) program is run to transfer the customer data from the existing SPA to the new SPA. Of course, a SPFU must be run for every SCP
6
in the AIN provisioned with the new or modified service.
Moreover, the service provisioning computers employed by Regional Bell Operating Companies (RBOCs) to modify subscription packages (e.g., by adding or deleting subscribers) on the AIN must also be provisioned with the multiple SPAs used in prior art systems. Like SCPs, the service provisioning computers cannot execute SPAs in their SSL language format. Instead, SPA object code must be delivered to the service provisioning computers and a service package version management (SPVM) program must be run to transfer customer data from an existing SPA to the new SPA. Thus, when a new or modified service is added to an AIN system, multiple SPFU and SPVM programs must be run to provision the new SPA at all required locations in the AIN system. This process utilizes a great deal of personnel time and t

Affiliated with

Also associated with

Rating

Service package application and a service activation manager... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Service package application and a service activation manager..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Service package application and a service activation manager... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3012592