Convergent services in the service oriented architecture Natalya Yashenkova The article describes how service oriented architecture and the standard OSS solutions can close the gap between the process of service creation, control of service's lifecycle, service implementation and the use of this service in IMS applications and converged services. This OSS solution can show the operators how to quickly bring new services to life and create the right market product, provide an easy ordering system, seamlessly manage the preparation for operation of basic services and enable subscribers to manage their own services. Keywords: Service oriented architecture, standard OSS solutions, IMS applications and converged services. New technologies and network architectures such as Internet protocol multimedia subsystem (IMS) and session initiation protocol (SIP) are enabling the introduction of many new converged applications and services. New service capabilities and the resulting convergences and operations support system (OSS) requirements have created the need for major enhancements to existing OSS systems, and in many cases, a total revamp of the OSS environment. This paper describes how using service-oriented architecture (SOA) and standards-based OSS solutions can bridge the gap between service creation, product life-cycle management, service fulfillment, and service usage for IMS and converged services. This reference OSS solution shows how operators can rapidly bring new service capabilities to life in the form of marketable products, easily capture and handle orders for these products, seamlessly manage the provisioning of underlying services, and enable subscribers to manage their services. An actual solution was prototyped as part of a Telemanagement Forum (TMF) Catalyst Project. For more details on the prototype solution, visit the NGN OSS Blueprint TMF Catalyst Project information page (www.tmforum.org/browse.aspx?catid=987&linkid=31970). All the interactions between application components in the OSS solution were 100 percent based on SOA. The project also implemented TMF next-generation OSS (NGOSS) contracts as a form of extended SOA. The solution modeled key data based on TMF shared information and data (SID) and also used the third-generation partnership project (3GPP) generic user profile (GUP) architecture. This paper summarizes the overall OSS architecture and describes in detail the service scenario for which a solution was built. It serves as a valuable reference for anyone who is involved in designing and developing an end-to-end OSS solution for managing the delivery of convergedservices on an IMS based infrastructure. Moreover, it shows how operators can more rapidly monetize their next-generation networks (NGNs). Converged Services Communications service providers have recognized that competitive differentiation is going to be increasingly driven by the variety and quality of products they deliver. Operators are under significant pressure to deliver segment-focused and tailored offerings to reduce churn and increase loyalty. A number of integrated operators have already started down the path of developing an assortment of converged services offerings that are better aligned with their customers interests, expectations, and lifestyles. These operators are experimenting with innovative combinations of fixed-line and mobile technologies to deliver a seamless service experience across all the individual domains. They are also starting to assemble a vast array of underlying service capabilities, devices, content, and merchandise to create unique and meaningful product offerings. New technologies and network architectures such as SIP and IMS are enabling the creation of many new converged applications and services. These architectures simplify and speed up
creation and deployment of new service capabilities. They often take an information technology (IT) centric approach that enables Java developers (for Java Enterprise Edition [J2EE] based systems), for example not just telecom experts to create and deploy real-time multimedia services. Services can now be created using a modular components and a building-blocks approach with service logic deployed as reusable code. These new network technologies and architectures will allow operators to create many new blended, bundled, and converged service offerings that have lots of variations, are introduced faster, have shorter life cycles, and are lifestyle-linked. Some examples of next-generation converged services that operators are beginning to roll out and experiment with include the following: On-demand services Location-based services Presence-related services o Findme/followmeacrossmultipleaccesspaths o Donotdisturb,callscreeningacrossmultipleaccesspaths Blended services o Subscriberordersanewringtoneforamobilephone,anditisautomaticallyusedfor subscriber s SIP phone as well o Subscriber has to leave the house but continues viewing his or her favorite TV program on mobile handset o Unlicensed mobile access (UMA) based wireless services using a single handset for wireline and wireless The Business and Systems Challenges Implementing new cross-domain network technologies and creating innovative converged service capabilities in the network is just the first step. Although new converged service and application capabilities will be deployable more quickly, operators still need to address the operational challenges associated with defining and managing market-facing product definitions, capturingand handling orders for them, managing the provisioning of underlying services, and enabling subscribers to administer relevant service parameters and settings. Operators need to implement OSS that seamlessly link the front- and back-office operations and tightly align service creation, product management, offer management, and service fulfillment processes. Operators require OSS solutions that bridge the gap between the network and the front office, help bring new service capabilities to market and accelerate revenue generation. Legacy OSS solutions are incapable of meeting the requirements for supporting converged services delivery, since they are often tailored to specific network domains, have monolithic solution approaches (attempt to address many diverse needs in a single application), and use proprietary or nonstandard information models and interfaces. New service capabilities and their resulting convergence and OSS requirements have raised the need for major enhancements to existing OSS systems and, in many cases, a total revamp of the OSS environment. Furthermore, with the introduction of Telecoms and Internet Converged Services and Protocols for Advanced Networks (TISPAN) NGN architecture for IMS based services, the need for GUP based server authentication and service profile management becomes a critical requirement for NGN services. For a complex integration for converged service scenarios, almost every component in a multi-application OSS environment will be impacted, including the following: Customer-relationship management (CRM) Needs to address increased complexity of offerings and eligibility/pricing criteria Customer databases Needs to maintain more product and service instances, relationships, and changes Product catalogs Needs to enable definition and management of more types and variations of bundled products and services and support faster product rollouts and shorter life cycles
Service inventory Needs to manage more content, more details, more varied presentation Order management New enhanced applications need life-cycle management of the order from acceptance, verification, fulfillment, change, and disconnect Service provisioning and activation Needs to pre-provision to facilitate the work of smart/intelligent network controlling mechanisms Resource inventory Needs to have detailed central repository of the service provider s entire physical and logical network infrastructure Billing Needs to adapt to increased billing and rating complexity due to microcharges and charges based on complex bundles Standards-Based OSS Solution Scope The reference OSS solution uses SOA and standards-based interfaces to bridge the gap between service creation, product management, and service fulfillment for IMS and other converged services infrastructures. This solution is a blueprint for the service delivery OSS for dynamic and rapidly changing converged services. The solution spans from service creation to product catalog representation, ordering, fulfillment, and subscriber parameter management and usage. The end- to-end OSS solution was prototyped and implemented to support a weather alert notification service for residential customers. The solution incorporates a number of best-practices and standards-based technologies. All the software components in the entire solution communicate with each other using Web services in a true SOA. A complete end-to-end service creation, fulfillment, and usage scenario has been realized based on a SOA framework that includes extensible markup language (XML)/simple object access protocol (SOAP) and Web services description language (WSDL). The solution also pioneered the use and detailed documentation of NGOSS contracts for service interfaces. Global service providers have examined their networks and OSS support in relation to moving to all Internet protocol (IP) NGNs and have concluded that these networks cannot deliver the desired service economy without effective OSS solutions based on NGOSS contracts that are a form of extended SOA. The TMF is working aggressively to produce implementable NGOSS contracts, and the NGN OSS Blueprint Catalyst Project is a key contributor to this effort. All key data in the project solution has been modeled based on the TMF SID information model, and the solution uses the 3GPP GUP architecture. The following were the key aspects of the standards-based OSS solution: Support of converged services based on TISPAN NGN architecture and TISPAN NGN OSS architecture Use of SOA framework (e.g., XML/SOAP, WSDL) Use of detailed NGOSS contracts for service interfaces 3GPP compliant GUP architecture Association of new service capabilities with products, along with definition of products and publication of these using a centralized product life-cycle management system Use of service provisioning and activation, service inventory, and resource inventory components for end-to-end fulfillment Subscriber data provisioning of the TISPAN NGN functionalities Enhanced scenario involving landline, mobile, and IPTV services Converged Services OSS Architecture
The prototype OSS solution was implemented for a converged services scenario involving a weather notification service. A subscriber enrolls for the weather notification service and registers a group of users that would receive weather alerts. When the weather alert is triggered, it is sent to the registered list of users based on the individual user policies. The primary system components in the architecture include the following: Service provider portal This is the Web page where the customer may order new products and the subscriber may add, delete, or modify the parameters for a service. Service creation environment The operator designs and introduces new services using these tools and environments. Product catalog/lifecycle management system (product control center) The operator designs and introduces new products and uses this application to manage the life cycle of products and market offerings. Order management This component performs necessary order decomposition and order handling functionality. Service provisioning/activation This system helps ensure that orders are completed in an accurate and timely manner by coordinating with other key delivery systems, including network inventory and service activation. Service inventory SIP server Network resource inventory Subscriber user profile GUP server Simulated HSS, billing OSS Solution Interfaces This section describes in detail the interactions among the components of the reference OSS solution. A high-level view of all of the interfaces is shown in Figure 2. The call sequence may be different for different scenario sets, but the interfaces themselves are not affected by the specific scenario being demonstrated. A scenario need not use all the interfaces.
Table 1 shows the operations supported by each interface and the data elements that are passed across each interface.
Weather Alarm Alert Service Scenario This section describes the set of scenarios that use the weather alarm service. The scenarios use the components and interfaces defined in the previous sections. Service Design and Implementation A service designer implements a service capability such as a find me/follow me SIP servlet in a simulated service creation environment (SCE). As part of implementation process, the service designer enters service capability information into the simulated SCE.
The SCE adds the service capability implementation to a SIP application server that can execute it. The service designer requests the SCE to export service capability information to a unified product catalog. Contacts, ServiceParamet The SCE exports the service capability definition to the product control center. Product Creation and Catalog Update A product manager defines new feature specifications in the product control center, using previously imported capability definitions. The product manager defines new product specifications in the product control center, using the new feature specifications. The product manager defines new product offerings in the product control center, using the new product specifications. The product manager publishes the new product offerings to various product catalogs managed by the product control center. The product manager requests the product control center to export the new product offerings to an order management and a billing system. The product control center exports the new product offering definitions to an order management and a simulated billing system. Customer Ordering of Alert Service A customer goes to a service provider s CRM portal to add converged services to his or her existing account. The customer uses the portal to see what product offerings are available. The CRM portal looks up the product offerings for which the customer is eligible in the appropriate product catalog and presents them to the customer. The customer selects and orders the weather alert service converged product offering. The CRM portal submits the order to an order management system. The order management system verifies and processes the order based on its product catalog (which is in sync with the product control center) and service catalog, then decomposes and sends a service order to the service provisioning and activation system. The service provisioning and activation system, using an inventory system, provisions the service and send activation data to the GUP server. The service activation system also notifies the subscriber portal about a new subscription to the service. The GUP server provisions the service in the simulated home subscriber server (HSS). The GUP server provisions the service in the simulated wireline element management system (EMS). The order management system notifies the simulated billing system that the new product has been purchased by the customer and its services activated. Customer Configuration of Contact Numbers The customer already subscribes to at least one service from the service provider. This could be mobile, landline, or IP services. The customer subscribes to the service under a name called subscriber. A subscriber goes to a service provider s Web portal to configure his or her weather alert service by specifying parameters of some user profile. The subscriber Web portal accepts the service configuration information provided by the subscriber (in this case, user profile details, including a list of contacts) and submits it to service activation. Service activation generates the service data for the user and applies it to the GUP server.
The GUP server updates the HSS with the service configuration information entered by the subscriber. Customer Configuration of Weather Alert Settings The user has been enrolled in weather alert service by a subscriber. The user goes to a service provider s Web portal to configure the weather alert service. The subscriber Web portal accepts the service configuration information provided by the user (e.g., call me on the mobile phone only, send alerts only to my landline, send to both landline and mobile) and applies it to the GUP server. The GUP server updates the HSS with the service configuration information entered by the user. Alert Service Triggering and Execution When the weather turns bad, the alert service running on the SIP server is triggered. The alert service refers to the service configuration information in the HSS to determine the list of contacts for the weather alert. Alert service on the SIP server calls the subscriber at the first contact in their weather alert service, but the subscriber does not pick up the call. At some point in the contact sequence, the subscriber is located at their mobile number by the SIP server and a live call is demonstrated. The SIP server sends a billing detail record to the simulated billing system. Conclusion Operators are under pressure to roll out new and differentiated services, NGN architectures need to support delivery of a variety of converged services, and the supporting OSS applications are required to enable the rapid introduction of new products and services. The reference OSS solution described here shows how using standards allows rapid introduction of new converged services. The solution uses the following key technology and domain standards: SOA framework (XML/SOAP, WSDL) Use of NGOSS contracts for service interfaces TMF SID for information/data model 3GPP GUP architecture References 1. Lean Development Applied to SO, Retrieved 2010-08-16. 2. Enterprise SOA. Prentice Hall, 2005 3. Erl, Thomas. Serviceorientation.org About the Principles, 2005-2006 4. Hoyer, Volker ; Stanoesvka-Slabeva, Katarina; Janner, Till; Schroth, Christoph; (2008). Enterprise Mashups: Design Principles towards the Long Tail of User Need. Proceedings of the 2008 IEEE International Conference on Services Computing (SCC 2008). Retrieved 2008-07-08.