The communications industry is in transition and business convergence is now a reality as telecom operators broaden their reach to create new sources of income.Triple-play and multi-play are on the agenda with integrated mobile, fixed, broadband and TV services. At the same time, user segments continue to fragment and customers are increasingly looking at service packages tailored to their personal lifestyles. Being customer focused, not product focused, is vital now. This calls for greater internal collaboration as well as closer relationships with content and internet providers. This business transformation requires a fundamental change in operation support system/business support system (OSS/BSS) solutions.
This is because traditional systems or network management solutions do not meet the needs of today's telecommunications applications and platforms and it is no longer viable to maintain traditional approaches to OSS implementations. The siloed approach of services supported in vertical stacks, in isolation from other offerings and systems, limits the potential for cost savings and poses significant barriers to converged service offerings such as fixed-mobile convergence. Moreover, managing performance and quality of service is a significant challenge as telecom operators move to the next-generation, converged, software-based era.
Key OSS/BSS parameters
The next-generation OSS should be able to reduce opex through increased automation and optimised business processes; have a higher modularity and openness in application architecture as well as a simplified architecture with harmonised platforms which allow OSS investments to be optimised while minimising system integration, maintenance and operations costs.
In the process of transitioning to newgeneration OSS (NGOSS), telecom operators are opting for an integrated approach wherein the OSS/BSS platform seamlessly links three main solution sets (customer management solutions, billing engine and revenue enablement) together.
In the case of customer management solutions, front-end customer care applications with a strong focus on increasing customer satisfaction and retention should be visible within the platform. The billing engine that rates and bills for any service offered in the telecommunications industry should form the core of the framework.
By providing a clear, single view of the customer – from the billing to customer care perspective – service providers will have the advantage of speaking to their customers in the language they demand.However, while there is an imminent need for a robust and scalable rating engine, this has to be thought through very carefully as the ratio of prepaid to post-paid subscribers is quite disproportionate (7:3).
In most Asian countries, the growth of prepaid subscribers has outstripped that of post-paid systems. The prepaid sector is a very lucrative and powerful segment that cannot be ignored. The ability of operators to be able to extend data and content services to prepaid customers and capture those revenues would be critical. Hence, there is a requirement of a differential billing platform, and there are innovative solutions from various vendors to cater to this. Clearly, there is a strong demand for a business solution that can manage these agreements and settlements with the appropriate parties.
Therefore, a growing number of telecom operators are running OSS transformation projects to manage business convergence and to overcome the obstacles posed by legacy systems. In the nextgeneration environments, operators are rolling out OSS/BSS applications and services that are driven by standards-based software solutions utilising commercial off-the-shelf (COTS) components. However, as service providers migrate from one-off and internally developed applications to COTS applications, they still encounter high costs and complexities in systems integration and maintenance. One of the most effective solutions is the use of open interfaces, which can be adopted by application vendors or used as a "common denominator" by systems integrators. But open interfaces need to be specified, designed, implemented, tested and supported, preferably in a neutral environment. Many operators are also relying on the promise of service-oriented architecture (SOA) to support optimised business processes.
The ability to evolve to new OSS/BSS architectures while simultaneously managing the challenges of day-to-day business operations imposed by the introduction of new services and technologies within predictable costs of ownership are the biggest challenges facing serviceproviders as they move towards convergence. Being technology ready to roll out VAS is where the other challenge lies.
OSS/BSS architectures
The two major industry initiatives that can aid in this systems integration process are the NGOSS and OSS through Java (OSS/J). While the TeleManagement (TM) Forum's NGOSS programme and the OSS/J programme have different focuses, both have the ultimate goal of promoting the delivery of reusable OSS solutions to service providers.
NGOSS is an ambitious and largely successful effort to describe four critical aspects of management systems: process, information, application and systems integration. These four aspects, known as the business process framework (eTOM), shared information data (SID) framework, application framework (TAM), and systems integration framework or technology-neutral architecture (TNA) are mature, stable and widely adopted frameworks.
eTOM provides the map and common language of business processes that are used in the industry. In addition, process flows are provided for an ever-expanding list of key processes. It can be used to categorise the existing processes that a service provider may use, act as a framework for defining the scope of a software-based solution, or simply enable better lines of communication between a service provider and the systems integrator and suppliers.
Without standardised information models, data may require extensive transformation each time it passes among applications requiring costly, customised integration across multiple system interfaces. SOA development and related integration architectures rely heavily on a common information model and a common language for all systems touched by integration efforts. SID provides the common language for software providers and integrators to use in describing management information, which, in turn, allows easier and more effective integration across software applications provided by multiple vendors. It not only succeeds in building this common language, but also in aligning data with pertinent business processes. To that end, the TM Forum Information Framework's information is mapped directly to the widely deployed eTOM process definitions. SID is currently extensively in use in the marketplace in a wide variety of implementation projects.
In order to successfully integrate applications provided by multiple software vendors, the "plumbing" of the system must be common. The TNA and contract interface form the core of the NGOSS integrated framework. TNA is an architecture that is sustainable through the technology changes. The contract interface defines application programming interfaces (APIs) for interfacing across the architecture from different software vendors. This architecture is technology neutral as it does not define how to implement the architecture, rather what principles must be applied to be solution framework compliant.
As the next generation of digital services pushes enterprises to collaborate with more partners and a greater number of systems, the ability to identify functional gaps becomes critical to purchasing and integration decisions. With TAM, organisations get a standardised model for grouping function and data into recognisable applications or services. In areas such as fulfilment, assurance and billing, TAM breaks out a growing number of functional areas, including customer, service, resource and supplier management. It helps service providers navigate the entire procurement process – from initial request for information, through systems comparison to actual implementation. Meanwhile, OSS/J along with multitechnology network management (MTNM) and multi-technology operations are technology-specific interface specifications that have been built using, or in harmony with, NGOSS frameworks. OSS/J delivers standards-based interface implementations for the development of component-based OSS systems. These technologies provide the foundation for unifying legacy systems and new applications quickly and at low cost. The OSS/J APIs are multi-technology based and include Java, XML and web services integration profiles. Each integration profile consists of specifications, a reference implementation and a conformance test suite. Standards like OSS/J provide a technical framework for integration. The standard APIs define an application-independent, or "canonical", form of the information that passes across the interfaces. The API also defines the behaviour of the interface, such as the notifications, queries and other events. These standard transactions can be mapped to the proprietary databases and functions of each application. In short, the standards provide a cheaper, faster, reusable and reliable way for integration. Since April 2008, OSS/J is part of the TM Forum Interface Program (TIP). Together, TM Forum and OSS/J have pushed hard for the widespread adoption of open-standard APIs by service providers and vendors alike.
The transformation to the next-generation OSS/BSS is an ongoing process and is taking place gradually as current OSS/BSS systems are critical for the operation of a network. This migration clearly presents a unique architectural challenge as very high levels of availability and transactional integrity are required.
Only a few of the world's largest operators can justify this full-scale, multi-year project. However, given the demands of the highly competitive environment, all players will need to expedite adoption of flexible system architectures. Telecom operators will offer the capability to change quickly and support new processes and market propositions.