Multi-Access Edge Computing in Action

Dario Sabella, Alex Reznik, Rui Frazao

• Publisher: CRC Press
• Year: 2019
• eBook ISBN: 9780429509377
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Networking
• Index: Computer Science

This book provides a complete and strategic overview of Multi-Access Edge Computing (MEC). It covers network and technology aspects, describes the market scenarios from the different stakeholders' point of view, and analyzes deployment aspects and actions to engage the ecosystem. MEC exists in and supports a highly complex "5G world" in which technologists and non-technology decision makers must act in concert and do so within a large interconnected ecosystem of which MEC is just one, albeit an important, part. Divided into three sections, with several chapters in each, the book addresses these three key aspects: technology, markets, and ecosystems.

PART 1
MEC AND THE
NETWORK

1

FROM CLOUD COMPUTING
TO MULTI-ACCESS
EDGE COMPUTING

This chapter introduces multi-access edge computing (MEC) from a network perspective, starting from the historical background of cloud computing, and then considering new trends (including open innovation, network softwarization, and convergence between Telco and information technology [IT]) that drove the evolution toward the edge.

Let us start, as the saying goes, in the beginning. What is MEC? To understand this properly, we actually need to start from the end, with the letter “C” denoting “Computing.” This book is primarily about computing, which currently means it is about “the Cloud” (whatever that means – we’ll get to that a bit later). Then, there is the “E” denoting “Edge.” Chances are you think you know what “edge computing” is, but we are willing to bet that your definition is too narrow. If that’s true, we hope that at the very least, this book helps broaden your “edge horizons.” Then, there is the “M” which stands for “Multi-access.” Here, the “access” is important – it is “edge computing” (whatever that means) which is somehow “connected” to an “access” – that is, a network that users and other client devices (e.g., those billions of things that the Internet of Things [IoT] is being built from) use to “access” the Internet. The “multi” in retrospect is the least important part of the acronym, a designation indicating that MEC technologies can be used in all kinds of networks (mobile, Wi-Fi, fixed access) to enable all kinds of applications.

And so, it appears, MEC is a kind of a chimera – a cloud technology that’s located away from the cloud and that has something important to do with networking. It is also a chimera because – as we shall see – it comes about from the convergence of several disparate trends that have been around for some time. But this does not mean that MEC as a field is uncoordinated, disjointed, and nonfunctional – no more so than the mythical Chimera was.

As a brief digression for those readers with a theoretical bent, MEC represents a practical convergence of computing, communication, and – through its critical importance in enabling the industrial IoT – control: the holy grail of modern information sciences. And for those of you with a more philosophical bent, it is also a vibrant illustration of the efficiency and robustness of decentralized decision-making as compared to centralized “optimized” approaches.

1.1 To Edge or Not to Edge

A proper place to start seems to be the question of why one even needs edge computing in general and MEC in particular. Much has been written on the subject, but it can be summarized as follows: there are applications for which the traditional cloud-based application hosting environment simply does not work. This can happen for a number of reasons, and some of the more common of these are:

• The application is latency sensitive (or has latency-sensitive components) and therefore cannot sustain the latency associated with hosting in the traditional cloud.
• Application clients generate significant data which requires processing, and it is not economical, or, perhaps even not feasible to push all this data into the cloud.
• There are requirements to retain data locally, for example, within the enterprise network.

A big driver for edge computing is the IoT, where edge computing is commonly referred to as fog computing. NIST (National Institute of Standards and Technology), in its “Fog Computing: Conceptual Model” report [8], makes the following statement:

Managing the data generated by Internet of Things (IoT) sensors and actuators is one of the biggest challenges faced when deploying an IoT system. Traditional cloud-based IoT systems are challenged by the large scale, heterogeneity, and high latency witnessed in some cloud ecosystems. One solution is to decentralize applications, management, and data analytics into the network itself using a distributed and federated compute model.

Moreover, IoT is rapidly developing into a significant driver of edge computing revenue – as evidenced by Microsoft’s edge cloud solution called “Azure IoT Edge.”

However, IoT is just one of the several types of applications that require edge presence. In a white paper that has been widely influential in defining what “5G” is, the Next Generation Mobile Networks (NGMN) alliance lists eight classes of 5G applications that define 5G user experience and drive requirements on 5G mobile networks [9]. These include:

• Pervasive Video
• 50+ Mbps Everywhere
• High-Speed Train
• Sensor Networks
• Tactile Internet
• Natural Disaster
• E-Health Services
• Broadcast Services

A rough top-level analysis of these categories leads to a conclusion that most of them either require edge computing or significantly benefit from it. Indeed, we can make the following statements:

• Pervasive Video: edge computing can be used to significantly reduce backhaul/core network loading by edge caching and video processing and transcoding at the edge.
• High-Speed Train: such “high-speed” environments will almost certainly require application presence “on the train” to avoid dealing with network limitations associated with connectivity from a high-speed platform to a stationary network.
• Sensor Networks: The massive IoT problem of collecting and processing massive amounts of data, which is a primary focus of fog computing, lies in this category.
• Tactile Internet: use cases and applications in this category are known to require end-to-end latencies as low as 1 msec. In most networks, the physical limitations imposed by the speed of light make it impossible to achieve such latencies without edge computing.
• Natural Disaster: supporting these use cases requires deploying networks on a “connectivity island” (i.e., with limited/intermittent or even absent connectivity to the Internet). Thus, any applications have to run at the edge.
• Broadcast Services: these can benefit significantly when content can be present at the edge, as that would save significant network traffic. Moreover, edge-based contextualization of broadcast can improve what is made available in each particular area.

Clearly, edge computing is a key enabling technology for 5G, something that was recognized as early as the NGMN paper, which lists “Smart Edge Node” as a “Technology Building Block” and lists its use to run core network services close to the user as well as its potential use for application services such as edge caching.

However, focused as it was on mobile networks, what the NGMN paper missed is that because its “Smart Edge Node” is a landing zone for applications, it really needs to become a kind of “cloud node.” This theme was picked up by ETSI (European Telecommunications Standards Institute) in the white paper “Mobile Edge Computing: A Key Technology Towards 5G” and in the creation of an Industry Specification Group (ISG) focused on what was called mobile edge computing (MEC) [10]. Within a few years, the group was renamed to multi-access edge computing (keeping the MEC abbreviation) to recognize the fact that its work was applicable across all types of access networks: mobile (3GPP defined) as well as Wi-Fi, fixed access, etc. Again, why paraphrase when we can just quote:

MEC thus represents a key technology and architectural concept to enable the evolution to 5G, since it helps advance the transformation of the mobile broadband network into a programmable world and contributes to satisfying the demanding requirements of 5G in terms of expected throughput, latency, scalability and automation.

One thing that was missed, or rather not highlighted by all this work, is that edge computing – specifically MEC – is not just a “5G technology.” In fact, MEC is a critical tool in enabling operators to launch 5G applications on their existing 4G networks. This can have a significant impact on the business side of MEC – something discussed in detail in Ref. [11] and also in our discussion of the economic and business aspect of MEC in Chapter 3.

To conclude this brief introductory discussion, let us summarize the themes: edge presence is needed to make the full world of 5G worknetwork. This includes IoT, which is the focus of many initial deployments, but encompasses a much broader set of applications, use cases, and markets. MEC enables such edge presence by creating a cloud-like application landing zone within the access network – that is, as close to the client devices as possible. It is therefore a key enabler of the emerging world of computing – 5G, IoT, AR/VR, etc. This book expands on these themes and examines in some detail what they mean, the various ecosystem players, challenges and opportunities, as well as provides an overview of the key technologies involved. However, we must start by actually explaining what MEC is – or is not – and this is what we turn to next.

1.2 The Cloud Part of MEC

Recall, a page or two back, we noted that the primary letter in the “MEC” abbreviation is the last one – “C” denoting “computing”, but really denoting “cloud.” And so, we begin by looking at the cloud computing aspects of MEC. The Wikipedia page on “Cloud Computing”¹ defines it as follows.

Cloud computing is an IT paradigm that enables ubiquitous access to shared pools of configurable system resources and higher level services that can be rapidly provisioned with minimal management effort, often over the Internet. Cloud computing relies on sharing of resources to achieve coherence and economies of scale, similar to a public utility.

As the same page notes, the term was popularized by Amazon Web Services (AWS) in the mid-2000s but can be dated to at least another decade prior. So, the cloud computing aspect of edge computing seems to be a well-known thing. Indeed, one of the main goals of edge computing is to “enable ubiquitous access to shared pool of configurable system resources and higher-level services that can be rapidly provisioned.” A detail-oriented reader may wonder why the quote stops where it does, and indeed this is not accidental.

So, let us consider what is not requoted, notably “sharing of resources to achieve coherence and economies of scale.” In fact, achieving what’s behind these two short terms required significant advances which took several decades to be realized to a point where cloud computing became an economically viable business:

• Separation of physical hardware and applications through virtualization. This made it possible to migrate application workloads between different hardware platforms without requiring existence of different SW builds for each particular type of HW.
• Convergence to a few, industry-standardized “compute architectures” – primarily the Intel x86 architecture, so that the vast majority of applications that are virtualized are built with the assumption of an Intel-architecture–based processing underlying it.
• Development of high-speed Internet, which made possible transfer of large amounts of data and computation outside private enterprise networks.
• Development of the World Wide Web, which enabled name-based resource access paradigms. (It is unlikely that cloud computing would work well if our applications had to rely on IP for resource addressing, since IP addresses are naturally tied – that is, “pinned” – to particular HW.)
• Introduction, notably by AWS, of REST-API–based service management framework – using the World Wide Web transport mechanism (HTTP).
• An economic environment that made possible the deployment of ma...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• Foreword
• Acknowledgments
• Authors
• Introduction
• Part 1 MEC and the Network
• Part 2 MEC and the Market Scenarios
• Part 3 MEC Deployment and the Ecosystem
• References
• Index