Dr. Sorin Georgescu sorin.georgescu@ericsson

1. Advanced Paradigms for Building Convergent Next Generation Services. Service Composition and Service Brokerage in Multimedia Architectures Dr. Sorin Georgescu sorin.georgescu@ericsson.com

2. Agenda • NG Service Platform • Multimedia Services Ontology • Service Composition Patterns • Adding Semantics to Service Composition • Enhancing the Business Model through Service Brokerage

3. Next Generation Networks Evolution Drivers • Societal and Business trends • Internet is becoming a major enabler of communications • Consumers are embracing computing, mobile and digital technology in their everyday life • Evolution of Business models require increased levels of personal mobility • Convergence • Converged devices (Mobile, WLAN, Internet etc.)  Connectivity • Converged services  Ease of use • Converged networks  Reliability, Security, Reduced OPEX/CAPEX • Converged business models  Increased margins, Avoidance of twin pitfalls risk • Access Technology Enhancements • HSPA (High Speed Packet Access) – evolved WCDMA • OFDMA (Orthogonal Frequency Division Multiple Access) – 3GPP LTE, WiMAX, MBWA, ADSL/VDSL, DVB-T/H etc. • Spatial Processing – multi-antennas Base Stations supporting advanced spatial processing

4. Non-Interactive Multimedia Video Music Ring tone Movies Person-to-Contentknown usability patterns Photos Internet Streaming Interactive Multimedia Text/Pictures Download MultimediaContent HTTP Video SMS/MMS Active phonebook Person-to-Persondominates traffic growth Image Social Networking Text P2P Calls Voice Presence Push-To-Talk MMS SMS Voice The Evolution to Multimedia ApplicationsA Mobile View

5. IMS – 3GPP Architecture for Convergent Next Generation Services • IMS is an open IP-based architecture using the Client-Server Network Computing model. • 3GPP originally specified IMS to enable real-time multimedia services over the IP bearer, in GSM and W-CDMA networks. • Later, 3GPP2 specified the MMD architecture for CDMA2000 networks based on IMS. 3GPP2 requirements are part of Common IMS in IMS release 8. • The xDSL access, specified by TISPAN, is integrated into IMS. • The cable access, specified by CableLabs in PacketCable 2.0, is part of IMS release 8. • Interworking with WLAN was specified in IMS release 6, while the mobility with WiMAX has been addressed in EPC specifications. • If IMS is not used: • Multimedia communication at best effort • Service roaming can be difficult to implement • Provisioning and charging are service specific • Compliance with LI requirements can be an issue

6. IMS Service Routing – the IFCs • In comparison to IETF SIP Routing where the originator of SIP request may specify a preferred path in the Route header, in IMS the P-CSCF removes this path and ensures that IMS SIP Routing is followed. • SIP requests in IMS architecture are always routed to the Home S-CSCF, in both the originating and terminating network. • The S-CSCF uses subscriber’s Service Profile (downloaded during registration), to link-in the SIP AS’ which will process the SIP request. • The Initial Filter Criteria (IFC) within the Subscriber Profile provide a simple service logic to decide which AS shall be linked-in. These rules are of static nature i.e. they do not change frequently. IMS AS HSS Home B IMS AS HSS Home A 2 7 9 5 1 8 6 S-CSCF I-CSCF S-CSCF 4 10 Visited B Visited A P-CSCF P-CSCF 3 11 IMS Service Routing = Service Profile based Routing

7. Limitations of ISC Service Orchestration Model SIP-AS SIP-AS SIP-AS SIP-AS SIP-AS SIP-AS Req URI = A Req URI = B S-CSCF S-CSCF HSS HSS I-CSCF I-CSCF • The application server decides whether to remain linked-in for the whole session by adding its address to the Record-Route SIP header. • Application Servers are unaware of the existence of other AS', and whether these will be linked-in. • No service or session state will be passed between application servers unless they use proprietary extensions i.e. are co-designed. • Response messages are routed to the AS’s in the reverse order • If during call handling procedure an AS retargets the SIP request by changing the Request URI, subsequent filter analysis in the S-CSCF is stopped and the S-CSCF forwards the request towards the new target without linking-in the other AS’ specified by IFC. 1 2

8. NG Service PlatformThe IMS-based Design

10. NG Service PlatformFunctional Description • Service Composition: • Invokes the services published by external Service Providers which are interconnected in a Service Overlay Network. • Services can be linked in statically (BPEL workflows) or dynamically, using their semantic description (OWL-S) • Corresponds to the network-centric composition model => lower complexity of client implementation. • Service Mediation: • Mediates service protocols, data format, identity, security features, business processes • Service Brokerage: • Negotiates with other brokers in the Service Overlay Network the services which the Service Composition function will invoke. • Uses context information to bind services based on dynamic conditions. • Service Discovery: • Publishes local services and performs service searches in the Service Overlay Network. • Searches can be static (UDDI queries) or dynamic (UDDI queries with constrains, SWS Proxy queries).

11. Agenda • NG Service Platform • Multimedia Services Ontology • Service Composition Patterns • Adding Semantics to Service Composition • Enhancing the Business Model through Service Brokerage

12. User Interface and Applications Trust Encryption Proof Logic RIF/ SWRL OWL SPARQL RDFS RDF XML URI Unicode Semantic Web Stack Service Modeling using Ontologies • Gruber, 1993: • “An Ontology is a formal, explicit specification of a shared conceptualization of a domain.” • Formal = unambiguous, machine understandable, described using a formal language • Explicit = precise, clarifying the subject • Conceptualization = abstract representation of the object of study • Ontologies consist of a set of axioms which place constrains on classes of individuals, and the types of relationships allowed between them. • Can be described in graphical form (ex. RDF, UML) or logical form (ex. Description Logic, Rules). RDF/S = Resource Description Framework / Schema OWL = Ontology Web Language SWRL = Semantic Web Rule Language RIF = Rules Interchange Format

13. Multimedia Ontology Security Sub-ontology Services Sub-ontology Presence Sub-ontology Identity Sub-ontology Content Sub-ontology Context Sub-ontology Multimedia Services Ontology • Constructs of the ontology: • Syntactic/semantic description of offered services (WSDL/OWL) • Description of mediation functions that can be linked-in at run-time • Description of data published • Specification of communication protocols • Description of Service Composition framework. Should include, if applicable, the description of the language used to specify the semantic composition • Multimedia Services Ontology is a sub-ontology of Multimedia Ontology which is associated to Multimedia Communication domain. • Multimedia Ontology makes multimedia services provided by various Service Providers (Telecom, IT, Web 2.0) interoperable.

14. Agenda • NG Service Platform • Multimedia Services Ontology • Service Composition Patterns • Adding Semantics to Service Composition • Enhancing the Business Model through Service Brokerage

15. Service Oriented (SOA, Web 3.0) Message Driven (MOM) Components (Corba, EJB) Client/Server Distributed Computing Evolution Service Oriented Computing (SOC) • In SOC, applications are statically/dynamically composed using services deployed in the network. The collaboration model can be transactional (synchronous), or workflow-based (asynchronous) • SOA is one possible realization framework of SOC. The communication paradigm typically used in SOA is Web Services • Web Services are: • Published (WSDL, OWL, SWSF) • Deployed • Discovered (UDDI, WSMO) • Invoked (SOAP) Service composition types: Service Orchestration = centralized engine which coordinates composed services according to a set of rules (workflow specification) Service Choreography = multiple actors/agents participate at the implementation of service composition (orchestration between every pair of choreographers)

16. User / Service Profile Temporal context User context Ambient context Broker BPEL Composition Engine Rules Context Discover Service Discovery and Publication UDDI Publish Service Creation Environment Developer Studio End User Studio Service Oriented Computing (cont.)Static Service Composition

17. Tim O’Reilly Web 2.0 definition: • The Web as a platform • Leverages customer data management (mash-ups) and user interaction model. Hence the challenge is to own core data (presence, location, identity, namespaces) • Promotes service evolution through user contributions. • The API’s exposed are simple enough so anybody can innovate. • No more software release cycles. Services are permanently in beta release. • Syndication of data instead of control. The data owner is actually paid by the advertisers. • Multi-device client (ex. Google/Open Handset Alliance Android mobile platform) • Rich user experience Web 2.0 in SOC landscape

18. Social Applications Social APIs Application Service Enablers Transport / Control Layer Devices Social Network Diagram Web 2.0 Design Elements • OpenSocial highlights: • Based on open standards (XML, HTML, Javascript, ATOM and REST). Uses Google Gadgets FW. • Can be combined with OpenID (common identity framework). • Personal data moves from site to site. • Each API addresses one area: People & Friends, Activities, Persistence, General API. • Mashup highlights: • Aggregation of data centric network services using asynchronous interactions (AJAX) • Implemented with client/server or three-tier architectures: • Content/API provider: shares mashable data objects typically retrieved using RSS, ATOM, SOAP, REST interfaces or “Screen Scraping” • Mashup hosting site (in three-tier architecture): server which aggregates data using Java Servlets, CGI, PHP or ASP. • Mashup client: uses client scripts (JavaScript) or applets to allow support of Rich Internet Applications (RIA) • Data may be cached in the client device (SQLite) • Blogs, Wikis, IM & Chat • Buddy List, Mashups • Publishing, Content Sharing • Open APIs: REST, RSS, JSON, SOAP, XML • Widgets: OpenSocial, Web Widgets, Gadgets, Badges • Syndication: RSS, ATOM

19. Data Base Node Service Photo Storage Application Logic API Page Logic Endpoints Templates Flickr Appl Email Flickr.com 3PP Appl. Flicker Architecture Service Composition in Web 2.0 • Compared to BPEL/WSCI developer-centric composition, Web 2.0 uses ad-hoc composition. The user builds the composite service “on-the-fly” from data retrieved from the network. Mobile devices (Smartphones) now have 128MB of RAM and 620 Mhz CPU, so Web 2.0 clients can now be mobile. • Web 2.0 application design is performed by the end user who in essence, has low programming skills. The service composition is defined through interaction with a GUI. • Client controlled composition • Development: client components use APIs to access server data • Execution: components run on the client and pre-fetch data from the server • Server controlled composition (early stage) • Development: the server uses public APIs to link services into new services • Execution: the client invokes the server which acts as an orchestrator

20. SOA Service Description Model SOA Reference Model • What is SOA: • A paradigm which defines concepts and general techniques for the design, encapsulation and instantiation of reusable business functions using loosely coupled service interactions • SOA Reference Model: • Service • Service description • Interaction • Contract & Policy • Visibility • Execution Context • Real world effect

21. Client SOA Service Composition Routing based on service identity (equivalent to PSI routing in IMS) • SOA Characteristics • Services have well defined Service Contracts • Services are encapsulated • Services share a message bus and messages exchanged are well documented • Services can be discovered dynamically • Services are loosely coupled • Systems of services are assembled at runtime • Service bus functions: • Supports an asynchronous message based communication protocol that uses a common format encoding scheme (SOAP/XML) • Routes, Translates and can Store and Forward exchanged messages • Supports a Discovery mechanism

22. Service Contract SOA UDDI SOA AS Schema SOAP/XML MLP SIP Service Bus MM7 SB API SB API SB API Enabler IMS AS GW AS Orig. network CSCF IMS JSR 281 Heterogeneous Service Bus IMS-SOA Architecture IMS-SOA Architecture • Service Enablers: • Provide functionality which can be used by other end-user applications (ex. Location Service) • Unaware of the context in which they are used. Only the consumer service is aware. • Service Bus • Handles the communication between IMS Application Servers and the Service Enablers and the communication with SOA Application Servers. • Optimized for Server-to-Server communication • Besides providing support for standard open protocols (ex. SOAP), may provide support for Native Interface protocols (ex. MLP, MM7, SIP etc.) • Service Orchestration • The consumer AS that invokes the Service Enabler implements the SCIM function. An external Service Broker may be used as well. • IMS Service Enablers are invoked from SOA domain through the GW AS.

23. Parlay X Web Services WS-I Basic Profile: WSDL + SOAP WS-I Secure Profile: WSDL + SOAP + WS-Security • Parlay X Web Services is an abstraction of Parlay WS • Parlay X WS GW acts as a Service Broker SCIM • Enablers which only support WS-I Basic Profile are enhanced with additional WS functionality such as WS-Security, WS-Policy, WS-Addressing • Services defined so far (17) cover: call control, messaging (SMS, MMS), payment, location, geocoding and mapping, presence etc. • Described in WSDL. Service discovery is based on UDDI.

24. Agenda • NG Service Platform • Multimedia Services Ontology • Service Composition Patterns • Adding Semantics to Service Composition • Enhancing the Business Model through Service Brokerage

25. Service Profile presented by SWS Service Model implements Service Grounding interacts using Semantic Modeling using OWL-S SWS = Semantic Web Service The Semantic Web • Highlights: • Information on the Web is machine understandable => automatic service discovery, invocation and composition. • Modeled as a graph where nodes have semantic descriptions. In Web 1.0 and 2.0 node descriptions are only syntactic. • Uses ontologies to represent elements of a domain and their relationships (OWL-S, SWSF, IRS-III, WSMO) Non-semantic web tag: <item>cat</item> Semantic web tag: <item rdf:about=“http://dbpedia.org/resource/cat”>cat</item> Tim Berners-Lee, 2001: “The Semantic Web looks at applications that enable transformations, by being able to take large amounts of data and be able to run models on the fly - whether these are financial models for oil futures, discovering the synergies between biology and chemistry researchers in the Life Sciences, or getting the best price and service on a new pair of hiking boots.”

26. Semantic Execution Environment Composition Engine Communication Handler Semantic/Ontology Reasoning Service Mediation Matchmaker Web Service Discovery SWS Execution Engine • Performs semantic information processing and ontology reasoning in order to: • discover and select the matching service • mediate the data, the protocol or the business process associated to service invoked. • invoke the service • Supports both the orchestration and choreography paradigms • Data exchanged by SWS is described as an ontology. • Can be looked at as a SOA implementation which allows to add/remove components at run-time. Resource DB

27. Planning Graph Generation Enforced Hill Climbing Engine PDDXML plan description Goal Determination Connectivity Graph PDDXML Parser Topology Handler PDDXML problem, domain description Xplan-based Composition Y X X Z Z Y Planning Sequence - Set of actions - Pos./neg. effects - Initial state description - User’s goal Semantic Service Composition • Semantic Composition Paradigms: • Action Based: the Reasoner uses the semantic description of discovered services to match requester goal at each composition step (run-time). Execution takes place directly through the grounding of the services. • AI Planning: a task list is generated to achieve the composition objectives i.e. service selection and flow management. Compensation in case of failure and replanning is a challenge. Examples of AI Planning: Conditional Planning, Conformant Planning, Hierarchical Task Planning (HTP) • Hybrid (Xplan): Combines guided local search with graph planning and a light form of HTP to produce a plan sequence of actions. There is not yet a unifying framework to allow interoperability between intelligent agents / reasoning engines.

28. Agenda • NG Service Platform • Multimedia Services Ontology • Service Composition Patterns • Adding Semantics to Service Composition • Enhancing the Business Model through Service Brokerage

29. Service Provider offer use Service Description Service Consumer invoke ( ) bindTo ( ) contains description described in Service Broker find ( ) negotiate ( ) User / Service Profile User context Temporal context Broker Ambient context Context decisions Service Brokerage in SOC Why we need Service Brokers: • Users are interested to customize service interaction model and run-time features based on context conditions (Ambient Intelligence, Location, Privacy Preferences etc.) • Control of the payment model. Users who do not want adds and are rather looking into QoS and Security/Privacy, need a Service Broker function in the network which can negotiate the service characteristics with multiple service providers based on user profile. • Service Broker functions: • Ranks services offered by the Service Providers based on service characteristics. It may do this autonomously (rules based negotiation), or by interacting with the user • Matches the service interaction model with context conditions • Performs identity and trust brokering • Performs payment brokering • Handles synchronization between fine-grained services Google business model: Users accept advertising and profiling in return to free services. AsSense, AdWorks - advertisers/publishers or youTube - content providers/users, perform brokerage at business level.

30. IMS Payment Brokerage • IMS services standardized so far (MMtel, PoC, Image/Video Share) have been deployed in the operator domain as their target are the telecom communities (mass deployments). • Separate from these basic services, it is expected that many new community specific services (niche services) will be provided in the near future by Service Providers. These services use open communication protocols (instead of SIP) and do not handle charging of the user directly. Instead, they use their business and trust relationship with the operator, to delegate payment service. • The Payment Brokerage function facilitates the establishment of the business relation between 3rd Party Content/Service Providers and mobile operators. Payment Model • The roles in Payment Model are similar to those in Credit Card industry: • Consumer • Merchant = Content Provider who publishes, supplies and sells content. • Broker/Acquirer • Issuer = Mobile Operator. The Operator uses its existing billing relationship with the consumer to charge for content.

31. Conclusions • Recent deployments of Multimedia and VoIP services in the Telcom and the Internet domain, have determined a blurring of roles in the value chain while at the same time enabling new business models. • Next Generation Services Convergence requires: • Implementation of converged devices (multi-access devices) • Support of a multi-access edge network • Unified roaming and session management framework • Development of service enablers • Interoperability between the native Service Platform (SP) and external Service Overlay Networks • The SP Interoperability Middleware has to provide support for: • Service Composition and Brokerage • Service Mediation • Service Discovery • Service Platform features like Multimodal Interaction, Interaction Management based on Ambient Intelligence, Content Management, Brokerage and Management of Semantic Information are desirable due to their significant impact on service usability.

32. Thank you for your attention! sorin.georgescu@ericsson.com