OSS is finally coming into its own, thrust into the spotlight by a confluence of technological advancement and market opportunity. Never before has the value proposition behind OSS been so central to the future of service providers’ businesses. Where it was once stuck in the back office and typically focused on process improvement and expense reduction, its role today has advanced several links up the value chain. OSS is what will enable service providers not only to deliver and manage the new sets of IMS- and SDP-based services they envision, but also to present the enabling value and capability of the communications infrastructure to new partner industries and customers.
Think of it as adding value to value—the OSS demonstrates the value and capabilities of the communications infrastructure to others that can leverage that value and add their own to create a profitable offering. OSS provides the means to deliver, manage and track those offerings. Further, it represents the glue that pulls the network, signaling and application infrastructures together to enable the kind of real-time, dynamic, fast-paced service environment providers are racing to deliver. To understand how OSS can do it all requires a breakdown of the advances, challenges and points of confusion found in the market today.
Defining IMS
One of the first problems to address is that there are too many uses for the term IMS. The true definition refers to the 3GPP-based standard, but from a business context this definition is too narrow. Most of the time when people talk about IMS from a business perspective, they are referring to an integrated, real-time services environment that both opens and ties together telecom networks and systems across technology domains and partner boundaries.
The IMS standard assumes an all-IP network environment. So, to be a stickler, one might say IMS is somewhat irrelevant until networks actually transition entirely to IP. This hard-line stance, however, would fail to recognize the activities happening around IMS technology today. “The last I counted there were 80-plus implementations, trials or tests under way globally,” says Sanjay Mewada, vice president of strategy for NetCracker and former Yankee Group lead analyst. “Most service providers buy into the concept that it’s the way to move forward for service creation and modeling.”
If there’s little or no dispute that IMS is ultimately the way forward, the reality is that no true IMS implementation is in production—as opposed to a trial or pre-IMS platform—anywhere in the world today. After conducting extensive research into telco and mobile back-office environments, real-time service management provider Sigma Systems found that “there isn’t anybody in the majors who has a pure IMS architecture, including service orchestration and complete control of application services. We haven’t seen anybody there yet,” says Preston Gilmer, vice president of marketing and business development. What this finding acknowledges is that IMS implementations are in the early stages of development, as technologies tend to go, even though the initial draft of the standard was introduced in 2003.
Current IMS Weaknesses
IMS—the technology—is meant to take over network intelligence, signaling and application management. It represents the next-generation signaling control plane and in that respect is often compared to SS7 and IN. The IMS standard is meant to provide interoperable, plug-and-play components that will allow service providers to pursue a best-of-breed strategy. The problem, however, is that IMS vendors may not always embrace the standards because they don’t want their products to become commoditized.
“Vendors are not willing to give up core features and core functionality. … IMS gives an opportunity to those vendors who lost their glory and spent millions creating gateways and softswitches. It gives them life beyond the dumb gateway or generic softswitch,” says Yaron Raps, service over IP practice lead for BusinessEdge Solutions.
If carriers are beginning to deploy IMS components, but components from different vendors are not interoperable, then initial deployments are likely to contradict the plug-and-play intent of the standard. “If you want to bring these components into your provisioning environment, it will make your life easier to go with one vendor,” says Raps. “You won’t be able to take a best-of-breed approach—the standards aimed for it, but the vendors are not allowing it to happen.” As opposed to spending time and money integrating best-of-breed components, a single vendor solution could make sense, but it in turn eliminates the proposed flexibility the standard intends.
IT vs. Network
If the equipment vendors truly are guilty of resisting the standard, it reflects a growing battle between network and IT. In the past, the boundaries between them were very well defined. Network owned the network, and services were part of the network organization’s domain. IT owned operations and did not have a lot of power—but in the past few years, this has changed.
Network is still king in many cases, and still has plenty of power in all carriers, but IT has grown in power and influence and become a legitimate rival. As carriers have consolidated, many disparate groups have moved under the IT umbrella, and sometimes those groups came out of the network domain. Inside some carriers, entire groups found themselves moved from network to IT literally overnight. “The hardware vendors had to come up with a meaningful story so IT would not steal all of their thunder,” says Mewada. “They went to 3GPP to get a standard, because that’s what network vendors are good at, and they got IMS. It was deliberately done.”
Because IMS-related services are IT-oriented, the battle now is over the service layer. In the application service-based world, the network and services are separated. Services operate from application servers—IT components that sit above the network and utilize its resources. But who owns the service layer is a big question that’s not always easily answered. “There is definitely a power struggle between IT and network,” says Ted Treuil, principal sales engineer for MetaSolv Software. “Qualifying and understanding who the decision makers are is not getting any easier.”
SDP Bridges Old and New
IMS technology is not the whole story today. The broader use of the term really focuses on new services, some of which will come from the IMS domain, but most of which still originate from the existing network base. Though IMS assumes an all-IP environment, carrier network infrastructures aren’t there yet. Service delivery platforms (SDPs) are being put in place now to bridge the gap between the new and the traditional so that carriers can begin to roll out more value-added applications and some IMS-like services. SDPs are at the heart of many of the major triple play rollouts, such as SBC’s Lightspeed, and the market is chock full of non-standard SDP offerings from a range of vendors.
One point of confusion in the market is that the terms SDP and IMS are often used interchangeably to refer to the same integrated services vision, though from a technology standpoint they are complementary but distinct. “Leading equipment providers tend to be confusing because they will say IMS/SDP portfolio in one statement, but when asked how they differentiate the two, the answer is often, ‘Which do you want to spend money on?’ ” says John Trembley, business development director for Oracle Corp. “SDP … is not meant to take over the network intelligence, service and management, but it provides a mediator between your SS7 world and your new IMS, SIP or IP environment.”
Most SDPs are basically preintegrated, multi-vendor OSS platforms, tied together with some major vendor’s middleware. The idea of a preintegrated OSS suite is nothing new. The difference today is that there’s a specific application for an SDP. Generally speaking, the SDP is what enables the application or service environment to call on needed network resources in the course of real-time or near real-time service delivery. The SDP provides a single point of contact that ideally ties the whole network infrastructure together and coordinates provisioning among network layers and across technology domains.
Ideally an SDP separates capability from technology. In other words, a given application service will have specific requirements for its delivery, including factors like bandwidth, QoS, cost, latency and others. The service doesn’t really care what technology delivers it, as long as it can meet those requirements. The SDP’s job is to coordinate the provisioning of the underlying network components to ensure that they meet the requirements necessary to deliver the services. This means orchestrating provisioning and assurance across technology domains, which continues to be a major challenge for vertically oriented carrier operations.
Integrated Services’ Impact on OSS
Whether we’re talking about IMS or SDP, it’s not necessary to get too caught up in the terms. What’s important is the vision of where services are going, starting with basic triple play, moving into SIP-oriented capabilities like subscriber mobility, and ultimately into integrated services across carrier and partner domains. The shift to real time, to service integration, to the open collaboration among partners, to the application-oriented nature of services, and toward more pure automation all have significant impacts on the role and design of OSSs.
“You’re no longer billing, delivering and assuring services that are internal, but rather are created across a number of parties,” says Beau Atwater, executive director in the technology office for global communications systems at Telcordia Technologies. “OSSs have to change from vertical stacks to demand and supply chain types of models. The thing telecom has never been able to do is to take their opaque processes and make them transparent.” While this fact raises issues for security and process integration, from an OSS perspective the biggest impact will come from the real-time nature of services.
Provisioning Impact
The new service environment will move service providers beyond the current subscription-based revenue model “to take advantage of transaction-based and advertising-based revenue,” says Atwater. This shift emphasizes on-demand capabilities in the OSS stack. “OSS is increasingly becoming part of the network,” says MetaSolv’s Treuil. “It will become more real-time, more part of the policy and control plane. The paradigm of having something in a static database off the network will probably morph over time.”
Provisioning is being pushed closer to the network and signaling layers, making functions like policy execution and user authentication key aspects of the service delivery process. In the same vein, billing-related functions like real-time charging are becoming a critical part of provisioning, authentication and accounting processes.
Five-Nines Is a Must
If OSS is moving toward the network, and also needs to be in synch with the signaling control plane, then five-nines reliability also becomes critical. That level of reliability is usually found in the network, but not in IT environments. In the past, if a provisioning system went down, it was tolerable as long as the system could recover in reasonable time. Treuil explains that moving forward, if OSS is essentially part of the network and critical to enabling transactions and thus revenue generation, it must be completely reliable.
Unfortunately, there are forces in the marketplace that like to argue the opposite. Many of the new players in the real-time provisioning and policy management and execution space will argue that this is an IT domain, so five-nines reliability is overkill and not worth spending the time and money to achieve. This is a perspective that does not understand the carrier world or embrace the principle that if something is in the revenue stream, it can’t break—ever.
“I don’t see carriers easing up on reliability requirements at all, though the way you get to them might be different and might borrow heavily from the IT world,” says Treuil. Techniques like clustering will help software environments achieve network-style reliability, and the speed and flexibility of IT systems will help drive flexibility and rapid service creation. “I’m old-world in terms of my ability to support, assure and bill,” says Martin Creaner, CTO for the TeleManagement Forum, “but I’m new-world in my ability to create.”
Growing Need for Pure Automation
Five-nines reliability also becomes more critical in the OSS domain in general, because OSSs are becoming far more automated and taking on a larger role. “The amount of responsibility in the management plane is getting enormous,” says Mark Nicholson, CTO for Syndesis Ltd. “We need a much more rigorous management plane. This is not support, it is orchestration—humans supporting the system, and not the other way around. [OSSs] are fully automated, provide visibility into what’s occurring and they manage all of the moving parts involved.” This is where the confluence of market opportunity and technology advancement takes place. The market is calling for more intelligence and automation in systems at the same time that OSS is moving from software that supports people to soft-machines that do the job themselves.
Inventory Capability
Inventory’s range of responsibilities is growing significantly, as well. “There’s been physical and logical inventory for many years, but now there’s service inventory and service capability,” says Treuil. Further, the service resources that must be managed extend well up into IT, and service layers and OSSs that are traditionally network-facing must become “IT- and asset-facing,” says NetCracker’s Mewada. “You have to manage the hard and soft assets including AAA, IP addresses and other assets that never lived in inventory.”
With all of these service elements and so many moving parts in the network, it becomes increasingly necessary to abstract capability from technology. With services being separated from the network, the question is no longer which technology is being requested, but rather which capabilities are necessary to deliver the service in question. This changes the role of inventory and provisioning collectively, because it puts an emphasis on the system being able to decide the best means to deliver a given service.
The underlying transport could be ATM, Ethernet or Frame Relay, for example, but it doesn’t matter as long as the service gets where it needs to how it needs to. For a policy-oriented provisioning engine to make a smart decision on how to align network resources to meet a service’s requirements, the inventory system must be able to display those network resources, seeing across technology domains and network layers and thus showing the provisioning system how to orchestrate them to provide the paths needed to deliver the service. Going back to the SDP versus IMS discussion, this is an example of how an OSS-based SDP can present the capabilities of the network up to the IMS platform, which is concerned with the IP network and wants to assume the underlying paths its IP traffic traverses are set up appropriately.
This is what Cramer Systems is talking about in its OSS Factory concept, and it is the direction most inventory vendors are moving. The role of the OSS is to demonstrate how all of the network raw materials are translated into services, and how the network capabilities can be leveraged to create and add value. This becomes especially important as carriers begin to open their back offices to partners who want to add their own value on top of the value of the communications infrastructure.
Achieving that kind of collaboration and fluid service creation is completely dependent on the ability of the underlying OSSs to present the service capabilities—and thus the business value—of the network. From this perspective, the whole SDP-IMS enchilada rests on the ability of inventory and provisioning to move from something technology-specific to something that speaks business language and hides the complexity of multi-technology orchestration from the folks trying to figure out what new services they can add to the mix.
Assurance Impact
With so much focus on service delivery, the importance of service assurance cannot be overlooked. Service assurance technology must be in place to monitor the quality of the customer’s experience with any and every service. Assurance is significantly impacted because of the focus shift from the network to the customer. Fortunately, for several years now assurance vendors have been abstracting their network-facing capabilities in the areas of fault and performance management to put measurements and alarms in a service context.
“Building tools where the service and customer are the focus is quite different. You might drill down into the network, but you want to start off with what the service impact is,” says Paul Gowans, worldwide business development manager for Agilent Technologies. He explains that in a network-facing environment, nearly every alarm is dealt with equally. In a service-focused environment, alarms could relate to circuits or elements that actually have little or no impact on customers. In such cases, maintenance and repair first should focus on problems affecting the most or highest value customers.
Assurance also faces the same cross-domain and intercarrier challenges confronting all other OSS areas. “Think about doing customer experience across all of those domains,” Gowans says. The need to get down to the subscriber device and combine that management information with data coming from the network is the big challenge for assurance in the new service environment. Carriers keep looking for ways to collect data as close to the customer as possible to get a good lock on customer experience and how network events shape it.
The consistent theme across all OSS areas is the need to enable cross-domain visibility by bringing disparate, vertical silos into a federated view of all resources and events. As Sigma’s Gilmer points out, service providers are focused on “centralizing access to information and having visibility of the customer.” Sigma Systems’ concept of real-time service management, for example, emphasizes creating customer profiles that can pull disparate information together into a customer context. This must be combined with visibility into all of the network resources that enable services to create a management process that’s as continuous as the lifecycle of a service itself.
SOA to Tie It All Together
For OSSs to provide this kind of continuous visibility, something has to make all of the currently disparate data accessible without the effort or expense of breaking down all of the existing silos. “The good news is you don’t have to change OSS functions much,” says Grant Lenahan, executive director and strategist for Telcordia’s IMS service delivery business unit. “You need to make them business-to-business capable.” It’s generally agreed—for the moment—that the best integration approach to make OSSs business-to-business capable and fully visible across domains is service-oriented architecture (SOA).
This would not be the first time a new integration technology was touted as the solution to all integration problems. Remember, it was not long ago that EAI was thought of in a similar light. “EAI focused on infrastructure and decoupling systems, but it did not have a mechanism for defining standards for what information should be communicated,” says Syndesis’ Nicholson. SOA builds on EAI in that SOA offerings typically provide the tools not only to move information, but to do so in a business context.
To be clear, SOA plays two critical roles in the IMS or SDP context. “It’s definitely being used to break down the OSS silos and decrease the integration tax on the IT side,” says Chris King, Senior Director, Worldwide Telecommunications Markets for BEA Systems. “It’s also being looked at as a tool for IMS and next-generation service creation.” One use of the technology involves application integration in a somewhat traditional sense. The other has more to do with enabling business-to-business service creation and allowing partners to add value on top of value.
SOA is not meant to be used for all application integration needs. It’s certainly the overarching architecture toward which carriers are moving, but it’s not the only integration method in the picture. “If you have two applications that need to communicate a lot, like activation and billing, large telcos do millions of those transactions per day. It’s a well defined, well understood interface, and there may not be a lot of value that a web services interface brings,” says King.
In such cases, point-to-point integration can make more sense in terms of the collaborative functions of those systems. Once integrated, an SOA wrapper can be built around the systems to provide access to their data and functionality. Hence, multiple integration techniques will co-exist under the SOA umbrella.
The decision comes down to performance. “If you have a huge transaction architecture and need to mesh multiple, fine-grain services, you’ll find there’s too much communication happening there,” says Creaner at TMF. What actually happens, explains Oracle’s Trembley, is that if the number of XML messages being exchanged becomes too great, a lot of network resources will be needed to allow applications to communicate. There’s also an issue with data itself, where “if all systems are loosely coupled and data is loosely coupled, a process may not be able to get to the data fast enough,” Trembley says.
Another major challenge for carriers who implement an SOA comes in agreeing on service and data definitions. “You have to get all of these people on the same page, and that’s a great slowdown for SOA, … and it’s not a problem that’s not going to go away,” says Trembley. “This challenge is greatly magnified when you have to take outside companies you want to integrate with into consideration. … That can become almost crippling.” BEA’s King agrees and says that “not only do you integrate the applications but you also have to define all the data in the same format and deal with different formats from system to system—there’s no silver bullet here.”
To help overcome this challenge, vendors include tools in their SOA suites that provide a centralized point for referencing data in a common definition, but will push changes to data back out to individual systems in the formats they require. These propagations can be managed alongside service definitions as part of the overall management of the SOA. A common definition must still be agreed upon—which is troublesome, given the battle between IT and network raging in the background—but the information models in the individual systems do not have to change.
Groups like the OSS/J have also contributed significantly to SOA efforts by providing the basis on which carriers can build common APIs and common data definitions to accelerate interface development and thus bring more applications into an SOA environment faster and with less effort. “OSS/J APIs are ready for adoption,” says King. “As you move to SOA you need to take legacy systems and expose them to the rest of the world. Service providers can either define that for themselves, or take advantage of this work that’s already been done.” With a rise in OSS/J adoption, it appears carriers are embracing the notion that their systems must become far more open and flexible.
OSS at Front and Center
In the end, none of the IMS, SDP or SOA goals will be realized without OSS pulling it all together. OSS is what demonstrates the value of a communications network to outside parties that want to add to it. It handles the management, delivery and assurance of services. With an increasing level of automation, OSS will help carriers take on the increased service management burden while keeping costs down and speed up. It’s the unifying element that gives business context to SOA integration and allows for new IMS and related service layers to be real-time in nature and optimize the resources of the network according to capability and availability, rather than technology.
“OSS essentially unleashes the power of IMS” and the integrated services vision, says Creaner. As such, 2006 is a watershed year for OSS—the year in which we will likely see whether this once obscure technology arena can grow from the overlooked middle child of IT to the differentiator separating the carriers that win from the ones that go belly-up.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article