Service Brokering: Opportunities and Challenges

Transcription

1 Introduction Service Brokering: Opportunities and Challenges Two developments offer new communications, information, and content delivery capabilities for responding to both business needs for increased productivity and consumer demand for exciting new services. Emerging from 3GPP and based on the SIP protocol, IMS promises new wireless, wireline, and multimedia network applications, with wireless and fixed/mobile convergence being early drivers of this technology. At the same time, ever-increasing numbers of web services based on the http protocol have already streamlined business activities and have made online activities a part of daily life. The challenge now facing our industry is successfully blending these capabilities to provide seamless end-user experiences aligned with the daily work and personal activities of end users. A key to meeting this challenge is our ability to deliver seamless combinations of IMS and web services. This involves feature interaction management among combinations of currently independent services, blending web and IMS/SIP applications, and providing the ability to define, provision, and support offers involving such converged applications. The general term for all of these functions is service brokering or blending. This paper will discuss Service Broker roles (note that we will use Service Broker as a generic term to describe many types of service blending methods), walk through various types of service brokering, discuss the shortcomings of the Service Capability Interaction Management (SCIM) concept as currently defined in 3GPP, address some fundamental requirements for a cross domain Service Broker which spans IMS and web Nicholas S. Huslak, Ph.D. and A.C. McQuaide, Jr. AT&T Enterprise Architecture 725 W. Peachtree St., Atlanta, GA USA nick.huslak@att.com / chet.mcquaide@att.com services, and outline essential steps in making the cross domain Service Broker concept a reality. This paper is based in part on a presentation [1] given at IMS/MMD (Dallas, TX USA) in November 2006 by the first author of this paper. Service Brokering Tasks and Approaches The Service Broker concept has begun to take shape in the industry, and agreement is gradually being reached on its two fundamental tasks: Service Execution Orchestration and Service Offering Coordination. Service Execution Orchestration ensures that (1) Applications can co-exist peacefully, which means that no application should be able to significantly harm the execution of another application; and (2) Applications can function collaboratively, which means that functionality can be delivered by a combination of applications that is not available from any one of them individually (in the same way that an orchestra delivers an auditory experience not possible with any single instrument). Examples of the two service execution orchestration functions are (1) SimRing / Voic and Call Waiting / Call Forwarding. We leave it as an exercise for the reader to think about how these two pairs of applications may interact poorly without supervision. (2) Linking voic to a web-based address book to allow the subscriber to respond to a voic with an , which is something that neither the address book nor the voic service could do independently. Figure 1 Features and Applications for Blending and/or Resolution 2007 AT&T Knowledge Ventures. All rights reserved.

2 Following up on the second of these examples, the orchestration part of Service Execution Orchestration refers to calling the applications in a particular order, introducing delays between application calls if necessary, performing database calls between applications, and/or performing other types of intervention. Such orchestration still requires service designers to define appropriate interaction logic in advance to deliver the intended constructive service interactions. The second major task of a Service Broker is Service Offering Coordination. This is the application packaging, provisioning, handling of deployment concerns, definition of management and maintenance procedures, usage of policy based decision making in the execution of the service, employment of load balancing techniques, and other operations functions necessary to appropriately package and offer blended services to users. Service Offering Coordination includes capitalizing on emerging networking and service architecture layer capabilities, such as the ability for applications to share use of subscriber data that is logically or physically centralized (for example in an HSS) and the use of application enablers such as those being developed by the Open Mobile Alliance [2]. Of the two major service brokering tasks, the balance of this paper will concentrate on service execution orchestration because of space limitations. Figure 1 on the previous page illustrates the range of SIP/IMS and Web Services applications that are candidates for blending in today s world. As an example, blending IPTV, caller ID, message notification, , IM, video conferencing, and telephony could transform the typical family room into the nerve center of the household. Such examples make it evident that Service Broker functionality must span both IMS/SIP and web services. Another aspect of Figure 1 is worth pointing out: service execution orchestration can take place at several levels. The features in the oval containing the Telephony applications (Call Screening, Sim Ring, etc.) can be orchestrated by the Service Broker, but may be handled by the application logic if they are all resident on the same telephony application server. In either event, another level of orchestration occurs when they are handled as a group against other SIP and Web Services. In fact, Service Brokering in general can be done at a number of possible levels (see, e.g., [3]). One possible decomposition is listed below. Basic IMS Session Control: This is service blending using standard IMS core elements using initial filter criteria (ifc) processing IMS Standard Service Capability Interaction Management (SCIM): The SCIM adds incremental capabilities to Basic IMS Session Control, including limited changes to ifc processing and ability to initiate AS and database dips without waiting for result returned from previous invocations. Note that this capability can be extended to include orchestration across multiple JSR 289 Servlets when all of the applications are running in the same runtime execution environment. Figure 2 Service Orchestration with Basic IMS Session Management

3 Business Rules / Policy Driven Orchestration: Loose scripting can be done across web services capabilities / applications by Business Process Execution Logic (BPEL) scripts in a Service Oriented Architecture (SOA) environment (not addressed further in this paper since this orchestration is limited to the Web Services environment). Converged Service Blending: This is the blending of SIP and Web Services, possibly using embedded lower level blending mechanisms on both the IMS and WS side. The balance of this paper drills down on the different types of Service Brokering mentioned above (except for Business Rules / Policy Driven Orchestration as noted). Basic IMS Session Control Figure 2 on the previous page illustrates service processing using only IMS core elements. An INVITE message is shown arriving at the S-CSCF. Initial Filter Criteria (ifc; 3 in this case) are downloaded from the HSS and matched against the incoming message. ifc #1 fails to match because it is looking for a different destination user. ifc #3 fails to match because it is looking for a SUBSCRIBE message going in the opposite direction. ifc #2 matches, and the call is routed to AS2 as a result. After service logic is processed on AS2, control is returned to the S-SCSF, at which time additional ifc processing (not shown in the example) may cause additional application servers to be invoked. This static, serial invocation of Application Servers is fairly easy to program, but falls short when blended service logic requires more sophisticated interactions among applications. IMS Standard SCIM The 3GPP standards provide a very high level definition of SCIM as illustrated in Figure 3 below (extracted from [4]). Basically, the standards position the SCIM as a specialized AS that is charged with interaction management. The SCIM to AS interface is IMS ISC, but vendors have added their own APIs/interfaces beyond what has been defined in standards. Other vendor extensions in the SCIM space add incremental capabilities to Basic IMS Session Control including: Database dips and ability to make asynchronous calls from SCIM to App Servers (i.e., initiation of an AS call without waiting for result returned from previous AS call) The ability to make limited changes to ifcs, including halting of processing after processing a particular ifc (on the next call, by altering the ifc list on the HSS; and on this call, by altering the set of ifcs already downloaded to the SCIM This type of service blending uses the ISC and other standardized interfaces, and stays within the IMS environment (i.e., no calls are made to invoke web services). However, note that several vendor SCIM products may soon implement HTTP listeners, which would upgrade these products into the Converged Services Blending category mentioned above. ifc processing sends a (new or unchanged) SIP transaction to the SCIM for invocation of a particular (typically complex) service. The SCIM may make several AS calls before returning control to the S- CSCF. Later ifc processing on the same session may result in another SCIM call to invoke another complex service. A further delineation can be drawn between Basic IMS Session Control and IMS Standard SCIM. In the former case, the CSCF deals with application servers that stand alone in providing service logic. In the latter case, the CSCF deals with a SCIM that does not stand on its own and is more like a pure scripting engine.!"# $%#&!'() *'+'+,-++. Figure 3 Standards Definition of IMS SCIM

4 A number of issues are not addressed or are addressed only partially in the brief text in the standards, including: Is SCIM a standalone function, part of an AS, or part of the S-CSCF? Does it handle SIP services only? What kind of interaction management does it provide? Does it provide support for 3rd party services, or must the applications be trusted ones provided by the carrier? The 3GPP recently released a preliminary version of a study of architectural impacts of IMS Service Brokering [5] that proposes various types of service brokering including (1) Centralized brokering, which is just today s SCIM; (2) Distributed brokering, in which service broker functionality is incorporated in a number of brokering-aware application servers involved in a blended service session; and (3) Hybrid brokering, in which peer Service Brokers in both of the first two categories are present. A requirements wish list was included that specifies that a service broker should be able to support the following capabilities: Have low impact on session handling from a performance perspective, including efficient interaction with application servers; Allow new applications to be easily introduced; Resolve interactions between IMS applications, non-ims applications, and enablers; Support service integration across various network types, across multiple application server providers, across multiple application servers, between SIP and non-sip applications; and with existing IN services; and Allow users to personalize and control their services. Finally, a section on improvements to the ISC interface (supported both northbound and southbound from the Service Broker) suggests the following enhancements to that protocol: Allow call to terminate to a different user without losing application servers involved in the routing; Handle batches of services that include potentially incompatible service combinations by introducing compatibility classes ; Improve error handling by allowing ifc processing to continue calling application servers in some cases rather than immediately clearing the call; Support additional service triggering points, some of which would take endpoint capabilities into account; and Allow multiple service invocations in one SIP transaction. Work items resulting from this study have the potential to go a long way toward making 3GPP SCIM standards complete and usable. Converged IMS / Web Services Blending Figure 4 below illustrates a Cross Domain Service Broker or Meta Service Broker as one of several key enablers (green blocks) for providing users with seamless access to combinations of Web and IMS services. Note that the ovals in the IMS and Web Services Platform blocks are intended to represent middle layer components that are specific to those blocks rather than being available across the domains (for example, the SCIM on the IMS side and an Orchestration function on the Web Services side are examples of such components). Actual implementation of a Cross Domain Service Broker product is a large undertaking that only a few vendors in the industry have tackled in a significant way. As mentioned above, some SIP Applications Converged / Blended Applications Web Applications OSS / BSS Environment Meta Service Broker Notification Server O S IMS IMS IMS-Specific middle layer components Location Server Presence Server Policy Server Security Services WSP WS-Specific middle layer components IMS Interfaces WS Interfaces Figure 4 Brokering of SIP and Web Services

5 vendors of IMS Service Brokers are considering an initial step of adding http listeners to their product in order to expand the range of inputs that can be accepted. Full support of seamless blending of Web and IMS services will require much more design and implementation work. Data Modeling for Service Brokering A key topic in the design process for a Cross Domain Service Broker is how the numerous types of data and their interrelationships can be structured in a comprehensive, cohesive, and coherent way. Such a model needs to address the relationships between users and their sessions, the various applications involved in a session, the different applications making up a marketed package, and perhaps most importantly, how the various types of interactions between applications should be modeled. Figure 5 below shows a Unified Modeling Language (UML) artifact for modeling of the data required in a Cross Domain Service Broker. UML conventions call for related data objects to be joined by a solid line and explanations of the relationship between the objects and their cardinality. For some of these relationships (especially when they have a many-to-many relationship), dotted lines lead away from the inter-class line to a correlation class that documents the relationship between pairs of elements in the two related classes. The extensive class model shows the two fundamental types of applications (IMS and Web) as examples of a generic application class. In the case of application, the correlation between two instances of applications is an instance of the interaction class, which can be any one of four types (Web-Web, IMS-Web, IMS-IMS, and Web-IMS). The right hand side of the class diagram shows the extensive structure joining sessions, users, packages of features, and subscriptions. Making Cross-Domain Service Brokering a Reality To meet the needs of service brokers, the architectural foundations of the Cross Domain Service Brokering must be laid carefully, ideally on an industry standard basis. The following list shows some of the necessary steps along the path to that reality. A uniform approach to coordinating application server and database calls is needed, including agreements on usage of presence and location information. Standard interfaces must be used everywhere in this approach. The ability of the Service Broker to converge web and SIP/IMS services must become a common objective. Variations in vendor definitions of service, feature, and application need to be harmonized in a standard taxonomy; i.e., one that will allow blending at the various levels mentioned in Figure 1 (including blending between individual telephony features, between groups of IMS features, and between IMS/Web services). SCIM interaction WS Orch. interaction Converged interaction Subscription is a Interaction Package 1 * 0..* User is a part of subscribes to is invoked by involves 0..* Feature 1 * interacts with contains 1 is part of Application Provider 2..* includes 0 * includes invoked in is involved in Session 0..* is a IMS Application Web Application App/Session Linkage User/Session Linkage Figure 5 Data Modeling Required for Service Brokering

6 The service offering orchestration (packaging, provisioning, etc.) side of Service Brokering needs further definition and alignment between vendors. Data modeling - to ensure that all of the stakeholders concerns are being met - must be at least investigated, and standards may need to be developed in this area. To make all of this happen, substantial cooperation is required among all key stakeholders, including individual carriers/operators, vendors and standards bodies (e.g., 3GPP, 3GPP2, OMA, ITU, MSF, IMS Forum). Finally, once the products are built and the service designers have had their chance to exercise their talents on the new platforms, prototyping and interoperability work is needed to validate the Service Broker products and demonstrate their value in delivering blended services to the marketplace. CONCLUSIONS Service Brokering offers many opportunities for all of the stakeholders (network/service providers, equipment vendors, ISVs, and customers). The following is a partial list of the opportunities and issues. The ability to create and deliver compelling service blends to business and consumer/mass markets could have great commercial value, supporting solutions which address business problems and responding to consumer needs and interests. Service execution orchestration capabilities of the Service Broker ensure that applications can co-exist peacefully and function collaboratively, allowing a set of applications to be blended so that the total effect to the subscriber (and network operator) is greater than the sum of the parts. Service broker capabilities which span IMS and web services are critical to meeting this opportunity, but are not yet in place. The IMS Service Capability Interaction manager (SCIM) defined in 3GPP standards is not yet adequately defined, but the current work effort in 3GPP may address these shortcomings. Industry cooperation is required to lay the foundations essential for Cross Domain Service Broker capabilities needed by today s service providers. Prototyping and interoperability events can validate the Service Broker concept and architecture, and demonstrate the value. References [1] Huslak, N., Service Brokering from a Carrier s Perspective, Presentation at IMS/MMD Dallas, 02 November [2] OMA Release Program and Specifications: Overview of OMA Release Program OMA Enabler Releases, Open Mobile Alliance, ram/ [3] Service Orchestration: The Key to Telco SOA, Light Reading s Service Software Insider I, Vol. 2, No. 2 April 2006 [4] Core Network; IP Multimedia (IM) session handling IM call model: Stage 2 (Release 7), 3rd Generation Partnership Project Technical Specification V7.0.0, December [5] 3GPP TR V0.5.0 ( ); Technical Specification Group Services and System Aspects; Study on Architecture Impacts of Service Brokering; Release 8; 3rd Generation Partnership Project, May 2007.