A Survey on Edge Computing Systems and Tools

11/07/2019 ∙ by Fang Liu, et al. ∙ 0

Driven by the visions of Internet of Things and 5G communications, the edge computing systems integrate computing, storage and network resources at the edge of the network to provide computing infrastructure, enabling developers to quickly develop and deploy edge applications. Nowadays the edge computing systems have received widespread attention in both industry and academia. To explore new research opportunities and assist users in selecting suitable edge computing systems for specific applications, this survey paper provides a comprehensive overview of the existing edge computing systems and introduces representative projects. A comparison of open source tools is presented according to their applicability. Finally, we highlight energy efficiency and deep learning optimization of edge computing systems. Open issues for analyzing and designing an edge computing system are also studied in this survey.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 13

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

In the post-Cloud era, the proliferation of Internet of Things (IoT) and the popularization of 4G/5G, gradually changes the public’s habit of accessing and processing data, and challenges the linearly increasing capability of cloud computing. Edge computing is a new computing paradigm with data processed at the edge of the network. Promoted by the fast growing demand and interest in this area, the edge computing systems and tools are blooming, even though some of them may not be popularly used right now.

There are many classification perspectives to distinguish different edge computing system. To figure out why edge computing appears as well as its necessity, we pay more attention to the basic motivations. Specifically, based on different design demands, existing edge computing systems can roughly be classified into three categories, together yielding innovations on system architecture, programming models and various applications, as shown in Fig. 

1.

Fig. 1: Categorization of edge computing systems.
  • Push from cloud. In this category, cloud providers push services and computation to the edge in order to leverage locality, reduce response time and improve user experience. Representative systems include Cloudlet, Cachier, AirBox, and CloudPath. Many traditional cloud computing service providers are actively pushing cloud services closer to users, shortening the distance between customers and cloud computing, so as not to lose market to mobile edge computing. For example, Microsoft launched AzureStack in 2017, which allows cloud computing capabilities to be integrated into the terminal, and data can be processed and analyzed on the terminal device.

  • Pull from IoT. Internet of Things (IoT) applications pull services and computation from the faraway cloud to the near edge to handle the huge amount of data generated by IoT devices. Representative systems include PCloud, ParaDrop, FocusStack and SpanEdge. Advances in embedded Systems-on-a-Chip (SoCs) have given rise to many IoT devices that are powerful enough to run embedded operating systems and complex algorithms. Many manufacturers integrate machine learning and even deep learning capabilities into IoT devices. Utilizing edge computing systems and tools, IoT devices can effectively share computing, storage, and network resources while maintaining a certain degree of independence.

  • Hybrid cloud-edge analytics. The integration of advantages of cloud and edge provides a solution to facilitate both global optimal results and minimum response time in modern advanced services and applications. Representative systems include Firework and Cloud-Sea Computing Systems. Such edge computing systems utilize the processing power of IoT devices to filter, pre-process, and aggregate IoT data, while employing the power and flexibility of cloud services to run complex analytics on those data. For example, Alibaba Cloud launched its first IoT edge computing product, LinkEdge, in 2018, which expands its advantages in cloud computing, big data and artificial intelligence to the edge to build a cloud/edge integrated collaborative computing system; Amazon released AWS Greengrass in 2017, which can extend AWS seamlessly to devices so that devices can perform local operations on the data they generate, while data is transferred to the cloud for management, analysis, and storage.

From a research point of view, this paper gives a detailed introduction to the distinctive ideas and model abstractions of the aforementioned edge computing systems. Noted that the three categories are presented to clearly explain the necessity of edge computing, and the classification is not the main line of this paper. Specifically, we review systems designed for architecture innovation first, then introduce those for programming models and applications (in Sec. II). Besides, some recently efforts for specific application scenarios are also studied.

While we can find a lot of systems using edge computing as the building block, there still lacks standardization to such a paradigm. Therefore, a comprehensive and coordinated set of foundational open-source systems/tools are also needed to accelerate the deployment of IoT and edge computing solutions. Some open source edge computing projects have been launched recently (e.g., CORD). As shown in Fig. 1, these systems can support the design of both architecture and programming models with useful APIs. We review these open source systems with a comparative study on their characteristics (in Sec. III).

When designing the edge computing system described above, energy efficiency is always considered as one of the major concerns as the edge hardware is energy-restriction. Meanwhile, the increasing number of IoT devices is bringing the growth of energy-hungry services. Therefore, we also review the energy efficiency enhancing mechanisms adopted by the state-of-the-art edge computing systems from the three-layer paradigm of edge computing (in Sec. IV).

Fig. 2: Major building blocks and organization of this survey paper.

In addition to investigations from the system view, we also look into the emerging techniques in edge computing system from the application view. Recently, deep learning based Artificial Intelligence (AI) applications are widely used and offloading the AI functions from the cloud to the edge is becoming a trend. However, deep learning models are known for being large and computationally expensive. Traditionally, many systems and tools are designed to run deep learning models efficiently on the cloud. As the multi-layer structure of deep learning, it is appropriate for edge computing paradigm, and more of its functions can be offloaded to the edge. Accordingly, this paper also studies the new techniques recently proposed to support the deep learning models at the edge (in Sec. V).

Our main contributions in this work are as follows:

  • Reviewing existing systems and open source projects for edge computing by categorizing them from their design demands and innovations. We study the targets, architecture, characteristics, and limitations of the systems in a comparative way.

  • Investigating the energy efficiency enhancing mechanism for edge computing from the view of the cloud, the edge servers, and the battery-powered devices.

  • Studying the technological innovations dedicated to deploying deep learning models on the edge, including systems and toolkits, packages, and hardware.

  • Identifying challenges and open research issues of edge computing systems, such as mobility support, multi-user fairness, and privacy protection.

We hope this effort will inspire further research on edge computing systems. The contents and their organization in this paper are shown in Fig. 2. Besides the major four building blocks (Sec. IISec. V), we also give a list of open issues for analyzing and designing an edge computing system in Sec. VI. The paper is concluded in Sec. VII.

Ii Edge Computing Systems and Tools

In this section, we review edge computing systems and tools presenting architecture innovations, programming models, and applications, respectively. For each part, we introduce work under the “push”, “pull”, and “hybrid” demand in turn.

Ii-a Cloudlet

Fig. 3: Cloudlet Component Overview and Functions that support application mobility. A: Cloudlet Discovery, B: VM Provisioning, C: VM Handoff.

In 2009, Carnegie Mellon University proposed the concept of Cloudlet [68], and the Open Edge computing initiative was also evolved from the Cloudlet project [62]. Cloudlet is a trusted, resource-rich computer or cluster of computers that are well-connected to the Internet and available to nearby mobile devices. It upgrades the original two-tier architecture “Mobile Device-Cloud” of the mobile cloud computing to a three-tier architecture “Mobile Device-Cloudlet-Cloud”. Meanwhile, Cloudlet can also serve users like an independent cloud, making it a “small cloud” or “data center in a box”. Although the Cloudlet project is not proposed and launched in the name of edge computing, its architecture and ideas fit those of the edge computing and thus can be regarded as an edge computing system.

The Cloudlet is in the middle layer of the three-tier edge computing architecture and can be implemented on a personal computer, low-cost server, or small cluster. It can be composed of a single machine or small clusters consisting of multiple machines. Like WiFi service access points, a Cloudlet can be deployed at a convenient location (such as a restaurant, a cafe, or a library). Multiple Cloudlets may form a distributed computing platform, which can further extend the available resources for mobile devices [47]. As the Cloudlet is just one hop away from the users’ mobile devices, it improves the QoS with low communication delay and high bandwidth utilization.

In detail, Cloudlet has three main features as follows.

Ii-A1 Soft State

Cloudlet can be regarded as a small cloud computing center located at the edge of the network. Therefore, as the server end of the application, the Cloudlet generally needs to maintain state information for interacting with the client. However, unlike Cloud, Cloudlet does not maintain long-term state information for interactions, but only temporarily caches some state information. This reduces much of the burden of Cloudlet as a lightweight cloud.

Ii-A2 Rich Resources

Cloudlet has sufficient computing resources to enable multiple mobile users to offload computing tasks to it. Besides, Cloudlet also has stable power supply so it doesn’t need to worry about energy exhaustion.

Ii-A3 Close to Users

Cloudlets are deployed at those places where both network distance and physical distance are short to the end user, making it easy to control the network bandwidth, delay and jitter. Besides, the physical proximity ensures that the Cloudlet and the user are in the same context (e.g., the same location), based on which customized services (e.g., the location-based service) could be provided.

To further promote Cloudlet, CMU built up an open edge computing alliance, with Intel, Huawei and other companies [62], to develop standardized APIs for Cloudlet-based edge computing platforms. Currently, the alliance has transplanted OpenStack to the edge computing platform, which enables distributed Cloudlet control and management via the standard OpenStack APIs [32]. With recent development of the edge computing, the Cloudlet paradigm has been widely adopted in various applications, e.g., cognitive assistance system [31, 30], Internet of Things data analysis [70], and hostile environments [69].

Unlike the cloud, cloudlets are deployed on the edge of the network and serve only nearby users. Cloudlet supports application mobility, allowing devices to switch service requests to the nearest cloudlet during the mobile process. As shown in Fig. 3, Cloudlet supports for application mobility relying on three key steps.

1) Cloudlet Discovery: Mobile devices can quickly discover the available Cloudlets around them, and choose the most suitable one to offload tasks.

2) VM Provisioning: Configuring and deploying the service VM that contains the server code on the cloudlet so that it is ready to be used by the client.

3) VM Handoff: Migrating the VM running the application to another cloudlet.

Ii-B CloudPath

Fig. 4: CloudPath Architecture [55].

CloudPath [55] is an edge computing system proposed by the University of Toronto. In such a system, diverse resources like computing and storage are provided along the path from the user device to the cloud data center. It supports on-demand allocation and dynamic deployment of the multi-level architecture. The main idea of CloudPath is to implement the so-called “path computing”, such that it can reduce the response time and improve the bandwidth utilization, compared with the conventional cloud computing.

As illustrated in Fig. 4, the bottom layer of CloudPath is user devices, and the top layer is the cloud computing data center. The system reassigns those tasks of the data centers along the path (for path computing) to support different types of applications, such as IoT data aggregation, data caching services, and data processing services. Developers can select an optimal hierarchical deployment plan for their services by considering the factors such as cost, delay, resource availability and geographic coverage. Path computing builds a multi-tiered architecture, and from the top (traditional data center) to the bottom (user terminal equipment), the device capability becomes weaker, while the number of devices gets larger. On the premise of clear separation of computing and states, CloudPath extends the abstract shared storage layer to all data center nodes along the path, which reduces the complexity of third-party application development and deployment, and meanwhile keeps the RESTful development style.

The CloudPath application consists of a set of short-cycle and stateless functions that can be quickly instantiated at any level of the CloudPath framework. Developers either tag functions to specify where (such as edges, cores, clouds, etc.) their codes run, or tag performance requirements (such as response latency) to estimate the running location. CloudPath does not migrate a running function/module, but supports service mobility by stopping the current instance and re-starting a new one at the expected location. Each CloudPath node usually consists of the following six modules.

1) PathExecute: implements a serverless cloud container architecture that supports lightweight stateless application functions/modules. 2) PathStore: provides a distributed eventual consistent storage system that transparently manages application data across nodes. 3) PathRoute: transmits the request to the most appropriate CloudPath node, according to the information such as user’s location in the network, application preferences, or system status. 4) PathDeploy: dynamically deploys and removes applications on CloudPath nodes based on application preferences and system policies. 5) PathMonitor: provides real-time monitoring and historical data analysis function to applications and CloudPath nodes. It collects the metrics of other CloudPath modules on each node through the PathStore and presents the data to users using web pages. 6) PathInit: is an initialization module in the top-level data center node and can be used to upload applications/services to the CloudPath.

Ii-C PCloud

Fig. 5: PCloud Architecture [38].

PCloud [38] integrates the edge computing and storage resources with those at the cloud to support seamless mobile services. The architecture of PCloud is shown in Fig. 5. Specifically, these resources are virtualized through a special virtualization layer named STRATUS [39], and form a distributed resource pool that can discover new resources and monitor resource changes. With the resource pool, the runtime mechanism is responsible for resource application and allocation. Through a resource description interface, the runtime mechanism selects and combines appropriate resources based on the requirements of specified applications. After the resources are combined, it generates a new instance to provide corresponding services for external applications, according to the resource access control policy. (Note that, the computing resources of the newly generated instance may come from multiple devices, which is equivalent to one integrated computing device for the external applications.) Thus, an application program is actually a combination of services running on the PCloud instance. For example, a media player application can be a combination of the storage, decoding and playing services. These services could be local or remote but are transparent to the applications. Furthermore, the PCloud system also provides basic system services, such as permission management and user data aggregation, to control the resources access of other users.

In the actual operation, the mobile application describes the required resources to the PCloud through interfaces. The PCloud will find out the optimal resource configuration by analyzing the description and the currently available resources, and then generates an instance to provide corresponding services for the application. PCloud integrates edge resources with cloud resources so that they can complement each other. The abundant resources from the cloud can make up for the lack of computing and storage capabilities at the edge; meanwhile, due to the physical proximity, edge devices can provide low-latency services to the user that cloud cannot offer. In addition, PCloud also enhances the availability of the entire system and can choose alternate resources when encountering network and equipment failures.

Ii-D ParaDrop

Fig. 6: ParaDrop System [49].

ParaDrop [49] is developed by the WiNGS Laboratory at the University of Wisconsin-Madison. It is an edge computing framework that makes the computing/storage resources close to mobile devices and data sources available to the third party developers. Its goal is to bring intelligence to the network edge in a friendly way.

ParaDrop upgrades the existing access point to an edge computing system, which supports applications and services like a normal server. To isolate applications under the multi-tenancy scenario, ParaDrop leverages the lightweight container virtualization technique. As Fig. 6 shows, the ParaDrop server (in the cloud) controls the deployment, starting and deletion of the applications. It provides a group of APIs, via which the developer can monitor and manage the system resources and configure the running environment. The web UI is also provided, through which the user can directly interact with the applications.

The design goals of ParaDrop include three aspects: multi-tenancy, efficient resource utilization and dynamic application management. To achieve these goals, the container technology is applied to manage the multi-tenancy resources separately. As the resources of the edge devices are very limited, compared with the virtual machine, the container consumes less resources and would be more suitable for delay sensitive and high I/O applications. Moreover, as applications running in the container, ParaDrop can easily control their startup and revocation.

ParaDrop is mainly used for IoT applications, especially IoT data analysis. Its advantages over traditional cloud system can be summarized as follows: a) since sensitive data can be processed locally, it protects the users’ privacy; b) WiFi access point is only one hop away from the data source, leading to low network delay and stable connection; c) only user requested data are transmitted to the equipment through the Internet, thus cutting down the total traffic amount and saving the bandwidth of the backbone network; d) the gateway can obtain the location information of the edge devices through radio signals (e.g., the distance between devices, and the location of the specific device), which facilitates the location-aware services; e) when edge devices cannot be connected to the Internet, the edge service can still work.

Ii-E SpanEdge

Fig. 7: SpanEdge Architecture [66].

Streaming processing is one important type of applications in edge computing, where data is generated by various data sources in different geographical locations and continuously transmitted in the form of streams. Traditionally, all raw data is transmitted over the WAN to the data center server, and stream processing systems, such as Apache Spark and Flink, are also designed and optimized for one centralized data center. However, this approach cannot effectively handle the huge data generated by a lot of devices at the edge of the network, and the situation is even worse when the applications require low latency and predictability. SpanEdge [66] is a research project of the Royal Institute of Technology in Sweden. It unifies the cloud central node and the near-edge central node, reduces network latency in WAN connections, and provides a programming environment that allows the program to run near the data source. Developers can focus on developing streaming applications without considering where the data sources are located and distributed.

The data center in SpanEdge is composed of two levels: the cloud data center is the first level and the edge data center (such as the operator’s cloud, Cloudlet, or Fog) is the second level. Partial streaming processing tasks run on the edge central nodes to reduce latency and boost performance. SpanEdge uses the master-worker architecture (as shown in Fig. 7) with one manager and multiple workers. The manager collects the streaming processing requests and assigns tasks to the workers. Workers mainly consist of cluster nodes whose primary responsibility is to execute tasks. There are two types of workers: hub-worker (first level) and spoke-worker (second level). The network transmission overhead and latency are related to the geographical location and network connection status between workers. The communication in SpanEdge is also divided into a system management communication (worker-manager) and a data transmission communication (worker-worker). System management communication aims to schedule tasks between managers and workers, and data transmission communication takes care of the data flow in each task. Each worker has an agent that handles system management operations, such as sending and receiving management information, monitoring compute nodes to ensure that they are running normally, and periodically sending heartbeat messages to the manager to ensure immediate recovery when the task fails.

SpanEdge allows developers to divide the tasks into local ones and global ones. Local tasks should run on the node near the data source and provide only part of the required data; global tasks are responsible for further processing the results of local tasks and aggregating all results. SpanEdge creates a copy of the local task on each spoke-worker which has all corresponding data sources. If the data is insufficient, the task is dispatched to the hub-worker. The global task runs on a separate hub-worker, and the scheduler selects the optimal hub-worker based on the network delay (i.e. the distance from the spoke-worker in the network topology).

Ii-F Cloud-Sea Computing Systems

Fig. 8: Cloud-Sea Computing Model.

Cloud-Sea Computing Systems project [80] is a main research thrust of the Next Generation Information and Communication Technology initiative (the NICT initiative) and a 10-year strategic priority research initiative, launched by the Chinese Academy of Science in 2012. The NICT initiative aims to address the three major technology challenges in the coming Zettabyte era: i) improving the performance per watt by times, ii) supporting more applications from the human-cyber-physical ternary computing, and iii) enabling transformative innovations in devices, systems and applications, while without polluting beneficial IT ecosystems.

In the cloud-sea computing system, “cloud” refers to the datacenters and “sea” refers to the terminal side (the client devices, e.g., human-facing and physical world facing subsystems). The design of the project can be depicted from three levels: the overall systems architecture level, the datacenter server and storage system level, and the processor chip level. The project contains four research components: a computing model called REST 2.0 which extends the representational state transfer (REST) [28] architectural style of Web computing to cloud-sea computing, a three-tier storage system architecture capable of managing ZBs of data, a billion-thread datacenter server with high energy efficiency, and an elastic processor aiming at energy efficiency of one trillion operations per second per watt.

As shown in Fig. 8, the cloud-sea computing model includes sea-side functions and cloud-side functions. The sea zone is expanded from the traditional cloud client, e.g., a home, an office, a factory manufacturing pipeline. There can be multiple client devices inside a sea zone, and each device can be human facing or physical world facing. In a sea zone, there is a special device (like a home datacenter or a smart TV set) designated as the seaport for three purposes: i) a gateway interfacing the sea zone to the cloud, ii) a gathering point of information and functionalities inside a sea zone, and iii) a shield protecting security and privacy of the sea zone. A device inside a sea zone does not communicate to the cloud directly, but through the seaport, either implicitly or explicitly. The SeaHTTP, a variant based on HTTP , is the widely-used protocol in sea zones of the cloud-sea system to connect with the cloud.

The cloud-sea computing model has four distinct features.

1) Ternary computing via sea devices: Human and physical world entities interface and collaborate with the cyberspace through the sea side. For example, users can leverage a smart phone application to read and control a sensor device in a home through an Internet application service.

2) Cooperation with locality: A specific network computing system will partition its functions between the sea side and the cloud side. Sea-side functions include sensing, interaction, and local processing while cloud-side functions include aggregations, request-response, and big data processing.

3) Scalability to ZB and trillion devices: This future Net will collectively need to support trillions of sea devices and to handle ZBs of data.

4) Minimal extension to existing ecosystems: The REST cloud-sea computing architecture attempts to utilize existing Web computing ecosystems as much as possible.

Overall, the cloud-sea computing model is proposed to migrate the cloud computing function to the sea side, and it focuses more on the devices at the “sea” side and the data at the “cloud” side. Typical edge computing is more generalized and may care about any intermediate computing resources and network resources between the “sea” and the “cloud”. The researches in cloud-sea computing (e.g., energy efficient computing and elastic processor designing) are consultative for the edge computing.

Ii-G Cachier and Precog

Fig. 9: Cachier System [21].

Cachier [21] and Precog [20] are two edge caching systems that proposed by the researchers from Carnegie Mellon University for image recognition. Recognition applications have strict response time requirements, while the computation is huge due to the model complexity and dataset size. With edge computing, we can leverage the computing resource of the edge nodes to process the matching, so the network delay can be reduced. Considering that edge nodes mainly provide services to nearby users, the spatio-temporal characteristics of service requests can be leveraged. From the perspective of caching, Cachier system proposes that edge nodes can be used as “computable cache devices”, which can cache recognition results, reduce matching dataset size and improve response time. By analyzing the response delay model and requests’ characteristics, the system can dynamically adjust the size of the dataset on the edge nodes according to the environment factors, thus ensuring optimal response time.

As Fig. 9

shows, Cachier consists of the Recognizer Module, the Optimizer Module, and the Offline Analysis Module. The Recognizer Module is responsible for analyzing and matching the received figures according to the cached training data and model. If there is a match, the result will be directly returned to the user, otherwise the figure will be transmitted to the cloud for recognition. The distribution estimator in the Optimizer Module can use the maximum a posteriori estimation to predict the request distribution. Secondly, given the classification algorithm and training dataset, the cache searching delay and the cache accuracy can also be calculated by the Offline Analysis Module. At last, the Profiler sub-module is responsible for estimating the network delay and cloud latency incurred by cache misses. It measures and records the delay under corresponding distance in real time, and uses the moving average filter to remove the noise data. By taking such information into the delay expectation time model, Cachier is able to calculate the optimal cache size, and then adjusts the cache on the edge nodes accordingly.

Fig. 10: Precog System [20].

Precog is an extension of Cachier. The cached data is not only on the edge nodes, but also on the end devices which are used for selection calculation in order to reduce the image migration between the edge nodes and the cloud. Based on the prediction model, Precog prefetches some of the trained classifiers, uses them to recognize the images, and cooperates with the edge nodes to efficiently complete the tasks. Precog pushes computing capability to the end device and leverages the locality and selectivity of the user requests to reduce the last mile delay. For the end device, if the cache system uses the same cache replacement policy as the edge node applies, it will lead to a large number of forced misses. For a single user, the device only has the request information of the user, and usually the user will not identify the same object multiple times in the near future. Therefore, Precog constructs a Markov model using the request information from the edge node to describe the relationship among the identified objects, and then predicts the potential future requests. Precog improves the delay expectation time model by considering the network state, device capabilities and the prediction information from edge nodes. The system architecture of Precog is illustrated in Fig. 

10

. We can see that it is mainly composed of the feature extraction module, the offline analysis module, the optimizer module and the profiler module. The edge node is mainly responsible for the construction of Markov model. Based on the offline analysis results, the Markov model prediction results, and the network information provided by the profiler module, the optimizer module determines the number of feature to be extracted as well as the data to be cached on the end device.

Ii-H FocusStack

Fig. 11: FocusStack System [5].

FocusStack [5] is developed by AT&T Labs, which supports the deployment of complex applications on a variety of potential IoT edge devices. Although the resources, such as computing, power consumption, connectivity, are limited on edge devices, they have the nature of mobility. Hence, it is very important to have a system that can discover and organize available edge resources. FocusStack is such a system that can discover a set of edge devices with sufficient resources, deploy applications and run them accordingly. Thus, the developers can focus more on the design of applications than on how to find and track edge resources.

FocusStack consists of two parts (as shown in Fig. 11): i) Geocast system, which provides location-based situational awareness (LSA) information, and ii) OpenStack extension (OSE), which is responsible for deploying, executing, and managing the containers on the edge devices. FocusStack builds a hybrid cloud of edge devices (containers) and data center servers (virtual machines). When a user initiates a cloud operation through the FocusStack API (such as instantiating a container), the LSA subsystem analyzes the scope of the request based on the Geocast route and sends a resource list of geographic locations to the target area, and waits for the response from (online) edge devices that can satisfy the requirements. Then, the selected edge device runs the corresponding OpenStack operations with the help of the conductor module.

The situational aware subsystem enables one group of devices to monitor the survival status of each other, and each device can update the sensing information of other devices. The geo-processing projection service is primarily intended to pass requests and reply messages between areas of interest, send out device control information (like drones) and broadcast location-based information. The service is based on a two-layer network, and data can be transmitted over a dedicated WiFi network or the Internet. The sender transmits the data packet to the geo-router server which tracks the location and metadata of each edge device, and then the data packet is sent to each device (including edge devices and a cloud device running a SAMonitor instance) in the specified area based on the address. Location and connection statuses are maintained by the geo-routing database (GRDB). The GCLib is a software framework that provides data acquisition services, and it runs on edge devices and cloud applications that use SAMonitor. Any application or service in need of the state of the device in the area needs a SAMonitor component to communicate with the LSA subsystem. The application server makes a request to SAMonitor through the FocusStack API, and then SAMonitor builds a real-time graph of the current area and returns a list of available edge devices. The regional graph is sent to the conductor in the OSE, which is responsible for checking whether the devices are capable of running the tasks, whether the pre-defined policy rules are met, and so on. After that, the available edge device list is submitted to the application server and the server selects devices to be used. OSE manages and deploys the program through the OpenStack Nova API. The edge devices run a custom version of Nova Compute to interact with the local Docker to manage the container. The container on the edge devices supports all OpenStack services, including access to virtual networks and application-based granularity configuration.

Ii-I AirBox

Fig. 12: AirBox Architecture [11].

AirBox [11] is a secure, lightweight and flexible edge function system developed by Georgia Institute of Technology. It supports fast and flexible edge function loading and provides service security and user privacy protection. The Edge Function (EF) in AirBox is defined as a service that can be loaded on an edge node, and the software stack that supports the edge function is named Edge Function Platform (EFP).

As shown in Fig. 12, the AirBox consists of two parts: the AB console and the AB provisioner. The back-end service manager deploys and manages the EF on the edge nodes through the AB console. The AB provisioner which runs at the edge is responsible for providing dynamic EF seamlessly. The edge functions are implemented through system-level containers with minimal constraints on developers. Security is enhanced by using the hardware security mechanisms like Intel SGX. AirBox provides centrally controlled backend services in discovering edge nodes and registering them. The AB console is a web-based management system, which activates the docker start-up process on the edge node with AB provisioner.

To ensure the security of the AirBox, the EF consists of a trusted part and an untrusted part. The untrusted part is responsible for all network and storage interactions. Based on OpenSGX APIs, AirBox provides four extensible APIs to implement secure communication and storage: Remote Attestation, Remote Authentication, Sealed Storage, and EF Defined Interface. AirBox supports a variety of edge features such as aggregation, buffering, and caching.

Ii-J Firework

Wayne State University’s MIST Lab proposes a programming model for edge computing—Firework [85]. In the model of Firework, all services/functions are represented in a data view of datasets and functions which can be the results of processing with their own data or secondary processing with other services/datasets. A system consisting of nodes that apply the Firework model is called the Firework system. In the Firework system, instead of dividing nodes into edge nodes and cloud ones, they are all considered as Firework nodes. Through the mutual invocation of the Firework nodes, the data can be distributed and processed on each node. Along the path of data transmission, the edge nodes perform a series of calculations upon the data, thus forming a “computational flow”. The beginning of the computational flow could be user terminals, edge servers close to the user, edge servers close to the cloud, or cloud nodes.

In the Firework system, the data processing service is split into multiple sub-services, and the scheduling of the data processing is performed at the following two layers.

1) Same sub-service layer scheduling: A Firework node can cooperate with another for the same sub-services in the surrounding area to achieve optimal response time. For idle Firework nodes, the system can schedule sub-service programs onto them, such that a cluster providing specific sub-service is formed dynamically and complete the service faster.

2) Computational flow layer scheduling: Firework nodes along the computational flow can cooperate with each other and dynamically schedule execution nodes to achieve an optimal solution. For example, depending on the states of the network, the system can choose Firework nodes for service providing based on the nodes’ locations (e.g., selecting those closest to the users).

Fig. 13: An example of a Firework instance that consists of heterogeneous computing platforms [85].

As shown in Fig. 13, Firework divides the nodes into computing nodes and managers, depending on the type of service those nodes provide. In general, each node with the Firework model has three modules: the job management module, the actuator management module, and the service management module.

Application
Scenarios
Edge
Computing
Systems
End
Devices
Edge Nodes
Computation
Architecture
Features/Targets
General
Usage
Scenario
Cloudlet Mobile devices Cloudlet
Hybrid
(3-tier)
Lightweight
VM migration
PCloud Mobile devices
Mobile devices,
local server, PC
Hybrid
(3-tier)
Resource integration,
dynamic allocation
ParaDrop IoT devices Home gateway
Hybrid
(3-tier)
Hardware,
developer support
Cachier & Precog Mobile devices
Mobile devices,
local server, PC
Hybrid
(3-tier)
Figure recognition,
identification
FocusStack IoT devices Router, server
Hybrid
(3-tier)
Location-based info,
OpenStack extension
SpanEdge IoT devices
Local cluster,
Cloudlet, Fog
Hybrid
(2-tier)
Streaming processing,
local/global task
AirBox IoT devices
Mobile devices,
local server, PC
Hybrid
(3-tier)
Security
CloudPath Mobile devices
Multi-level
data centers
Hybrid
(multi-tier)
Path computing
Firework Firework.Node Firework.Node
Two-layer
scheduling
Programming model
Cloud-Sea Sea Seaport
Hybrid
(3-tier)
Minimal extension,
transparency
Vehicular
Data
Analytics
OpenVDAP CAVs XEdge
Hybrid
(2-tier)
General
platform
SafeShareRide
Smartphones
and vehicles
Smartphones
Hybrid
(2-tier)
In-vehicle
security
Smart
Home
Vigilia
Smart
home devices
Hubs
Edge
only
Smart
Home Security
HomePad
Smart
home devices
Routers
Edge
only
Smart
Home Security
Video
Stream
Analytics
LAVEA
Edge
or cloud
Low
latency response
VideoEdge Cameras
Cameras and
private
clusters
Hybrid
(3-tier)
Resource-accuracy
tradeoff
Video
on drones
Autonomous
drones
Portable
edge computers
Edge
only
Bandwidth
saving
Virtual
Reality
MUVR Smartphones
Individual
households
Edge
only
Resource utilization
efficiency
optimization
TABLE I: Summary of edge computing systems

1) Service management module: This type of module is designed for the management of data views. It provides interfaces to update the data view, as well as relevant programs for data processing.

2) Job management module: This type of module is responsible for the scheduling, monitoring, and evaluation of the task executions. When the local computing resources are insufficient, the module can look into the node list and the data view and make resource re-scheduling at the same sub-service layer. When the sub-service is running, the module can also provide necessary monitoring information and give feedback to other upstream and downstream nodes for flow layer scheduling.

3) Actuator management module: This type of module is mainly responsible for managing all hardware resources and hosting the execution processes of different tasks. With the help of this module, the device, running environment and the upper layer functions could be decoupled, so that the nodes of Firework system are not limited to a certain type of devices, and the data processing environment is not limited to a certain type of computing platform.

Ii-K Other Edge Computing Systems

The edge systems introduced above depict some typical and basic innovations on the exploitation of edge analytics for highly-responsive services. The previous systems are used in general cases, which lay the foundation of further development. We highlight that, in addition to these efforts, there are many other edge systems tuned for a series of different application scenarios.In Table I, we briefly summarize the general and application-specific edge systems, which leverage different kinds of edge nodes to serve diverse end devices using either a hybrid or edge only computation architecture.

Compared to both on-board computation and cloud-based computation, edge computing can provide more effective data analytics with lower latency for the moving vehicles [84]. In [84], an open full-stack edge computing-based platform OpenVDAP is proposed for the data analytics of connected and autonomous vehicles (CAVs). OpenVDAP proposes systematic mechanisms, including varied wireless interfaces, to utilize the heterogeneous computation resources of nearby CAVs, edge nodes, and the cloud. For optimal utilization of the resources, a dynamic scheduling interface is also provided to sense the status of available resources and to offload divided tasks in a distributed way for computation efficiency. SafeShareRide is an edge-based attack detection system addressing in-vehicle security for ridesharing services [48]. Its three detection stages leverage both the smartphones of drivers and passengers as edge computing platform to collect multimedia information in vehicles. Specifically, speech recognition and driving behavior detection stages are first carried out independently to capture in-vehicle danger, and video capture and uploading stage is activated when abnormal keywords or dangerous behaviors are detected to collect videos for cloud-based analysis. By using such an edge-cloud collaborative architecture, SafeShareRide can accurately detect attacks in-vehicle with low bandwidth demand.

Another scenario that edge computing can play an important role is the IoT devices management in the smart home environment. Wherein, the privacy issue of the wide range of home-devices is a popular topic. In [76], the Vigilia system is proposed to harden smart home systems by restricting the network access of devices. A default access deny policy and an API-granularity device access mechanism for applications are adopted to enforce access at the network level. Run time checking implemented in the routers only permits those declared communications, thus helping users secure their home-devices. Similarly, the HomePad system in [82] also proposes to execute IoT applications at the edge and introduces a privacy-aware hub to mitigate security concerns. Homepad allows users to specify privacy policy to regulate how applications access and process their data. Through enforcing applications to use explicit information flow, Homepad can use Prolog rules to verify whether applications have the ability to violate the defined privacy policy at install time.

Edge computing has also been widely used in the analysis of video stream. LAVEA is an edge-based system built for latency-aware video analytics nearby the end users [81]. In order to minimize the response time, LAVEA formulates an optimization problem to determine which part of tasks to be offloaded to the edge computer and uses a task queue prioritizer to minimize the makespan. It also proposes several task placement schemes to enable the collaboration of nearby edge nodes, which can further reduce the overall task completion time. VideoEdge is a system that provides the most promising video analytics implementation across a hierarchy of clusters in the city environment [35]. A 3-tier computation architecture is considered with deployed cameras and private clusters as the edge and remote server as the cloud. The hierarchical edge architecture is also adopted in [75]

and is believed to be promising in processing live video stream at scale. Technically, VideoEdge searches thousands of combinations of computer vision components implementation, knobs, and placement and finds a configuration to balance the accuracy and resource demands using an efficient heuristic. In 

[78], a video analytics system for autonomous drones is proposed, where edge computing is introduced to save the bandwidth. Portable edge computers are required here to support dynamic transportation during a mission. Totally four different video transmission strategies are presented to build an adaptive and efficient computer vision pipeline. In addition to the analytics work (e.g., object recognition), the edge nodes also train filters for the drones to avoid the uploading of the uninteresting video frames.

In order to provide flexible virtual reality (VR) on untethered smartphones, edge computing can be useful to transport the heavy workload from smartphones to their nearby edge cloud [46]. However, the rendering task of the panoramic VR frames (i.e., 2GB per second) will also saturate the individual households as common edge in the house. In [46], the MUVR system is designed to support multi-user VR with efficient bandwidth and computation resources utilization. MUVR is built on a basic observation that the VR frames being rendered and transmitted to different users are highly redundant. For computation efficiency, MUVR maintains a two-level hierarchical cache for invariant background at the edge and the user end to reuse frames whenever necessary. Meanwhile, MUVR transmits a part of all frames in full and delivers the distinct portion for the rest frames to further reduce the transmission costs.

Iii Open Source Edge Computing Projects

Besides the designed edge computing systems for specific purposes, some open source edge computing projects have also been launched recently. The Linux Foundation published two projects, EdgeX Foundry in 2017 and Akraino Edge Statck [4] in 2018. The Open Network Foundation(ONF) launched a project namely CORD (Central Office Re-architected as a Datacenter) [17]. The Apache Software Foundation published Apache Edgent. Microsoft published Azure IoT Edge in 2017 and announced it as an open source in 2018.

Among them, CORD and Akraino Edge Stack focus on providing edge cloud services; EdgeX Foundry and Apache Edgent focus on IoT and aim to solve problems which bring difficulties to practical applications of edge computing in IoT; Azure IoT Edge provides hybrid cloud-edge analytics, which helps to migrate cloud solutions to IoT devices.

Iii-a Cord

Fig. 14: Hardware Architecture of CORD.

CORD is an open source project of ONF initiated by AT&T and is designed for network operators. Current network infrastructure is built with closed proprietary integrated systems provided by network equipment providers. Due to the closed property, the network capability cannot scale up and down dynamically. And the lack of flexibility results in inefficient utilization of the computing and networking resources. CORD plans to reconstruct the edge network infrastructure to build datacenters with SDN [57], NFV [34] and Cloud technologies. It attempts to slice the computing, storage and network resources so that these datacenters can act as clouds at the edge, providing agile services for end users.

Fig. 15: Software Architecture of CORD.

CORD is an integrated system built from commodity hardware and open source software. Fig. 14 shows the hardware architecture of CORD [17]. It uses commodity servers that are interconnected by a Fabric of White-box switches. White-box switch [51] is a component of SDN switch, which is responsible to regulate the flow of data according to SDN controller. These commodity servers provide computing, storage resources, and the fabric of switches are used to build the network. This switching fabric is organized to a Spine-Leaf topology [61], a kind of flat network topology structure which adds a horizontal network structure parallel to the trunk longitudinal network structure, and then adds corresponding switching network on the horizontal structure. Comparing to traditional three-tier network topology, it can provide scalable throughput for greater East-to-West network traffic, that is, traffic coming from network diagram drawings that usually depict local area network (LAN) traffic horizontally. In addition, specialized access hardware is required to connect subscribers. The subscribers can be divided into three categories for different use cases, mobile subscribers, enterprise subscribers and residential subscribers. Each category demands different access hardware due to different access technologies. In terms of software, Fig. 15 shows the software architecture of CORD [17]. Based on the servers and the fabric of switches, OpenStack provides with IaaS capability for CORD, it manages the compute, storage and networking resources as well as creating virtual machines and virtual networks. Docker is used to run services in containers for isolation. ONOS(Open Network Operating System) is a network operating system which is used to manage network components like the switching fabric and provide communication services to end-users. XOS provides a control plane to assemble and compose services. Other software projects provide component capabilities, for example, vRouter(Virtual Router) provides with virtual routing functionality.

The edge of the operator network is a sweet spot for edge computing because it connects customers with operators and is close to customers’ applications as data sources. CORD takes edge computing into consideration and moves to support edge computing as a platform to provide edge cloud services (from the released version ). CORD can be deployed into three solution, M-CORD (Mobile CORD), R-CORD (Residential CORD) and E-CORD (Enterprise CORD) for different use cases. M-CORD focuses on mobile network, especially 5G network, and it plans to disaggregate and virtualize cellular network functions to enable services be created and scaled dynamically. This agility helps to provide multi-access edge services for mobile applications. For those use cases like driverless cars or drones, users can rent the edge service to run their edge applications. Similarly, R-CORD and E-CORD are designed to be agile service delivery platforms but for different users, residential and enterprise users relatively.

So far, the deployment of CORD is still under test among network operators, and more researches are needed to combine CORD with various edge applications.

Iii-B Akraino Edge Stack

Akraino Edge Stack, initiated by AT&T and now hosted by Linux Foundation, is a project to develop a holistic solution for edge infrastructure so as to support high-availability edge cloud services [4]. An open source software stack, as the software part of this solution, is developed for network carrier to facilitate optimal networking and workload orchestration for underlying infrastructure in order to meet the need of edge computing such as low latency, high performance, high availability, scalability and so on.

To provide a holistic solution, Akraino Edge Stack has a wide scope from infrastructure layer to application layer. Fig. 16 [4] shows the scope with three layers. In the application layer, Akraino Edge Stack wants to create a virutal network function (VNF) ecosystem and calls for edge applications. The second layer consists of middleware which supports applications in the top layer. In this layer, Akraino Edge Stack plans to develop Edge API and framework for interoperability with 3rd party Edge projects such as EdgeX Foundry. At the bottom layer, Akraino Edge Stack intends to develop an open source software stack for the edge infrastructure in collaboration with upstream communities. It interfaces with and maximizes the use of existing open source projects such as Kubernetes, OpenStack and so on. Akraino Edge Stack provides different edge use cases with blueprints, which are declarative configurations of entire stack including hardware, software, point of delivery, etc [4]. The application domains of these blueprints start from Telco industry and are expected to applied in more domains like Enterprise and industrial IoT. Now Akraino Edge Stack has put forward several blueprints such as Micro-MEC and Edge Media Processing. Micro-MEC intends to develop a new service infrastructure for smart cities, which enables developing services for smart city and has high data capacity for citizens. Edge Media Processing intends to develop a network cloud to enable real-time media processing and edge media AI analytics with low latency.

Fig. 16: Akraino Edge Stack’s Scope.

As an emerging project, Akraino Edge Stack has been taken to execution since August 2018. Thus more researches need to be done with the development of this project.

Iii-C EdgeX Foundry

EdgeX Foundry is a standardized interoperability framework for IoT edge computing, whose sweet spots are edge nodes such as gateways, hubs, and routers [25]. It can connect with various sensors and devices via different protocols, manage them and collect data from them, and export the data to a local application at the edge or the cloud for further processing. EdgeX is designed to be agnostic to hardware, CPU, operating system, and application environment. It can run natively or run in docker containers.

Fig. 17 [25] shows the architecture of EdgeX Foundry. “South side” at the bottom of the figure includes all IoT objects, and the edge of the network that communicates directly with those devices, sensors, actuators and other IoT objects to collect the data from them. Relatively, “north side” at the top of the figure includes the Cloud (or Enterprise system) where data are collected, stored, aggregated, analyzed, and turned into information, and the part of the network that communicates with the Cloud. EdgeX Foundry connects these two sides regardless of the differences of hardware, software and network. EdgeX tries to unify the manipulation method of the IoT objects from the south side to a common API, so that those objects can be manipulated in the same way by the applications of north side.

EdgeX uses a Device Profile to describe a south side object. A Device Profile defines the type of the object, the format of data that the object provides, the format of data to be stored in EdgeX and the commands used to manipulate this object. Each Device Profile involves a Device Service, which is a service that converts the format of the data, and translates the commands into instructions that IoT objects know how to execute. EdgeX provides SDK for developers to create Device Services, so that it can support for any combination of device interfaces and protocols by programming.

Fig. 17: Architecture of EdgeX Foundry.

EdgeX consists of a collection of microservices, which allows services to scale up and down based on device capability. These microservices can be grouped into four service layers and two underlying augmenting system services, as depicted in Fig. 17. The four service layers include Device Services Layer, Core Services Layer, Supporting Services Layer and Export Services Layer, respectively; the two underlying augmenting system services are System Management and Security, respectively. Each of the six layers consists of several components and all components use a common Restful API for configuration.

1) Device Services Layer: This layer consists of Device Services. According to the Device Profiles, Device Service Layer converts the format of the data, sends them to Core Services Layer, and translates the command requests from the Core Services Layer.

2) Core Services Layer: This layer consists of four components: Core Data, Command, Metadata, and Registry & Configuration. Core Data is a persistence repository as well as a management service. It stores and manages the data collected from the south side objects. Command is a service to offer the API for command requests from the north side to Device Services. Metadata is a repository and management service for metadata about IoT objects. For example, the Device Profiles are uploaded and stored in Metadata. Registry & Configuration provides centralized management of configuration and operating parameters for other microservices.

3) Supporting Services Layer: This layer is designed to provide edge analytics and intelligence [34]. Now the Rules Engine, Alerting and Notification, Scheduling and Logging microservices are implemented. A target range of data can be set to trigger a specific device actuation as a rule and Rules Engine helps realize the rule by monitoring the incoming data. Alerting and Notifications can send notifications or alerts to another system or person by email, REST callback or other methods when an urgent actuation or a service malfunction happens. The scheduling module can set up a timer to regularly clean up the stale data. Logging is used to record the running information of EdgeX.

4) Export Services Layer: This layer connects EdgeX with North Side and consists of Client Registration and Export Distribution. Client Registration enables clients like a specific cloud or a local application to register as recipients of data from Core Data. Export Distribution distributes the data to the Clients registered in Client Registration.

5) System Management and Security: System Management provides management operations including installation, upgrade, starting, stopping and monitoring, as EdgeX is scalable and can be deployed dynamically. Security is designed to protect the data and command of IoT objects connected with EdgeX Foundry.

EdgeX is designed for the user cases dealing with multitudes of sensors or devices, such as automated factories, machinery systems and lots of other cases in IoT. Now EdgeX Foundry is in the rapid upgrading phase, and more features will be added in future releases. An EdgeX UI is in development as a web-based interface to add and manage the devices.

Iii-D Apache Edgent

Apache Edgent, which was known as Apache Quarks previously, is an Apache Incubator project at present. It is an open source programming model for lightweight runtime data analytics, used in small devices such as routers and gateways at the edge. Apache Edgent focuses on data analytics at the edge, aiming to accelerate the development of data analysis.

Fig. 18: Model of the Edgent Applications.

As a programming model, Edgent provides API to build edge applications. Fig. 18 illustrates the model of the Edgent applications. Edgent uses a topology as a graph to represent the processing transformation of streams of data which are abstracted to a Tstream class. A connector is used to get streams of data from external entities such as sensors and devices in physical world, or to send streams of data to back-end systems like a cloud. The primary API of Edgent is responsible for data analysis. The streams of data can be filtered, split, transformed or processed by other operations in a topology. Edgent uses a provider to act as a factory to create and execute topologies. To build an Edgent application, users should firstly get a provider, then create a topology and add the processing flow to deal with the streams of data, and finally submit the topology. The deployment environments of Edgent are Java 8, Java 7 and Android.

Edgent provides APIs for sending data to back-end systems and now supports MQTT, IBM Watson IoT Platform, Apache Kafka and custom message hubs. Edgent applications analyze the data from sensors and devices, and send the essential data to the back-end system for further analysis. For IoT use cases, Edgent helps reduce the cost of transmitting data and provide local feedback.

Edgent is suitable for use cases in IoT such as intelligent transportation, automated factories and so on. In addition, the data in Edgent applications are not limited to sensor readings, they can also be files or logs. Therefore, Edgent can be applied to other use cases. For example, it can perform local data analysis when embedded in application servers, where it can analyze error logs without impacting network traffic [6].

Iii-E Azure IoT Edge

Fig. 19: Diagram of Azure IoT Edge.

Azure IoT Edge, provided by Microsoft Azure as a cloud service provider, tries to move cloud analytics to edge devices. These edge devices can be routers, gateways or other devices which can provide computing resources. The programming model of Azure IoT Edge is the same as that of other Azure IoT services [9] in the cloud, which enables user to move their existing applications from Azure to the edge devices for lower latency. The convenience simplifies the development of edge applications. In addition, Azure services like Azure Functions, Azure Machine Learning and Azure Stream Analytics can be used to deploy complex tasks on the edge devices such as machine learning, image recognition and other tasks about artificial intelligence.

Azure IoT Edge consists of three components: IoT Edge modules, IoT Edge runtime and a cloud-based interface as depicted in Fig. 19. The first two components run on edge devices, and the last one is an interface in the cloud. IoT Edge modules are containerized instances running the customer code or Azure services. IoT Edge runtime manages these modules. The cloud-based interface is used to monitor and manage the former two components, in other words, monitor and manage the edge devices.

IoT Edge modules are the places that run specific applications as the units of execution. A module image is a docker image containing the user code. A module instance, as a docker container, is a unit of computation running the module image. If the resources at the edge devices are sufficient, these modules can run the same Azure services or custom applications as in the cloud because of the same programming model. In addition, these modules can be deployed dynamically as Azure IoT Edge is scalable.

IoT Edge runtime acts as a manager on the edge devices. It consists of two modules: IoT Edge hub and IoT Edge agent. IoT Edge hub acts as a local proxy for IoT Hub which is a managed service and a central message hub in the cloud. As a message broker, IoT Edge hub helps modules communicate with each other, and transport data to IoT Hub. IoT Edge agent is used to deploy and monitor the IoT Edge modules. It receives the deployment information about modules from IoT Hub, instantiates these modules, and ensures they are running, for example, restarts the crashed modules. In addition, it reports the status of the modules to the IoT hub.

IoT Edge cloud interface is provided for device management. By this interface, users can create edge applications, then send these applications to the device and monitor the running status of the device. This monitoring function is useful for use cases with massive devices, where users can deploy applications to devices on a large scale and monitor these devices.

A simple deployment procedure for applications is that: users choose a Azure service or write their own code as an application, build it as an IoT Edge module image, and deploy this module image to the edge device with the help of the IoT Edge interface. Then the IoT Edge receives the deployment information, pulls the module image, and instantiates the module instance.

Azure IoT Edge has wide application areas. Now it has application cases on intelligent manufacturing, irrigation system, drone management system and so on. It is worth noting that Azure IoT Edge is open-source but the Azure services like Azure Functions, Azure Machine Learning and Azure Stream are charged.

Iii-F Comparative Study

We summarize the features of the above open source edge computing systems in Table II. Then we compare them from different aspects in Table II, including the main purpose of the systems,application area, deployment, target user, virtualization technology, system characteristic, limitations, scalability and mobility. We believe such comparisons give better understandings of current open source edge computing systems.

Aspect EdgeX Foundry
Azure IoT
Edge
Apache Edgent CORD
Akraino
Edge Stack
User access
interface
Restful API
or EdgeX UI
Web service,
Command-line
API
API or
XOS-GUI
N/A
OS support Various OS Various OS Various OS Ubuntu Linux
Programming
framework
Not provided
Java, .NET, C,
Python, etc.
Java
Shell script,
Python
N/A
Main purpose
Provide with
Interoperability
for IoT edge
Support hybrid
cloud-edge
analytics
Accelerate the
development
process of
data analysis
Transform edge of
the operator network
into agile service
delivery platforms
Support edge
clouds with an
open source
software stack
Application area IoT Unrestricted IoT Unrestricted Unrestricted
Deployment Dynamic Dynamic Static Dynamic Dynamic
Target user General users General users General users Network operators
Network
operators
Virtualization
technology
Container Container JVM
Virtual Machine
and Container
Virtual Machine
and Container
System
characteristics
A common API for
device management
Powerful
Azure services
APIs for
data analytics
Widespread
edge clouds
Widespread
edge clouds
Limitation
Lack of
programable
interface
Azure Services
is chargeable
Limited to
data analytics
Unable to
be offline
Unable to
be offline
Scalability
Scalable
Scalable
Not scalable
Scalable
Scalable
Mobility
Not support
Not support
Not support
Support
Support
TABLE II: Comparison of Open Edge System Characteristics

Iii-F1 Main purpose

The main purpose shows the target problem that a system tries to fix, and it is a key factor for us to choose a suitable system to run edge applications. As an interoperability framework, EdgeX Foundry aims to communicate with any sensor or device in IoT. This ability is necessary for edge applications with data from various sensors and devices. Azure IoT Edge offers an efficient solution to move the existing applications from cloud to edge, and to develop edge applications in the same way with the cloud applications. Apache Edgent helps to accelerate the development process of data analysis in IoT use cases. CORD aims to reconstruct current edge network infrastructure to build datacenters so as to provide agile network services for end-user customers. From the view of edge computing, CORD provides with multi-access edge services. Akraino Edge Stack provides an open source software stack to support high-availability edge clouds.

Iii-F2 Application area

EdgeX Foundry and Apache Edgent both focus on IoT edge, and EdgeX Foundry is geared toward communication with various sensors and devices, while Edgent is geared toward data analysis. They are suitable for intelligent manufacturing, intelligent transportation and smart city where various sensors and devices generate data all the time. Azure IoT Edge can be thought as the expansion of Azure Cloud. It has an extensive application area but depends on the compute resources of edge devices. Besides, it is very convenient to deploy edge applications about artificial intelligence such as machine learning and image recognition to Azure IoT Edge with the help of Azure services. CORD and Akraino Edge Stack support edge cloud services, which have no restriction on application area. If the edge devices of users don’t have sufficient computing capability, these two systems are suitable for users to run resource-intensive and interactive applications in connection with operator network.

Iii-F3 Deployment

As for the deployment requirements, EdgeX Foundry, Apache Edgent and Azure IoT Edge are deployed in edge devices such as routers, gateways, switchers and so on. Users can deploy EdgeX Foundry by themselves, add or reduce microservices dynamically, and run their own edge applications. Differently, users need the help of cloud-based interface to deploy Azure IoT Edge and develop their edge applications. CORD and Akraino Edge Stack are designed for network operators, who need fabric switches, access devices, network cards and other related hardware apart from compute machines. Customers have no need to think about the hardware requirements and management process of the hardware, but to rent the services provided by the network operators like renting a cloud service instead of managing a physical server.

Iii-F4 Target user

Though these open source systems focus on edge computing, their target users are not the same. EdgeX Foundry, Azure IoT Edge and Apache Edgent have no restriction on target users. Therefore, every developer can deploy them into local edge devices like gateways, routers and hubs. Differently, CORD and Akraino Edge Stack are created for network operators because they focus on edge infrastructure.

Iii-F5 Virtualization technology

Virtualization technologies are widely used nowadays. Virtual machine technology can provide better management and higher utilization of resources, stability, scalability and other advantages. Container technology can provide services with isolation and agility but with negligible overhead, which can be used in edge devices [54]. Using OpenStack and Docker as software components, CORD and Akraino Edge Stack use both of these two technologies to support edge cloud. Different edge devices may have different hardware and software environment. For those edge systems which are deployed on edge devices, container is a good technology for services to keep independence in different environment. Therefore, EdgeX Foundry and Azure IoT Edge choose to run as docker containers. As for Edgent, Edgent applications run on JVM.

Iii-F6 System characteristic

System characteristics show the unique features of the system, which may help users to develop, deploy or monitor their edge applications. It will save lots of workload and time if making good use of these characteristics. EdgeX Foundry provides a common API to manage the devices, and this brings great convenience to deploying and monitoring edge applications in large scale. Azure IoT Edge provides powerful Azure services to accelerate the development of edge applications. Apache Edgent provides a series of functional APIs for data analytics, which lowers the difficulty and reduces the time on developing edge analytic applications. CORD and Akraino Edge Stack provide with multi-access edge services on edge cloud. We only need to keep connection with operator network, and we can apply for these services without the need to deploy an edge computing system on edge devices by ourselves.

Iii-F7 Limitation

This subsection discusses the limitation of the latest version of them to deploy edge applications. The lastest version of EdgeX Foundry has not provided a programmable interface in its architecture for developers to write their own applications. Although EdgeX allows us to add custom implementations, it demands more workload and time. As for Azure IoT Edge, though it is open-source and free, Azure services are chargeable as commercial software. For Apache Edgent, it is lightweight and it focuses on only data analytics. As for CORD and Akraino Edge Stack, these two systems demand stable network between data sources and the operators because the edge applications are running on the edge of operator network rather than local devices.

Iii-F8 Scalability

Increasing applications at edge make the network architecture more complex and the application management more difficult. Scalability is one major concern in edge computing. Among these edge computing systems, Azure IoT Edge, CORD and Akraino Edge Stack apply docker technology or virtual machine technology to support users to scale up or down their applications efficiently by adding or deleting module images. EdgeX Foundry is also a scalable platform that enables users to dynamically add or reduce microservices to adapt to the actual needs. But Apache Edgent is not scalable enough because every Edgent application is a single Java application and performance cannot be changed dynamically.

Iii-F9 Mobility

For EdgeX Foundry, Apache Edgent and Azure IoT Edge, once the applications are executed on some edge devices, they cannot be dynamically migrated to other devices. CORD and Akraino Edge Stack, deployed in the telecom infrastructure, support mobile edge services through mobile access network like 4G/5G. The mobility of these systems meet the need of cases such as unmanned cars and drones.

Iii-F10 Scenarios

We discuss the choice of open-source tools from the perspective of the following three scenarios, as shown in Fig. 20.

Fig. 20: The choice of open-source tools in different scenarios.

In the first scenario, suppose IoT edge applications are running on local area network (LAN), and the local enterprise system is regarded as back-end system with no need for third-party clouds. In this case, EdgeX Foundry or Apache Edgent are favorable because they enable users to build and control their own back-end system without being bound to any specific cloud platform. Furthermore, for the sake of managing and controlling edge devices on a large scale, EdgeX Foundry is a better choice for good device management capability. If considering data analysis, Apache Edgent is preferable to EdgeX Foundry. It provides a programming model to accelerate the development of edge analytic applications and a set of powerful APIs for data processing.

In the second scenario, suppose the cloud services push to the edge of network to improve the quality. In this case, Auzre IoT Edge provides a convenient way for developers to migrate the applications from the cloud to the edge devices, and to leverage third-party high value services or functions when developing edge systems. Besides, AWS IoT Greengrass and Link IoT Edge, which are published by Amazon and Alibaba Cloud, are good choices as the competitive projects. More specifically, Azure IoT Edge provides Azure services such as Azure Functions, Azure Stream Analytics, and Azure Machine Learning. AWS IoT Greengrass can run AWS Lamda functions and machine learning models that are created, trained, and optimized in the cloud. Link IoT Edge provides Function Compute and other functions. Based on the application requirements, a suitable system could be chosen among them by taking account the functions they provide.

In the third scenario, suppose the users expect to directly leverage third-party services to deploy edge applications without any hardware or software system locally. In this case, edge systems such as CORD and Akraino Edge Stack are suitable. The users could choose one of them dependent on their application requirements. These systems are deployed by telecom operators. And telecom operators are also the providers of network services. Thus when there exist special network requirements of edge applications, these systems could satisfy the requirements. For example, edge computing applications on unmanned vehicles or drones need the support of wireless telecom networks (such as 4G/5G), in this case, a mobile edge computing service provided by these systems is a good choice.

In addition to the systems described above, there are other emerging open source projects. Device Management Edge, as part of Mbed IoT Platform published by ARM, is responsible for edge computing and provides the ability to access, manage and control Edge devices. KubeEdge, released by Huawei, provides edge nodes with native containerized application orchestration capabilities.

Iv Enhancing Energy Efficiency of Edge Computing Systems

In the design of an edge computing system, energy consumption is always considered as one of the major concerns and evaluated as one of the key performance metrics. In this section, we review the energy efficiency enhancing mechanisms adopted by the state-of-the-art edge computing systems, from the view of top cloud layer, middle edge server layer and bottom device layer, respectively (the three-layer paradigm is illustrated by Fig. 21).

Fig. 21: The Three-layer Edge Computing Paradigm from a Power Source View.

Iv-a At the Top Cloud Layer

For cloud computing, a centralized DC can comprise thousands of servers and thus consume enormous energy [53]. As an alternative to the cloud computing, does the edge/fog computing paradigm consume more or less energy? Different points of view have been given: some claim that decentralized data storage and processing supported by the edge computing architecture are more energy efficient [77, 67], while some others show that such distributed content delivery may consume more energy than that of the centralized way [27].

The authors in [37] give a thorough energy analysis for applications running over the centralized DC (i.e., under cloud mode) and decentralized nano DCs (i.e., under fog mode), respectively. The results indicate that the fog mode may be with a higher energy efficiency, depending on several system design factors (e.g., type of application, type of access network, and ratio of active time), and those applications that generate and distribute a large amount of data in end-user premises result in best energy saving under the fog mode.

Note that the decentralized nano DCs or fog nodes in our context are different from the traditional CDN datacenters [72, 73, 71]. They are also designed in a decentralized way but usually with much more powerful computing/communicating/storage capacities.

Iv-B At the Middle Edge Server Layer

At the middle layer of the edge computing paradigm, energy is also regarded as an important aspect, as the edge servers can be deployed in a domestic environment or powered by the battery (e.g., a desktop or a portable WiFi router, as shown in Fig. 21). Thus, to provide a higher availability, many power management techniques have been applied to limit the energy consumption of edge servers, while still ensuring their performances. We give a review of two major strategies used at the edge server layer in recent edge computing systems.

Iv-B1 Low-power system design and power management

In [44], the tactical cloudlet is presented and its energy consumption when performing VM synthesis is evaluated particularly, under different cloudlet provisioning mechanisms. The results show that the largest amount of energy is consumed by i) VM synthesis due to the large payload size, and ii) on-demand VM provisioning due to the long application-ready time. Such results lead to the high energy efficiency policy: combining cached VM with cloudlet push for cloudlet provision.

A service-oriented architecture for fog/edge computing, Fog Data, is proposed and evaluated in [23]. It is implemented with an embedded computer system and performs data mining and data analytics on the raw data collection from the wearable sensors (in telehealth applications). With Fog Data, orders of magnitude data are reduced for transmission, thus leading to enormous energy saving. Furthermore, Fog Data is with a low power architecture design, and even consumes much less energy than that of a Raspberry Pi.

In [7], a performance-aware orchestrator for Docker containers, named DockerCap, is developed to meet the power consumption constraints of the edge server (fog node). Following the observe-decide-act loop structure, DockerCap is able to manage container resources at run-time and provide soft-level power capping strategies. The experiments demonstrate that the obtained results with DockerCap is comparable to that from the power capping solution provided by the hardware (Intel RAPL).

An energy aware edge computer architecture is designed to be portable and usable in the fieldwork scenarios in [64]. Based on the architecture, a high-density cluster prototype is built using the compact general-purpose commodity hardware. Power management policies are implemented in the prototype to enable the real-time energy-awareness. Through various experiments, it shows that both the load balance strategies and cluster configurations have big impacts on the system energy consumption and responsiveness.

Iv-B2 Green-energy powered sustainable computing

Dual energy sources are employed to support the running of a fog computing based system in [56], where solar power is utilized as the primary energy supply of the fog nodes. A comprehensive analytic framework is presented to minimize the long-term cost on energy consumption. Meanwhile, the framework also enables an energy-efficient data offloading (from fog nodes to the cloud) mechanism to help provide a high quality of service.

In [45], a rack-scale green-energy powered edge infrastructure, InSURE (in-situ server system using renewable energy) is implemented for data pre-processing at the edge. InSURE can be powered by standalone (solar/wind) power and with batteries as the energy backup. Meanwhile, an energy buffering mechanism and a joint spatio-temporal power management scheme are applied, to enable efficient energy flow control from the power supply to the edge server.

Iv-C At the Bottom Device Layer

As a well-recognized fact, the IoT devices in edge computing usually have strict energy constraints, e.g., limited battery life and energy storage. Thus, it remains a key challenge to power a great number (can up to tens of billions) of IoT devices at the edge, especially for those resource-intensive applications or services [52]. We review the energy saving strategies adopted at the device layer of the edge computing diagram. Specifically, we go through three major approaches to achieving high energy efficiency in different edge/fog computing systems.

Iv-C1 Computation offloading to edge servers or cloud

As a natural idea to solve the energy poverty problem, computation offloading from the IoT devices to the edge servers or cloud has been long investigated [65, 43, 19]. It was also demonstrated that, for some particular applications or services, offloading tasks from IoT devices to more powerful ends can reduce the total energy consumption of the system, since the task execution time on powerful servers or cloud can be much shortened [33]. Although it increases the energy consumption of (wireless) data transmission, the tradeoff favors the offloading option as the computational demand increases [15].

Having realized that the battery life is the primary bottleneck of handheld mobile devices, the authors in [19] present MAUI, an architecture for mobile code offloading and remote execution. To reduce the energy consumption of the smartphone program, MAUI adopts a fine-grained program partitioning mechanism and minimizes the code changes required at the remote server or cloud. The ability of MAUI in energy reduction is validated by various experiments upon macro-benchmarks and micro-benchmarks. The results show that MAUI’s energy saving for a resource-intensive mobile application is up to one order of magnitude, also with a significant performance improvement.

Like MAUI [19] , the authors in [15] design and implement CloneCloud, a system that helps partition mobile application programs and performs strategically offloading for fast and elastic execution at the cloud end. As the major difference to MAUI, CloneCloud involves less programmer help during the whole process and only offloads particular program partitions on demand of execution, which further speeds up the program execution. Evaluation shows that CloneCloud can improve the energy efficiency of mobile applications (along with their execution efficiency) by 20 times. Similarly in [10], by continuous updates of software clones in the cloud with a reasonable overhead, the offloading service can lead to energy reduction at the mobile end by a factor. For computation intensive applications on resource constrained edge devices, their executions usually need to be offloaded to the cloud. To reduce the response latency of the image recognition application, Precog is presented which has been introduced in Sec. II-G. With the on-device recognition caches, Precog much reduces the amount of images offloading to the edge server or cloud, by predicting and prefetching the future images to be recognized.

Iv-C2 Collaborated devices control and resource management

For energy saving of the massive devices at the edge, besides offloading their computational tasks to more powerful ends, there is also a great potential via sophisticated collaboration and cooperation among the devices themselves. Particularly, when the remote resources from the edge server or cloud are unavailable, it is critical and non-trivial to complete the edge tasks while without violating the energy constraint.

PCloud is presented in [38]

to enhance the capability of individual mobile devices at the edge. By seamless using available resources from the nearby devices, PCloud forms a ‘personal cloud’ to serve end users whenever the cloud resources are difficult to access, where device participation is guided in a privacy-preserving manner. The authors show that, by leveraging multiple nearby device resources, PCloud can much reduce the task execution time as well as energy consumption. For example, in the case study of ‘neighborhood watch with face recognition’, the results show a

reduction in energy consumption on a PCloud vs. on a single edge device. Similar to PCloud, the concept of mobile device cloud (MDC) is proposed in [26], where computational offloading is also adopted among the mobile devices. It shows that the energy efficiency (gain) is increased by via offloading in MDC. The authors of [50] propose an adaptive method to dynamically discovery available nearby resource in heterogeneous networks, and perform automatic transformation between centralized and flooding strategies to save energy.

As current LTE standard is not optimized to support a large simultaneous access of IoT devices, the authors in [2] propose an improved memory replication architecture and protocol, REPLISON, for computation offloading of the massive IoT devices at the edge. REPLISON improves the memory replication performance through an LTE-optimized protocol, where Device-to-Device (D2D) communication is applied as an important supporting technology (to pull memory replicas from IoT devices). The total energy consumption of REPLISON is generally worse than the conventional LTE scenario, as it needs more active devices. However, the energy consumed per device during a single replicate transmission is much less. With further evaluation results, it shows that REPLISOM has an energy advantage over the conventional LTE scenarios as long as the size of replica is sufficiently small.

For IoT devices distributed at the edge, the authors in [3] leverage the software agents running on the IoT devices to establish an integrated multi-agent system (MAS). By sharing data and information among the mobile agents, edge devices are able to collaborate with each other and improve the system energy efficiency in executing distributed opportunistic applications. Upon the experimental platform with 100 sensor nodes and 20 smartphones as edge devices, the authors show the great potential of data transmission reduction with MAS. This leads to a significant energy saving, from to , under different edge computing scenarios. As another work applying data reduction for energy saving, CAROMM [40] employs a change detect technique (LWC algorithm) to control the data transmission of IoT devices, while maintaining the data accuracy.

V Deep Learning Optimization at the Edge

In the past decades, we have witnessed the burgeoning of machine learning, especially deep learning based applications which have changed human being’s life. With complex structures of hierarchical layers to capture features from raw data, deep learning models have shown outstanding performances in those novel applications, such as machine translation, object detection, and smart question and answer systems.

Traditionally, most deep learning based applications are deployed on a remote cloud center, and many systems and tools are designed to run deep learning models efficiently on the cloud. Recently, with the rapid development of edge computing, the deep learning functions are being offloaded to the edge. Thus it calls for new techniques to support the deep learning models at the edge. This section classifies these technologies into three categories: systems and toolkits, deep learning packages, and hardware.

V-a Systems and Toolkits

Building systems to support deep learning at the edge is currently a hot topic for both industry and academy. There are several challenges when offloading state-of-the-art AI techniques on the edge directly, including computing power limitation, data sharing and collaborating, and mismatch between edge platform and AI algorithms. To address these challenges, OpenEI is proposed as an Open Framework for Edge Intelligence [86]. OpenEI is a lightweight software platform to equip edges with intelligent processing and data sharing capability. OpenEI consists of three components: a package manager to execute the real-time deep learning task and train the model locally, a model selector to select the most suitable model for different edge hardware, and a library including a RESTFul API for data sharing. The goal of OpenEI is that any edge hardware will has the intelligent capability after deploying it.

In the industry, some top-leading tech-giants have published several projects to move the deep learning functions from the cloud to the edge. Except Microsoft published Azure IoT Edge which have been introduced in Sec. III-E, Amazon and Google also build their services to support deep learning on the edge. Table III summarizes the features of the systems which will be discussed below.

Amazon Web Services (AWS) has published IoT Greengrass ML Inference [8]

after IoT Greengrass. AWS IoT Greengrass ML Inference is a software to support machine learning inferences on local devices. With AWS IoT Greengrass ML Inference, connected IoT devices can run AWS Lambda functions and have the flexibility to execute predictions based on those deep learning models created, trained, and optimized in the cloud. AWS IoT Greengrass consists of three software distributions: AWS IoT Greengrass Core, AWS IoT Device SDK, and AWS IoT Greengrass SDK. Greengrass is flexible for users as it includes a pre-built TensorFlow, Apache MXNet, and Chainer package, and it can also work with Caffe2 and Microsoft Cognitive Toolkit.

Cloud IoT Edge [16] extends Google Cloud’s data processing and machine learning to edge devices by taking advantages of Google AI products, such TensorFlow Lite and Edge TPU. Cloud IoT Edge can either run on Android or Linux-based operating systems. It is made up of three components: Edge Connect ensures the connection to the cloud and the updates of software and firmware, Edge ML runs ML inference by TensorFlow Lite, and Edge TPU specific designed to run TensorFlow Lite ML models. Cloud IoT Edge can satisfy the real-time requirement for the mission-critical IoT applications, as it can take advantages of Google AI products (such as TensorFlow Lite and Edge TPU) and optimize the performance collaboratively.

Features AWS IoT Greengrass Azure IoT Edge Cloud IoT Edge
Developer Amazon Microsoft Google
Components
IoT Greengrass Core, IoT Device SDK,
IoT Greengrass SDK
IoT Edge modules, IoT Edge runtime,
Cloud-based interface
Edge Connect, Edge ML, Edge TPU
OS Linux, macOS, Windows Windows, Linux, macOS Linux, macOS, Windows, Android
Target device Multiple platforms (GPU-based, Raspberry Pi) Multiple platforms TPU
Characteristic Flexible Windows friendly Real-time
TABLE III: Comparison of Deep learning Systems on Edge

V-B Deep Learning Packages

Many deep learning packages have been widely used to deliver the deep learning algorithms and deployed on the cloud data centers, including TensorFlow [1]

, Caffe 

[41]

, PyTorch 

[29], and MXNet [13]. Due to the limitations of computing resources at the edge, the packages designed for the cloud are not suitable for edge devices. Thus, to support data processing with deep learning models at the edge, several edge-based deep learning frameworks and tools have been released. In this section, we introduce TensorFlow Lite, Caffe2, PyTorch, MXNet, CoreML [18], and TensorRT [60], whose features are summarized in Tables IV.

TensorFlow Lite [36] is TensorFlow’s lightweight solution which is designed for mobile and edge devices. TensorFlow is developed by Google in 2016 and becomes one of the most widely used deep learning frameworks in cloud data centers. To enable low-latency inference of on-device deep learning models, TensorFlow Lite leverages many optimization techniques, including optimizing the kernels for mobile apps, pre-fused activations, and quantized kernels that allow smaller and faster (fixed-point math) models.

Facebook published Caffe2 [12] as a lightweight, modular, and scalable framework for deep learning in 2017. Caffe2 is a new version of Caffe which is first developed by UC Berkeley AI Research (BAIR) and community contributors. Caffe2 provides an easy and straightforward way to play with the deep learning and leverage community contributions of new models and algorithms. Comparing with the original Caffe framework, Caffe2 merges many new computation patterns, including distributed computation, mobile, reduced precision computation, and more non-vision use cases. Caffe2 supports multiple platforms which enable developers to use the power of GPUs in the cloud or at the edge with cross-platform libraries.

PyTorch [29]

is published by Facebook. It is a python package that provides two high-level features: tensor computation with strong GPU acceleration and deep Neural Networks built on a tape-based auto-grad system. Maintained by the same company (Facebook), PyTorch and Caffe2 have their own advantages. PyTorch is geared toward research, experimentation and trying out exotic neural networks, while caffe2 supports more industrial-strength applications with a heavy focus on the mobile. In 2018, Caffe2 and PyTorch projects merged into a new one named PyTorch 1.0, which would combine the user experience of the PyTorch frontend with scaling, deployment and embedding capabilities of the Caffe2 backend.

MXNet [13]

is a flexible and efficient library for deep learning. It was initially developed by the University of Washington and Carnegie Mellon University, to support CNN and long short-term memory networks (LSTM). In 2017, Amazon announced MXNet as its choice of deep learning framework. MXNet places a special emphasis on speeding up the development and deployment of large-scale deep neural networks. It is designed to support multiple different platforms (either cloud platforms or the edge ones) and can execute training and inference tasks. Furthermore, other than the Windows, Linux, and OSX operating systems based devices, it also supports the Ubuntu Arch64 and Raspbian ARM based operating systems.

CoreML [18] is a deep learning framework optimized for on-device performance at memory footprint and power consumption. Published by Apple, users can integrate the trained machine learning model into Apple products, such as Siri, Camera, and QuickType. CoreML supports not only deep learning models, but also some standard models such as tree ensembles, SVMs, and generalized linear models. Built on top of low level technologies, CoreML aims to make full use of the CPU and GPU capability and ensure the performance and efficiency of data processing.

The platform of TensorRT [60] acts as a deep learning inference to run the models trained by TensorFlow, Caffe, and other frameworks. Developed by NVIDIA company, it is designed to reduce the latency and increase the throughput when executing the inference task on NVIDIA GPU. To achieve computing acceleration, TensorRT leverages several techniques, including weight and activation precision calibration, layer and tensor fusion, kernel auto-tuning, dynamic tensor memory, and multi-stream execution.

Considering the different performance of the packages and the diversity of the edge hardware, it is challenging to choose a suitable package to build edge computing systems. To evaluate the deep learning frameworks at the edge and provide a reference to select appropriate combinations of package and edge hardware, pCAMP [87] is proposed. It compares the packages’ performances (w.r.t. the latency, memory footprint, and energy) resulting from five edge devices and observes that no framework could win over all the others at all aspects. It indicates that there is much room to improve the frameworks at the edge. Currently, developing a lightweight, efficient and high-scalability framework to support diverse deep learning modes at the edge cannot be more important and urgent.

In addition to these single-device based frameworks, more researchers focus on distributed deep learning models over the cloud and edge. DDNN [74] is a distributed deep neural network architecture across cloud, edge, and edge devices. DDNN maps the sections of a deep neural network onto different computing devices, to minimize communication and resource usage for devices and maximize usefulness of features extracted from the cloud.

Neurosurgeon [42] is a lightweight scheduler which can automatically partition DNN computation between mobile devices and datacenters at the granularity of neural network layers. By effectively leveraging the resources in the cloud and at the edge, Neurosurgeon achieves low computing latency, low energy consumption, and high traffic throughput.

Features TensorFlow Lite Caffe2 PyTorch MXNet CoreML TensorRT
Developer Google Facebook Facebook DMLC, Amazon Apple NVIDIA
Open Source
License
Apache-2.0 Apache-2.0 BSD Apache-2.0 Not open source Not open source
Task Inference Training, Inference Training, Inference Training, Inference Inference Inference
Target Device
Mobile and
embedded device
Multiple platform Multiple platform Multiple platform Apple devices NVIDIA GPU
Characteristic Latency
Lightweight, modular,
and scalable
Research
Large-scale
deep neural networks
Memory footprint and
power consumption.
Latency and
throughput
TABLE IV: Comparison of Deep Learning Packages on Edge

V-C Hardware System

The hardware designed specifically for deep learning can strongly support edge computing. Thus, we further review relevant hardware systems and classify them into three categories: FPGA-based hardware, GPU-based hardware, and ASIC.

V-C1 FPGA-based Hardware

A field-programmable gate array (FPGA) is an integrated circuit and can be configured by the customer or designer after manufacturing. FPGA based accelerators can achieve high performance computing with low energy, high parallelism, high flexibility, and high security [79].

[83] implements a CNN accelerator on a VC707 FPGA board. The accelerator focuses on solving the problem that the computation throughput does not match the memory bandwidth well. By quantitatively analyzing the two factors using various optimization techniques, the authors provide a solution with better performance and lower FPGA resource requirement, and their solution achieves a peak performance of GOPS under a working frequency.

Following the above work, Qiu et al. [63] propose a CNN accelerator designed upon the embedded FPGA, Xilinx Zynq ZC706, for large-scale image classification. It presents an in-depth analysis of state-of-the-art CNN models and shows that Convolutional layers are computational-centric and Fully-Connected layers are memory-centric. The average performances of the CNN accelerator at convolutional layers and the full CNN are GOPS and GOPS under a working frequency, respectively, which outperform previous approaches significantly.

An efficient speech recognition engine (ESE) is designed to speed up the predictions and save energy when applying the deep learning model of LSTM. ESE is implemented in a Xilinx XCKU060 FPGA opearting at . For the sparse LSTM network, it can achieve 282GOPS, corresponding to a TOPS on the dense LSTM network. Besides, energy efficiency improvements of and are achieved, respectively, compared with the CPU and GPU based solution.

V-C2 GPU-based hardware

GPU can execute parallel programs at a much higher speed than CPU, which makes it fit for the computational paradigm of deep learning algorithms. Thus, to run deep learning models at the edge, building the hardware platform with GPU is a must choice. Specifically, NVIDIA Jetson TX2 and DRIVE PX2 are two representative GPU-based hardware platforms for deep learning.

NVIDIA Jetson TX2 [59] is an embedded AI computing device which is designed to achieve low latency and high power-efficient. It is built upon an NVIDIA Pascal GPU with 256 CUDA cores, an HMP Dual Denver CPU and a Qualcomm ARM CPU. It is loaded with 8GB of memory and 59.7GB/s of memory bandwidth and the power is about 7.5 watts. The GPU is used to execute the deep learning task and CPUs are used to maintain general tasks. It also supports the NVIDIA Jetpack SDK which includes libraries for deep learning, computer vision, GPU computing, and multimedia processing.

NVIDIA DRIVE PX [58] is designed as the AI supercomputer for autonomous driving. The architecture is available in a variety of configurations, from the mobile processor operating at 10 watts to a multi-chip AI processors delivering 320 TOPS. It can fuse data from multiple cameras, as well as lidar, radar, and ultrasonic sensors.

V-C3 Asic

Application-Specific Integrated Circuit (ASIC) is the integrated circuit which supports customized design for a particular application, rather than the general-purpose use. ASIC is suitable for the edge scenario as it usually has a smaller size, lower power consumption, higher performance, and higher security than many other circuits. Researchers and developers design ASIC to meet the computing pattern of deep learning.

DianNao family [14] is a series of hardware accelerators designed for deep learning models, including DianNao, DaDianNao, ShiDianNao, and PuDianNao. They investigate the accelerator architecture to minimize memory transfers as efficiently as possible. Different from other accelerators in DianNao family, ShiDianNao [22] focuses on image applications in embedded systems which are widely used in edge computing scenarios. For the CNN-based deep learning models, it provides a computing speed faster than that of NVIDIA K20M GPU, with an body area of and a power of .

Edge TPU [24] is Google’s purpose-built ASIC for edge computing. It augments Google’s Cloud TPU and Cloud IoT to provide an end-to-end infrastructure and facilitates the deployment of customers’ AI-based solutions. In addition, Edge TPU can combine the custom hardware, open software, and state-of-the-art AI algorithms to achieve high performance with a small physical area and low power consumption.

Vi Key Design Issues

The edge computing system manages various resources along the path from the cloud center to end devices, shielding the complexity and diversity of hardware and helping developers quickly design and deploy novel applications. To fully leverages the advantages, we discuss the following key issues which need to be paid attention when analyzing and designing a new edge computing system.

Vi-1 Mobility Support

Mobility support has two aspects: user mobility and resource mobility. User mobility refers to how to automatically migrate the current program state and necessary data when the user moves from one edge node coverage domain to another so that the service handover is seamlessly. Currently, Cloudlet and CloudPath provide service migration through terminating/finishing existing task and starting a new VM/instance in the target edge node. Fine-grain migration and target edge node prediction are not supported. Resource mobility refers to i) how to dynamically discover and manage available resources, including both the long-term resources and short-term ones, and ii) when some edge devices are damaged how the system can be resumed as soon as possible with replacements. For example, PCloud and FocusStack supports edge devices dynamic join and leave with no task running. Intelligent dynamic resource management is still required for edge computing systems.

Vi-2 Multi-user Fairness

For edge devices with limited resources, how to ensure the fairness of multi-user usage, especially for the shared resources and rare resources. For example, a smartphone made up of various sensors and computing resources can act as an edge node to serve multiple users. However, as the smartphone has limited battery life, it is a problem to fairly allocate resources when receiving many requests. The resource competition is more intense, the requests are coming from different irrelevant tasks, it is hard to decide who should use the resource with only local information. Besides, the unfairness can be used as an attack strategy to make the critical task resource hungry, which may lead to main task failure. The existing edge computing systems do not pay much attention to the multi-user fairness, the basic solution (bottom-line) is to provide resource isolation, users only get what the edge node promised when it accepts the request. More fairness strategies require system support, like related task status updates, etc.

Vi-3 Privacy Protection

Unlike cloud computing, edge devices can be privately owned, such as gateway devices for smart home systems. When other users use such edge devices, obtain their data, and even take control of them, how to ensure the owner’s privacy and guest users’ data privacy is important. AirBox is a lightweight flexible edge function system, which leverages hardware security mechanism (e.g. Intel SGX) to enhance system security. Other system have not pay much attention to privacy and security. Existing cloud security approaches can be applied with the consideration of the resource limitation. Enhancing resource isolation, setting up privilege management and access control policies can be potential directions to solve the privacy problem.

Vi-4 Developer Friendliness

The system ultimately provides hardware interaction and basic services for upper-level applications. How to design interactive APIs, program deployment module, resource application and revocation, etc., are the key factors for the system to be widely used. Therefore, to design an edge computing system, we should think from an application developer’s perspective. Specifically, to provide effective development and deployment services is a good idea to help improve the ecosystem of the edge computing system. For instances, EdgeX Foundry and Apache Edgent provide APIs to manage devices and analyze data respectively. ParaDrop supports monitoring devices and application status through developer APIs, and provides a web UI for users to manage/configure gateway as well as deploy applications to devices.

Vi-5 Multi-domain Management and Cooperation

Edge computing involves multiple types of resources, each of which may belong to a different owner. For examples, the smart home gateways and sensors of the house owner, networks resources and base stations from the Internet service providers (ISP), traffic cameras owned by the government. How to access these resources and organize them according to the requirements of application and services, especially in emergency situations, is a problem that the edge computing system needs to consider. Existing researches assume we have the permission to use various devices belongs to different owners. In the initial stage, systems focus on the functionality perspective rather than implementation issues like price model. With the developing of edge computing, the real deployment issues should be solved before we enjoy all the benefits.

Vi-6 Cost Model

In cloud computing, the corresponding virtual machine can be allocated based on the resource requested by the user, and the cost model can be given according to the resource usage. In edge computing, an application may use resources from different owners. Thus, how to measure resource usage, calculate overall overhead, and give an appropriate pricing model are crucial problems when deploying an edge computing system. Generally, edge computing systems focus on how to satisfy the resource requirements of various services and applications, some of them pay more attention to the energy consumption due to the nature of mobile nodes, more complex overhead are not considered.

Vi-7 Compatibility

Currently, specialized edge computing applications are still quite few. For examples, ParaDrop applications require additional XML configuration file to specify the resource usage requirements, SpanEdge needs developers to divide/configure tasks into local tasks and global tasks. Common applications are not directly supported to run in edge systems. How to automatically and transparently convert existing programs to the edge version and conveniently leverages the advantages of edge computing are still open problems. The compatibility should be considered in the edge system design. Specifically, how to adapt traditional applications to the new architecture and realize the basic functions so that they can run successfully, deserving further exploration and development.

Vii Conclusions

Edge computing is a new paradigm that jointly migrates the capability of networking, computation, and storage from the remote cloud to the user sides. Under the context of IoT and 5G, the vision of edge computing is promising in providing smarter services and applications with better user experiences. The recently proposed systems and tools on edge computing generally reduce the data processing and transmission overhead, and improve the efficiency and efficacy of mobile data analytics. Additionally, the integration of edge computing and deep learning techniques further fosters the research on edge-based intelligence services. This article introduced the representative systems and open source projects for edge computing, presented several energy efficiency enhancing strategies for performance consideration and technologies for deploying deep learning models at the edge, and suggested a few research directions during system design and analysis.

References

  • [1] M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis, J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard, et al. (2016) TensorFlow: a system for large-scale machine learning.. In OSDI, Vol. 16, pp. 265–283. Cited by: §V-B.
  • [2] S. Abdelwahab, B. Hamdaoui, M. Guizani, and T. Znati (2016) Replisom: disciplined tiny memory replication for massive iot devices in lte edge cloud. IEEE Internet of Things Journal 3 (3), pp. 327–338. Cited by: §IV-C2.
  • [3] S. Abdelwahab, B. Hamdaoui, M. Guizani, T. Znati, and J. Riekki (2018) Energy efficient opportunistic edge computing for the internet of things. Web Intelligence and Agent Systems, pp. In Press. Cited by: §IV-C2.
  • [4] (2018) Akraino edge statck. Note: https://www.akraino.org Cited by: §III-B, §III-B, §III.
  • [5] B. Amento, B. Balasubramanian, R. J. Hall, K. Joshi, G. Jung, and K. H. Purdy (2016) FocusStack: orchestrating edge clouds using location-based focus of attention. In IEEE/ACM Symposium on Edge Computing (SEC), pp. 179–191. Cited by: Fig. 11, §II-H.
  • [6] (2018) Apache edgent. Note: http://edgent.apache.org Cited by: §III-D.
  • [7] A. Asnaghi, M. Ferroni, and M. D. Santambrogio (2016) DockerCap: a software-level power capping orchestrator for docker containers. In Computational Science and Engineering (CSE) and IEEE Intl Conference on Embedded and Ubiquitous Computing (EUC) and 15th Intl Symposium on Distributed Computing and Applications for Business Engineering (DCABES), 2016 IEEE Intl Conference on, pp. 90–97. Cited by: §IV-B1.
  • [8] (2019)(Website) External Links: Link Cited by: §V-A.
  • [9] (2018) Azure iot. Note: https://azure.microsoft.com/en-us/overview/iot/ Cited by: §III-E.
  • [10] M. V. Barbera, S. Kosta, A. Mei, and J. Stefa (2013) To offload or not to offload? the bandwidth and energy costs of mobile cloud computing. In INFOCOM, 2013 Proceedings IEEE, pp. 1285–1293. Cited by: §IV-C1.
  • [11] K. Bhardwaj, M. Shih, P. Agarwal, A. Gavrilovska, T. Kim, and K. Schwan (2016) Fast, scalable and secure onloading of edge functions using airbox. In IEEE/ACM Symposium on Edge Computing (SEC), pp. 14–27. Cited by: Fig. 12, §II-I.
  • [12] (2019)(Website) External Links: Link Cited by: §V-B.
  • [13] T. Chen, M. Li, Y. Li, M. Lin, N. Wang, M. Wang, T. Xiao, B. Xu, C. Zhang, and Z. Zhang (2015) Mxnet: a flexible and efficient machine learning library for heterogeneous distributed systems. In LearningSys at NIPS, Cited by: §V-B, §V-B.
  • [14] Y. Chen, T. Chen, Z. Xu, N. Sun, and O. Temam (2016) DianNao family: energy-efficient hardware accelerators for machine learning. Communications of the ACM 59 (11), pp. 105–112. Cited by: §V-C3.
  • [15] B. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti (2011) Clonecloud: elastic execution between mobile device and cloud. In Proceedings of the sixth conference on Computer systems, pp. 301–314. Cited by: §IV-C1, §IV-C1.
  • [16] (2019)(Website) External Links: Link Cited by: §V-A.
  • [17] (2018) CORD. Note: https://www.opennetworking.org/cord Cited by: §III-A, §III.
  • [18] (2019)(Website) External Links: Link Cited by: §V-B, §V-B.
  • [19] E. Cuervo, A. Balasubramanian, D. Cho, A. Wolman, S. Saroiu, R. Chandra, and P. Bahl (2010) MAUI: making smartphones last longer with code offload. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pp. 49–62. Cited by: §IV-C1, §IV-C1, §IV-C1.
  • [20] U. Drolia, K. Guo, and P. Narasimhan (2017) Precog: prefetching for image recognition applications at the edge. In Proceedings of the Second ACM/IEEE Symposium on Edge Computing, pp. 17. Cited by: Fig. 10, §II-G.
  • [21] U. Drolia, K. Guo, J. Tan, R. Gandhi, and P. Narasimhan (2017) Cachier: edge-caching for recognition applications. In 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS), pp. 276–286. Cited by: Fig. 9, §II-G.
  • [22] Z. Du, R. Fasthuber, T. Chen, P. Ienne, L. Li, T. Luo, X. Feng, Y. Chen, and O. Temam (2015) ShiDianNao: shifting vision processing closer to the sensor. In ACM SIGARCH Computer Architecture News, Vol. 43, pp. 92–104. Cited by: §V-C3.
  • [23] H. Dubey, J. Yang, N. Constant, A. M. Amiri, Q. Yang, and K. Makodiya (2015) Fog data: enhancing telehealth big data through fog computing. In Proceedings of the ASE BigData & SocialInformatics 2015, pp. 14. Cited by: §IV-B1.
  • [24] (2019)(Website) External Links: Link Cited by: §V-C3.
  • [25] (2018) EdgeX foundry. Note: https://www.edgexfoundry.org Cited by: §III-C, §III-C.
  • [26] A. Fahim, A. Mtibaa, and K. A. Harras (2013) Making the case for computational offloading in mobile device clouds. In Proceedings of the 19th annual international conference on Mobile computing & networking, pp. 203–205. Cited by: §IV-C2.
  • [27] A. Feldmann, A. Gladisch, M. Kind, C. Lange, G. Smaragdakis, and F. Westphal (2010) Energy trade-offs among content delivery architectures. In Telecommunications Internet and Media Techno Economics (CTTE), 2010 9th Conference on, pp. 1–6. Cited by: §IV-A.
  • [28] R. T. Fielding and R. N. Taylor (2000) Architectural styles and the design of network-based software architectures. Vol. 7, University of California, Irvine Irvine, USA. Cited by: §II-F.
  • [29] (2019)(Website) External Links: Link Cited by: §V-B, §V-B.
  • [30] K. Ha, Z. Chen, W. Hu, W. Richter, P. Pillai, and M. Satyanarayanan (2014) Towards wearable cognitive assistance. In Proceedings of the 12th annual international conference on Mobile systems, applications, and services, pp. 68–81. Cited by: §II-A3.
  • [31] K. Ha, P. Pillai, W. Richter, Y. Abe, and M. Satyanarayanan (2013) Just-in-time provisioning for cyber foraging. In Proceeding of the 11th annual international conference on Mobile systems, applications, and services, pp. 153–166. Cited by: §II-A3.
  • [32] K. Ha and M. Satyanarayanan (2015) Openstack++ for cloudlet deployment. School of Computer Science Carnegie Mellon University Pittsburgh. Cited by: §II-A3.
  • [33] K. Ha (2016) System infrastructure for mobile-cloud convergence. Ph.D. Thesis, Carnegie Mellon University. Cited by: §IV-C1.
  • [34] H. Hawilo, A. Shami, M. Mirahmadi, and R. Asal (2014) NFV: state of the art, challenges, and implementation in next generation mobile networks (vepc). IEEE Network 28 (6), pp. 18–26. Cited by: §III-A, §III-C.
  • [35] C. Hung, G. Ananthanarayanan, P. Bodik, L. Golubchik, M. Yu, P. Bahl, and M. Philipose (2018)

    VideoEdge: processing camera streams using hierarchical clusters

    .
    In Proceedings of the IEEE/ACM Symposium on Edge Computing (SEC), pp. 115–131. Cited by: §II-K.
  • [36] (2019)(Website) External Links: Link Cited by: §V-B.
  • [37] F. Jalali, K. Hinton, R. Ayre, T. Alpcan, and R. S. Tucker (2016) Fog computing may help to save energy in cloud computing. IEEE Journal on Selected Areas in Communications 34 (5), pp. 1728–1739. Cited by: §IV-A.
  • [38] M. Jang, K. Schwan, K. Bhardwaj, A. Gavrilovska, and A. Avasthi (2014) Personal clouds: sharing and integrating networked resources to enhance end user experiences. In Proceedings of IEEE INFOCOM, pp. 2220–2228. Cited by: Fig. 5, §II-C, §IV-C2.
  • [39] M. Jang and K. Schwan (2011) Stratus: assembling virtual platforms from device clouds. In Proceedings of the IEEE International Conference on Cloud Computing, pp. 476–483. Cited by: §II-C.
  • [40] P. P. Jayaraman, J. B. Gomes, H. L. Nguyen, Z. S. Abdallah, S. Krishnaswamy, and A. Zaslavsky (2014) Cardap: a scalable energy-efficient context aware distributed mobile data analytics platform for the fog. In East European Conference on Advances in Databases and Information Systems, pp. 192–206. Cited by: §IV-C2.
  • [41] Y. Jia, E. Shelhamer, J. Donahue, S. Karayev, J. Long, R. Girshick, S. Guadarrama, and T. Darrell (2014) Caffe: convolutional architecture for fast feature embedding. In Proceedings of the 22nd ACM international conference on Multimedia, pp. 675–678. Cited by: §V-B.
  • [42] Y. Kang, J. Hauswald, C. Gao, A. Rovinski, T. Mudge, J. Mars, and L. Tang (2017) Neurosurgeon: collaborative intelligence between the cloud and mobile edge. ACM SIGPLAN Notices 52 (4), pp. 615–629. Cited by: §V-B.
  • [43] R. Kemp, N. Palmer, T. Kielmann, F. Seinstra, N. Drost, J. Maassen, and H. Bal (2009) Eyedentify: multimedia cyber foraging from a smartphone. In 2009 11th IEEE International Symposium on Multimedia, pp. 392–399. Cited by: §IV-C1.
  • [44] G. Lewis, S. Echeverría, S. Simanta, B. Bradshaw, and J. Root (2014) Tactical cloudlets: moving cloud computing to the edge. In Military Communications Conference (MILCOM), 2014 IEEE, pp. 1440–1446. Cited by: §IV-B1.
  • [45] C. Li, Y. Hu, L. Liu, J. Gu, M. Song, X. Liang, J. Yuan, and T. Li (2015) Towards sustainable in-situ server systems in the big data era. In ACM SIGARCH Computer Architecture News, Vol. 43, pp. 14–26. Cited by: §IV-B2.
  • [46] Y. Li and W. Gao (2018) MUVR: supporting multi-user mobile virtual reality with resource constrained edge cloud. In Proceedings of the IEEE/ACM Symposium on Edge Computing (SEC), pp. 1–16. Cited by: §II-K.
  • [47] Z. Li, C. Wang, and R. Xu (2001) Computation offloading to save energy on handheld devices: a partition scheme. In Proceedings of the 2001 international conference on Compilers, architecture, and synthesis for embedded systems, pp. 238–246. Cited by: §II-A.
  • [48] L. Liu, X. Zhang, M. Qiao, and W. Shi (2018) SafeShareRide: edge-based attack detection in ridesharing services. In Proceedings of the IEEE/ACM Symposium on Edge Computing (SEC), Cited by: §II-K.
  • [49] P. Liu, D. Willis, and S. Banerjee (2016-10) ParaDrop: enabling lightweight multi-tenancy at the network’s extreme edge. In 2016 IEEE/ACM Symposium on Edge Computing (SEC), Vol. , pp. 1–13. External Links: Document, ISSN Cited by: Fig. 6, §II-D.
  • [50] W. Liu, T. Nishio, R. Shinkuma, and T. Takahashi (2014) Adaptive resource discovery in mobile cloud computing. Computer Communications 50, pp. 119–129. Cited by: §IV-C2.
  • [51] A. W. Manggala, Hendrawan, and A. Tanwidjaja (2016) Performance analysis of white box switch on software defined networking using open vswitch. In International Conference on Wireless and Telematics, Cited by: §III-A.
  • [52] Y. Mao, C. You, J. Zhang, K. Huang, and K. B. Letaief (2017) A survey on mobile edge computing: the communication perspective. IEEE Communications Surveys & Tutorials 19 (4), pp. 2322–2358. Cited by: §IV-C.
  • [53] T. Mastelic, A. Oleksiak, H. Claussen, I. Brandic, J. Pierson, and A. V. Vasilakos (2015) Cloud computing: survey on energy efficiency. Acm computing surveys (csur) 47 (2), pp. 33. Cited by: §IV-A.
  • [54] R. Morabito (2017) Virtualization on internet of things edge devices with container technologies: a performance evaluation. IEEE Access 5, pp. 8835–8850. Cited by: §III-F5.
  • [55] S. H. Mortazavi, M. Salehe, C. S. Gomes, C. Phillips, and E. de Lara (2017) Cloudpath: a multi-tier cloud computing framework. In Proceedings of the Second ACM/IEEE Symposium on Edge Computing, pp. 20. Cited by: Fig. 4, §II-B.
  • [56] Y. Nan, W. Li, W. Bao, F. C. Delicato, P. F. Pires, Y. Dou, and A. Y. Zomaya (2017) Adaptive energy-aware computation offloading for cloud of things systems. IEEE Access 5, pp. 23947–23957. Cited by: §IV-B2.
  • [57] B. A. A. Nunes, M. Mendonca, X. Nguyen, K. Obraczka, and T. Turletti (2014) A survey of software-defined networking: past, present, and future of programmable networks. IEEE Communications Surveys & Tutorials 16 (3), pp. 1617–1634. Cited by: §III-A.
  • [58] (2019)(Website) External Links: Link Cited by: §V-C2.
  • [59] (2019)(Website) External Links: Link Cited by: §V-C2.
  • [60] (2019)(Website) External Links: Link Cited by: §V-B, §V-B.
  • [61] K. C. Okafor, I. E. Achumba, G. A. Chukwudebe, and G. C. Ononiwu (2017) Leveraging fog computing for scalable iot datacenter using spine-leaf network topology. Journal of Electrical and Computer Engineering,2017,(2017-4-24) 2017 (2363240), pp. 1–11. Cited by: §III-A.
  • [62] (2018)(Website) External Links: Link Cited by: §II-A3, §II-A.
  • [63] J. Qiu, J. Wang, S. Yao, K. Guo, B. Li, E. Zhou, J. Yu, T. Tang, N. Xu, S. Song, et al. (2016)

    Going deeper with embedded fpga platform for convolutional neural network

    .
    In Proceedings of the 2016 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, pp. 26–35. Cited by: §V-C1.
  • [64] T. Rausch, C. Avasalcai, and S. Dustdar (2018) Portable energy-aware cluster-based edge computers. In 2018 IEEE/ACM Symposium on Edge Computing (SEC), pp. 260–272. Cited by: §IV-B1.
  • [65] A. Rudenko, P. Reiher, G. J. Popek, and G. H. Kuenning (1998) Saving portable computer battery power through remote process execution. ACM SIGMOBILE Mobile Computing and Communications Review 2 (1), pp. 19–26. Cited by: §IV-C1.
  • [66] H. P. Sajjad, K. Danniswara, A. Al-Shishtawy, and V. Vlassov (2016) SpanEdge: towards unifying stream processing over central and near-the-edge data centers. In IEEE/ACM Symposium on Edge Computing (SEC), pp. 168–178. Cited by: Fig. 7, §II-E.
  • [67] S. Sarkar and S. Misra (2016) Theoretical modelling of fog computing: a green computing paradigm to support iot applications. Iet Networks 5 (2), pp. 23–29. Cited by: §IV-A.
  • [68] M. Satyanarayanan, V. Bahl, R. Caceres, and N. Davies (2009) The case for vm-based cloudlets in mobile computing. IEEE pervasive Computing. Cited by: §II-A.
  • [69] M. Satyanarayanan, G. Lewis, E. Morris, S. Simanta, J. Boleng, and K. Ha (2013) The role of cloudlets in hostile environments. IEEE Pervasive Computing 12 (4), pp. 40–49. Cited by: §II-A3.
  • [70] M. Satyanarayanan, P. Simoens, Y. Xiao, P. Pillai, Z. Chen, K. Ha, W. Hu, and B. Amos (2015) Edge analytics in the internet of things. IEEE Pervasive Computing (2), pp. 24–31. Cited by: §II-A3.
  • [71] G. Tang, H. Wang, K. Wu, D. Guo, and C. Zhang (2018) When more may not be better: toward cost-efficient cdn selection. In INFOCOM WKSHPS, pp. 1–2. Cited by: §IV-A.
  • [72] G. Tang, H. Wang, K. Wu, and D. Guo (2019) Tapping the knowledge of dynamic traffic demands for optimal cdn design. IEEE/ACM Transactions on Networking (TON) 27 (1), pp. 98–111. Cited by: §IV-A.
  • [73] G. Tang, K. Wu, and R. Brunner (2017) Rethinking cdn design with distributee time-varying traffic demands. In INFOCOM, pp. 1–9. Cited by: §IV-A.
  • [74] S. Teerapittayanon, B. McDanel, and H. Kung (2017) Distributed deep neural networks over the cloud, the edge and end devices. In Distributed Computing Systems (ICDCS), 2017 IEEE 37th International Conference on, pp. 328–339. Cited by: §V-B.
  • [75] L. Tong, Y. Li, and W. Gao (2016) A hierarchical edge cloud architecture for mobile computing. In Proceedings of the 35th Annual IEEE International Conference on Computer Communications (INFOCOM), pp. 1–9. Cited by: §II-K.
  • [76] R. Trimananda, A. Younis, B. Wang, B. Xu, B. Demsky, and G. Xu (2018) Vigilia: securing smart home edge computing. In Proceedings of the IEEE/ACM Symposium on Edge Computing (SEC), pp. 74–89. Cited by: §II-K.
  • [77] V. Valancius, N. Laoutaris, L. Massoulié, C. Diot, and P. Rodriguez (2009) Greening the internet with nano data centers. In Proceedings of the 5th international conference on Emerging networking experiments and technologies, pp. 37–48. Cited by: §IV-A.
  • [78] J. Wang, Z. Feng, Z. Chen, S. George, M. Bala, P. Pillai, S. Yang, and M. Satyanarayanan (2018) Bandwidth-efficient live video analytics for drones via edge computing. In Proceedings of the IEEE/ACM Symposium on Edge Computing (SEC), pp. 159–173. Cited by: §II-K.
  • [79] T. Wang, C. Wang, X. Zhou, and H. Chen (2018) A survey of fpga based deep learning accelerators: challenges and opportunities. arXiv preprint arXiv:1901.04988. Cited by: §V-C1.
  • [80] Z. Xu (2014) Cloud-sea computing systems: towards thousand-fold improvement in performance per watt for the coming zettabyte era. Journal of Computer Science and Technology 29 (2), pp. 177–181. Cited by: §II-F.
  • [81] S. Yi, Z. Hao, Q. Zhang, Q. Zhang, W. Shi, and Q. Li (2017) Lavea: latency-aware video analytics on edge computing platform. In Proceedings of the Second ACM/IEEE Symposium on Edge Computing (SEC), pp. 15. Cited by: §II-K.
  • [82] I. Zavalyshyn, N. O. Duarte, and N. Santos (2018) HomePad: a privacy-aware smart hub for home environments. In Proceedings of the IEEE/ACM Symposium on Edge Computing (SEC), pp. 58–73. Cited by: §II-K.
  • [83] C. Zhang, P. Li, G. Sun, Y. Guan, B. Xiao, and J. Cong (2015) Optimizing fpga-based accelerator design for deep convolutional neural networks. In Proceedings of the 2015 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, pp. 161–170. Cited by: §V-C1.
  • [84] Q. Zhang, Y. Wang, X. Zhang, L. Liu, X. Wu, W. Shi, and H. Zhong (2018) OpenVDAP: an open vehicular data analytics platform for cavs. In Proceedings of the IEEE 38th International Conference on Distributed Computing Systems (ICDCS), Cited by: §II-K.
  • [85] Q. Zhang, X. Zhang, Q. Zhang, W. Shi, and H. Zhong (2016) Firework: big data sharing and processing in collaborative edge environment. In Proceedings of the IEEE Workshop on Hot Topics in Web Systems and Technologies (HotWeb), pp. 20–25. Cited by: Fig. 13, §II-J.
  • [86] X. Zhang, Y. Wang, S. Lu, L. Liu, L. Xu, and W. Shi (2019-07) OpenEI: An Open Framework for Edge Intelligence. In 2019 IEEE 39th International Conference on Distributed Computing Systems (ICDCS), pp. . External Links: Document, ISSN Cited by: §V-A.
  • [87] X. Zhang, Y. Wang, and W. Shi (2018) PCAMP: performance comparison of machine learning packages on the edges. In USENIX Workshop on Hot Topics in Edge Computing (HotEdge 18), Boston, MA. External Links: Link Cited by: §V-B.