Ericsson Composition Engine Next-generation IN

Transcription

1 Service-layer solution for, IMS, other service technologies 22 Ericsson Composition Engine Next-generation The evolution from circuit-switched intelligent networks toward IMS, the internet, and the web requires an open platform that can seamlessly and efficiently integrate legacy and new services. J örg N i e möl l e r, Ioa n n i s F i kou r a s, F r a n s de Ro oi j, Luc a s K l o s t e r m a n n, U l f S t r i nge r a n d U l f Ol s s on The evolution from traditional circuit-switched intelligent networks to an open IMS service layer, and the integration of commercially successful internet services, such as Web 2.0 social networks, require new strategies and investments in new technologies. Leveraging the existing subscriber base and legacy investments is critical in this evolution. The Ericsson Composition Engine provides an environment for managing feature interaction among intelligent networks, IMS, and internet services; it also enables the creation of converged and differentiating s. Service composition technology makes it possible to manage interaction issues between heterogeneous platforms and features, allowing for easy creation and reuse of functionality and mediating between technologies. BOX A ACE AJAX ARI BICC EA EJB ESB ETC IMS IM-SCF IM-SSF S ISC ISDN ISUP The core infrastructure of many of today s networks has entered a transition phase, as users have begun migrating from classical circuit-switched (CS) networks toward IP Multimedia Subsystem (IMS)-controlled networks. Protecting investments in the intelligent network () service infrastructure of the circuit-switched network and preserving a good user experience for subscribers requires an evolution not a revolution toward the new architecture. services are frequently complex and costly to develop and integrate. And given that circuit-switched and IMS networks can be expected to coexist for many years, it makes good sense to reuse services within an IMS context where applicable. The services a user is familiar with should migrate with the user toward the new network technology. In this context, existing services can be reused as they are and integrated with IMS. Alternatively, existing services can BOX b CAP, CAMEL and AP CAP is short for CAMEL part. CAMEL is short for customized s for mobile networks enhanced logic. AP is short for intelligent network part. Terms and abbreviations Advanced Composition Engine asynchronous Javascript and XML assist request instructions bearer-independent call control execution agent enterprise JavaBeans enterprise service bus establish temporary connection IP Multimedia Subsystem IMS service control function IMS service switching function intelligent network intelligent network server IMS service control integrated services digital network ISDN user part JBI JCA JEE JSR NG- OCS RMI SCP SRF SS7 SSF VPN VXML WS Java business integration Java cryptography architecture Java platform, Enterprise edition Java standardizations request next-generation intelligent network online charging system remote method invocation service control point session initiation protocol specialized resource function signaling system 7 service switching function virtual private network voice extensible markup language web service be combined with newly developed components and evolve to true IMS or converged services, thereby profiting from evolved network and terminal capabilities. The approach of choice needs to be motivated on a case-by-case basis. Also, the ability to enrich existing or evolved services by combining them with services from web and internet domains will give rise to even more attractive services with a superior user experience. Of course, new IMS services should be implemented to serve IMS users as well as the still larger base of circuit-switched subscribers. The Ericsson Composition Engine can help implement advanced IMS services that, in principle, are also accessible to circuit-switched subscribers. Consequently, operators can avoid new investments in legacy technology and services become independent of the access technology, which is a big step toward communication anywhere. Ericsson s approach to evolving the circuit-switched service layer is to provide an open multiprotocol service platform that can be used for pure circuitswitched services, pure IMS services, and converged services. Furthermore, it provides advanced capabilities for integrating existing circuit-switched services with IMS. As realized by the Ericsson Composition Engine (ECE), Next Generation (NG-) offers an efficient evolution strategy that, in many instances, avoids implementing and maintaining multiple variants of the same service within separate domains. Instead, it allows existing services to be reused to serve the new IMS user base, making use of a wide range of versions that implement the service. A main requirement put on the service layer is the ability to use open technology. C_209a.indd

2 23 Accordingly, the Ericsson Composition Engine is based on the Open Multimedia Platform framework10, which provides a Java EE/JSR289 environment derived from the SUN Glassfish Communication Server. Operators today are under increasing pressure to differentiate themselves and to provide clear value to their customers, not only in traditional settings but also by embracing new internet services such as Web 2.0 communities. One way of easily achieving differentiation is to combine vertical services, such as telephony, messaging, location, IPTV, push-to-talk, and presence. Likewise, operators can capitalize on the popularity of internet services by integrating them into new types of telecom mashups realizing typical longtail s. Consider a location-based weather forecast service that is triggered by a push-to-talk voice message: a composite service of this kind could reuse existing telecom enablers, such as push-totalk, location, and messaging, while adding internet weather forecast and online map services to the mix. The Ericsson Composition Engine enables operators to efficiently implement and deploy telecom mashups of this kind for circuitswitched and IMS users. Next-generation architecture Session initiation protocol () and services differ both in protocol syntax and corresponding protocol state models. Therefore, they are, as part of a user session, invoked in very different ways. services are directly linked into the signaling chain and have full control of the user session. services, by contrast, are kept apart from the call session and maintain a control relationship that is limited by the protocol capabilities, mechanisms, and triggers defined for. Further, due to the nature of standards, business logic is intertwined with protocol-handling logic and protocol-determined state machines. Consequently, use cases that incorporate multiple service technologies require more than the basic mapping of signaling and session state; indeed, any integration between and services based on the latest technology also require a significant portion of the business logic that applies to the s at hand. Figure 1 Ericsson Composition Engine architecture integrating IMS,, and the web. Services in the public internet AJAX SCP other vendor Web service Services on enterprise service bus SOAP server SCP Ericsson AP, CAP, Advanced composition engine SSF stack AP, CAP, Circuit switched (CS) core ISUP /BICC MMTel server IP Multimedia Subsystem (IMS) core CS/Legacy domain Figure 2 JSR 289 IMS service control (ISC) interface Service switching function (SSF) ISUP /BICC Converged JEE/ server SCF stack AP, CAP, IMS domain The Ericsson Composition Engine bridges technology worlds. Services in the public internet services Services on an enterprise service bus AJAX Multimedia telephony (MMTEL) MMTEL /CAMELservices Composition engine Service database JEE/JSR 289 CS networks IMS network Internet C_209a.indd

3 Service-layer solution for, IMS, other service technologies 24 The Ericsson Composition Engine provides the basis for Ericsson s nextgeneration. It is based on an open Java EE server platform for circuit-switched and IMS-triggered services. Advanced composition features make it possible, using a single trigger, to combine locally or remotely deployed services of different technologies in a single composition. The Ericsson Composition Engine is a superset of functions and concepts introduced by 3GPP, including the IP server (-AS); S service capability interaction manager (SCIM); IMS service-switching function (IM-SSF); service control function (SCF); and trigger interaction manager (TRIM). It can handle the protocols used on the web as well as the service layers of the circuit-switched and packet-switched (PS)/IMS domains. The aforementioned intertwining of protocol capabilities and service business logic requires a high degree of adaptability from an IM-SSF solution. Flexible alignment and integration of the IM-SSF with services is thus a key feature for converged scenarios. The Ericsson Composition Engine approaches this requirement by providing IM-SSF functionality via the server platform. With the toolset available on this platform, Ericsson can tailor IM-SSF functionality to the unique needs of the integration use case at hand. This integration strategy is in clear contrast to a hypothetical solution that favors a generic IM-SSF node as a gateway between circuit-switched and IMS domains. A node of this kind would provide a com- BOX d prehensive but static set of SSF functionality, thereby failing in practical integration cases. The Ericsson Composition Engine presents an innovative solution to resolving the feature-interaction issues that arise from the composition of services coming from heterogeneous network domains. Composite services require featureinteraction support and are implemented as a custom mediation function that considers the complete communication needs of the constituent services. The Java Enterprise Edition (JEE) server and container (JSR289) form the basis of the solution (Figure 1). are integrated via the Java API for XML web services (JAX-WS JSR224). The platform integrates CAP/ AP via the Java connector architecture (JCA). protocol stacks implement an SSF role that makes it possible to use legacy services in the composition logic that resides on the platform. In addition, the protocol stacks expose the server as a service-control function (SCF). Services implemented on the server can thus be exposed to the circuit-switched domain as services. The protocol stacks take care of lowlevel protocol operations, such as the coding and decoding of messages and parameters. They also support mediation, but they alone should and do not implement complete service-logic-specific communication procedures and service interaction. The idea is to clearly separate toplevel service logic (such as business logic) from support components (such as the protocol stacks that provide control communication capabilities). Nevertheless, in order to provide the best user experience, SCIM The service capabilities interaction manager (SCIM) is an entity in the service layer of IMS that was introduced by 3GPP as part of the REL-5 version of the 3G network.8 Capabilities interaction management refers to the coordinated execution of services. SCIM is an additional layer between the S-CSCF and servers, interfacing the S-CSCF and the AS through an IMS service control (ISC) interface. SCIM is sometimes considered to be a stand-alone entity. The functionality applied by SCIM is also referred to as service brokering. BOX e box c IM-SSF The IM-SSF is specified by 3GPP as part of the REL-5 version of the 3G network. The IM-SSF serves as a -AS toward the IMS core network. Out going or incoming sessions from an IMS subscriber who subscribes to legacy services are routed through the IM-SSF, which translates signaling from the S-CSCF into CAP signaling toward the SCP. The concept of reversed IM-SSF or IM-SCF is also sometimes introduced to address the opposite use case, exposing the server as a service control function (SCF) to the circuit-switched network. TRIM The trigger interaction manager (TRIM) is a logical entity that distributes a single trigger from the circuit-switched core network over multiple servers. TRIM targets service distribution in the circuit-switched network and contains logic that identifies which services are to be invoked for a particular call. TRIM may, for example, be used to combine VPN with Personal Greeting Service in one call. BOX f services must be aware of the capabilities provided by the underlying networks. Ericsson NG services products are typically realized as Java s in the environment described above. Ericsson and third parties also use this environment for custom service development. The Ericsson Composition Engine supports interaction with IMS Multimedia Telephony (MMTel). Ordinarily, the IMS core invokes services either before or after MMTel service invocation. The introduction of the Ericsson Composition Engine adds two additional integration points to Ericsson s MMTel solution. The Ericsson Composition Engine can receive indications from the MMTel service logic and provide information regarding further routing of the call. It can also influence the execution of MMTel services by adding an information element in the IMS service control (ISC) channel. This mechanism enables ECE-based service composition with, for example, the included MMTel-terminating service but without MMTel call forwarding. Advanced service composition is a function in the Ericsson Composition Engine that makes it possible to handle feature interaction between services that run on different platforms. Equally important, it creates and executes workflows by instantiating the abstract descriptions of the composite service (Figure 2). Service-composition technology, as provided by the Advanced Composition Engine (ACE), targets integrators, enabling them to quickly adapt or real- MMTel The IMS multimedia telephony service (MMTel) is an IMS standard that enables real-time multimedia communication with the characteristics of a telephony service over fixed broadband, fixed narrowband, and mobile access. Converged, fixed and mobile real-time multimedia communication is achieved using media capabilities such as voice, real-time video, text, file transfer and the sharing of pictures, audio and video clips. C_209a.indd

4 25 ize new adapted business offerings from existing services. Advanced composition follows SOA principles, and essentially extends the SOA tooling to the IMS and SS7 worlds. facilitates the rapid and dynamic implementation of customized mediators without having to write, generate, or compile classical source code.6 This approach to service composition flexibly reuses existing service components and combines them with new functionality. Most mediation tasks can be covered by pre-designed services (for example, translating user addresses between and circuit-switched addressing schemes) from an existing component toolbox. is technology-agnostic and allows components from different platforms and technologies to be mixed within a single composite service. It currently supports services, -based services, SOAP/web services, and JSON RESTful services. Further technologies can be added efficiently without changing the core composition concepts or the way in which composite services are designed. helps developers to reuse functionality they need only define the functions to be included in the composite service, and related dependencies and constraints. selects, in run-time, the constituent services to be executed and maintains the overall composition session context. Constituent services are selected by matching developer-stipulated requirements and constraints with the current system state and the service descriptions stored in a service repository. The accumulated state in a composite service enables the management of service interaction between constituent services across technological borders. Rather than being based on protocol abstraction, the full network triggering context, including network addressing information, is available in the composition context. Any protocol parameter can be used as input for decisions or as input for services used in the composition. Mediation functionality can be added to the composition through components that use the shared state for example, a component that translates the user address received in an AP mes- sage into a user ID. To summarize, advanced service composition BOX g SOAP, JSON, RESTful nables s to react flexibly and e to tolerate changes in the environment such as different deployment, multitenancy, system load, and system faults; dynamically selects the services to be included in the composition at the time of execution. This gives a more flexible reaction to run-time conditions than a solution that is based on pre-defined workflows; provides a toolset for managing interaction between services that originate in different technological worlds; and enables efficient adaptation to the requirements of new use cases while reusing large parts of previous work. SOAP is short for simple object access protocol. JSON is short for JavaScript object notation. RESTful is short for representational state transfer. BOX h S-CSCF and IFC S-CSCF is short for serving call session control function. IFC is short for initial filter criteria. Graphical creation environment for composite services Advanced service composition is carried out through a graphical development environment that integrates graphical creation tool for modeling a composite services; a monitoring and debugging environment for composite services; front-end to the service repository; and a an environment for deploying and managing the compositions on the Advanced Composition Engine. Next-generation use case The following example, which originates from a recent customer proof of concept, demonstrates an IMS-triggered /SS7 composite service involving on-line charging and VPN control implemented in the circuit-switched network. The limited ability of the core network setup to address number normalization and to filter emergency numbers as required for the use case at hand causes an exceptional implementation. In this respect, the example shows how easily the Ericsson Composition Engine can address integration-specific requirements. It is important to note that the integration of a VPN service with IMS and online charging does not need to be realized as described in this example. In particular, Ericsson s VPN service is already integrated with online charging, and to fully profit from network and terminal evolution, it will evolve to be integrated Figure 3 Example composition skeletons (originating and terminating) for realization of the use case. Start NN_VPN_O Start NN_VPN_T Skeleton Id: VPN_NN_OCS_orig Constraint: ServiceReference= NN_VPN_o Skeleton Id: VPN_NN_OCS_term Constraint: ServiceReference= NN_VPN_t Number normalization Number normalization Constraints: (Function=NN) Constraints: (Function=NN) Emergency NR check Virtual private network $( sip_request.to)= 112 OR $( sip_request.to)= 911 Constraints: (Function=VPN) AND (NT=IMS) FALSE Virtual private network Constraints: (Function=VPN) AND (NT=IMS) TRUE End End Online Charging Constraints: (Function=OCS) AND (NT=IMS) End C_209a.indd

5 Service-layer solution for, IMS, other service technologies Vinjett 26 with IMS directly. However, this customer example demonstrates the ability of advanced service composition to seamlessly integrate circuit-switched/ and packet-switched/ims services within a single. Example: Subscriber A, who has an assigned VPN group (for example, a short-numbers group for family members), calls Subscriber B, who also has an assigned VPN group. When Subscriber A calls an emergency response number (such as 112 and 911), the Ericsson Composition Engine only invokes the number normalization service; that is, it skips the VPN and online charging service, and forwards the VITE to the core network immediately after the number normalization sends back the VITE. The number normalization service handles special numbers like emergency numbers by inserting a location suffix in the B-number in order to redirect the call to the correct emergency center. Figure 3 shows the composition skeleton for the above example. Using either of these services, the composite service handles user interaction, releases the call, or both. The services can perform user interaction without involving the composition. In the paradigm, releasing the call implies that the next service is not invoked. In this example use case, there is no need to act on subsequent events ( answers) in the composition, because there is no need to link new services or web services based on the occurrence of these events. The skeletons are only executed at VITE. The two composition skeletons in Figure 4 are for the originating side (left) and the terminating side (right). A check is performed on the originating side to determine if an emergency number has been called. This check determines whether or not the VPN and online charging service should be triggered or bypassed. The VPN is always used in the terminating case. The constraint in the top element of the skeletons represents the selection of composition based on information stored in the S-CSCF/IFC and passed on in the AS uniform resource identifier. Figure 4 shows the high-level architecture for -triggered compositions. The execution agent (EA) integrates the Advanced Composition Engine with Figure 4 High-level architectural view of -triggered compositions with and SS7-based services. Focus is on the call/session control part. Multiservice composition engine Online charging Ro OC integration EA AP EA Number normalization AP VPN AR if J EE AS (including JSR289 container) ISC S-CSCF the container and services. The online charging integration service is a locally deployed service that integrates with online charging via Diameter. User interaction may be a factor for both VPN and online charging integration services. However, only the VPN user interaction is visualized in Figure 5. An establish temporary configure 5 GW SRF nection (ETC) message from the VPN is mapped by the AP EA into setting up a dialogue using the E164 address in the ETC. The VITE is routed by the IMS network via a circuit-switched/ims gateway to the specialized resource function (SRF), which contacts the VPN via an assist request instructions (ARI) message. An alternative approach is to chan- Concepts of IM-SSF, TRIM and SCIM. Service conrol point (SCP) Service conrol point (SCP) Trigger interaction manager (TRIM) server server ISC () ISC () IMS service switching function/ IMS service control function (IM-SSF/IM-SCF) ISC () IMS service capabilities interaction manager (SCIM) ISC () ISC () ISC () SSF Circuit-switched core Circuit-switched domain IMS core Packet-switched/IMS domain C_209a.indd

6 27 nel all user interaction via an IMS MRF and have the VPN map user announcement IDs in the ECE. Figure 5 also shows the difference between the and paradigms: services are added to the signaling chain, whereas services maintain a control relationship with the actual call session in the network. Summary and outlook Ericsson NG- is a composition platform that can handle the various protocols used in the web as well as the service layers of the circuit-switched and packet-switched/ims domains. In addition to supporting migration use cases between circuit-switched/ and packet-switched/ims, the concepts presented in this article allow operators to realize new and IMS services and to enrich existing services with services from web and internet domains. The Ericsson Composition Engine (ECE) is an innovative solution to abstracting and resolving the feature-interaction issues that result from the composition of services coming from heterogeneous network domains, as part of the evolution toward IMS and internet services. Further, it enables operator-specific service orchestration. The architecture of the Ericsson Composition Engine enables IM-SSF, reversed IM-SSF, SCIM and TRIM use cases without being restricted to a pure brokering node or to compositions based exclusively on call-control protocols. Existing services can be flexibly reused and combined within new contexts. This is supported by a service composition framework that enables mediation between service components across technological borders. Jörg Niemöller, Lucas Klostermann, who joined Ericsson in 1998, is Senior Researcher at the Ericsson Research Service Layer Technologies unit. His current focus is on techniques for composing and managing services within a converged next-generation service layer. Jörg has held several positions in system management and research while working on solutions for the mobile core network, charging, and billing. He holds a M.Sc. in electrical engineering from the University of Dortmund, Germany. who joined Ericsson in 1997, is Solution Architect of the Ericsson Composition Engine product, and an Expert in multimedia architecture and technologies at Business Unit Multimedia. He has been an active driver of using open technologies in the service layer as well as past Parlay/ParlayX products. In his previous life, he obtained a Ph.D. in high-energy physics after a four-year stay at CERN, Geneva, Switzerland. Ioannis Fikouras is the initiator and main driver of SOA and service composition research at Ericsson. His research on service composition led to the prototyping of multiservice composition and, later, its production as part of the Ericsson Composition Engine. Ioannis holds an M.Sc. in computer science and a Ph.D. from the University of Bremen, Germany. Frans de Rooij, who joined Ericsson in 1990, is a Strategic Product Manager at Business Unit Multimedia, where he is responsible for the Ericsson Composition Engine. Frans has held a number of R&D positions while working in the Intelligent Network domain. Over the years, he has worked with the AXEbased platform, followed by the TSP-based Intelligent Network Server, and now, the Next-generation platform, Ericsson Composition Engine. Ulf Stringer has worked in the telecom industry since 1987 and joined Ericsson in He is a Strategic Solution Manager for Multimedia Solutions at Ericsson Global Services, working with NG- and SDP solutions. Before joining Ericsson, Ulf spent 10 years developing public safety and solutions at TeliaSonera in Sweden. Ulf Olsson has a background in software architecture for distributed military command and control systems. He joined Ericsson in 1996, mainly to work with architecture issues concerning packet-based systems (PDC, GPRS, UMTS packet and the CDMA 2000 packet core network). He is a Senior Expert with the Systems Management group, Business Unit Multimedia. His professional focus is on IMS, enterprise and developer-oriented issues. Ulf holds an M.Sc. in engineering physics from the Royal Institute of Technology, Stockholm. References and trademarks 1. Introduction to IMS. Ericsson white paper, March Olsson, U. and Stille, M.: Communication services The key to IMS service growth. Ericsson Review, Vol. 85(2008)1, pp MMTEL a standard for multimedia services over IMS. Ericsson white paper, July Services in the IMS Ecosystem. Ericsson white paper, February TS v rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Network architecture (Release 8), September Dinsing, T., Eriksson, G., Fikouras, I., Gronowski, K., Levenshteyn, R., Pettersson, P. and Wiss, P.: Service composition in IMS using Java EE servlet containers. Ericsson Review, Vol. 84(2007)3, pp Rogier Noldus et al.: IMS multi-access, single core, consistent service delivery. IC TS v rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Network architecture (Release 8), September Next-generation intelligent networks: migrating to IMS. Ericsson white paper, June Bo Andren: Open Multimedia Platform Framework. Ericsson Review No 1, 2009 Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. C_209a.indd