Advertisement
Product Releases
Advertisement

Service Network Provisioning: Drowning in The Chaos of Subscriber Information?

Mon, 09/08/2003 - 7:45am

By Richard Burke, Co-Founder and Director of network architects White Obsidian.

Many mobile telephone network operators are finding that their subscribers require more and better services to remain "loyal;" they also require a better overall service. These same subscribers are always on the look out for the cheapest options, best tariffs and better service quality. Thus, operators are finding it more and more imperative to ensure subscriber loyalty, while capturing subscribers from their competitors. This need to ensure subscriber loyalty and win new subscribers forces operators into dropping their tariffs for existing services while investing in new equipment to provide new services, ideally before their competitors. These market forces are squeezing the profit margins for operators, desperate to find new areas in which to reduce costs and yet increase efficiency while ensuring and attracting subscriber loyalty and therefore their money.

One area that is quite often overlooked is that of provisioning; creating and managing subscriber profile data on core / service network platforms etc., the creation of information on subscribers' devices and the addition of new services into the operators' networks. The ability to centrally manage subscriber information from dozens of different and dispersed systems within the operator in an efficient and simple manner has simply failed to materialize to any great extent.

The corporate IT environment has, or perhaps had, a similar problem; that of managing multiple instances of user information across many IT systems such as email, HR, network operating systems, etc. However, the "IT World" has begun to address these situations using processes and technologies to provide single points of command and control for this data. The main differences between the telecommunications operator and the corporate IT environment is the magnitude of data and number of "people," coupled with requirements for near real time data, responses and a higher level of "up time" or resiliency. The average corporate IT department might have to manage 10 to 20 thousand users while even a small mobile operator has to handle hundreds of thousands of subscribers. (In this context, IT users and mobile subscribers can be said to be similar in that they are both "people" of which structured information is stored; objects and attributes.)

Issues
The provisioning of a Service Network (this phrase should be considered to include the Core Network and elements of the business and billing environment for the purpose of this article) is a rather complex and unwieldy process comprising of numerous customized interfaces between numerous different systems and platforms forming a spider web like mesh of connections and data protocols.. There are a number of reasons for the complexity, cost and unwieldiness of the provisioning process:

a. Complex relationships of interfaces between different systems
To integrate even a simple platform into a Service Network requires a large amount of custom development to ensure that the required business rules (those of creation order, denial of service, data types and service definition parameters etc.), data, data and process flows of subscriber creation and information are correctly implemented. Each platform integrated will have to communicate with a number of other platforms in order to function. These might include the SMSC and web portals for subscriber self provisioning / feedback, the HLR and other Core Network platforms to ensure that, e.g., GPRS support is enabled; business systems to perform checks at the provisioning stage to ensure the requested service is supportable to the subscriber and that the subscriber can pay for it. Therefore, even for a single platform providing a simple service, there could be as many as six different interfaces that need to be customised and written. When a service or platform that requires interaction with other existing Capability Platforms or Services is integrated, this "mesh" of customised / custom written interfaces becomes even greater. This can lead to a large and highly complex "spider web" of interfaces and relationships between the systems

b. Protocols and methods of subscriber data transfer vary between vendors' solutions (sometimes even within a single vendor solution!)
There are almost as many different protocols that can be used to provision subscriber information as there are different platforms; LDAP, RMI Java, simple CSV, file over FTP, etc. Different vendors select different methods and protocols for provisioning that best suit their expertise and needs. In some cases, more than one aspect of a Capability Platform needs to be provisioned separately e.g. a Nokia MMSC has the NPS (the profile store) and the TGW for folders. In some cases within the same Capability Platform, the different "elements" use different protocols for provisioning; in the example above, the Nokia MMSC uses Java RMI to provision to the TGW and a CSV type file over FTP for the profile store.

c. Different Capability Platforms / Service Platforms require different subscriber profile data stores and methods
Depending on the Capability Platform or Service Platform and vendor, different databases or profile stores are used. Therefore, an operator could find that it has dozens of different data stores, all manageable in different ways, all requiring different expertise to manage. To emphasize the complexity, these data stores may be required to share similar information within one another, but may not have a common protocol or method in which to do so.

d. Different Capability Platforms / Service Platforms require differing amounts and types of subscriber profile information
Different Platforms, and 3G Services especially, require different amounts and type of subscriber profile information. A WAP Gateway may need to know in which format a subscriber wishes to view text whilst an OTA won't. The type of information required in each system and its structure is called its schema. The schema on different systems will be different, e.g., the key attribute on an MMSC might be the subscriber's MSISDN but on a WAP Gateway it might be a user name. The same type of information might be named or structured differently; on the MMSC MSISDN might have +nn for country code but on other systems it might have 00, nn or no country code at all. Other systems might use the same information in the same, or differing format, but might use different labels for the same data; e.g. MSISDN on one system might be known as Tel. on another.

e. Continuous provisioning requirements
To provide a "one off" provisioning solution, i.e. the creation of an account or profile on a platform, is not enough although it is simpler to supply. Modern networks require a continuous process of provisioning, allowing the operator to enable and disable services or aspects of a service. The operator must also be able to turn on legal interception to a subscriber or range of subscribers, "black list" subscribers, change service information about subscribers and of course remove subscribers and services from subscribers, etc. Even more complexity is added when subscribers are allowed to "self-provision" via SMS or WEB Portals. This means that the subscriber manages aspects of his "experience" of the operator's network. Such things as data format for receiving messages is one example, passwords to systems is another. The subscriber, should the operator offer complex services, may wish to manage his information relevant to that service, e.g. a service that sends the subscriber stocks and shares information may be configurable as to sell and buy levels. The subscriber will wish to regularly change this profile information determining when and how he receives information. All of these changes are in fact part of the provisioning process and need to be managed. Should the operator have no central means of storage and management for this data, it may mean another layer of middleware or data stores and complex interface relationships to provide this flexibility to his subscribers.

Home Grown Solutions
With the lack of synchronised or standardised methods for provisioning across differing and dispersed platforms, operators have often been forced to build their own provisioning solutions. These systems are often "home grown" on available hardware requiring costly experts in the fields of programming, interfaces and protocols. The major drawback with home grown solutions of this type is the fact that they are not built upon tried and tested solutions from global IT vendors with multi-million pound research and development budgets, hundreds of qualified development staff and a global model. Also operators can find themselves employing numerous IT experts to nurture the home-grown solutions

3G added complexity
Proposed 3G-based services add even more complexity to the Service Network "mesh" of system relationships and interfaces. The arrival of 3G will add a greater richness and complexity to the subscriber profile data. Also with the advent of 3G, and advanced 2.5G services, the old adage of one service per Capability Platform no longer applies. Most 3G services in the future will require access to multiple Capability Platforms; Location Services, MMSC, SMSC, WAP all perhaps for a single Service. This means a greater time to market for such services, as they will each need to be programmed to interact with the relevant Platforms and with the provisioning solution, etc.

It is likely that existing provisioning solutions will simply collapse under the weight of these extra requirements, either that or operators will be forced to run two or three other solutions in parallel with the provisioning solution in order to meet expectations. A better approach would be a complete review of all existing Subscriber Profile data, where it is kept and what is likely to request it; then overhaul the entire data structure.

Alternate solutions
It can be seen from this article that existing provisioning solutions are already insufficient to the tasks to which they should be put and are highly unlikely to scale to new generations of services and customer expectations. A migration from existing data stores to a centralised approach, similar as can be seen in the IT World, would reap greater benefits for mobile telephone network operators; reduce integration and management costs, quicker "to market" times for new platforms and services and greatly improve the subscribers; experience.
1.2 Conventions
• This article refers to "systems", "platforms", "capability platforms", "services", "service platforms" and "business systems". These should all to be considered as Service Network Capability Platforms / Service Platforms etc. and may be used interchangeably.

• The term "Subscriber Profile" can mean either the instance of data stored on a system or as an overall term meaning the entirety of data held within the operator about a subscriber

. 1.3 Definitions
• API — Application Programme Interface
CIMD2— Computer Interface to Message Distribution
CORBA — Common Object Request Broker Architecture
CSV — Comma-Separated Values
• FTP — File Transfer Protocol
• GPRS — General Packet Radio Service
• HLD — High Level Design
• HLR — Home Location Register
• IMEI — International Mobile Equipment Identity
• IMSI — International Mobile Subscriber Identity
• Java RMI     — Java Remote Method Invocation
• LDAP — Lightweight Directory Access Protocol
• LLD — Low Level Design    
• MMS — Multimedia Message
•MMSC — Multimedia Messaging Service Centre
• MSISDN — Mobile Station ISDN Number
• ODBC — Open Database Connectivity
• OSF — White Obsidian Service Network Framework
• OSFL — White Obsidian Service Network Framework Light
• PRS — Product Requirement Specification
• SMS — Short Message
• VLR — Visitor Location Register
• x.500 — A common standard for the structuring of information in Directory Services
•XML — Extensible Mark-up Language

About White Obsidian:
White Obsidian works predominantly in the mobile telecommunications operator markets, helping telecommunications operators simplify their Service Network design and synchronise their subscriber information across different platforms - creating greater efficiencies, cost savings and a better subscriber experience. White Obsidian was founded in 2002 on the principle of process and technology delivery, independent of vendor and product alliances. White Obsidian is proud to use these principles to ensure the best solutions for its clients' requirements.

White Obsidian is located at 7 Mount Mews, Hampton on Thames, Great Britain, TW12 2SH;
www.white-obsidian.com; +44 (0)20 8213 5191.

Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading