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

2. Contents
tbd

3. Industry Status Edge (Cloud) Computing
ETSI MEC:
Work on architecture progressing, target Feb 2016, then focus on APIs to 3rd parties by summer 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 Sept 2015
Big Cloud players:
IBM: quiet
HP: quiet
Google: most recent move for latency reduction is introducing bridges to CDNs (see PR)
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

4. 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

5. 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.

6. 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?

7. 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 …

8. 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)

9. 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

10. 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?

11. 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

12. 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

13. 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.

14. 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, ….

15. 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

16. 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?

17. 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?

18. 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?

19. Many Thanks! We are interested in your comments & support!
Please contact:
openedgecomputing.org
Prof. Mahadev Satyanarayanan
Carnegie Mellon University
Dr. Yun Chao Hu
Huawei Technologies
Valerie Young
Intel
Rolf Schuster
Vodafone Group Services