SDP and OSS/BSS: On a Collision Course or Ready for Integration?
Susana Schwartz
12/01/2006
Two years ago, everyone became an “IMS vendor”; last year, everyone became a supplier of “SCIMs”; and this year, everyone is becoming an “SDP vendor.”
Like its predecessors, the term “service delivery platform” is very loosely defined, as there are no standards to explain what an SDP is or what it should comprise. Therefore, individual vendors and their customers are coming up with their own definitions, which inevitably lead to confusion about what the SDP does and how it affects OSS/BSS.
SDP should be viewed through a prism of service-oriented architecture (SOA), since it is a network-based approach by which operations are segmented and services coupled.
Since the network domain is the service execution domain, the SDP is ostensibly a SOA-based infrastructure for re-using service components as products are mixed and matched.
For example, IPTV, VoIP and other applications utilizing a SCIM (service capability interaction manager) are using session-based capabilities that operate in “run time” on the network. By having a common execution environment for gaming, video streaming and IPTV, the SDP can bridge the gap into the business processes that touch provisioning, ordering and billing for each of those services.
The SDP provides an execution environment in which services run as part of IMS and NGN initiatives. The point of the SDP is to create an integration point between services and business processes.
Where does the SDP fit in relation to IMS?
IMS is moving operators toward a common IP core for fixed and mobile networks. Its purpose is to enable carriers to work with the control plane, which are the horizontal applications that define network behaviors (as opposed to vertical applications in the management plane).
That access to horizontal planes can help reduce CapEx and OpEx. That, in turn, opens the door for the SOA principle intended to transform how services are created and offered. The SOA principle is enabled when services are linked to business processes, which is what the SDP is designed to do.
At the heart of the SDP is the application server, as it is germane to decoupling the services from the underlying networks so that applications can be bolted together without reconfiguring and disrupting underlying networks.
For that reason, companies with strong application server backgrounds—such as IBM, BEA, Oracle and Microsoft—are considered key SDP players.
Other than application servers, however, databases, SIP servers and devices (for example, Microsoft’s out-of-the-box IPTV) are also considerations for the SDP. And with its recent acquisition frenzy, Oracle has upped the ante by adding OSS/BSS applications to the SDP mix. However, standards-based interfaces, plug-ins and adapters allow its competitors to reach out to CRM, billing and provisioning from other companies.
Regardless of its strategy, no individual player possesses all components of an SDP end-to-end, although some may claim to, and some are definitely attempting to get there.
So what is it that carriers should consider when weeding through all the hype?
Most are seeking IMS execution across converged mobile and fixed networks. As network migrations take place, the chosen SDP should be able to drive services to SIP-based, horizontal, IP platforms through IMS networks. Since the goal is to get multimedia and telephony to go over the Web, the roll-out of the SDP seems to correlate to SIP functionality for VoIP services and things like presence, location and more advanced voice mail services.
“As SIP becomes prevalent, it may actually negate IMS, even though they are currently meant to work together,” says Oracle’s Vittorrio Viarengo, vice president of SDP product development. He believes SIP is the “simpler, easier, cheaper route.” Analogous to the lack of traction for IPv6, he points out that everyone still uses “plain old IPv4, because it’s the simplest thing and it’s embedded.”
But SIP has already gotten to the point where there is a competitive market for componentized SIP stacks that are standard. “We have to support legacy applications like fixed line, as well as SIP to support upcoming IMS networks,” says Viarengo.
Interfaces through Parlay help extend IT platforms, and SIP is used to support IMS. “The point is to eliminate the need to start from scratch,” says Viarengo, noting that the building blocks are there through SIP for presence and call control. “With a few lines of Java code and SIP endpoints, you can develop applications about the status of a subscriber in a network and his or her location.”
The key to an SDP seems to be all things open and standard. For example, SDP players like Oracle, IBM and BEA have all worked to deliver Java, the standards-based IP core, with the intention of empowering developers to expedite development of services.
The hope is that the millions of developers who know Java could, in essence, become telecom developers without any telecom expertise.
“With SDP, we can extend the core Java server with the network interfaces that talk to telco networks so they don’t become IT islands,” says Viarengo.
That is all well and good, but why bother building services quickly if you can’t tie them to CRM, billing or customer support? Although the back office is not as “sexy,” the fact is that SDPs and the move toward SOA will not succeed without a change in mindset around OSS/BSS.
‘Run Time’ OSS/BSS
There is little point in increasing the agility of the delivery and execution environment if the back office remains siloed rather than componentized. In order to manage catalogs of scores—or hundreds, or even thousands—of offerings, “customer-aware” OSS/BSS will be necessary if “Internet speed” is to be brought to provisioning, activation, billing, customer care and other components in the OSS/BSS chain.
“For that reason, SDPs should trigger operators to get their OSS/BSS house in order,” according to Tim Greisinger, vice president of communications industry solutions in IBM’s Software Group. He acknowledges that different service providers get excited about SDP for different reasons, “but they all should know it can help establish common interfaces to centralize OSS/BSS.”
It does so by serving as a buffer among different OSS/BSS components and the service execution environments. In essence, the SDP becomes an abstraction layer between the billing system and something like an IPTV environment, for example.
Greisinger notes that it was this concept that drove SBC’s Project Lightspeed, which implemented an SDP as the primary way to protect its subscriber content and to manage OSS/BSS interfaces for network inventory, activation, provisioning and billing.
SBC “didn’t want to have a new silo of subscriber data owned by Microsoft’s IPTV environment,” Greisinger says. “By using the subscriber management function of their SDP, they can launch additional services with a common view of the subscriber. Similarly, they didn’t have to retrofit new service subscriber data into their billing systems like carriers traditionally have done.”
To avoid silos and the need to rebuild from scratch, common platforms and standard interfaces were the key to Lightspeed, and are the heart of most SDP initiatives.
“You orchestrate and interact with OSS/BSS through SID data models and eTOM processes that are abstracted into generic definitions of customers and views of processes,” Greisinger explains.
That is one of the reasons Web Services standards are starting to get considerable traction.
“Web Services is a standard information technology that becomes the plumbing for integrating with SDPs. They link the network elements providing the network interface,” says Mark Nicholson, CTO with Syndesis, which is involved in management aspects such as taking subscriptions from portals or call centers and getting configurations into the SDP and related applications. He warns that carriers must also consider the next layer up when building SDPs: “The SDP model must expose APIs so that attributes about subscribers are known by the network and the OSS/BSS.”
That is daunting for now, as carriers will no longer have software sitting on top of the network; instead, it has to become an actual part of the network. “That means the signaling will ask the application what it should do—and it cannot take too long to do so, otherwise you compromise the customer experience,” says Nicholson, reiterating the importance of reliability not just in the code, but in simulations of huge volumes.
For the underlying plumbing to be reliable and scalable, Web Services has to evolve a bit more before it becomes a dominant infrastructure. Meanwhile, services will continue to be provisioned in a static manner until network-based architectures are segmented in such a way that dynamic service registries in Web Services are possible.
Orchestration and Choreography
“Orchestration” is quickly becoming an overused term, but it is something that must happen at many levels for SDPs to succeed.
The type of Web Services orchestration conducted at the eTOM level is somewhat similar to that done by the SCIM in IMS across multiple elements in real time. That technology is fundamentally similar to the type of Web Services orchestration done at the eTom level. With an SDP, the focus is on Web Services and leveraging SID data mapping and eTOM processes.
“For interfacing with service provider systems, Web Services is the focus for OSS/BSS, as well as SID modeling to share information across multiple interfaces from many vendors,” explains IBM’s David Mangini, global solution owner for SDP.
While “orchestration” is a term used to describe the SCIM function, it is the word “choreography” that Mangini considers more accurate for an SDP.
“SDP brings one common set of interfaces into a carrier’s range of OSS/BSS systems so they can be shared among all services,” he says. “It does so by choreographing three dimensions, including services that are executed to users, as well as business processes with OSS/BSS, and hosting of portals out to third parties wishing to bring their content and applications to partner service providers. Through SDP, the service provider can leverage the same OSS/BSS interfaces for all parties.”
That usually happens through service management functions, such as subscription management, content management, and device management.
The choreography of interfaces representing the OSS/BSS systems necessary for certain services means that IPTV, content services, gaming and other services can use the same billing, provisioning and CRM systems through interfaces that abstract differences.
If carriers configure services through service creation tools and through their networks, they have to extend the concept of service creation and assembly into OSS and then up to BSS.
“The execution environment provided by an SDP possesses operational elements to centralize OSS/BSS and virtualize the definition of services, as well as overlay subscriber profiles on top of logical service definitions,” says CTO Doug Tucker of Ubiquity Software, which has defined an SOA infrastructure on top of its SIP application server.
“We break SDP into two categories: functional and operational,” says Tucker, explaining that “functional” means the development environment within the SOA-based infrastructure. That is the piece used for managing and executing the functional components within the infrastructure. “Operational” refers to the act of centralizing OSS/BSS and virtualizing service definitions through the overlay of subscriber definitions and profiles on top of logical service definitions.
“The point of all of this is that the SDP has to push service creation outside of what happens in the network and apply it to OSS/BSS. Then, when something new is bolted into the network, changes are driven to OSS so it understands new products in the network,” says Tucker.
For that to happen, all components need to be more “aware” of customers who are “always on.”
‘Run-Time’ Customers
Next-gen services will mean that CRM cannot just fade away after the service is provisioned and activated. Fulfillment and activation must be ongoing, as an awareness of what the customer wants to do at any given moment will be key to enabling people to bundle and re-bundle services on demand.
The SDP can only be effective in discovering, fulfilling and managing services if it can work with OSS/BSS that operate as components. That’s what IMS is supposed to facilitate by enabling the reuse of modular service components and that is the whole point of investing in IMS, NGN and SDPs. The goal is to avoid the need to set up and tear down services as customer life cycles morph.
“Today, a Tier 1 can bolt in a new application in about a month, but it takes about 18 months to get the OSS up to par,” says Brian Naughton, vice president of architecture and strategy at Axiom Systems. “The problem is that OSS is playing catch-up in execution time and becomes a bottleneck for new agile platforms underneath.”
The source of the difficulty is that assurance, fulfillment and CRM do not understand how to combine resources into services that customers use and bundle. It’s understandable, since carriers are engrossed in IP network migrations. However, the time is nearing where billing, customer care and OSS components will all have to change on the fly with real-time service changes.
To blur the boundaries between SDP and OSS/BSS, work is underway to define processes and the “black boxes” that are currently missing in carriers’ architecture.
For example, BT, TeliaSonera and Cable & Wireless have begun to assemble service creation tools to deal with run time, and how customers order services. They are working on the logic that would allow for the bundling of components in an SOA environment. The proof of concept was initiated by these companies and their vendors, as well as Oracle—including its SDP, Fusion and Siebel folks—Axiom, Atos Origin, Celona and Huawei. The collaboration has now evolved into a TMF Catalyst project called the “Product and Service Assembly Initiative.”
The purpose is “OSS Refab,” as Axiom’s Naughton calls for the creation of a reference OSS architecture. “Its purpose will be to reveal the pieces of the operational stack and the pieces of functionality that will fill holes in today’s active catalogs and models, like eTom and SID.”
By December, the group hopes to have demonstrated how new products can be launched by bridging the gap between OSS/BSS and service execution systems and devices.
No Silver Bullet
“The first thing to keep in mind is that SDP is not a ‘platform,’ per se, as in one ‘box’ or one piece of software,” notes Sanjay Mewada, vice president of strategy for NetCracker and former Yankee Group analyst. “SDP is not something you buy like a Cisco router or CRM software package; a better term for SDP would be ‘service delivery framework.’”
For that reason, SDP requires the assembly of many components, each capitalizing on different strengths of different vendors.
Mewada breaks SDP into five segments. The first is service delivery platforms that should talk to any network. That is where vendors with strengths in the network will excel.
The second part of the framework involves communication with the IT infrastructure, such as servers for applications, voice mail, email and content. All are used to deliver services, even though they don’t “live” in the network.
Third is the part of the SDP that must talk to the front-end system to create services. A company like a Microsoft might excel in that part of the service creation puzzle.
Fourth is the integration environment responsible for stitching together so many disparate components. Companies like IBM, BEA and Oracle would excel in this area.
And the last part is the integration into OSS/BSS, which, as stated here, is an ongoing process of discovery among vendors and carriers.
“No one does soup-to-nuts, real-time service support, but carriers need to determine what elements are most crucial to them,” says Beau Atwater, executive director of portfolio strategy with Telcordia, whose Granite and Expediter products focus on the real-time charging aspects of the SDP. The company also has partnered with SAP to open up to partner systems for improvements in the service supply chain.
“One of the key trends we see driven by SDP is the ‘return of the customer,’” says Atwater, noting a renewed emphasis on the customer experience. “SDP is a key part of that by enabling customers to make changes to their services, which can only happen through convergence of OSS/BSS.”
He believes carriers have to consider how well their SDP framework will re-use components such as HLRs and other subscriber management systems. “Rapid service creation relies on solid back-office systems for subscriber and inventory management,” adds Atwater. “There is a blurring of the lines between SDP and OSS/BSS, as it’s all about high-performance software that will support your business.”
As carriers evolve their execution environments, they have to consider workflow and process first, so that they understand how subscribers will access and grab services from portals using different devices. “To have billing and provisioning and activation work, your charging systems have to understand how one things feeds into the next,” says Atwater.
Again, the success of the SDP comes back to having your OSS/BSS “house in order.”
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article