PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey on Edge Computing Systems and Tools

Fang Liu, Guoming Tang, Youhuizi Li, Zhiping Cai, Xingzhou Zhang, Tongqing Zhou

arXiv:1911.02794v1cs.DCcs.NI

TL;DR

Edge computing addresses the need to process growing IoT data closer to users amid the limits of cloud-only processing. This survey reviews representative systems and open-source tools, compares their characteristics and applicability, and examines energy efficiency, deep-learning support, and open issues. It concludes that edge systems can reduce processing and transmission overhead while improving mobile data analytics, but deployment remains constrained by limitations such as insufficient programmability or network requirements in some tools.

  • Problem

    Edge computing lacks standardization and foundational open-source systems/tools, while cloud-centered processing struggles with huge edge-generated data and low-latency, predictable applications.

  • Method

    The paper surveys representative edge systems and open-source projects, compares their characteristics and applicability, and reviews energy-efficiency and deep-learning techniques.

  • Results

    The survey finds that edge systems generally reduce data-processing and transmission overhead and improve the efficiency and efficacy of mobile data analytics.

  • Takeaways & Limitations

    Edge computing supports smarter edge-based services by integrating networking, computation, storage, and deep-learning techniques near users.

  • Takeaways & Limitations

    Some surveyed tools remain limited by missing programmable interfaces, chargeable cloud services, narrow analytics focus, or requirements for stable networks between data sources and operators.

Abstract

from arXiv · show

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.

I. INTRODUCTION

Edge computing emerged to move data processing toward the network edge as IoT and 4G/5G increase data demands and challenge cloud-only processing. This survey categorizes systems, compares representative projects and tools, examines energy efficiency and deep-learning support, and identifies open research issues.

  • Motivation: IoT proliferation and 4G/5G adoption are driving edge computing, which processes data at the network edge.The growth of edge systems reflects changing data-access patterns and increasing demands that challenge linearly scaling cloud capability.
  • Motivation: Existing edge systems are categorized by design demands into push from cloud, pull from IoT, and hybrid cloud-edge analytics.These categories correspond to innovations in system architecture, programming models, and applications, while primarily clarifying why edge computing is needed.
  • Survey scope: The paper compares edge systems and open-source projects by their targets, architectures, characteristics, limitations, and applicability.It addresses the lack of standardization by reviewing foundational open-source systems and tools that provide useful APIs for edge architecture and programming models.
  • Emerging techniques: The survey examines energy-efficiency mechanisms across cloud, edge-server, and battery-powered-device layers, alongside techniques for deploying deep-learning models at the edge.The deep-learning review includes systems and toolkits, packages, and hardware.
  • Open issues: It identifies open issues including mobility support, multi-user fairness, and privacy protection in edge computing systems.These issues are presented as directions intended to support further research on analyzing and designing edge systems.
  • Survey scope: The survey reviews architecture innovations, programming models, and applications under push, pull, and hybrid demands.It introduces systems designed for architecture innovation first, followed by systems for programming models and applications.

A. Cloudlet

Cloudlet extends mobile-cloud computing with a nearby, resource-rich tier that supports low-latency offloading and application mobility. Its architecture emphasizes temporary state, physical proximity, and movement between cloudlets.

  • A. Cloudlet: Cloudlet adds a trusted, resource-rich intermediary between mobile devices and the cloud, forming a three-tier architecture.The intermediary may be a personal computer, low-cost server, or small cluster.
  • A. Cloudlet: Cloudlets temporarily cache interaction state rather than maintaining long-term state, reducing their burden as lightweight clouds.
  • A. Cloudlet: Cloudlets provide sufficient resources and stable power for multiple mobile users to offload computing tasks.
  • A. Cloudlet: Physical and network proximity lets cloudlets control bandwidth, delay, and jitter while enabling context-aware services.
  • A. Cloudlet: Application mobility lets devices switch requests to the nearest cloudlet during movement through discovery, provisioning, and migration.
  • A. Cloudlet: CloudPath builds multi-tier path computing with on-demand allocation and dynamic deployment across user devices, intermediate nodes, and cloud data centers.Developers can choose hierarchical deployments using cost, delay, resource availability, and geographic coverage.

3) PathRoute:

The surveyed systems bring computation and services toward edge devices through virtualization, containerization, and hierarchical processing. They target mobile, IoT, and streaming workloads by combining local execution with cloud coordination.

  • 3) PathRoute:: PCloud virtualizes edge and cloud computing and storage into a distributed resource pool that discovers resources and monitors changes.
  • 3) PathRoute:: PCloud analyzes application resource descriptions and current availability to generate an optimal resource configuration and instance.Applications may combine local or remote storage, decoding, and playback services transparently.
  • 3) PathRoute:: ParaDrop upgrades access points into edge servers and uses lightweight containers to isolate applications in multi-tenant deployments.Containers consume fewer resources than virtual machines and suit delay-sensitive, high-I/O applications.
  • 3) PathRoute:: ParaDrop supports local IoT data analysis, privacy protection, low network delay, reduced backbone traffic, location awareness, and operation without Internet connectivity.
  • 3) PathRoute:: SpanEdge uses cloud and edge data-center levels with manager-worker scheduling so partial streaming tasks can execute near data sources.Developers divide work into local tasks near sources and global tasks that aggregate results.

F. Cloud-Sea Computing Systems

Cloud-sea computing separates sea-side devices and functions from cloud-side resources while using an intermediate seaport to connect, aggregate, and protect each sea zone. The model extends Web computing toward large-scale device and data environments.

  • F. Cloud-Sea Computing Systems: Cloud-sea computing treats datacenters as the cloud and client-side human-facing or physical-world-facing devices as the sea.
  • F. Cloud-Sea Computing Systems: Each sea zone uses a seaport as its cloud gateway, information and functionality gathering point, and security and privacy shield.Devices communicate with the cloud through the seaport rather than directly.
  • F. Cloud-Sea Computing Systems: Sea-side functions include sensing, interaction, and local processing, while cloud-side functions include aggregation, request-response, and big-data processing.
  • F. Cloud-Sea Computing Systems: The project targets future environments containing trillions of sea devices and ZBs of data.
  • F. Cloud-Sea Computing Systems: The REST 2.0 architecture attempts to reuse existing Web computing ecosystems for cloud-sea computing.
  • F. Cloud-Sea Computing Systems: Cloud-sea computing focuses on migrating cloud functions toward the sea side, whereas generalized edge computing may use intermediate computing and network resources.

G. Cachier and Precog

Cachier and Precog apply edge resources and request locality to image recognition, while FocusStack, AirBox, and Firework address deployment, security, and distributed service programming. Together, these systems illustrate specialized edge mechanisms for prediction, location awareness, trusted execution, and adaptive collaboration.

  • G. Cachier and Precog: Cachier combines recognition, optimization, and offline analysis modules to match images against cached models and estimate cache size.It uses request-distribution prediction, cache accuracy, and delay models to adjust edge caches.
  • G. Cachier and Precog: Precog extends Cachier by caching trained classifiers on end devices and using a Markov model to predict future image requests.It combines end-device and edge-node processing to reduce image migration and last-mile delay.
  • G. Cachier and Precog: FocusStack discovers edge devices, deploys and manages containers, and builds a hybrid cloud from edge containers and data-center virtual machines.
  • G. Cachier and Precog: AirBox loads edge functions through a console and edge provisioner, using system-level containers and hardware security mechanisms such as Intel SGX.Its secure APIs support remote attestation, remote authentication, sealed storage, and developer-defined interfaces.
  • G. Cachier and Precog: Firework represents services and functions as data views and splits processing into sub-services that can be scheduled across cooperating nearby nodes.Idle nodes can receive sub-services to form dynamic clusters and complete services faster.

2) Computational flow layer scheduling:

Firework coordinates heterogeneous edge nodes through dynamic scheduling, while the survey places edge systems across diverse application scenarios and open-source projects. These systems support responsive analytics and distributed processing across vehicles, homes, video, drones, and VR.

  • Computational flow layer scheduling: Firework nodes cooperate along computational flows and dynamically schedule execution nodes, selecting nearby nodes according to network state.The example criterion is node location, such as choosing nodes closest to users.
  • Computational flow layer scheduling: Each Firework node includes job management, actuator management, and service management modules, while its architecture separates computing nodes from managers.The actuator-related module manages hardware resources and task processes, decoupling devices, execution environments, and upper-layer functions.
  • Application scenarios: Edge computing systems address varied scenarios, including connected vehicles, smart homes, latency-aware video analytics, drone vision, and multi-user virtual reality.Examples include OpenVDAP, Vigilia, LAVEA, drone computer-vision pipelines, and MUVR.
  • Open-source systems: Open-source projects surveyed include CORD, Akraino Edge Stack, EdgeX Foundry, Apache Edgent, and Azure IoT Edge.The projects cover edge cloud services, IoT interoperability and analytics, and hybrid cloud-edge analytics.

A. CORD

CORD reconstructs operator edge infrastructure from commodity hardware and open-source software, while Akraino Edge Stack targets holistic, highly available edge-cloud infrastructure. EdgeX Foundry provides hardware- and environment-agnostic IoT interoperability through edge microservices.

  • A. CORD: CORD addresses closed, inflexible operator infrastructure by building dynamically scalable edge datacenters from commodity hardware and open-source software.Its hardware uses commodity servers and white-box switches organized in a Spine-Leaf topology, with ONOS and XOS providing network and service control.
  • A. CORD: CORD supports mobile, residential, and enterprise deployments through M-CORD, R-CORD, and E-CORD service-delivery platforms.M-CORD targets mobile and 5G networks, while R-CORD and E-CORD target residential and enterprise users.
  • A. CORD: CORD remains under test among network operators, and additional research is needed to combine it with diverse edge applications.
  • B. Akraino Edge Stack: Akraino Edge Stack develops an open-source infrastructure and orchestration stack for high-availability edge-cloud services and requirements such as low latency, performance, scalability, and interoperability.Its scope spans infrastructure, middleware, and applications, including Edge APIs and frameworks for third-party edge applications.
  • C. EdgeX Foundry: EdgeX Foundry is a hardware- and operating-system-agnostic interoperability framework connecting heterogeneous IoT devices to local or cloud applications.Its Device Profiles describe object types, data formats, stored data, and device commands, while Device Services translate data and commands across protocols.

1) Device Services Layer:

The surveyed IoT edge tools provide device-facing services, analytics pipelines, and export mechanisms. Apache Edgent emphasizes lightweight stream analytics that filters local data before sending essential information to back-end systems.

  • 1) Device Services Layer: EdgeX Foundry’s Device Services Layer converts device data formats, forwards data to Core Services, and translates commands into device instructions.
  • 2) Core Services Layer: EdgeX Core Services store device data and metadata and expose command interfaces for north-side requests.Core Data persists collected data, while Metadata stores information such as Device Profiles.
  • 3) Supporting Services Layer: EdgeX supporting services provide edge analytics, rules-based actuation, alerts, notifications, scheduling, and logging.The Rules Engine monitors incoming data and can trigger device actuation when configured data ranges are reached.
  • 4) Export and system services: EdgeX export services connect core data to registered cloud or local clients, while system management supports installation, upgrades, operation, and monitoring.Security protects data and commands from connected IoT objects.
  • Apache Edgent: Apache Edgent models lightweight edge stream analytics as topologies, with connectors for external data sources and providers that create and execute processing graphs.Applications can filter, split, transform, and process streams in Java 7, Java 8, or Android environments.
  • Apache Edgent: Edgent analyzes sensor, device, file, or log data locally and sends essential results to back-end systems, reducing transmission cost and providing local feedback for IoT use cases.

E. Azure IoT Edge

Azure IoT Edge moves compatible cloud applications and analytics to edge devices through containerized modules managed by an edge runtime and cloud interface. The survey compares it with other open edge systems by purpose, deployment, users, scalability, and related characteristics.

  • E. Azure IoT Edge: Azure IoT Edge uses the Azure IoT programming model to move existing cloud applications to routers, gateways, and other edge devices for lower latency.The approach supports applications including machine learning and image recognition.
  • E. Azure IoT Edge: Its architecture comprises containerized IoT Edge modules, an IoT Edge runtime, and a cloud-based management interface.The runtime manages modules on devices, while the cloud interface deploys applications and monitors device status at scale.
  • E. Azure IoT Edge: Deployment packages user code or Azure services as a Docker module image, which the edge system pulls and instantiates on the target device.
  • E. Azure IoT Edge: Azure IoT Edge has applications in intelligent manufacturing, irrigation, and drone management, but Azure Functions, Azure Machine Learning, and Azure Stream are charged services.
  • Comparison: The comparison framework evaluates open edge systems by purpose, application area, deployment, target users, virtualization, characteristics, limitations, scalability, and mobility.EdgeX Foundry emphasizes device interoperability, Apache Edgent emphasizes edge data analysis, and Azure IoT Edge emphasizes cloud-to-edge application migration.
  • Comparison: EdgeX Foundry, Apache Edgent, and Azure IoT Edge can be deployed on local edge devices, whereas CORD and Akraino Edge Stack target network operators and require related infrastructure.Azure IoT Edge deployment and application development use a cloud-based interface.

5) Virtualization technology:

Edge computing systems use virtualization, scalability, mobility, and system-specific characteristics to support diverse deployment scenarios. Tool selection depends on cloud dependence, device-management needs, and whether telecom-operated infrastructure is available.

  • Virtualization technology: Virtual machines improve resource management, utilization, stability, and scalability, while containers provide isolated, agile services with negligible overhead.
  • System characteristics: EdgeX Foundry offers common device-management APIs, Azure IoT Edge integrates Azure services, and system characteristics can simplify application deployment and monitoring.
  • Limitations: The latest EdgeX Foundry lacks a programmable application interface, Azure services remain chargeable, and Apache Edgent has limited scalability.
  • Scalability: EdgeX Foundry, CORD, and Akraino Edge Stack support scalable application deployment through microservices, containers, or virtual machines, whereas Edgent applications cannot dynamically change performance.
  • Mobility: CORD and Akraino Edge Stack support mobile edge services through telecom access networks, meeting mobility needs for applications such as unmanned cars and drones.
  • Scenario-based tool selection: For local enterprise back ends, EdgeX Foundry or Apache Edgent are favorable; cloud-to-edge services favor Azure IoT Edge and competitors; telecom-provided infrastructure favors CORD or Akraino.
  • Emerging projects: Device Management Edge manages edge devices, while KubeEdge provides native containerized application orchestration for edge nodes.
  • Energy efficiency: Energy efficiency is evaluated across cloud, edge-server, and device layers using the three-layer edge-computing paradigm.

A. At the Top Cloud Layer

Energy efficiency in edge systems depends on deployment architecture and workload characteristics across cloud, fog, server, and device layers. Reviewed mechanisms include cloudlet provisioning, data reduction, power capping, energy-aware hardware, and computation offloading.

  • Cloud and fog energy use: Decentralized edge processing has conflicting energy assessments: some studies find it more efficient, while others report higher consumption than centralized processing.
  • Cloud and fog energy use: Fog mode may provide higher energy efficiency than centralized cloud mode, depending on application type, access network, and active-time ratio.
  • Edge-server energy management: Cloudlet studies identify VM synthesis and on-demand provisioning as major energy consumers, motivating cached-VM and cloudlet-push provisioning.
  • Edge-server energy management: Fog Data reduces transmitted data by orders of magnitude through wearable-sensor analytics and uses a low-power architecture to save energy.
  • Edge-server energy management: DockerCap performs runtime container-resource management and achieves results comparable to Intel RAPL hardware power capping.
  • Edge-server energy management: Energy-aware cluster experiments show that load-balancing strategies and cluster configurations substantially affect system energy consumption.
  • Device-layer energy management: IoT devices face strict battery and storage constraints, making computation offloading a key energy-saving strategy for resource-intensive applications.
  • Device-layer energy management: MAUI uses fine-grained program partitioning for mobile code offloading and achieves up to one order of magnitude energy savings with significant performance improvement.

2) Collaborated devices control and resource management:

Edge intelligence requires coordination among devices, edge resources, and cloud services because IoT devices have limited energy and computing capacity. The survey reviews collaboration mechanisms, edge-oriented learning systems, packages, and selection tools.

  • Collaborated devices control and resource management: When remote edge or cloud resources are unavailable, device collaboration can complete tasks without violating energy constraints.
  • Collaborated devices control and resource management: PCloud forms a privacy-preserving personal cloud from nearby devices, reducing task execution time and energy consumption when remote resources are difficult to access.
  • Collaborated devices control and resource management: REPLISON uses LTE-optimized memory replication and D2D communication, reducing energy per device for a replicate transmission despite higher total energy consumption.
  • Deep learning at the edge: Deep-learning functions are moving from cloud centers to edge devices, requiring techniques that address limited computing power, data sharing, and platform-algorithm mismatch.
  • Deep learning at the edge: OpenEI combines local task execution and training, hardware-specific model selection, and RESTful data sharing to provide intelligent capabilities across edge hardware.
  • Industry systems: AWS IoT Greengrass ML Inference and Google Cloud IoT Edge extend cloud-developed or cloud-optimized machine-learning capabilities to local edge devices.
  • Deep-learning packages: Cloud-oriented deep-learning packages are often unsuitable for edge devices because of computing-resource limitations, motivating edge-specific frameworks and tools.
  • Deep-learning packages: TensorFlow Lite targets low-latency on-device inference using mobile kernels, pre-fused activations, and quantized kernels that produce smaller and faster models.

C. Hardware System

Edge hardware for deep learning is organized into FPGA-, GPU-, and ASIC-based systems, each targeting efficient execution under edge constraints. Representative designs optimize throughput, energy, portability, or application-specific computation.

  • FPGA-based hardware: FPGA accelerators offer high performance, low energy use, parallelism, flexibility, and security for edge deep-learning workloads.
  • FPGA-based hardware: A VC707 FPGA CNN accelerator reaches 61.62 GOPS at 100MHz while improving performance and reducing FPGA resource requirements.
  • FPGA-based hardware: A Xilinx Zynq ZC706 accelerator reports 187.8 GOPS for convolutional layers and 137.0 GOPS for the full CNN at 150MHz.
  • FPGA-based hardware: ESE accelerates sparse LSTM inference to 282 GOPS and achieves 40x and 11.5x energy-efficiency improvements over CPU- and GPU-based solutions.
  • GPU-based hardware: GPU platforms support edge deep learning through parallel execution, with Jetson TX2 targeting low latency and power efficiency and DRIVE PX targeting autonomous driving.
  • ASIC-based hardware: ASICs are application-specific circuits suited to edge computing because they can provide smaller size, lower power consumption, higher performance, and higher security.
  • ASIC-based hardware: DianNao accelerators reduce memory transfers, while ShiDianNao targets embedded image applications and CNN acceleration.
  • ASIC-based hardware: Google Edge TPU combines custom hardware, open software, and AI algorithms to support high performance in a small physical area with low power consumption.

VI. KEY DESIGN ISSUES

Edge computing design must coordinate heterogeneous, distributed resources while supporting mobility, fairness, privacy, developer usability, ownership, pricing, and application compatibility. The survey identifies these issues as important for analyzing and designing systems that can support edge applications.

  • 1) Mobility Support: Mobility support must handle user handoffs and dynamic resource discovery, management, failure recovery, and replacement.Existing examples support coarse-grained service migration or device join and leave, but fine-grain migration, prediction, and intelligent resource management remain needed.
  • 2) Multi-user Fairness: Multi-user fairness is difficult on resource-constrained edge devices, where competition and limited local information can threaten critical tasks.Existing systems mainly provide resource isolation; stronger fairness strategies require additional system support such as task-status updates.
  • 3) Privacy Protection: Privacy protection must address privately owned edge devices, guest access, data exposure, and control risks under resource constraints.AirBox uses hardware security mechanisms such as Intel SGX, while other directions include resource isolation, privilege management, and access control.
  • 4) Developer Support: Developers need interactive APIs, deployment, resource application and revocation, and effective development services to make edge systems broadly usable.The paper recommends designing systems from an application developer’s perspective to improve the edge-computing ecosystem.
  • 5) Resource Organization: Edge systems must coordinate resources owned by households, ISPs, and governments according to application needs, especially during emergencies.The challenge spans smart-home gateways and sensors, network resources and base stations, and government-owned traffic cameras.
  • 6) Pricing: Pricing requires measuring resource usage and overall overhead when applications consume resources from multiple owners.Unlike cloud allocation, edge deployments may cross ownership boundaries, requiring an appropriate pricing model.
Loading 1911.02794v1…