Browse Prior Art Database

Dual-Database Architecture to Improve Performance of Database NEs in Mobile Networks

IP.com Disclosure Number: IPCOM000129129D
Original Publication Date: 2005-Oct-25
Included in the Prior Art Database: 2005-Oct-25
Document File: 3 page(s) / 79K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

All commercially available general-purpose relational databases are designed to support applications, which deal with relatively high-update volumes. Such databases have increasingly become heavy-weight due to the variety of complex transactions that are to be performed in these applications. On the other hand, the database transactions involved in telecommunications products (HLR - Home Location Register, VLR - Visitor Location Register, etc.) are relatively less complex. There are ‘directory’ based databases available, which are more optimized only for ‘read’ operations. But, their perfomance is far below for the ‘write/update’ requests. In both the cases, databases related performance requirements of telecommunication products are partially fulfilled. Hence, there is a need for a solution to overcome this. In the following, there is a Dual-Database architecture proposed with which this problem can be solved. In figure 1 such a Dual-Database architecture is shown. In the diagram and also in the below sections, Oracle and Apertio are taken as examples for SQL (Structured Query Language) and LDAP (Lightweight Directory Access Protocol) based databases respectively. This Dual-Database concept is generic and can be implemented with other databases also.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

S

Dual-Database Architecture to Improve Performance of Database NEs in Mobile Networks

Idea: Arati Udupi, IN-Bangalore; Atul Khandelwal, IN-Bangalore; Nithyanandham M, IN-Bangalore;

Rajeev G, IN-Bangalore; Roopa Hegde, IN-Bangalore

All commercially available general-purpose relational databases are designed to support applications, which deal with relatively high-update volumes. Such databases have increasingly become heavy- weight due to the variety of complex transactions that are to be performed in these applications. On the other hand, the database transactions involved in telecommunications products (HLR - Home Location Register, VLR - Visitor Location Register, etc.) are relatively less complex. There are 'directory' based databases available, which are more optimized only for 'read' operations. But, their perfomance is far below for the 'write/update' requests. In both the cases, databases related performance requirements of telecommunication products are partially fulfilled. Hence, there is a need for a solution to overcome this.

In the following, there is a Dual-Database architecture proposed with which this problem can be solved. In figure 1 such a Dual-Database architecture is shown. In the diagram and also in the below sections, Oracle and Apertio are taken as examples for SQL (Structured Query Language) and LDAP (Lightweight Directory Access Protocol) based databases respectively. This Dual-Database concept is generic and can be implemented with other databases also.

Basic idea:

As indicated in the diagram of figure 1, there are two databases used here. The application uses the LDAP based server like 'Apertio' for all 'read' transactions, and SQL based server like 'Oracle' for all 'write' transactions. With such Dual-Database architecture, it is possible to gain the advantages of both types of the databases. All 'read' actions, which is major in number in case of databases NEs (Network Elements) used in mobile networks, will be faster now as they are performed only via the directory/LDAP based database server. Similarly, all 'write' transactions are passed to the Oracle database server, which can process them very fast.

Note on synchronization:

There needs to be light-weight synchronization triggers, which take care of updating the in-memory Apertio database. This way, it is ensured that the database used for 'read' is in synchronization with the 'write' database. These triggers should be fired in the background, so that the 'write' transactions will be faster i.e. the 'write' transactions do not depend on the completion of the 'Sync trigger' execution.

Note on database interface layer:

Database interface layer which typically is part of the...