Submitted To: REG WG Date: 06 October 2011

1. Submitted To: REG WG Date: 06 October 2011 Availability: Public OMA Confidential Contact: Francesco Vadalà (REQ Chair) Source: Corrado Moiso, Francesco Vadalà (Telecom Italia) OMA-REQ-2011-0176-INP_High_level_reqs_for_SDPHigh level requirements for Service Delivery Platform (SDP) X USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT. THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS. Intellectual Property Rights Members and their Affiliates (collectively, "Members") agree to use their reasonable endeavours to inform timely the Open Mobile Alliance of Essential IPR as they become aware that the Essential IPR is related to the prepared or published Specification. This obligation does not imply an obligation on Members to conduct IPR searches. This duty is contained in the Open Mobile Alliance application form to which each Member's attention is drawn. Members shall submit to the General Manager of Operations of OMA the IPR Statement and the IPR Licensing Declaration. These forms are available from OMA or online at the OMA website at www.openmobilealliance.org.

2. Introduction • On 27 September, TP Chair has sent an email to REQ mailing list, with subject “Requesting your input - SDP requirements for ITU-T workshop presentation” and stating: Dear members of REQ, In October, OMA is invited to speak at the ITU-T SDP Workshop. The topic of the OMA presentation will be the recent progress and achievements in standardization for service enablers, and requirements for future SDP (Service Delivery Platform) standardization activity. I have started preparing the draft presentation. To add the next level of content, I would like to solicit the input from REQ on any requirements for future SDP standardization. There are many definitions for SDP, but is understood to include components such as: • Service creation • Service execution • Enabler exposure • OSS/BSS integration • Charging • etc I would greatly appreciate if I could receive a consolidated REQ response on requirements for SDP standardization, either from work items currently under development or requirements still under consideration. I would appreciate your input, if any, by Monday October 10th. Please let me know if you would like me to attend one of the upcoming REQ calls to provide more background. I’d also be happy to engage in further discussions on the REQ exploder. Thank you and kind regards, Musa Unmehopa – TPC • This input aims to address such request from the REQ point of view

3. Context • Currently, OMA REQ has no dedicated SDP WIs. • Nevertheless, taking into account the following key topics (list not exhaustive) on discussion/working in OMA: • Current Status of API Launch (e.g. Key Findings from SDP Global Summit, Berlin 20-22 Sept, 2011) • All-IP BoF activity and report as well as All-IP Workshop in Sorrento (February 2010) and in Las Vegas (July 2010) • Activity aiming on bridging mobile and Internet worlds (e.g. MobSocNet) • Trends in new business models and technology • E.g. move from the telco to the Internet paradigm • Etc. • … it is possible to identify some insights for future SDP standardization from the point of view of the main standard body for service level (i.e. OMA).

4. Around the Service Delivery Platform (1/2) • A Service Delivery Platform (SDP) is a framework for the design of a “horizontal” Service Layer supporting the integration of service platforms deployed on the Telco Operator’s infrastructure by means of the sharing and interworking of service enablers and service functions. • An SDP makes easier the development and the delivery of services defined by combining several enablers, which may be related to different service types (e.g., voice, content-based, messaging). • An SDP can be used by Telco Operators to deliver internal services to their customers and to expose some of the service components to 3rd party service providers through Network APIs. • In the Internet domain the service concept and the service composition concept mainly refer to contents; the availability of a variety of sources of information and services (e.g., RSS Feed, Atom, contents related to Social Network) in the Web 2.0 world leads to the need of tools for the rapid creation of applications called Mashups (a.k.a. Composite Services) that combine these different sources of information and services.

5. Around the Service Delivery Platform (2/2) • The deployment scenario is then twofold: • composite services, that are executed on application servers internal to the Telco Operator SDP, access service internal components and components provided by 3rd part service providers; • composite services (mashups), that are executed in the open Internet domain, take advantage of the enablers and/or of other services offered by Telco Operator to 3rd party domains (e.g., as service components through Service Exposure). • Moreover, specific examples of applications or service components are those running in the devices • E.g., such service components may expose their functionalities through Device APIs • E.g., such applications are downloaded by a store, installed and executed in the devices, and such applications may invoke at run-time Network APIs exposed by Telco Operators. • Finally, composition of service components provided by different service providers requires the development of payment models. • These must consider the involvement of at least three actors: the provider of the composite service, the provider of the service component and the end-users involved in a service session. For instance, it is necessary to consider the payment options when a service component is executed “on behalf of a specific user”.

6. Potential requirements for future SDP standardization • SDP to support the twofold scenario: • composite services, that are executed on application servers internal to the Telco Operator SDP, access service components provided by 3rd part service providers; • composite services (mashups), that are executed in the open Internet domain, access enablers and/or of other services offered by Telco Operator to 3rd party domains. • SDP to support service components and 3rd party applications running in the users’ devices • SDP to support dynamic offering, negotiation and subscription for accessing the exposed service components: • an open service marketplace requires high level of flexibility and automation; • SDP to support dynamic update of policies for protecting the exposed service components (e.g., policies on load control), according to the changes to the active subscriptions; • SDP to support dynamic mechanisms for optimizing the allocation of resources according to the requests of the applications, and for guaranteeing a fair usage of them in the open marketplace. • SDP to support flexible payment model, e.g. when a service component is executed “on behalf of a specific user”.

7. Conclusion and recommendations • This input is provided on a specific request by TP Chair to REQ WG • Due to the time constraints, it has not been possible to conduct a deeper analysis. • The intention of this contribution is not to be exhaustive neither to represent the overall view from OMA perspective on such important topic. • The intention of this contribution is to provide (on the basis of knowledge of authors, current OMA Work Items activity as well as trends indentified by OMA with collateral activities such as Workshop) some insights (i.e. high level requirements see slide #6) that may be taken into account for future SDP standardization • As such, those identified requirements may be used at discretion of TP chair during his presentation • REQ and ARC members are kindly requested to have a look at this document, and provide comment by 10° October (as per deadline indicated by TP Chair)

8. References • Corrado Moiso, Pierpaolo Baglietto, Massimo Maresca, Michele Stecca, Service Composition Technology for the Internet of Services and for Next Generation Telecom Services, 3rd GI/ITG KuVS Fachgespräch on NG SDPs: “Towards SDPs for the Future Internet” http://www.fokus.fraunhofer.de/en/ngni/news_events/events/kuvs_sdp_fg/3rd_meeting/index.html