The industry has spent substantial resources supporting the TeleManagement Forum in its development of the Telecommunications Operations Map (TOM) and the enhanced eTOM model. But if the IP multimedia subsystems (IMS) architecture is successfully deployed by telecommunications service providers, would they build their new OSS/BSS based on the TOM model?
First, why deploy IMS? Second, why is the TOM model used for today’s OSS/BSS infrastructure? And lastly, why could IMS make the TOM model obsolete?
Why IMS?
As presented in a past editorial, service providers are excited about IMS for three business reasons. First, it enables operators to better monetize their existing investment IP networks; second, it better enables innovative new services; and third, it increases operations efficiency. Even if IP monetization and new services fail to materialize, as many have in the past, service providers can justify IMS based on increased operational efficiency alone. In today’s environment, operational efficiency means efficient OSS/BSS infrastructure and processes.
So, assuming operational efficiency is the driver for IMS deployment, as many in the industry believe, what is the vision or model for next-generation OSS/BSSs?
The TOM Model
Before considering OSS/BSS models for IMS, what about existing models? About 16 years ago the International Telecommunications Union (ITU) developed a model called the Telecommunications Management Network (TMN) to help operators formalize the structure of their OSSs. The model consisted of five layers. Top to bottom, they consist of the business, service, network, network element management and network elements themselves. The TMF expanded the TMN service management/network management layers into a telecommunications operations map (the TOM model), which was further refined with the eTOM successor.
The TOM model has become the industry standard and common vision for how to break down the complex problem of supporting the people running a telecom network and business. At its core, the model defines the components for three basic telecom office functions: fulfillment (service order to activation), service assurance (what was purchased was actually delivered as intended) and billing (what was delivered was in fact billed for)—thus, the so-called FAB processes. (Note that additional processes are defined for settlement, care and other business operations.)
The TOM model proved valuable as telecoms added new services and new infrastructure, entered the merger and acquisitions game, took on new lines of business and payment models—all of which transformed their OSSs into a snarl of smokestacks, swivel chairs, revenue assurance problems and worse. In short, the TOM model helped operators get a handle on their OSSs, and provides a framework for integrating their myriad back-office systems.
Enter IMS
IMS changes the world of telecom. It’s an architecture designed to bring all services (voice, video, data and applications) under one IP-based delivery platform and to add a powerful signaling plane enabling precise control over service delivery. Both functions have huge implications for an operator’s OSS/BSS infrastructure.
First, if the IMS vision is realized, operators will throw out the old legacy network elements (TDM, circuit switching, etc.). In turn, they will throw out the legacy OSS/BSS infrastructure tied to those archaic elements (e.g., EMS, inventory, NMS, provisioning, and more). That alone is a huge benefit for OSS/BSS managers and the bottom line, as most of those systems are home-grown, are based on antiquated programming methodologies, have huge maintenance expenses (as only a few people truly understand them), are totally inflexible, are slow, etc.
Second, the IMS signaling plane gives operators what they have never had before: a single point to provision service, deliver QoS, collect usage information, provide real-time AAA (authentication, authorization and accounting), integrate application services, control terminals and more. As a result, the antiquated OSSs will be displaced with IMS-based OSSs that have standard APIs for fulfillment, assurance and billing (FAB).
This shift mitigates many of the pain points the have plagued the industry, and as addressed by TOM. In the FAB-context, consider the following:
Billing—Mediation systems collect the service usage information for billing and other post-delivery processes (BI, audits, CALEA and others). Mediation has been a significant area of difficulty for operators because in the past they had to collect usage information from a wide-range of heterogeneous, diverse network elements used to deliver services. The problem is that there might be hundreds or thousands of such usage sources—including class 5 switches (both access and tandem), routers, application servers, ATM/Frame switches, messaging servers, modems/access devices, and the list goes on. The complexity can quickly wind out of control. However, in IMS, all signaling messages go through one point: the serving proxy (S-CSCF). Thus, there is a single point in the network to collect usage information that is independent of the network device that is delivering the service. Further, the DIAMTER standard will offer a single exchange protocol and record structure to access the usage information in both real time and batch mode. We would argue that the IMS usage interface potentially reduces mediation complexity 10-fold.
Fulfillment—Like mediation, provisioning systems have been a major source of difficulty for operators because of the diversity of network elements that must be configured to deliver services, as well as the difficult steps (work flow) required to correctly set configuration parameters on each. In the IMS architecture, however, services aren’t provisioned using a traditional “design and assign” approach. Instead, the architecture relies on a server, called the home subscriber server (HSS), to act as a directory of user accounts and the services authorized for that account. This approach is far superior to the fragmented, disparate directories of provisioning information found in today’s OSS/BSS smokestacks. Further, in addition to providing usage information, the S-CSCF can also be used to configure dynamic parameters on a per-service basis. This is particularly useful for provisioning QoS for specific applications (such as providing performance-based connectivity for a video session or audio-conference).
Assurance—Service assurance has also been an OSS trouble spot. This is because it is difficult to correlate network performance and errors against service performance for a particular session and/or service invocation. IMS doesn’t provide any additional protection against network failures. However, since all signaling messages (including setup and ongoing call control messages) are routed through the S-CSCF, any errors that might occur during session setup or during the ongoing session can be easily captured in real time. In turn, this information can be used to automatically apply credits, and/or provide performance information to customer service for account, SLA and dispute management. The same information can be useful for revenue assurance (switch to bill, and configuration audits)—where operators lose 3 to 15 percent of their billable revenue.
Although the standards are still in the beta stage, the IMS architects have worked hard to offer a clean and effective OSS framework for fulfillment, assurance and billing. This is new to our industry, and should significantly reduce OSS complexity, integration costs and ongoing OPEX.
Of course, not all OSS issues go away with IMS. You still need network management to deal with fault and performance management. You still need to exchange QoS provisioning and authorization messages between IMS signaling points and the network to support session-based QoS. Likewise, you will need to exchange IMS session information to application, VoIP, SS7 and other third-party service infrastructure. You still need integration points with billing and customer management infrastructure.
However, with the IMS community addressing the core OSS pain points, what’s left for the TOM model to do?
This is an open question with critical implications for operators. Billing World & OSS Today, of course, welcomes other industry perspectives on this question.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article