Mobile network operators have arrived at something of a crossroads in terms of formulating a strategy for managing the vast amounts of data about each of their subscribers that they are continuing to accumulate. Subscriber-data management (SDM) is an area that must be addressed, and the chosen approach will be critical to future competitiveness and profitability.

Doing nothing about SDM is not an option, because many services and applications designed to run over 4G networks require access to customer data in real time. Real-time charging, upselling, targeted marketing and loyalty campaigns, location-based services and even simple user log-ins will all require real-time access to customer data.

The ability to process and manipulate vast amounts of data in real time using in-memory techniques has been around for a while and has its roots in areas such as processing cash-machine and credit-card transactions. It first came to the attention of the telecoms industry when Oracle bought Times Ten, a pioneering company in this field, in June 2005. Since then, a number of telecoms-focused companies have included in-memory processing in the development of home-subscriber servers in particular, which are essentially the customer-data gateways of next-generation networks.

The problem that operators face is how to access data in real time. At present, subscriber data is held in a number of service-specific silos, usually in different formats and often covering customer information specific to only a particular service. In addition, there is a great deal of duplication and, inevitably, conflict among the data. The key to real-time services and application delivery is bringing all this data to a single, common point and in a uniform format, so that it can be accessed by all domains from the network right up to the call center. There are essentially two ways to approach the problem, both of which have pros and cons.

The first solution is to federate these disparate databases using an abstraction layer of some sort. This involves developing connectors that essentially mediate between each database and the common layer, producing the effect of a single, virtual database that can be accessed by the rest of the network. The main problem with this approach is that interposing an additional layer between the data and the rest of the network will create latency problems.

Although the resulting time lag might be unnoticeable to begin with, as services become more complex and more popular and as it becomes necessary to process much greater volumes of data in real time, significant delays will be inevitable and will negatively affect the customer's perception of the network operator. This will be unacceptable in an environment where customers will have come to expect fixed-broadband-like quality of service on a mobile device. Add difficulties such as resolving conflicts between data from different silos every time the data-abstraction layer is refreshed and the integration costs incurred every time a service element is upgraded or sourced from a different supplier, and this approach begins to look unattractive. What it does have going for it, however, is that capex is minimal and that legacy systems can be incorporated into next-generation service-delivery frameworks without having to move the original data.

Indeed, one of the main problems with the other solution to the subscriber-data-management problem - the single data repository - is the migration and reconciliation of subscriber data from disparate service silos, which is the stuff of operators' worst nightmares. Although there are a few companies specializing in reformatting and migrating data from multiple sources to a single repository, the potential for things to go wrong are manifold.

But such considerations should be set against the advantages of true, real-time capabilities in a scalable service environment. The single-repository approach also offers future-proofing for operators that want to migrate to SOA-based architectures and implement IMS in the longer term. The bottom line is that although data migration might be fraught with potential difficulties, it has to be done only once. The dilemma that operators face is whether to take the safe - if shorter-term - option of federation or take a deep breath and go for full-scale migration to a single subscriber database.