Sudeep: happy new year to all IG
members
... a few updates about upcoming meetings
... followed by two guest speakers: Dario Sabella from Intel,
vice chair of MEC in ETSI
... involved in several industry groups focused on edge
computing innovation
... then a talk by Prof. Qiao and Wangs from Beijing University
of Posts and Telecommunications
... focused on machine learning and neural networks and impact
on moving some of the compute to the edge
... before these talks, a few announces of upcoming meetings in
February
scribe: On Feb 5th, a review from
Google on lessons learned while developing the Network
Information API (implemented in some of the browsers)
... the API gives insights about network conditions
... and the Google folks will share what they learned in the
process of developing and deploying that API
... On Feb 13th, a presentation by Michael Mccool, co-chair of
the Web of Things Working Group
... will give insights on the intersection of service worker /
web worker in the context of edge computing
Dario: this presentation gives an
overview of the topic - we won't cover everything, but the
slides are further references
... this is an overview on edge computing - not an exhaustive
view, but hopefully an interesting view of the topic
... there is a wide consensus on the revenue potential from
edge computing
... I'm part of the standards body, vice-chairman of the ETSI
MEC standard
... there are other standard bodies and industry groups
covering different aspects of edge computing
... I've helped coordinate an Intel white paper covering the
various standard bodies
... where you can find more relevant information
... there are many activities reflecting the need to cover many
different aspects
... there are commercial products, open source projects
... in addition to ETSI, 3GPP is defining how to implement MEC
in a cellular network
... The KPIs of MEC include: improved latency naturally, but
there are other KPIs e.g. cost savings
... each vertical might have different needs from edge:
performance is key, but not necessarily just latency
... [slide 7: where is the edge?]
... The definition of where the edge is intentionally
foggy
... the answer is "it depends"
... it can be at differently level of distance from the end
user
... there is a trade-off of performance & cost when scaling
MEC deployments
... there is flexibility in deployment options
... [ETSI MEC]
... MEC stands for Multi-Access Edge Computing (initially
Mobile Edge Computing)
... it's not only for cellular operators, but other access
methods (incl wifi, fixed access)
... MEC is cloud computing at the network edge
... the standards group has participation from a wide set of
participants, from the wide ecosystem
... 98 partners amont MEC members and participatns
... "MEC offers to app developers and content providers
cloud-computing capabilities and an IT service environment at
the edge of the network"
... 3GPP is starting to work seriously on the topic
... we're a committed to build a consistent story across
standard bodies
... [slide 11: MEC architecture]
... this is network agnostic, not based on a particular access
method
... it is inspired by the ETSI NFV framework
... this produces services, but can also consume services that
would exposed to other applications
... the client side can communicate through the @@@ interface
that instantiates a proxy application in the MEC side
Song: I would like to know which part of the specification is the most interesting for developers
Dario: from a dev perspective, we
have written a white paper and organized a webinar to address
this topic
... as a developer, the information I would need to use a MEC
system is given in slide 12
... developers don't need to know about the underlying
infrastructure, they want to use the services
... there are different type of categories of specifications in
MEC
... starting from MEC 016, UE Application interface
... and general principles for API
... (restfull, http, data structures)
... there are freely available OpenAPI representations of these
APIs
... the rest of the specs are less relevant to developers
directly
Developing Software for Multi-Access Edge Computing
Dario: we are not preventing that
new service APIs can be implemented without standardization as
long as they follow the API principles
... we're not aiming at providing the full list of APIs
... [slide 13: OpenAPI description files, MEC 0023]
... for interoperability, we have standardized a number of APIs
that have been required by the industry
... the OpenAPI representations of the APIs are available on
forge.etsi.org
... We have other activities in ETSI MEC beyond the traditional
standardization work
... we want to engage the ecosystem - app developers aren't
interested in reading specs, they want to develop their
services
... that's why we've been developing Proof-of-concepts,
promoting MEC via hackathons
... and MEC deployment trials
scribe: there is an upcoming
hackathon in April, with an open call for developers with a
focus on Android
... an example of a standardized API, led by Intel, is the MEC
V2X API (vehicle-to-everything)
... this is related to automotive
... slide 16 shows the list of foreseen functionalities
... this is a stable draft
... it helps with interop across car makers and operators
... [overview of the API structure]
... one of the methods is predicted_qos - we're not
standardizing who is producing that info, just how it is
exposed
... [MEC use cases]
... MEC GS 002 collects our use cases - it shows the use cases
supported by MEC
... there are 3 categories: consumer-oriented services (e.g.
app computation off-loading)
... operator and third-party services (not directly for the
benefit of the end-user)
... and network perf and QoE improvements - this can be fully
transparent to the user
... [App Computation Offloading]
... This allows the MEC host to execute compute-intensive
functionalities with high perf than the mobile devices, both
from a time and energy perspective
... the trade-off is the cost (computing, power, time) of
transmitting the data
... this has to be analyzed on a case by case basis to evaluate
how useful the offloading is
... examples incl video processing, AI, ML
... app offloading could benefit from being requested from the
client-side, e.g. via a Web API
... this may need a counterpart work in ETSI (not planned at
the moment)
... [5GAA]
... I also wanted to touch on what we're doing in 5GAA (5G
Automotive Associated) where MEC is a key technology
... this is where the predicted QoS work emerges, which was
demonstrated in November
Sudeep: maybe let's keep this for discussion with Google in February
Dario: makes sense
Qiao: the topic is accelerating
deep neural networks for the Web with edge computing
... deep neural networks show great promise in providing more
intelligence to Web applications
... there are typical execution schemes: javascript/Web
Assembly on the client - but that requires loading heavy DNN
models (e.g. ~100 MB)
... the other more common approach is to run the model on the
remote cloud
... but that requires sending large amount of data to the
cloud, increases computing pressure, and creates privacy
concern (e.g. for home security camera)
... Mobile Edge computing is providing an important
infrastructure via 5G
... it allows to reduce the burden from the core network and
reduces the in-device computing cost
... so we would need to dynamically distribute the computing
around the various ndoes
... the client would only need to download a small part of the
model and keep the privacy-sensitive data on-device
... the challenge is how to provide this offloading in a
changing network conditions
... we introduce an efficient branch to the traditional neural
networks
... it can help accelerate the inference on the Web with
collaborative mechanism on the edge server
... [slide 6]
... network conditions and device computing capabilities can
change dynamically
... this requires a context-aware algorithm that takes into
account these parameters
... we propose an adaptive framework
... with a web runtime adapter, with a model optimized for
mobile users
... depending on whether a set of conditions are satisified,
some of the computing is offloaded to the edge and the
cloud
... [slide 7]
... Is there a better metaphor to distribute computing on the
Web?
... how can we make it easier to use edge computing for web
developers?
... how can we detect when using edge computing is the most
efficient approach (e.g. network conditions, computing
capabilities of the end device)
Sudeep: thank you - very
interesting and relevant use case
... relevant both to MEC and network quality prediction
... also intersections with the WebNN work in W3C and the Web
of Things work (service and capability discovery)
... we will have to continue investigating this discussion
Song: +1
Sudeep: we need to look at what
kind of APIs, what needs to be down in the browser context vs
in-apps
... thank you everyone