Service providers want IMS to enable service creation, but little is understood about the orchestration on the fulfillment and assurance sides, which could be the deal breaker in bringing IMS to life.
Customers want more choices. Rather than remaining locked into one-size-fits-all product offerings, they want to mix and match the mobile, wireline, TV and content services and brands they like.
That means telecom will have to shift its mindset toward the more flexible approach employed by companies such as Google or Yahoo, whose service-oriented models allow customers to choose from hundreds, if not thousands of services.
“The goal is a subscriber-oriented model based on subscriptions to services and suites that are flexible enough to be mixed and matched in personalized, dynamic ways and changed on the fly without much lead time,” says David Croslin, chief IT product architect for Verizon Business. He refers to service suites as the killer app that IMS could deliver. “We want to match the enterprise business model with the optimal communications suite whenever we want. No three-month lead times. The sales team will say it, and we will deliver it.”
He concedes that a change in mindset is needed on both the subscriber and carrier sides of the equation for the potential of IMS to be realized. “Though there are thousands of Centrex features actually available today, most people make decisions based on cost rather than feature sets,” says Croslin, who adds that he expects that will change. “Despite how it works today, we know we have to go beyond a good cost model and onto a rich feature set, as that is the super glue that will keep the customers with us.”
Service providers will also have to understand how their roles will change. “A carrier could be operating as a wholesale entity in one moment and as a transport mechanism or even content provider in another scenario. It really depends on where we will stand in the business model for a given service or suite of services,” says Croslin.
IMS, as a service creation and execution environment, opens up telecom applications to the outside world (see sidebar, “Web Services Convergence with IMS”). What could ensue would be larger numbers of diverse services that would be introduced, removed and changed in very short time frames.
He admits, however, there is little point to implementing IMS to create new services if it still takes months or even years to get the OSS/BSS to accommodate the new services.
While much of the hype around IMS thus far has revolved around the network benefits, little has been said about the management plane for fulfillment, provisioning, QoS, billing and customer care—all critical to the success of IMS.
“Management orchestration is important because it envelops all the steps that must take place from the time a person indicates they want to subscribe to a service to the point the service is fulfilled,” notes Mark Nicholson, CTO of Syndesis. He is one of a growing number of people in the industry who believe the potential of IMS will not be realized without orchestration on multiple levels within fulfillment and assurance.
“While there is talk about ‘IMS billing or IMS OSS,’ it’s a trap because domains are not yet interacting correctly,” says Fiona Fulton, Convegys’ market strategy manager. She believes “IMS-enabled” is more the appropriate term for what is developing today. “Triple and quad play will sit along side IMS, which will be running the same services in a different way. “Coexistence is the key,” says Fulton. “What IMS does is push the need for converged BSS so that you have a single customer with a combination of accounts, whether digital TV, circuit switched, WiFi and IMS.” She believes it will be the responsibility of billing and customer care to hide the complexity of how the networks and combinations of services work.
Orchestration Hype “Orchestration or brokering of multiple network and service combinations will be the key to success, so the question is not whether orchestration will be paramount to the success of IMS, but how many points of orchestration will actually be necessary,” says Croslin. He points to the fact “orchestration” and “domain” have become overloaded and overused terms that confuse rather than clarify. “Everyone uses those terms according to their own view, which makes it difficult for people to make the right choices.”
Indeed, policy orchestration, services orchestration, security orchestration at the edge, and the many types of transport orchestration all have to take place for IMS to work. “Regardless of the service, advanced management and brokering functions must be in place at the edge, and--once the subscriber enters a network--at many levels up the stack,” explains Croslin.
The confusion around the word “domain” stems from the fact it could refer to technology domains, such as IP, layers 4 through 7, and IP Ethernet. “Domain” also could refer to the network domains that have to exchange routing information about how to get to certain servers or elements required in the service, such as ATM, frame relay, optical and Ethernet.
As if that’s not enough, some vendors refer to “domain” to represent different silos of services. That means security, service and accounts, billing, OSS, call flow, services and other silos that have to be managed so that interactions among the different domains are known.
Orchestration can’t be understood if the domains that are being “orchestrated” aren’t understood.
“You can’t orchestrate what you don’t know about,” says Leapstone’s Chris Daniel, VP of business development and VP within the MultiService Forum’s board of directors. “If you have video conferencing from a specialized SIP vendor and an enhanced do-not-disturb service in an Java SIP Servlet environment, and a unified messaging platform capable of initiating an SMS or IM session, it requires the provisioning system to give the network to the correct rules and policies to know when and how to manage each service across the different application servers,” says Daniel. “If carriers’ service creation solutions are not GUI-driven, they may kill off the purpose of IMS.”
IMS will not be “operationalized” if carriers do not have a view of how IMS domains interact with other domains. For IMS to be viewed as a new infrastructure high up in the stack, it has to be managed effectively.
IT/Nework Silos
While the equipment providers are well on their way to making sure the networking equipment is compliant with IMS, it’s the elements around provisioning, QoS and management that remain unexplored. “That could be attributable to the fact network people generally are not accustomed to working with ‘decomposed’ architecture,” says Peter Dragunas, who heads up HP’s worldwide Network Domain Group, noting it’s important that IT get involved from the get-go.
“Some carriers are looking at IMS as an aggregated SOA architecture, while others look at it as an environment that can be decomposed into many small pieces. If left to the network organization, the stuff in the management plane is ignored until things start to break,” says Dragunas.
“IMS will create interesting ‘tension’ between IT and network organizations right now as these things start to get built,” notes Dragunas.
In other words, IMS is the inflection point where organizational issues must be dealt with to get value out of a huge investment. “The network folks might not see the benefit of certain stovepipes, which may lead them to buy into IMS services, which means more stovepipes and less re-use,” says Dragunas.
For that reason, IT must get involved early on to think of IMS in terms of SOA and architecture, and how IMS will integrate with the network
“IMS is a traditional telco buy, but if you look from the top down, you see it as more of an IT buy, so the service delivery platform has to come from a company that knows both,” says HP’s Michele Campriani, who heads up the worldwide Operations Domain, which encompasses both OSS and BSS and HP's SOA. “The higher-level intelligence needed for orchestration, the real-time stuff on the network and the OSS, all need their own flavor of orchestration.”
Companies in the application creation plane (i.e., Ubiquity, BEA, RedKnee) are stepping in with service delivery platforms (SDPs) that include service delivery kits (SDKs) and tools designed to manage application servers or sets of application servers.
Because SDPs are based on differing technologies and features (i.e., SIP, JAIN, Parlay/OSA, SOAP, Java, etc.), it’s easy for service providers to fall into a trap of believing their SDP will take care of everything. The “IMS in a box” approach could actually mitigate the building-block approach at the heart of IMS, the purpose of which is to decompose services in such a way that they can be re-used throughout applications.
Carriers should look for SDPs possessing tool kits that are independent of the underlying platform. If equipment manufacturers create proprietary IMS ecosystems with Home Subscriber Server (HSS) and Call Session Control Functions (CSCF) components lacking open hooks to others, cross-provider interworking among servers, information models and service details could become problematic as the number of services increase from a handful to hundreds, or even thousands.
“You want to allow the service provider to define all of the services that are available in the IMS network and creates the rules by which the services are orchestrated across the solution for each unique subscriber profile,” says Daniel. He believes that SDKs for core IMS orchestration have to be part of the provisioning solutions, so that lifecycle management of the individual services and services packages will enable the rapid integration of new services and rapid changes of portfolios to come to fruition.”
Without easier integration, the evolution of IMS could prove more painful than originally thought. The addition of SDPs and applications servers for each new service means there could be 30, 40 or 70 silos with which to grapple from an operational and IT perspective.
This will become even more complicated as carriers continue to add non-IMS services to their bundles, such as VoIP and IPTV. Rather than sit around and wait for everything to become IMS-powered.
“This gets very complicated, with all the different elements and feature servers used for VoIP, IPTV, DVRs, home security systems, in-house monitoring systems and so on. You could have 50 different services working interactively, so you have to have something that knows conflicts and synergies,” says Syndesis’ Nicholson, who believes fulfillment has to see how all this comes together if a customer is to use disparate technologies, such as a buddy list to be interspersed among SMS and IPTV technologies.
“If an operator, whose enhanced screening service is based on JSLEE [JAIN Service Logic Execution Environment] has also bought an off-the-shelf prepaid service, the process of defining a specific orchestration flow as part of the application logic itself is arduous as each element has been developed in completely independent service domains,” says Daniel.
Unfortunately, much of the “orchestration” talk today revolves around IMS standards that speak to micro orchestration, such as call set-up and data flow through a call.
“What’s needed is a way to get the right data into the right systems at the right time. A layer of macro orchestration currently is missing,” says Sigma Systems’ CTO Brian Cappellani. “There has to be customer-specific logic in the provisioning systems so that the real-time and operational impacts of each of those services independently, and inter-dependently, are understood.”
That customer-specific logic must recognize processes and resources from all domains and coordinate them according to the requirements of a requested set of services and the profiles of customers tied to those services.
The management plane in IMS will have to fulfill each service individually, which inevitably will cause conflicts across applications as the number of service suites increases.
Without coordination, a teen downloading a high-definition movie to his PC could freeze up Mom’s IPTV screen or Dad’s VoIP call, or a subscriber who just accepted a promotion for Yahoo!IM could fail to receive the service because it conflicts with an existing location-dependent service that puts messages into an offline archive after a certain hour.
The next-gen customers will call the support centers within seconds after ordering a new service if it’s not working, which means the processes used to transition customers from fulfillment to assurance will have to be greatly shortened once multiple services are offered across network and technology domains. The transition will have to go from weeks to seconds. When fulfillment is ready, so too must be assurance and billing.
For that reason, carriers orchestration at the management plane for fulfillment, assurance, billing and CRM are paramount. It can take an average of five years to make the necessary changes, so those carriers building IMS architecture must think about this before large volumes force quality problems that chase customers away.
Web Services Convergence with IMS
Because IMS “standardization” is limited to routing, services are not defined well in the IMS domain. Consequently, Web Services are becoming a key element for opening up telecom applications to the outside world. As evidenced by the momentum of Parlay/ParlayX, developers want interactive services between telecom-specific and non-telecom entities.
The traction of Web Services like Simple Object Access Protocol (SOAP), Business Process Execution Language (BPEL) and other service composition tools means robust orchestration technologies do exist, but they do not involve SIP. That is critical since the next wave of telecom services will have to sustain thousands of transactions and depend on developers that may or may not have telecom expertise.
As carriers partner with third parties for new roll-outs, Web Services will be critical for bridging IMS application servers in telecom environments to servers in non-telecom environments. As that happens, service providers will need to understand the interaction between Web Services and IMS to orchestrate services.
“Carriers have to take into account the different levels of orchestration that are necessary for service composition to happen quickly and in great numbers,” says Peter Dragunas, who heads up HP’s worldwide Network Domain Group. “Real-time service composition has to happen close to the network, but the high-performance value-add services created in Web Services environments will sit on top of IMS.” Real-time SIP-based services will have to interconnect to higher service layers of Web-based services. IT tools will be needed to support new services made possible by an IMS architecture.
“Because Web Services generally lack the real-time performance and reliability requirements that carriers have come to expect from their core architectures, vendors such as IBM, Microsoft and BEA are focused on providing major solutions to address the service providers’ needs for integrating Web Services with their IMS architectures, alternate client-server architectures [i.e. IPTV or gaming], and the use of Web Services in their NGOSS solutions themselves,” explains Leapstone’s Chris Daniel, vice president of business development and vice president within the MultiService Forum’s board of directors.
As NGOSS uses underlying processes from eTOM and SID (and APIs resulting from the merger with OSS/J), there can be a common denominator between execution and operations environments. A common information model is the goal for real-time execution and management, which requires a shared view.
“However, Web Services orchestration also comes with its own service delivery kits, which is means additional layers of orchestration will be necessary,” says Daniel, noting it is critical that service providers understand not only IMS service orchestration, but the general relationship for how Web Services and IMS interact, as well as how Web Services interact with other client-server architectures.
