PaperlayerView exact revision on arXiv

Source-linked AI summary

Architectural Design Alternatives based on Cloud/Edge/Fog Computing for Connected Vehicles

Haoxin Wang, Tingting Liu, BaekGyu Kim, Chung-Wei Lin, Shinichi Shiraishi, Jiang Xie, Zhu Han

arXiv:2009.12509v1cs.NI

TL;DR

Connected vehicles require computing architectures that can support computation-intensive workloads and diverse QoS demands, while prior surveys insufficiently compare architectural alternatives. This paper surveys cloud-, edge-, and fog-based designs, classifies them as computation-aided or computation-enabled, and compares their benefits, disadvantages, challenges, and requirements across CV applications.

  • Problem

    Existing CV surveys often focus on a single cloud, edge, or fog architecture and do not systematically compare alternatives or their benefits, challenges, and system requirements.

  • Method

    The paper conducts a comprehensive survey of cloud-, edge-, and fog-based CV architectures and proposes a computation-aided versus computation-enabled classification.

  • Results

    The paper presents a holistic comparison of architectural alternatives according to CV functional requirements, including advantages, disadvantages, and research challenges.

  • Takeaways & Limitations

    Architectural choice should be considered against the differing QoS requirements and operating conditions of CV applications.

Abstract

from arXiv · show

As vehicles playing an increasingly important role in people's daily life, requirements on safer and more comfortable driving experience have arisen. Connected vehicles (CVs) can provide enabling technologies to realize these requirements and have attracted widespread attentions from both academia and industry. These requirements ask for a well-designed computing architecture to support the Quality-of-Service (QoS) of CV applications. Computation offloading techniques, such as cloud, edge, and fog computing, can help CVs process computation-intensive and large-scale computing tasks. Additionally, different cloud/edge/fog computing architectures are suitable for supporting different types of CV applications with highly different QoS requirements, which demonstrates the importance of the computing architecture design. However, most of the existing surveys on cloud/edge/fog computing for CVs overlook the computing architecture design, where they (i) only focus on one specific computing architecture and (ii) lack discussions on benefits, research challenges, and system requirements of different architectural alternatives. In this paper, we provide a comprehensive survey on different architectural design alternatives based on cloud/edge/fog computing for CVs. The contributions of this paper are: (i) providing a comprehensive literature survey on existing proposed architectural design alternatives based on cloud/edge/fog computing for CVs, (ii) proposing a new classification of computing architectures based on cloud/edge/fog computing for CVs: computation-aided and computation-enabled architectures, (iii) presenting a holistic comparison among different cloud/edge/fog computing architectures for CVs based on functional requirements of CV systems, including advantages, disadvantages, and research challenges.

I. INTRODUCTION

Connected vehicles generate demanding computation and communication workloads, making cloud, edge, and fog architectures important for meeting diverse QoS requirements. Existing surveys undercompare these architectural alternatives, motivating a broader architectural review.

  • I. INTRODUCTION: Connected vehicles support safer, more comfortable, and more efficient transportation services but face substantial computation and communication demands.Examples include intelligent driving, cruise assistance, and high-resolution map creation.
  • I. INTRODUCTION: Cloud computing provides scalable, virtualized, and computation-intensive processing, but CV data volumes and latency-sensitive applications challenge remote-cloud processing.CV sensors can generate data at very high rates, while many applications require rapid responses.
  • I. INTRODUCTION: Cloud, edge, and fog computing enable computation offloading, with edge processing reducing response delay by locating computation closer to vehicles.Cloud computing offers large-scale processing, while edge and fog architectures address latency and distributed-resource needs.
  • I. INTRODUCTION: Different cloud, edge, and fog architectures suit CV applications with different latency, computation-resource, storage, and workload requirements.Workloads can vary across time and locations, complicating capacity planning and resource management.
  • I. INTRODUCTION: Prior surveys largely focus on one computing architecture or on communication, leaving limited systematic comparison of architectural benefits, challenges, and system requirements for CVs.The paper identifies a gap in comprehensive comparisons across cloud-, edge-, and fog-based alternatives.

B. Contribution

The paper surveys cloud/edge/fog architectural alternatives for connected vehicles and organizes them around a new computation-aided versus computation-enabled classification. It also compares these alternatives by functional requirements and identifies open design challenges.

  • B. Contribution: The paper provides a comprehensive survey of proposed cloud/edge/fog computing architectural alternatives for connected vehicles.
  • B. Contribution: It introduces a classification of connected-vehicle computing architectures into computation-aided and computation-enabled architectures.
  • B. Contribution: The paper compares architectures holistically using functional requirements, including advantages, disadvantages, and research challenges.
  • B. Contribution: It identifies open issues involving hybrid architectures, data-traffic localization, mobility across heterogeneous architectures, and computing-resource management.

II. CV SYSTEM DESIGN

The connected-vehicle ecosystem combines vehicles, roadside units, and centers to support communication, monitoring, warnings, control, and data-driven services. U.S. and European initiatives illustrate the deployment and security context for these systems.

  • A. USDOT Activities on CVs: U.S. and European initiatives support cooperative vehicle communications for safety, comfort, traffic services, and connected-vehicle deployment.
  • II. CV SYSTEM DESIGN: The CV ecosystem has three levels—vehicles, RSUs, and centers—with both intra-level and inter-level communications.
  • II. CV SYSTEM DESIGN: RSUs perform local computation and communication, while centers monitor vehicle and RSU data and make broader ecosystem decisions.
  • II. CV SYSTEM DESIGN: The ecosystem includes security mechanisms such as USDOT’s SCMS, which aims to ensure communication integrity, authenticity, and privacy.

B. Functional Requirements of CV Systems

Connected-vehicle systems must support data sharing, processing, monitoring, warnings, and control across vehicles, roadside infrastructure, and centers. Cloud, edge, and fog architectures provide alternative placements for the computing capabilities needed by these functions.

  • B. Functional Requirements of CV Systems: The five main CV-system functions are data sharing, data processing, monitoring, warning, and control.
  • B. Functional Requirements of CV Systems: Data-sharing requirements vary across V2V, V2D, and V2I communication levels in collected-data size, bandwidth, and throughput.
  • B. Functional Requirements of CV Systems: Data processing depends on computing-unit power because services such as intelligent driving require heavy processing of cruising, video, and control data.
  • B. Functional Requirements of CV Systems: Each ecosystem function can require security levels for confidentiality, integrity, and availability.
  • B. Functional Requirements of CV Systems: Cloud architectures place centers remotely, whereas edge/fog architectures distribute computing capabilities closer to vehicles or field equipment.

1) Data Generation in vehicular networks:

Vehicular data generation differs from smartphone workloads in volume, direction, timing, availability, security, and connectivity requirements. These differences make network and service design especially consequential for safety-critical CV applications.

  • Data volume and direction: Vehicles generate large sensor datasets and primarily produce data for cloud services, unlike smartphones that mainly consume downloaded content.High-end vehicles may have around a hundred sensors, and each vehicle is expected to send at least 20 GB monthly to the cloud.
  • Response time: CV services span millisecond-scale response requirements and less stringent workloads, but delayed responses can create safety consequences in applications such as platooning.Fail-safe modes may activate when abnormal delays occur.
  • Network availability: Different CV services require different levels of network availability, from continuous connectivity for platooning to intermittent connectivity supported by local computation and storage.Standalone navigation maps are an example of a service that can continue without continuous network access.
  • Connectivity selection: Moving vehicles may encounter heterogeneous wireless networks with different costs and latencies, requiring service execution decisions that account for latency and cost.The decision arises when multiple network options are available along a vehicle route.
  • Security and privacy: Security and privacy protections must account for safety-critical consequences while balancing the added latency, computation, storage, and design complexity of stronger encryption.Compromised roadway safety information can trigger unexpected vehicle control operations.

5) Data Locality and Data Sovereignty:

CV data is often local to the area where it is generated, while national rules may constrain where data can be stored or transmitted. Architectural design must therefore address locality, sovereignty, heterogeneous connectivity, communication reliability, security, and deployment choices.

  • Data locality: Local CV data is often meaningful only near its source, so sending all data to remote clouds can waste network bandwidth and cloud storage.Examples include nearby vehicle positions, road-sign semantics, and local HD-map information.
  • Data sovereignty: National regulations may require certain vehicle data to remain within a country or follow locally imposed transmission rules.The paper notes that OEMs may lack sufficient customization for such restrictions.
  • Network heterogeneity: Uncertain vehicular connections, changing topology, limited cellular bandwidth, and incomplete base-station coverage motivate heterogeneous networks combining cellular and V2V ad hoc communication.The design challenge concerns allocating resources across complementary connectivity options.
  • V2V communication: V2V broadcasting can improve shared-content delivery among nearby vehicles, but IEEE 802.11p broadcast lacks RTS/CTS and is therefore vulnerable to hidden-terminal problems.The issue is especially relevant when co-located vehicles share navigation or environment-recognition content.
  • Deployment and mobility: Application placement across cloud, edge/fog nodes, and vehicles depends on network topology, delay tolerance, and mobility predictions, while fast mobility can restrict some offloading frameworks.Mobility management is identified as a common challenge for hierarchical architectures.

IV. CLOUD/EDGE/FOG COMPUTING ARCHITECTURES FOR CVS

The survey organizes CV cloud/edge/fog architectures into computation-aided and computation-enabled categories, then further distinguishes centralized, distributed, and hybrid resource organizations. It evaluates these alternatives through functional design considerations spanning data, applications, communication, resources, interaction, and security.

  • Architectural classification: The proposed classification separates computation-aided architectures, where CVs generate tasks, from computation-enabled architectures, where CVs also possess computation capabilities.The second category can coordinate and allocate idle vehicle resources through vehicle clouds or fogs.
  • Computation-aided architectures: Computation-aided architectures rely on external cloud, edge, or fog infrastructure as the only computation resources for CV-generated tasks.Vehicles act as computation sources while nearby edge nodes or cloud servers perform the computation.
  • Design considerations: The survey examines data, applications, communication, computation and storage, interaction, and security as key architectural design considerations.These considerations cover both external infrastructure coordination and the management of vehicle-associated resources.
  • Computation-enabled architectures: Computation-enabled architectures add vehicle computation resources and require security and privacy mechanisms alongside coordination of vehicle-cloud or vehicle-fog resources.The paper defines a vehicle cloud or fog as a group of autonomous vehicles whose resources can be dynamically coordinated and allocated to authorized users.
  • Resource organization: Architectures are further divided into centralized, distributed, and hybrid forms according to how computation resources are distributed.Centralized designs may also use hierarchical organization from network edges to remote centers.

A. Computation-aided Computing Architectures

Computation-aided CV architectures leave task execution to external infrastructure and include centralized, hierarchical, and hybrid designs. The surveyed alternatives trade centralized aggregation and capacity against the lower latency, communication flexibility, and mobility-management challenges of edge, fog, and hybrid deployments.

  • Architecture scope: Computation-aided architectures treat CVs as task sources while external edge or cloud units perform computation according to service requirements and load.The surveyed designs include nearby WiFi routers, small-cell and macro-cell base stations, and cloud servers.
  • 1) Centralized Architecture: Centralized cloud architectures support data aggregation and large-scale studies, including vehicle-based air-quality monitoring that trades monitoring accuracy against data-offloading overhead.Dynamic grid partitioning and probabilistic reporting adjust sampling and avoid redundant data.
  • 1) Centralized Architecture: Remote centralized clouds become inefficient for latency-critical and computation-intensive CV applications, motivating hierarchical architectures that add RSUs, base stations, and edge or fog servers.These architectures place computation closer to vehicles while retaining centralized cloud resources.
  • 2) Hybrid Architecture: Mobility management remains a common challenge for hierarchical architectures, and fast vehicle mobility can seriously restrict some offloading frameworks.Mobility prediction is used in one approach to decide which data RSUs should fetch and how to schedule transmission.
  • 2) Hybrid Architecture: The four-layer urban traffic architecture combines environment sensing, SDN-enabled communication, MEC servers, and a remote core cloud to support programmable routing and heterogeneous wireless access.Its communication layer separates data and control planes and uses multiple vehicle wireless modules.
  • 2) Hybrid Architecture: Mobile edge servers reduce offloading delay and suit latency-sensitive applications, while the cooperative fog design adds geographically distributed fog servers beneath an edge layer containing VANETs, IoT, and cellular networks.A rapid road-accident rescue system is given as an example for the low-latency MEC architecture.

B. Computation-enabled Computing Architectures

Computation-enabled architectures allow connected vehicles to generate tasks while retaining computation capabilities, using centralized, distributed, or cooperative resources. Vehicle clouds extend this model through dynamic or static resource sharing, but mobility, limited network capacity, and security complicate cooperation.

  • Computation-enabled architectures let vehicles compute generated tasks themselves, through nearby vehicle clusters, or with remote-cloud cooperation.
  • 1) Distributed Architecture: Vehicle clouds coordinate vehicle resources as distributed computing units that provide low-cost computation, sensing, communication, and data-sharing services.
  • 1) Distributed Architecture: Dynamic vehicle clouds manage idle resources among requesters and processors, while a vehicle may serve as a processor for one job and requester for another.
  • 1) Distributed Architecture: Static vehicle clouds use parked vehicles to augment fog-computing storage and computation capacity.
  • 1) Distributed Architecture: Vehicular network capacity limits data sharing and cooperation, while moving attackers complicate location security, authentication, data security, and access control.

2) Hybrid Architecture

Hybrid architectures combine vehicle clouds with centralized cloud resources or organize users, mobile buses, public infrastructure, and remote clouds into multiple layers. These designs exploit heterogeneous computing resources, but require careful scheduling and still face unresolved security challenges.

  • 2) Hybrid Architecture: Hybrid vehicle-cloud architectures connect moving or static vehicle clouds to centralized clouds through roadside units acting as gateways.
  • 2) Hybrid Architecture: A four-layer architecture links end users, mobile buses, public infrastructure, and remote cloud resources through access points near bus stations.
  • 2) Hybrid Architecture: The proposed architecture distinguishes layers by communication capacity, computation capability, and inherent properties such as bus mobility.
  • 2) Hybrid Architecture: Mobile buses offload tasks from station access points through millimeter-wave links, while fixed fog or cloud resources process tasks when no buses are available.
  • 2) Hybrid Architecture: Hybrid computation-enabled systems inherit security challenges involving vehicle-cloud trust, misbehavior, privacy, and interactions among many entities.

C. Comparison among Computing Architectural Alternatives

The paper compares centralized, distributed, and hybrid computing architectures for connected-vehicle applications using five functional requirements of vehicle systems.

  • Centralized, distributed, and hybrid architectures are compared according to five functional requirements for connected-vehicle systems.

1) Data Sharing: *

Architectural alternatives trade centralized capacity and stability against distributed locality and hybrid flexibility. The comparison identifies bandwidth, mobility, resource reliability, interoperability, security, and task scheduling as central challenges.

  • 1) Data Sharing: 60 petabytes of vehicle data per month would take 70 days to transact at 10 GB per second, illustrating centralized bandwidth bottlenecks.
  • 1) Data Sharing: Distributed architectures enable rapid direct vehicle-to-vehicle exchange without cellular base stations or WLAN access points, but mobility destabilizes connections and complicates security.
  • 1) Data Sharing: Hybrid architectures face diverse-network management and security challenges, including difficult message-integrity and user-authentication verification at high vehicle speeds.
  • 2) Data Processing: Centralized architectures offer stable access to large storage and computation resources, supporting applications requiring substantial capacity.
  • 2) Data Processing: Distributed resources vary with traffic density and vehicle availability, requiring frequent monitoring and candidate discovery.
  • 2) Data Processing: Hybrid computation-aided architectures provide more potential computation sources and lower latency through neighboring fog nodes or roadside units, but require costly heterogeneous deployment and interoperability.
  • 2) Data Processing: Hybrid systems require comprehensive task schedulers that select processing approaches using application and system criteria such as latency, data volume, capacity, energy, cost, load, and accessibility.

3) Monitoring, Warning, and Control: *

Monitoring, warning, and control architectures must match application requirements, balancing centralized visibility and historical data against latency, mobility, and heterogeneity constraints.

  • Centralized: Centralized architectures support global monitoring, warnings, and control decisions using cloud coverage and accumulated historical vehicle data.They can support traffic, accident, road-condition, and weather warnings, as well as control decisions informed by current and historical conditions.
  • Architecture selection: Architecture selection must follow application requirements: centralized computation-aided designs suit data-intensive traffic management but not latency-critical autonomous driving.The paper contrasts complicated traffic management strategies with autonomous driving’s stringent computation-latency requirements.
  • Computation-enabled architectures: Computation-enabled architectures may provide more flexible and lower-cost services through diverse providers and shorter requester–provider distances, but mobility, stability, and security remain challenges.The cited challenges include fast mobility support and dynamic participation of mobile computing resources.
  • Heterogeneous networks: Vehicular services face heterogeneous connectivity because DSRC offers low latency while LTE offers broader coverage and higher data rates but longer round-trip time.The paper reports DSRC below 10 milliseconds RTT and LTE over 300 milliseconds RTT, motivating heterogeneous networking.
  • Mobility support: Seamless service across heterogeneous infrastructures requires open interfaces that disclose supported or prohibited services as vehicles move between organizations and regions.Infrastructure ownership, limited deployment areas, and changing service availability complicate mobility support.

2) Data processing:

Data processing architectures must manage heterogeneous computing resources, localize traffic, and explore hybrid placements to satisfy diverse connected-vehicle service requirements.

  • Computing resource management: Computing resource management must match service demands with the differing memory and computation limits of clouds, edge and fog servers, RSUs, and vehicles.Relevant mechanisms include resource allocation, computation offloading, and provisioning based on workload and predicted demand.
  • Other hybrid architectural alternatives: Hybrid designs can place distributed computing at the highest layer and centralized units closer to vehicles, reducing communication and computation latency.The alternative also combines neighboring-vehicle and fog resources into a virtual localized controller.
  • Open research problems: The survey identifies hybrid architectures, traffic localization, heterogeneous mobility support, and resource management as outstanding research problems.These issues remain open within the field’s relative infancy.
Loading 2009.12509v1…