Patent Application
20080137833
The development of the Advanced Intelligent Network (AIN) has allowed telephone companies to offer various services that were heretofore difficult and expensive to develop. A variety of new services are possible by using the infrastructure of the AIN, including the ability to provide custom services to a subscriber at different locations.
The AIN architecture is dependent on network databases called Service Control Points (SCPs) that store data and programs used to control various switching structures in the telephone network. Originally, the design of the AIN anticipated that the SCPs would be flexible to meet future needs, and to a large extent that has occurred. Because the SCPs are used to provide enhanced services, the architecture was designed with redundancy. However, the SCPs are specialized processors, and fairly expensive relative to other types of processing equipment. Over time, the SCPs were required to interface with other types of databases and data centers. However, access to these databases and datacenters by the SCPs was not designed within the AIN architecture, and hence the robust reliability mechanisms were not readily applicable to the SCP-to-database/data center portion of the network. Thus, there is a need for flexible mechanisms to provide greater reliability and control in regard to the SCP accessing various databases and datacenters.
Reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
Exemplary embodiments are described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the inventions are shown. These exemplary embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
In
The SSPs use a signaling network, such as Signaling System No. 7 (SS7), which comprises Signaling Transfer Points (STPs) 108a, 108b for routing signaling messages to the various network elements. The STPS can be deployed in pairs, and each SSP is connected via signaling links 106a, 106b to each STP. Thus, if one of the STPs is unavailable, the mated STP in the pair is designed to seamlessly pick up the load.
The STPs are used to route signaling messages to a specialized database called a service control point (SCP). The SCP 112a, 112b is a combination database and application server, which can handle queries launched by the SSPs. It stores data for handling relatively simply queries, and also provides instructions to the SSP for executing more complicated call handling applications. The SCP communicates with the SSPs using an AIN protocol, and provides the appropriate information regarding how a call at the SSP should be handled. The SCPs are also deployed in mated pairs, so that if one is unavailable, the other can seamlessly pickup the load. This type of configuration is sometimes called an “active-active” configuration as both SCPs are typically running and handling queries. One complication of this type of architecture is that data that is updated on one SCP should be synchronized with the other SCP, since they are logically viewed as a single SCP.
As noted, the SCPs communicate to the SSPs using a standard AIN protocol, and execute custom applications designed around the AIN protocol. Because the SCPs control the SSPs and potentially impact millions of subscribers, they are thoroughly tested, and operate on a highly reliable processing platform. As can be expected, SCPs are fairly expensive, and their operation is controlled by the telephone company. It is imperative to the telephone network provider that these systems be “stable” and reliable. Consequently, the whole telecommunications architecture is designed to be tolerant of faults.
As a consequence, there is a tension between designing the SCPs to be flexible platforms that can accommodate new service offerings, and desiring the SCPs to be stable and reliable service platforms for providing services. Typically, stable and reliable service platforms are achieved by not adding new services (which frequently can cause unexpected problems). However, as they are also designed to be flexible service platforms, new applications should be readily accommodated, and this typically requires extensive testing.
One approach to achieving flexibility is to allow the SCPs to access data stored in traditional databases. This provides several benefits. First, there may be data already stored by a telecommunications service provider in databases for other reasons. Rather than duplicating the data in the SCP (which creates additional issues regarding data synchronization), the SCP may query the other database. Further, rather than expanding the data storage capabilities, or deploying additional SCPs (which are rather expensive), the existing SCPs can access the less expensive database systems.
Thus, it would be helpful for SCPs to access databases in datacenters using commonly available data communication networks. These standard databases typically do not accommodate the AIN protocols, nor are the data communications networks interconnecting them designed to be as reliable as the telecommunications networks.
An exemplary embodiment for providing a flexible service architecture while maintaining stability via the SCPs is shown in
The SCPs can access the necessary data in the database by using the well known TCP/IP protocol. Thus, messages are sent from the SCP to the appropriate database using an IP address that identifies the primary site. For example, Site A 204a will have an IP address, IP1 distinct from Site B 204b, which would be IP2. In the event of a Site A becoming unavailable, the SCP should use the address for Site B. This requires each SCP to maintain a table of each IP address for a given application, which is duplicated on Site A and Site B. Maintaining a table with both IP addresses values is not by itself difficult. Functionality must be defined so that the SCP knows when to switch to using the alternative IP address.
In SS7, this functionality is provided in part by the STPs, which provide for ‘alias’ addressing. An alias address is an address which can be mapped to one of two other addresses, which can result in routing the message to one of two elements, based on which element is operation. Procedures are defined within SS7 for the automatic detection and failover in case of a link or network element failure and the use of an alias address. While these procedures could be incorporated into the SCP for communication to the datacenter, this would require functionality added to the LAN infrastructure and the databases. Customizing the operation of the LAN and database operation would negate part of the benefits of using readily available platforms for the LAN and the databases.
One approach is to provide a mechanism in the SCP allowing a manual redirection of messages to the backup database. This would direct the SCP to use the backup IP address. Essentially, a flag or other type of status indication provides information as to whether the primary or backup IP address would be used for messages sent from the SCP. Since it is presumed that the primary database is usually available, a manual mechanism would provide an effective cost/benefit solution of providing backup access with minimal infrastructure development cost. This would allow use of readily available LANs and databases, with minimal impact to the SCP functionality.
The mechanism for reconfiguring the SCPs to switch over from a primary site (e.g., Site A) to a secondary site, Site B, can be accomplished in multiple ways. One approach is to define procedures in the SCP application level program to detect failure at the application layer, and communicate the need to a management application to switch over to the secondary site. This approach requires the SCP application to be modified, and since an SCP may be executing several applications, each would have to be modified.
Another approach is to indicate the need to switch from the primary to the secondary data center via human intervention. The determination that there is a need to switch over is accomplished by a human, most likely in response to observation of other systems, notifications, alarms, or outputs. For example, alarms or other notifications may bring to the attention of a systems administrator that one of the data centers or databases is inoperable. The determination that a datacenter is unavailable can be due to a cataclysmic event, such as total failure of power, destruction of the premises (e.g., fire, tidal wave, earthquake, etc.), or can be a planned event (such as the primary data center being taken off line for maintenance or upgrading).
The human interaction can occur in a variety of ways. As shown in
Exemplary call flow for handling such an interaction is shown in
In the next step 308, the user enters information and the system validates the caller. If the information is not validated, the call is ended at step 312. If the information is validated, the process continues with the user indicating the desired action.
The particular form of the prompts and responses can be designed in a number of ways. The user may be asked to select to use the primary or secondary site. Alternatively, the user may simply be asked whether the SCP would “toggle” and use whatever is the alternative database (whether primary or secondary). In another embodiment, the user could actually enter the numerical IP address value.
As a result of the user's input in step 314, the IVR then initiates a command to the SCP at step 316. The SCP processes the command, and then confirms acting on the request in step 318. The IVR, in turn, confirms the status with the user. At this point, the caller has accomplished the function of manually causing the SCP to redirect calls to another data center and the call is ended in step 320.
The IVR is one approach for allowing the user to indicate the switchover to the alternate data site. This approach can be embodied with other equipment, other than a dedicated IVR. For example, the SSP has functionality that can be controlled by SCP so as to provide an IVR-like functionality of providing prompts to a caller, authorizing information entered by the caller, and setting a flag based on analyzing the user's input. Essentially, the AIN infrastructure of the SCP and SSP can be defined to accomplish the SCP's switch over to a backup datacenter.
Another embodiment is to use a web-based interface for the user to manually indicate a switchover to a backup database. In this case, the user could log onto a secure web site, which prompts the user for identification, passcode, and/or other forms of security information. The user would then be prompted, via text or graphics, as to what data center should be used. The system could provide an immediate switch-over (as in the case of an unplanned outage of the primary data center) or the system could request a time for affecting the switch over (as in the case of a planned outage of the primary data center).
In the next step 404, the web server prompts the user to enter identification and authentication information. The information can be in various forms, including passwords, secret keys, digital signatures, secure protocols, the aforementioned time-synchronized numerical indicators, etc. The authentication and identification information may further be provided in multiple stages of interaction or prompting by the web-server. The web server may be able to authenticate the user locally, or may require remote access to other servers to access information necessary to validate the information provided by the user.
The next step 406 indicates the options available based on whether the information is validated by the web-server. If the information is not validated, then the communication may be terminated 408. In various embodiments, the user may be provided with multiple attempts, and the system may employ various well known security schemes in an attempt to block the same user after they have repeatedly failed.
Assuming that the information is validated, then an indication is provided in step 410 to the SCP from the web-server that a request was received for switching over to using the alternate datacenter. This indication can be conveyed in different methods, but typically is conveyed using a data communications network allowing the SCP to communicate with the web-server.
In the next step 412, the address for the alternative datacenter is ascertained. The web server may indicate the address to the SCP, or the SCP may retrieve the correct address from its own memory, or by querying another database. Regardless, in step 414 the SCP then transmits the queries to the alternative database using the updated address information. At this point, in step 418, the changeover to the alternative database can be considered completed.
Regardless of whether a voice or web-based interface is used, the same mechanism can be used to redirect queries to the secondary data center. Thus, when the primary data center is returned to an operation or on-line status, queries can be redirected via the same mechanism.
This provides an approach for quickly re-routing queries to a secondary data center, that is located outside of the public switched telephone network, without having to reprogram the service logic or having to modify the routing tables in routers. This new approach allows switchover to a secondary site even when communication links are operational from the SCP to the primary data center, but problems are encountered in the application layer, which the application may not be able to readily detect. This approach also allows maintenance personnel, who are trained to maintain the day-to-day operations, to maintain operation without having to involve trained support personnel who would otherwise have to be involved in ascertaining and correcting the problem. Further, the change can be made remotely, using any public telephone, which facilitates timely changeover without having to wait for authorized or trained personnel to be physically on-site.
Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
