Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-07-24
2001-10-30
Alam, Hosain T. (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C709S217000, C709S220000, C709S223000, C710S008000, C379S201060, C379S211010
Reexamination Certificate
active
06311186
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to a database system. More particularly, the present invention relates to a telecommunications database system which permits an intelligent peripheral to have channelized database access to a plurality of databases.
BACKGROUND OF THE INVENTION
Data requirements in the telecommunications field are changing. Telecommunication switches and intelligent peripherals today require real-time access to large amounts of data. This data includes, but is not limited to, subscriber profiles, configuration data, voice recordings, and speech recognition templates. Today's Intelligent Peripheral (IP) contains an ever increasing array of data objects. Access to these objects must be real-time, distributed, and scalable. However one drawback encountered is that the conventional database storage mechanisms deployed tend to limit the size and complexity of IP's.
Another drawback encountered is that the conventional approach of replicating subscriber data is no longer feasible. Databases are commonly accessed through Service Control Points (SCP's). These SCP's typically provide access to off-the-shelf Structured Query Language (SQL) database products such as Oracle, Sybase, or Informix. The SCP computer platforms are usually mid- to high-end fault-tolerant or fault resilient computers. Often, the contents of the SCP databases are replicated to provide the required throughput. For example, this is the case with the portable 800-number databases. An 800-number database is located on the network by utilizing known in advance addresses, either physical, or logical. These addresses can be managed and changed through Signaling Connection and Control Part (SCCP) management functions, or through similar highly available network architectures. Each database contains the entire universe of available data, and can meet the needs of an IP. However, the replication of databases is logistically difficult. As a result, the latency for 800-number changes is measured in weeks.
Furthermore, personalized data such as subscriber profiles, voice recognition templates, and such are not easily replicated to a number of dispersed SCP locations. Additionally, data which is changed often (such as voice messages) are not candidates for replication due to latency issues.
A further drawback encountered is that the hardware for IP is not acceptable for use in databases. Computer systems which are tuned to the real-time database requirements of these off-the-shelf database products are often not appropriate for inclusion in IPs and switching devices. For example, an ATT 5ESS Class 5 end office switch is not by nature a good candidate for inclusion of Oracle 7.2 Parallel Server. Voice processing components are not generally compatible with the high-end database computer hardware. Open Computer Telephone Integration components like the Dialogic D24SC-T1 require an ISA bus computer, and are incapable of running in the multi-processor mode required by most high-end databases. Due to the above-reasons, the Intelligent Network (IN) architecture clearly shows the SCP as a separate distinct component.
A still further drawback encountered is the use of global rather than distributed databases. IP Platforms are usually distributed throughout a network. This allows the voice processing ports to be directly connected to the location requiring enhanced services. For most telephone networks, including cellular networks, the IP Platforms are scattered throughout the coverage area. The cost of long-hauling the telephone circuits to central locations is less economical than replicating the IP platforms. When subscriber-based data services are not centralized, all IP services would have to be processed out of the IP that contains the subscriber data. The general model for the wired network infrastructure is to have a global database for each IN that is fragmented by category of access. The recommendation is a series of separate SCP's-one for each category. Some categories include:
1. Call Management Services Database (CMSDB)
2. Line Information Database (LIDB)
3. Business Information Database (BSDB)
4. Home Location Register (HLR)
5. Visitor Location Register (VLR)
Another drawback encountered is that current IP databases are centralized. The IN model is to centralize subscriber data for a region into a singular CMSDB. In the wireless network model, an HLR is defined to retain information about subscribers, and is in effect a distributed database. The cellular roaming network providers distribute a table which maps ranges of Mobile Identification Numbers (MIN) to particular HLR databases. If the volume of transactions exceeds the capacity of the HLR's database, the service provider has few options. One is splitting the database into two pieces, but this is operationally complex and will result in service outages.
More particularly, IP vendors typically connect their service circuit computers onto a network which serves the data from a remote computer running the SQL database. The conventional approach is to build a single large database which must by necessity grow to the required size. By adding additional processors, fragmenting the database into distinct pieces which remain logically one database, and performing careful database management, the database can grow to meet the requirements of the IP service circuits. Ultimately, the database grows to a size which is difficult to manage, or even impossible to expand. At this point, the IP service circuits can no longer expand to handle additional traffic.
Thus, a single population of users grows to a point where the database prevents expansion of service. It is difficult and nearly impossible to split the database into two manageable pieces since the inbound telephone traffic is not segmented in any way. If the database can be split, the action will disrupt service for a substantial period of time.
To make matters worse, the new applications being developed and marketed require significantly larger amounts of data than previously required. For example, the throw away calling card results in databases with hundreds of millions of records. Because calling card service circuits have no control over where a call is originated, the database must be ubiquitous, being available for all service circuits. Further complicating matters is that the throw away calling cards are often left with a small negligible balance which must be maintained until the card expires. This time period is often one or more years.
Another problem with the conventional telecommunications IP infrastructure is the inability to utilize data across different platforms. Cellular companies typically have a Voice Activated Dialing platform entirely separate and distinct from the MTSO (Mobile Telephone Switch), which, in turn, is distinct from a voice mail system. Thus, each user may be provisioned in three separate databases. Some of these databases are network-wide accessible, and some are not. Voice mail and voice activated dialing, therefore, may only be available in certain regions based on data availability.
Another problem with the conventional telecommunications IP infrastructure is the lack of Standard Network Interfaces. All current SQL databases require vendor specific drivers and interfaces which are designed for the client computer. Thus, software from Oracle must run on the IP computer node to fully take advantage of the SQL database from Oracle. There are no industry standards for how a client can connect to and perform SQL transactions. Open Database Connectivity (ODBC) and CORBA provide Application Programming Interfaces (API's), but utilize drivers to implement vendor-specific transport mechanisms. For example, to run Oracle Client or Oracle ODBC, SQL*net is required on the client computer system.
ADVANTAGES OF THE INVENTION
It is an advantage of the present invention to provide a database system which overcomes the drawbacks of the prior art described above.
These and other advantages of the present invention will become apparent
Fisher Duncan S.
MeLampy Patrick J.
Penfield Robert F.
Ryan Theresa H.
Alam Hosain T.
Alam Shahid
Priority Call Management, Inc.
Thomas Kayden Horstemeyer & Risley, L.L.P.
LandOfFree
Telecommunications switching system utilizing a channelized... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Telecommunications switching system utilizing a channelized..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Telecommunications switching system utilizing a channelized... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2573480