Open Edge Computing – Review for 11 Dec 2015 Meeting – Guenter Klas, ….

Contents tbd

Industry Status Edge (Cloud) Computing ETSI MEC: Work on architecture progressing, target Feb 2016, then focus on APIs to 3rd parties by summer 2016. Lack of engagement by a number of companies, incl. Ericsson. ETSI MEC PoCs: 2 proposals available so far. Other publicly announced trials/PoCs: DTAG with Nokia, Continental, Fraunhofer for V2X, motorway A9 in Germany, see PR 11 Nov 2015 EE with Nokia on video orchestration, Wembley stadium London, see MEC Congress 29-30 Sept 2015 Big Cloud players: IBM: quiet HP: quiet Google: most recent move for latency reduction is introducing bridges to CDNs (see PR) http://www.lightreading.com/data-center/cloud-strategies/google-builds-cloud-bridges-to-cdns/d/d-id/718092 Microsoft: Edge cloud a non-feature at Future Decoded, 11 Nov 2015. However, MS Azure has joined Open Fog on 19 Nov 2015. Cloudlets still promoted by V. Bahl, Sept 2015. http://www.networkworld.com/article/2979570/cloud-computing/microsoft-researcher-why-micro-datacenters-really-matter-to-mobiles-future.html

Observations about OEC (1) The good news Cloudlets are a well-known concept. The term has been adopted by various companies (incl. Nokia, Akamai) Lots of publications exists about Cloudlets as enabler. Many parties know about the cloudlet concept (though don’t take action in OEC) Cloudlets predate ETSI MEC and Open Fog for a number of years, has a long research history Working code for Cloudlet is available. Level of interest in Cloudles appears to be rising: Queries e.g. from Crowncastle, NTT Labs, Elisa

Observations about OEC (2) Challenges Level of interest: OEC is a (too) small group today. Initial interest from various players hasn’t translated into action or funding: e.g. Red Hat, Nokia Overlap with others: In particular with ETSI MEC IEG: regarding goal to reach out to verticals and IT industry Level of usability/maturity of Cloudlet software platform: Difficult to install from scratch for non-experts, in particular difficult to install both OpenStack + Cloudlets on any HW/SW platform  could we create an installer for both? Possibly current SW too tightly linked to a particular HW configuration Cloudlet per se is not the E2E solution yet: What about orchestration, app deployment, edge discovery etc.? Recommended: Get System Integrators/Consulting companies on board to do that job.

Observations about OEC (3) Challenges continued Out of town mega-malls suck up all footfall: “Die letzten schauen in die Roehre” 3GPP RAN vendors attracted by ETSI MEC  difficult to attract them to OEC.org as well. Cloud hosting providers look to leverage the edge. Microsoft already joined Open Fog. We don’t have any cloud hosting companies on board. Open Fog has put a stake in the ground as cloud-enabling the IoT. ETSI MEC has put a stake in the ground as RAN-enabling edge applications. Difficult to engage with vertical markets. Better to use “market insiders”, “vertical market consulting companies” as proxies. Positioning of OEC seems not fully clear to the audience: What does it stand for? What space does it claim to occupy or was it first to occupy? What’s in for supporters? Current members face resourcing issues Current members are not aggressively promoting OEC.org. Why?

Stakeholder Analysis Active in OEC initiative Key players in Openstack Intel Huawei Vodafone CMU Vedams Key players in Openstack Red Hat HP Key players in Linux Canonical/Ubuntu Key players in Cloud Microsoft Azure IBM Bluemix AWS Google Salesforce.com …. Interested in Cloudlets NTT labs CrownCastle Vantrix Daqri Key players in Verticals Consulting companies Members of vertical industries Position unclear regarding OEC Nokia Ericsson ALU Juniper Brocade System integrators CGI Accenture …

Alternative Paths Forward Option 1: Merge into ETSI ISG MEC Option 2: Continue as is Option 3: Continue & Expand Option 4: Set up as membership-free low-cost organisation Option 5: Set up as project with membership fees under another umbrella organisation Option 6: Set up as independent organisation (own legal non-profit org)

Option 1: Merge into ETSI ISG MEC Pros: ETSI ISG MEC has more momentum than OEC More members formally signed up to ETSI MEC ETSI MEC has an established PoC framework ETSI MEC has a dedicated industry enablement group IEG Cons: Membership biased to network infrastructure vendors, lack of ISVs and apps developers Despite large membership, contributions only from a few companies. ‘Charter’ of OEC doesn’t naturally fit to existing charter of ETSI MEC (MEC telco architecture, particular middleware functions, certain APIs towards applications ETSI ISG MEC focussed on standards, thus technology agnostic, i.e. not promoting OpenStack-based solution. ETSI ISG MEC has no record in working with OpenStack or other opensource communties. (Same for OPNFV.) Lower chance to get extra funding

Option 1: Merge into ETSI ISG MEC Form: Inside IEG? Or an activity loosley coupled to IEG and controlled by ETSI MEC? OEC leaves industry outreach to ETSI MEC IEG OEC focuses exclusively on maturing Cloudlet software and getting it into OpenStack Transition process?

Option 2: Continue and Expand Assumptions: Cloudlets as Iaas, PaaS of interest for IoT, Tactile Internet, 5G etc. Software gets mostly improved based on feedback from real use Goals: Position OEC as creator of open source software enabler here to enable 5G Deliver actual pilot use cases in 2016 with cloudlets to prove benefits Get partners in the boat that represent a wider spectrum of stakeholders (e.g. cloud service providers) Get cloudlet component into OpenStack in 2016 Successfully position OEC vis-à-vis ETSI MEC and Open Fog: ETSI MEC: provides edge apps with RAN context information. Open Fog: typically smaller footprint of fog nodes for IoT area OEC.org: niche of heavy compute at edge and low latency, an enabler component

Option 2: Continue and Expand Strategy and Execution Split into 2 phases: Bootstrap + Scaling up Phase 1 (Bootstrap) Further mature the Cloudlet software platform Dec 2015 – June 2016 in parallel to performing pilots. Attract further voluntary funding/sponsors Get cloud hosting providers on board to broaden the set of partners Get consulting companies engaged in vertical markets on board as proxies to those markets Attract technical consulting companies/system integrators to fill E2E system gaps Phase 2 (Scaling up): Establish consortium with membership fees, once Phase 1 has been successful

Option 2: Continue and Expand What’s the model for doing pilots with interested enterprises (app developers)? Phase 1 (bootstrapping): CMU holds hands with very few PoCs (1 – 3) Phase 2 (scaling up): CMU contributes a mature enabler, the PoCs run on their own, no further heavy, direct involvement from CMU. Bilateral part: App developer provides their HW/SW to CMU under NDA. CMU allocate 1+ student(s) to the pilot. CMU may modify their SW to run on Cloudlet. CMU do E2E software integration. Open part in OEC.org: Pilot description (as a case study) Sharing all learnings from the pilots. All improvements to Cloudlet SW are open for all.

Option 2: Continue and Expand Tactial steps Dec 2015 – June 2016 Explore webinars: with a consulting company for a vertical industry + other members of such industry Bilateral pilots with Crowncastle, Daqri Try to onboard a cloud hosting provider OEC need at least one big player to endorse the Coudlet concept Who is it? IBM Bluemix, Amazon EC2, Microsoft Azure, …? Try to onboard a technical consulting company / system or cloud integrator Such companies can go and fill system-level gaps according to custom strategies (e.g. orchestration, discovery) Who is it? CGI, Accenture, IBM, Fujitsu, HP, ….

Option 2: Continue and Expand Funding plan 2016 Requirements USD 250k for lead engineer USD 150k per PoC, 2 PoCs Total: USD 550k Sources of funds

Outcome OpenStack Summit JP Hints that Cloudlets should be engineered as a separate new component in OpenStack No extension to Nova Pros: Can proceed more independently Cons: Cannot leverage e.g. the Nova community  need to build new sub-community What’s required to progress cloudlets in OpenStack Settting up new, open project there Signing up some other developers Still degree of freedom: Separate module in OpenStack, OPNFV, OnosFW ? Is our Cloudlet concept too narrow? What is needed for automotive? Where is VM handoff needed? Where is edge server discovery needed?

Technology: Actions needed for Cloudlets Getting extensions made to QEMU Describe the technical problem  See document written by Kiryong. Consider how to get the modifications made: A) Do them within OEC B) Piggyback the effort on any QEMU-related effort triggered by OPNFV. In this case ensure the changes from CMU and from OPNFV can co-exist. Who can work with whom? Lifting the cloudlet source code up to Liberty release 4 – 8 weeks of development (minimum) to integrate cloudlet code into OpenStack Liberty Who are the developer resources? Who are the testing resources?

Marketing: Actions needed for OEC Initiative Improving the website Building a community of practice / customers for MEC with support of Purdue University and their Open Innovation faculty?

Many Thanks! We are interested in your comments & support! Please contact: info@openedgecomputing.org openedgecomputing.org Prof. Mahadev Satyanarayanan Carnegie Mellon University satya@cs.cmu.edu Dr. Yun Chao Hu Huawei Technologies yunchao.hu@huawei.com Valerie Young Intel valerie.j.young@intel.com Rolf Schuster Vodafone Group Services Rolf.Schuster@Vodafone.com