Net!Works Steering Board Meeting DEC 2011

1. Overall FI-WARE Vision Thomas M. Bohnert, Deputy Chief Architect FI-PPP Net!Works Steering Board MeetingDEC2011

2. Future Internet Public-Private Partnership - Program after Call 1 http://www.fi-ppp.eu/

3. FI-WARE in Figures Main data 26 partners 5 Universities 4248 Person Months (excl. open calls) Total Funding 41 M€ Open calls 12,3 M€ Total budget 66,4 M€ Three years duration

4. Suppliers Governments Manufacturer Consumers Retailers Wholesalers Internet of Services Cloud Computing Internet of Things Future Networks FI Core Platform Architecture: Vision Future Internet Business Platform Provisioning – Hosting – Refactoring – Brokering – Consumption

5. Building a platform for users Consumers People Businesses Apps/Services Provider Open Interfaces Platform Provider Provide “Generic Enablers” to the usage areas…and beyond

6. FI Core Platform Architecture: main chapters Functionality Trust and Security Operations Context/Data Management

7. The Future Internet PPP Core Platform

8. Elements & Functions of FI Core Platform • The FI Core Platform comprises a set of technological “Generic Enablers” which are considered general purpose and common to almost any “usage areas” • Generic Enablers (therefore, the FI Core Platform) will provide open interfaces: • To Application Developers (APIs) • To support interoperability with other GEs (need for replacement) Usage area projects under the PPP Cloud Hosting App/Service Delivery Support Services Interface to IoT Interface to Network Security, Trust Dev Tools

9. What is a FI-WARE Generic Enabler (GE)? • The implementation of a FI-WARE Generic Enabler (GE)becomes a building block of a FI-WARE Instance • Any implementation of a Generic Enabler (GE) is made up of a set of components which together supports a concrete set of Functions and provides a concrete set of APIs and interoperable interfaces that are in compliance with open specifications published for that GE • There might be multiple compliant implementations of a given GE • Each Architecture Chapter in FI-WARE will lead to definition of a set of GEs

10. Creation of FI-WARE Instances

11. I2ND General Architecture • Four Classes of Interfaces (FI-WARE Generic Enablers) • CDI: Connected Devices Interfacing • CE: Cloud Edge • NetIC: Network Information and Control • S3C: Service, Capability, Connectivity, and Control • The interfaces • Expose corresponding network state information to the user • Offer a defined level of control and management • Aim to overcome limitations of today's network and device interfaces • Combining different worlds: • Telecommunication services (Session Initiation Protocol – SIP – speaking) • Web-services (Simple Object Access Protocol – SOAP – speaking) • Openness to other Future Internet worlds

12. The CDI Generic Enabler Application Developers Network Providers Services Apps • Itprovidesmeans to detect and exploit device capabilities • Communication Services • Network Status, QoS, QoE,.. • Device Services • Sensors, battery, short range radio, Remote Management ,… • Personal/Data Services • User Profile (Identity, Authentication), Local Data, PIM, … • Media Services • Graphics rendering , Streaming Features , … CDI API Cloud Proxy CDIL-NET CDIL-APP InterfacingLayer QoS Camera PIM QoE Network Status Streaming Features User Profile Remote Mgmt Short Range Radio I/F Graphics Rendering Local Data Sensors CDIL-PAL (Opt) CDI Platform AdaptionLayer OS Connected Device HW, Capabilities, Features, Information • Broad range of networked components: Handsets (cell phones, smart phones), Tablets, Smart TVs, In-Vehicle Infotainment, Info kiosks, …

13. Home Network Devices The CE Generic Enabler • It provides interfaces between the applications hosted in the cloud proxy and external application • cloud-based application to management features • transparent or adapted communications to the end devices • Other Interfaces include • Inside/outside communication entity and the management • Access to permanent local storage • Communication with the local devices (uPnP/Dlna, …) • Communication with other cloud proxies Cloud Applications Cloud Applications Cloud Applications CloudProxies Cloud Proxy Containers / Virtual Machines Containers / Virtual Machines Containers / Virtual Machines Cloud Proxy API Service Platform Management VM Management Local Storage CE End Device Communication

14. transport network A virtual network(s) transport network B The NetIC Generic Enabler • Open Networking concept enabling network nodes to provide intelligent network connectivity by dynamic configuration via open interfaces • Network Information and Control • Programmability enablement within the network • Flow processing, Routing, Addressing • Resource management • Homogeneous access to heterogeneous open networking devices • Network virtualisation enablement FiWare-internal and –external use cases(represented by, e.g., network providers, cloud hosting providers, content providers S3C API S3C NetIC API Interface Control PathStatistics Traffic Statistics NetIC Topology Path Control Traffic Control subnetwork a subnetwork b subnetwork c subnetwork d

15. The S3C Generic Enabler Application Domains Application Domains Application Domains • It provides an extended interfacing for service platforms dynamically adapting their requirements to the packet core network • Service, Capability, Connectivity, and Control elements • Network Event Management • Resource Management (computation, QoS, …) • Operator’s Authentication, Authorisation, Accounting, Auditing and Charging • Connectivity Management • Network Context Data Management • Based on 3GPP EPC architecture Services API Network Event Mgmt. Resource Mgmt. Connectivity Mgmt. Operator SA4C & LI Small data push/pull Network Data Caching and Aggregation Inter-Carrier Mgmt. Network Context Data Mgmt. Network Identity Mgmt. S3C BC/MC Mgmt. ANDSF PCRF PDN GW 3GPP Evolved Packet Core NET_IC Generic Enabler HSS AAA ANGw ePDG S-GW Untrusted Non-3GPP Trusted Non-3GPP MME 2G/3G eNodeB CDI-Net

16. The FI-WARE Testbed will be a case example of a FI-WARE Instance. It: will allow Use Case projects and third parties to run and test Future Internet Applications based on FI-WARE GEs, validating them. is aimed to be complete, in the sense that it will comprise reference implementations of all GEs defined in the FI-WARE Architecture. Will be operated under central control and be accessible from a dedicated website. FI-WARE partners will provide support to UC projects in deploying their conceptual prototypes on top of the FI-WARE testbed The FI-WARE Testbed

17. The project will work towards the establishment of an Open Innovation Lab by combining: The FI-WARE Testbed The FI-WARE Development Support Infrastructure (forge + additional community tools) It is intended that this Open Innovation Lab be available to third parties (specially SMEs) after the second year FI-WARE Open Innovation Lab

18. FI-PPP Architecture Board • Principal Concern • Support coordinated, sustainable, uniform interaction • Two processes defined accordingly • FI-WARE General Support • FI-WARE Theme/Epic/Feature Requests • FI-WARE General Support • Technical support for any external stakeholders • FI-WARE Theme/Epic/Feature Requests • Backlog for Feature Requests by Use Case projects

19. European Commission Policy/decision making level • Policy making • Programme Future • Impact • EC/EP/Council contact Advisory Board Chair PPP Steering Board Architecture Board PPP Secretariat Standardisation Business Models European Commission PPP Programme Office SME & Open Innovation

20. FI-PPP Architecture Board • Meetings 2011 • Mai 19, AB Kick-Off, Co-located with the FI-Assembly, Budapest, Hungary • Major outcomes: • High-level introduction of the persons projects, and organizations involved in the AB • FI-WARE Roadmap and Agile Approach introduced in great detail • June 19, AB Virtual Meeting • Major outcomes: • Introduction of the FI-PPP Backlog Template (Agile Approach) • Discussion and identification of potential collaboration support tools (e.g. AgileFant, FusionForge, Trac, etc) • Discussion on methodologies for requirements engineering (processes, tools

21. FI-PPP Architecture Board • Meetings 2011 (cont’d) • July 11-12, AB Meeting, Madrid, Spain • Major outcomes: • Agreement on the FI-PPP backlog template • Rules for on-demand expert invitation to AB • Collaborative tools for Agile discussed (AgileFant and FusionForge for Agile Development) • August 25, AB Virtual Meeting • Major outcomes: • Process for "FI-WARE General Support" presented and agreed • AgileFantdroped in favor of FusionForge/Tracker/Wiki

22. FI-PPP Architecture Board • Meetings 2011 (cont’d) • Sept 21-22, AB Meeting, Paris, France • Major outcomes: • FI-WARE Product Vision presented and agreed • Collaboration space "FI-WARE FusionForge“ accepted • FI-WARE Tutorials for collaboration introduced • Oct 25, AB Meeting, Co-Located with FI - Assemply, Poznan, Poland • Major outcomes: • Status on INFINITY Capacities DB • FI-WARE Apps/Services Framework presented to Usage Areas (follow-up requested) • FI-WARE Feature Request Process and Unclassified Backlog introduced and accepted • Timeline towards 1st FI-WARE OpenCall agreed

23. Mainmilestones in FI-WARE

24. We plan to maintain ~30% (12M Euro) of the project budget for distribution among new partners New partners will be selected through Open Calls to allow for responding to emerging user requirements not identified at the start of the project, e.g., due to new usage areas, new technologies, new economic conditions Specific component of the budget will be reserved for SMEs (aprox 30%) and Research Centers (aprox 30%) Selection of new partners will be done according to the procedure issued by the Commission European Commission 23 October 2009v1a Guidance note for project coordinators planning a competitive call for additional beneficiaries in an ICT Integrated Project or Network of excellence Management of Open Calls

25. Open callprocedure The budget devoted to the Open Calls is 12.300.000 €, or 30% of total funding. The expected distribution of this budget between the two planned Open Calls is about 8.000.000 € in the first Open Call and 4.300.000 € in the second Open Call.

26. Firstcallprocedure

27. Secondcallprocedure

28. Thanks !! Creating a solid basis for the Internet of the Future

29. It’s about software that works and successful Use Case projects using it It’s about minimizing the paperwork which is not actually valuable to target users (App developers/providers) It’s about paving the way to actual transference of results Pushing standardization Gaining attention by stakeholders (providers, developers) What should be different in FI-WARE

30. What is FI-WARE Product Vision • A document that helps FI-WARE partners and users to reach a common understanding about the essenceof the product • A full technical spec answering all the questions upfront: • Over-engineering the “Product Vision” would introduce unnecessary delays at the start, going against Agile principles • A dynamicdocument (Wiki) that evolves over time adding links to: • Architecture Specifications • Technical Roadmap • Results from Exploitation Analysis • A static document archived in some folder What is not

31. A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product. We don't do internal service-oriented platforms, and we just as equally don't do external ones. This means that the "not getting it" is endemic across the company: the PMs don't get it, the engineers don't get it, the product teams don't get it, nobody gets it. But making something a platform is not going to make you an instant success. A platform needs a killer app.

32. The Future Internet is based on Optics - Dynamic Infrastructure Sharing (IaaS => Cloud) www.geysers.eu

33. Users of I2ND Interfaces • Applications running on connected devices and cloud Proxies • Interacting with the end user through GUI • Using device features (i.e. sensors, profile information, stored data, etc.) • Using information accessible remotely (i.e. network services or cloud services) by means of the connectivity device capabilities • FI-WARE Services • B2B, B2C services provided by the FI-WARE platform • Get access to the underlying features, functionalities, and information • FI-WARE are usually services provided through other FI-WARE GEs interacting with I2ND GEs

34. Conclusions • The Generic Enablers of FI-WARE’s Interface to the Network and Devices Provide • Functionality to “Enable the Intelligent Connectivity” • Connecting applications/application platforms to the network intelligently • Leveraging on full potential of features of the network • Accessing the device capabilities • Interacting with cloud proxies • Open Standardised Interface specifications • Support for Mobility and Quality of Service/Experience (QoS/E) • Security, ID management and privacy important but covered by the trust and security working group in the project – close relationships and definition of the respective interfaces • I2ND’s GEs represent the network and devices for all other FI-WARE’s GE

35. Specifications of APIs (Application Programming Interfaces) and Interoperable Protocols supported by FI-WARE Generic Enablers (GE) will be open and Royalty-free The FI-WARE project will deliver a reference implementation for each of the GEs defined in the FI-WARE Architecture Some components of these reference implementations may be closed source while others may be open source The concrete open source license selected by the owning partners who work together in the implementation of a given component will be agreed by them, taking into account the Access Rights obligations and avoiding any impact on other Project partners and their work packages Licenseterms: No costswithinthe FI-PPP program, FRAND conditionsoutsidethe FI-PPP Principles about IPRs