Welcome to Billing World & OSS Today's online newsletter.
Where’s the Service Integration?
To make money off their IMS investments, carriers must “operationalize” IMS with next-gen service orchestration on many levels.
By Susana Schwartz
Moving forward, choice will drive change. Today’s customers are locked in to services provided by their operators’ one-size-fits-all approaches, but, given the choice, they’d prefer to mix and match services from carriers, cable companies, satellite companies, and strong brands like Virgin, ESPN or Apple.
That means the finite amount of services offered today by carriers could morph into endless amounts of services created through bundling with third-parties.
IMS is expected to be germane to that transition, as its strength is supposed to be quickly and easily exposing data to third parties.
As carriers build shiny new IMS architectures, they hope to drive a lot of value in terms of speed to market with new service bundles. But to build something as important as IMS without tools that help manage services and orchestrate the inter-relationships among applications and network elements will prove self-defeating in the end.
Tools are needed to effect brokering so that a single media resource can be shared and re-used by multiple applications while also having the proper network resources aligned for its delivery, often in real-time.
Unfortunately, the tools today are not standardized on any specific protocol or a set of common definitions for service orchestration. Service brokering tools and definitions are therefore being left open to interpretation by individual vendors. Because IMS continues to be designed in an insular manner, with the assumption that it will operate over all-IP networks, service delivery could become complicated. The orchestration of inter-domain relationships must recognize non-IMS and non-IP systems involved in delivering a service. In other words, proprietary definitions and silo-based management of IMS systems translations can defeat the whole purpose of IMS.
As discussed in the Feb. 16th newsletter about Service Capability Interaction Manager (SCIM), the process of coordinating multiple SIP application servers is facilitated by the SCIM, an ad hoc standard for orchestration inside an IMS environment. But SCIM gives visibility only into the IMS domain. The IMS domain, to work effectively, must interact with and be supported by other packet-switched, circuit-switched and application domains. “The SCIM is supposed to be an ephemeral thing,” notes David Jacobs, CTO and Co-founder of Jacobs Rimell. “Defining what the service will be in real-time or in line with an event that is taking place may depend on one application that in turn relies on other applications running on a physical set of servers, or, it could be multiple applications on the same server.”
The IMS definition of orchestration has to apply at multiple levels, as service brokering will be necessary to decide not only what application servers are involved in service bundles, but at a second tier where different services from other domains can be bridged with the IMS domain. Ultimately, orchestration will be necessary across application servers as well as inside IMS application servers and in step with network technologies that actually deliver those applications. Part of the problem also lies in the fact application servers possess their own services developer kits (SDKs) to define what services a particular application server needs to orchestrate within its own domain.
Because Ubiquity, BEA, RedKnee and others in the application creation plain have their own SDKs and tools based on different technologies and standards (i.e., SIP, JAIN, Parlay/OSA, SOAP, Java, etc.), the next generation of service creation solutions will have to be more GUI-driven than was the case in the traditional world.
“The SDK for core IMS has to be part of the provisioning solution, so that lifecycle management, rapid integration of new services and rapid changes of portfolios can come to fruition,” says Leapstone’s Chris Daniel, VP of business development and VP within the MultiService Forum’s board of directors. He suggests some sort of “ “master provisioning solution” exist. “That would take unique definitions and orchestrates them across the solution,” says Daniel.That concept has started to emerge under several titles, including inter-domain managers, service managers or master provisioners. These terms are often used interchangeably and of course are not standardized.
Regardless of the term used, the concept is to abstract capability from technology by simplifying how multiple circuits and consequent QoS provisions and characteristics appear to the IMS domain for each service provisioned according to a customer profile. Inter-domain managers utilize logic analogous to process workflows to recognize resources from all domains and align or coordinate them according to the requirements of a requested set of services. SOA architectures can be used to facilitate communication between the master provisioners and domain-specific provisioning systems that already exist in the traditional IN or legacy world. However, the capabilities of each domain still must be abstracted and defined so that their capabilities can be invoked easily by the master provisioning system, service orchestration system, or inter-domain manager – whatever one wants to call it - that is responsible for aligning those domains for service delivery.
“You can’t orchestrate what you don’t know about,” says Daniel. So if one operator’s enhanced screening service is based on JSLEE, and a conferencing application and prepaid service is based on something else, there might be problems exposing APIs amid the different environments if all the supporting interfaces aren’t known.
If a service provider wants to combine video conferencing, personal free phone service, enhanced do-not-disturb service, and unified messaging all into one bundle, the provisioning domain has to have objects representing each service and its consequent operational characteristics and real-time characteristics. The master provisioning system has to insure that each domain, including the core IMS network, is provisioned appropriately but will allow IMS elements, such as the home subscriber server (HSS) and the CSCF (Call/Session Control Function), to do their jobs within the IMS domain. “So if you have video conferencing from a specialized SIP vendor and an enhanced do-not-disturb service in an IBM environment, and a unified messaging platform that drops SMSs into a mobile network or bridges into an IM session, you have to know in real-time what is happening in each domain to complete the service,” says Daniel.
Companies might be tempted to handle that type of complexity with traditional provisioning solutions, but hard-coded provisioning APIs will break once carriers go beyond bundling two or three services. To handle the different unique objects that need to be grouped for bundles as services are added or modified, the master provisioner must support all applications in the service bundle, not just those that plug into their own environments. As IMS and related content delivery architectures are built out, they should be constructed with an inherent recognition that there will be a master provisioner or inter-domain manager that will be used for abstraction and brokering. If they are not designed in this way – and in many cases they are not today – then all a service provider is really doing is building new silos that don’t communicate. Once again, should this happen, the promise of service integration will not be realized and telcos will have spent billions to build out IMS signaling just to deliver SIP-based telephony and TV offerings that are minimally interactive and therefore do not add much value over what’s already available to customers today.
Because Web Services, such as ParlayX and related technologies like SOAP and WSDL enable non-telecom IT developers to create network applications, the need for mechanisms that bridge application servers in telecom environments to servers in non-telecom environments will only increase. “As that happens, Web Services will become a third orchestration layer in and of itself,” claims Daniel. Web Services have well-defined orchestration layers designed to link robust tool sets from companies like IBM, Microsoft, and BEA. But each environment comes with an equivalent set of its own SDKs, which is why three different layers of orchestration will be necessary.
The All-Important Product Catalog
Flexibility will be key when adding services to product portfolios, which then affect product catalogs, which in turn affect lifecycle management of individual services, service packages and interfaces among network elements requiring OSS/BSS.
For that reason, the product catalog has been the object of debate as of late, for configuration of enhanced services rely on it and who owns it.
To operationalize IMS, operators must first settle the battle about where the product catalog will reside. Where billing and CRM vendors claim to own the product catalog in order to determine what is available and what to charge, the fulfillment folks also have a stake in it to know the configuration of applications and network elements responsible for delivering services.
For the SCIM to invoke a function such as trigger a do-not-disturb function on a video-on-demand stream, the view of the product catalog as seen by billing, CRM and/or fulfillment must be consistent and accurate.
There will have to be a truce between billing and OSS ultimately, as each will have to understand the roles and responsibilities of the other as product bundles roll out.
“More than workflow orientation, is necessary, as a single view of customer and service needs to be seen by all parties involved in overlaying services on top of existing infrastructure and services,” says Jacobs.
That leads to discussions of the arduous yet necessary journey to bring together IT and IN to facilitate a unified view of the customer.
The bottom line is that carriers must truly understand what elements are configured or created for a particular service, and they must prepare for the fact that the more services they bundle, the more simultaneous and voluminous the transactions will be.
It’s imperative that service orchestration be as much a consideration as is the SDP, the SCIM, the HSS, and the CSCF, otherwise, the evolution of IMS will be more painful than its worth for multiple SDPs, application servers and services will lead to the creation of more, not less, silos to manage with little, if any, value added.
Upcoming TeleStrategies Conference Events
Communications Taxation '06 June 12-14, Tysons Corner, VA. More Info
To subscribe to Billing World and OSS Today print magazine Click Here
To subscribe to this e-Newsletter use the form on our homepage: BillingWorld.com
To unsubscribe to this e-Newsletter click here and type "Please Take Me off" in the subject box.
CSG Workforce Express Implemented with Time Warner Time Warner Cable's Southwest Ohio Division is the first customer to use CSG(R) Workforce Express from CSG Systems. The stand-alone workforce management solution has a third-party billing system supplying underlying customer account information. CSG's Workforce Express is designed to help cable and direct broadcast satellite operators address the costly process of matching the appropriate technician to the correct job. The solution is designed to improve technician routing, field personnel location and job status tracking and is meant to narrow the window for estimated time of arrival data.
Alcatel to Integrate Syndesis Service Delivery Suite A partnership between Syndesis and Alcatel will mean that Alcatel will embed Syndesis’ IP triple play service delivery management into its OSS portfolio for triple play. The integrated package will focus on end-to-end service delivery across access, aggregation and core, including subscriber-centric activation and discovery in multi-vendor networks.
VOIP LOGIC selects Highdeal VoIP Logic LLC, a hosted and managed multimedia IP applications provider, has selected Highdeal’s Transactive® pricing and rating solution for use in its on demand service delivery platforms for VoIP and IP multimedia network applications. Highdeal Transactive is a modular software suite designed to provide carrier-grade pricing, rating, charging and billing functionality for VoIP, IPTV and mobile data.
Valista Delivers Unified Payments Platform Valista is answering the rapid growth in mobile payments with the latest version of PaymentsPlus. The solution enables split payments, which involves the use of multiple payment options (i.e., direct-to-bill, PSMS, debit/credit card, stored value, loyalty points) in a single transaction, while enabling funds to be distributed in real-time among multiple recipients involved in the transaction. Valista believes this will enable the launch of services with payment options including direct-to-bill, premium SMS, credit/debit cards, Person-to-Person (P2P) payments, stored value, proximity payments, loyalty programs and electronic vouchers.
Telenet Deploys MetaSolv for Digital TV Activation Leading cable operator Telenet, the largest provider of broadband cable services in Belgium, has implemented convergent service activation from MetaSolv Software, Inc. Telenet will use the solution for its digital TV offering. The cross-domain activation will handle orders involving complex services that trigger activation and configuration requirements in multiple domains, including POTS, VoIP, Digital TV, and DSL. Telenet had already used the platform for voice and broadband IP data services, including VoIP.
1-800-Reconex Switches to OSG Billing Services Oregon-based utility provider 1-800-Reconex and one of its utilities, U.S. Tel, have switched to OSG Billing Services to improve print and mail efficiencies and invoice design for their pre- and post-paid residential and business telephony services. The companies will immediately begin using OSG’s Dynamic Messaging application to create marketing messages on the front page of their invoices. 1-800-Reconex cited OSG’s reliability and ability to improve customer communications as the primary drivers of the changeover.
