Technical Article » Subscriber data consolidation: General

In the early days of mobile telecoms there were one or two network elements which held subscriber data - typically in internal proprietary databases.

These were highly specialised systems with unparalleled reliability (unlike emerging IT technology). The services were basic voice communication and the associated subscriber data was relatively simple.

Fast forward to the present day and there is a proliferation of network elements in the mobile network, ranging from core network elements to messaging platforms to service/content delivery systems to support to the vast number of mobile products and services that are available in the market.

Mobile operators are now operating in the fixed space (and vice versa) and moving into infotainment. With this, the amount of subscriber data in the network as a whole has dramatically risen as well as the complexity of this data. IT technology has matured and been adopted into telecom systems - you can now build your own MMSC now.

With the mobile telecoms market reaching a plateau, operators are now looking to reduce costs and increase the efficiency of their networks. With the resulting fierce competition we are seeing, operators are also looking to make customers stick with them through a superior customer experience and by offering innovative products.

A fundamental barrier to achieving the goals of the operators is the current subscriber data architecture in the network. The disparate systems often have the same subscriber data. The data they hold needs to be highly available and resistant to disasters. Therefore they each need to implement complex database architectures raising the overall purchase and operational cost.

The ability to provide a superior customer experience is dampened when the customer-facing systems need to source customer data from multiple systems and deal with inconsistencies, e.g 3 versions of the subscriber’s address, multiple customer identifiers etc.

Many operators are now addressing this problem by deploying centralised subscriber databases. They hope that a centralised subscriber database will reduce the complexity of their network elements and thus their cost as well as allowing them to build great user experiences.

We are currently in the process of integrating a centralised network database product into an operator network. When looking for the right product, we set the following requirements: Open interfaces, high read/write transaction throughput with low latency, horizontal and vertical scalability, flexibility of the schema and geographic distribution. The product we selected was an in-memory LDAP directory which has a distributed architecture.

We put together an overall schema for subscriber and application specific data based on the existing GSM subscriber schemas. The schema was converted into a tree structure and broken up into sections to allow for scaling. The segments of the tree were distributed across separate hosts. To improve the availability of the data, each segment of the tree was duplicated across two hosts. The product software handles communication between different segments of the tree and the synchronisation of data between duplicated tree segments intrinsically.

We have decided to implement the centralised subscriber database across two sites, one in Melbourne and the other in Sydney. This brings the data close to the client applications as well as provides disaster recovery capability in the event of the loss of a site.

The first user of this database will be a custom built EIR (equipment identity register) which we are developing in parallel. This allows the database to be tested in the field with an application with a relatively simple schema. The design of the EIR was vastly simplified (along with cost) as the persistence of subscriber and application data could be divorced to the centralised subscriber database.

Our next step is to move some of the existing network elements developed by us over to use the centralised subscriber database. Following this our aim is to integrate 3rd party client applications against the subscriber database.

In reality, it is unlikely that all network subscriber data will be in a single database. There is a balance between the benefits of rationalising data (in particular subscriber data) and the benefits of keeping data with the Client application. Against this there are technical challenges with developing a centralised database to store all types of data for all types of users.

We need to develop a philosophy to help us assess what data is suitable to be rationalised into a centralised database.