PaperlayerView exact revision on arXiv

Source-linked AI summary

Soft-Defined Heterogeneous Vehicular Network: Architecture and Challenges

Kan Zheng, Lu Hou, Hanlin Meng, Qiang Zheng, Ning Lu, Lei Lei

arXiv:1510.06579v1cs.NI

TL;DR

The paper addresses the difficulty of adapting HetVNET architectures to changing network demands while meeting diverse ITS QoS requirements. It proposes SERVICE, a Cloud-RAN-based soft-defined HetVNET with pooled multi-domain resources and hierarchical control, and concludes that the approach is feasible for future vehicular communication and 5G networks.

  • Problem

    Existing HetVNET architectures cannot efficiently handle heterogeneous access technologies, changing network conditions, and increasing ITS service demands.

  • Method

    SERVICE applies SDN to a multi-layer Cloud-RAN architecture and uses hierarchical control to pool and coordinate multi-domain resources for vehicle users.

  • Results

    The paper concludes that SERVICE provides centralized control, flexibility, and open interfaces between functions and layers, supporting its feasibility for future vehicular communication and 5G networks.

  • Takeaways & Limitations

    Soft-defined HetVNET is presented as a promising way to meet future vehicular communication requirements by virtualizing and pooling multi-domain resources in clouds.

Abstract

from arXiv · show

Heterogeneous Vehicular NETworks (HetVNETs) can meet various quality-of-service (QoS) requirements for intelligent transport system (ITS) services by integrating different access networks coherently. However, the current network architecture for HetVNET cannot efficiently deal with the increasing demands of rapidly changing network landscape. Thanks to the centralization and flexibility of the cloud radio access network (Cloud-RAN), soft-defined networking (SDN) can conveniently be applied to support the dynamic nature of future HetVNET functions and various applications while reducing the operating costs. In this paper, we first propose the multi-layer Cloud RAN architecture for implementing the new network, where the multi-domain resources can be exploited as needed for vehicle users. Then, the high-level design of soft-defined HetVNET is presented in detail. Finally, we briefly discuss key challenges and solutions for this new network, corroborating its feasibility in the emerging fifth-generation (5G) era.

I. INTRODUCTION

HetVNET integrates heterogeneous access networks to address diverse ITS requirements, but traditional architectures struggle with coordination, scalability, and rapid service deployment. The paper proposes SERVICE, a Cloud-RAN- and SDN-based architecture intended to pool resources, improve efficiency, and reduce management costs.

  • I. INTRODUCTION: High vehicle mobility and changing topology make LTE alone unable to guarantee satisfactory ITS services, especially safety applications’ strict latency requirements.The introduction identifies mobility, topology dynamics, and increasing vehicle density as constraints on LTE-only support.
  • I. INTRODUCTION: Traditional HetVNET architectures cannot efficiently coordinate heterogeneous wireless technologies, wasting infrastructure and spectrum resources as network scale increases.Different services are better supported by different access technologies, while existing architectures provide limited cooperation among them.
  • I. INTRODUCTION: SERVICE proposes a multi-tier Cloud-RAN architecture that jointly exploits cloud resources for vehicular users.The architecture is motivated by Cloud-RAN’s centralized processing and flexible resource use.
  • I. INTRODUCTION: SDN separates the data and control planes on an open platform, enabling improved network efficiency while reducing management and maintenance costs.The paper presents this separation as a convenient extension of the Cloud-RAN platform.
  • I. INTRODUCTION: The paper presents a preliminary cloud-based heterogeneous vehicular network study and discusses its implementation challenges and possible solutions.The stated scope includes the SERVICE framework, SDN-based system design, and networking challenges.

II. SERVICE FRAMEWORK

SERVICE combines heterogeneous vehicular access technologies with a flexible Cloud-RAN architecture and pooled computing resources. Its multi-tier cloud design places communication and computation resources across remote, local, and mobile-cloud settings to support differing service requirements.

  • II. SERVICE FRAMEWORK: HetVNET combines LTE, DSRC, and potentially D2D access for V2I and V2V communication, but selecting suitable access methods while exploiting all radio resources remains challenging.LTE is positioned mainly for V2I, DSRC supports low-latency V2V services, and D2D can support non-safety services through proximity.
  • II. SERVICE FRAMEWORK: SERVICE adopts Cloud-RAN with soft-defined networking to integrate heterogeneous wireless network infrastructures for HetVNET.The architecture separates RRHs from baseband processing and supports open-platform virtualization and dynamic resource allocation.
  • II. SERVICE FRAMEWORK: The architecture uses heterogeneous base stations and computing infrastructures with different coverage, user capacity, processing, and storage abilities.Macro cells cover larger areas and more users, whereas small cells provide smaller coverage and typically support fewer users.
  • II. SERVICE FRAMEWORK: The architecture pools diverse communication, computation, storage, and sensing resources while allowing users to customize computing environments for desired services.The framework treats vehicles and other devices as heterogeneous participants in a cloud-based service system.
  • II. SERVICE FRAMEWORK: SERVICE applies a multi-tier cloud architecture in which cloudlets are integrated with local RAN resources to provide close-to-user service functionality.The paper describes physical proximity as important for timely delivery and low end-to-end response times.

1) Micro Cloud:

SERVICE organizes resources through vehicle-based Micro Clouds and geographically defined service areas connected to Local Clouds. Local processing and coordination reduce latency and associate resources across cloud layers for time-sensitive vehicular services.

  • 1) Micro Cloud:: Micro Clouds use computing, sensing, communication, and storage resources built into vehicles to provide services to authorized nearby users.Vehicles are treated as “computer-on-wheels,” with an onboard controller coordinating their available resources.
  • 1) Micro Cloud:: A service area is SERVICE’s basic geographical unit, with each area associated with a Local Cloud that controls local communication and computing infrastructures.Local resources may be deployed at macro-cell sites, and users can connect to nearby cloud resources after entering the service area.
  • 1) Micro Cloud:: Local Clouds are recommended for physical and MAC-layer operations, rather than remote clouds, to support radio resource management near users.This placement reflects the architecture’s division of responsibilities across cloud layers.
  • 1) Micro Cloud:: Direct access to Local Clouds decreases latency by avoiding wired transmission through core networks and can improve user experience for interactive services.The paper particularly connects Local Cloud allocation with the strict latency requirements of safety-related applications.
  • 1) Micro Cloud:: Local Clouds can act as caches or service proxies and associate resources across different layers when services span multiple cloud tiers.This cross-layer association is identified as a central role of the Local Cloud in the multi-layer architecture.

3) Remote Cloud:

SERVICE uses a layered, hierarchical SDN design to coordinate heterogeneous resources and respond to vehicle-service demands. Its remote-cloud option offers substantial processing and storage capacity but introduces wired-link delay, cross-SA traffic, and signaling overhead.

  • 3) Remote Cloud:: Remote-cloud access requires both wireless and wired links, which may slow user–server interactions.
  • 3) Remote Cloud:: Cross-SA remote-cloud offloading can create substantial east-west wired traffic and unavoidable signaling overhead.
  • 3) Remote Cloud:: The remote cloud provides powerful processing and storage capacity when a local cloud cannot meet vehicles’ QoS requirements.Requests may be offloaded to the remote cloud or a neighboring local cloud.
  • A. SDN Logical Architecture: SERVICE separates network infrastructure, control, and application layers, with the control layer determining network behavior and performance.
  • 2) Control Layer:: A hierarchical control layer assigns global, non-real-time functions to Primary Controllers and regional, low-latency QoS control to Secondary Controllers.
  • 2) Control Layer:: Horizontal controller interfaces distribute control loads, let Secondary Controllers coordinate locally, and simplify deployment of additional controllers.

3) Application Layer:

SERVICE applications use Secondary Controllers to manage access and resources according to current network conditions. This supports load balancing while preserving existing users’ QoS requirements.

  • 3) Application Layer:: Access Management redirects new vehicle requests when a virtual base station becomes overloaded, balancing traffic while meeting existing users’ QoS requirements.
  • 3) Application Layer:: Dynamic Resource Allocation treats each vehicle as a resource unit and uses virtual resource pools to satisfy new requests from current network states.

B. Concept of Virtual Base Station (vBS)

Soft-defined virtual base stations abstract and combine physical resources for vehicle services. Macro and small-cell vBS types are selected for coverage, data-rate, and latency needs.

  • B. Concept of Virtual Base Station (vBS): Soft-defined vBSs abstract physical resources through control-plane functions and provide the data/control functionality needed by vehicle users.
  • B. Concept of Virtual Base Station (vBS): A macro-cell vBS serves coverage requirements within one service area, whereas a small-cell vBS supports high-data-rate or short-latency services.
  • B. Concept of Virtual Base Station (vBS): Macro-cell vBSs generally receive more resources than small-cell vBSs because their implementation complexity and communication capabilities differ.
  • B. Concept of Virtual Base Station (vBS): Each SERVICE vBS follows the layered architecture, while application-layer functions can optimize operation and coordinate interference among neighboring vBSs.

C. Benefit of SDN in SERVICE

SDN in SERVICE enables shared, virtualized management of heterogeneous resources and supports coordinated scheduling, resource utilization, and mobility management. The architecture can reduce deployment costs and improve utility, but multi-domain dynamics make resource abstraction and management challenging.

  • C. Benefit of SDN in SERVICE: Shared infrastructure and radio resources can significantly reduce CAPEX and OPEX for new ITS services while allowing heterogeneous services to coexist.
  • C. Benefit of SDN in SERVICE: Logically centralized control of infrastructure and resources creates an opportunity to maximize system utility and allocate dedicated resources for strict-QoS services.
  • C. Benefit of SDN in SERVICE: The use of SDN in HetVNET introduces network-design challenges, including abstracting and managing dynamic resources across communication, computation, and storage domains.
  • C. Benefit of SDN in SERVICE: Virtualized resources can be scheduled across homogeneous or heterogeneous networks, jointly utilized across domains, and used for mobility management aimed at seamless connectivity.
  • C. Benefit of SDN in SERVICE: Multi-domain resource virtualization senses and maps communication, computation, and storage resources into a reusable resource pool.

1) Multi-Domain Resource Sensing (MDRS) Entity:

The MDRS entity senses heterogeneous communication, computation, and storage resources so the controller can maintain resource information for coordinated allocation. It balances sensing accuracy and control overhead through periodic, adaptive, and event-evoked reporting.

  • Multi-Domain Resource Sensing (MDRS) Entity: MDRS maintains information about communication, computation, and storage resources whose availability changes across domains, locations, vehicles, and cloud tiers.The controller uses this information to find and utilize multi-domain resources.
  • Multi-Domain Resource Sensing (MDRS) Entity: Regular sensing periodically reports available multi-domain resources to the MDRV entity, which records and updates the resource information.
  • Multi-Domain Resource Sensing (MDRS) Entity: The controller adapts sensing periods to network conditions and can configure different periods for different areas.This balances sensing overhead against performance and reduces sensing cost when conditions change slowly.
  • Multi-Domain Resource Sensing (MDRS) Entity: Event-evoked sensing immediately reports accidents, interrupted links, or traffic overload to the controller.
  • Multi-Domain Resource Sensing (MDRS) Entity: Virtualized resource sub-pools represent communication, computation, and storage resources in unified logical forms for centralized management.Examples include multidimensional communication grids, virtual machines, and virtual storage pools.
  • Multi-Domain Resource Sensing (MDRS) Entity: RU granularity trades flexibility against control cost, and fixed-size resource units may be unsuitable when resource usage and traffic load vary rapidly.The paper therefore identifies adaptive RU selection as important for system performance.

B. Cooperative Management on Wireless Resource

Cooperative management uses centralized control across wireless access systems to address coverage gaps, mobility, and interference. It supports both homogeneous coordination among similar systems and heterogeneous coordination across systems such as LTE and DSRC.

  • B. Cooperative Management on Wireless Resource: High vehicle mobility and limited base-station coverage can create non-coverage areas and low data rates, motivating cooperative communication.
  • B. Cooperative Management on Wireless Resource: Homogeneous cooperation coordinates nodes using the same wireless access system, while heterogeneous cooperation coordinates different systems such as LTE and DSRC.
  • B. Cooperative Management on Wireless Resource: Inter-cell interference can be mitigated across space, frequency, and time dimensions using beamforming, priority configuration, and Almost Blank Subframes.
  • B. Cooperative Management on Wireless Resource: Centralized control enables cooperation by collecting link information and coordinating requests between local and higher-level controllers.A heterogeneous-cooperation procedure can request CSI for surrounding LTE and V2V links before selecting a corresponding scheme.
  • B. Cooperative Management on Wireless Resource: Cooperative schemes can target different objectives, including minimizing delay or outage probability and maximizing throughput.

C. Joint Utilization on Multi-Domain Resource

Joint multi-domain resource utilization lets the system trade communication, computation, and storage resources to support vehicle-user QoS. The paper describes coordinated allocation, content delivery, offloading, and dynamic decision-making under changing resource conditions.

  • C. Joint Utilization on Multi-Domain Resource: Broadcasting information to users in the same tribes can save communication resources compared with unicasting.The controller forms tribes using dimensions such as location, activity, and interest.
  • C. Joint Utilization on Multi-Domain Resource: Cloud storage and computation can enlarge vehicle-user storage and processing capacity, but the benefit depends on unstable communication capacity.Using the cloud at an inappropriate time may cause excessive energy consumption and latency.
  • C. Joint Utilization on Multi-Domain Resource: Offloading decisions use multi-domain resource information to determine request acceptance, serving vBS selection, and communication and computation allocation.The stated objective is to maximize SERVICE revenue.
  • C. Joint Utilization on Multi-Domain Resource: Because requests and resources change dynamically, a steady algorithm based only on the present global state may not maximize system revenue.The paper models the problem as an MDP with states, actions, rewards, and transition probabilities.
  • C. Joint Utilization on Multi-Domain Resource: Communication, computation, and storage resources can be traded and allocated cooperatively under centralized control to optimize SERVICE performance.

D. Mobility Management in SERVICE

SERVICE addresses mobility-related outages and frequent handovers by separating mobility control from local high-rate transmission. Its Win-Lots design uses wide control coverage with local transmissions, while retaining unresolved control-channel design issues.

  • D. Mobility Management in SERVICE: Separating data and control channels can reduce the possibility of mobility-related outage during vehicle movement.
  • D. Mobility Management in SERVICE: “Wide Control and Local Transmissions,” or “Win-Lots,” assigns mobility-related control to MvBSs and high-data-rate transmission to SvBSs.
  • D. Mobility Management in SERVICE: Win-Lots can avoid handover when a user moves within one service area, addressing the bottleneck between coverage and transmission capacity.
  • D. Mobility Management in SERVICE: Low-frequency resources are preferred for MvBS control coverage, whereas high-frequency resources are more suitable for SvBS transmission.
  • D. Mobility Management in SERVICE: Mobility management can use cloud storage and vehicle reports to record and update trajectories, activating control functions near neighboring service-area edges.
  • D. Mobility Management in SERVICE: Win-Lots still requires a new control-channel format because the SvBS control channel omits cell-specific signaling.

V. CONCLUSION

The paper investigates SDN in HetVNET using a Cloud-RAN architecture called SERVICE and proposes hierarchical control to support a unified, flexible network. It concludes that the approach is promising, while emphasizing that substantial challenges and further investigation remain.

  • The soft-defined HetVNET is presented as promising for meeting future vehicular communication requirements and supporting ubiquitous 5G networks.
  • Multi-domain resources can be virtualized and pooled in clouds for vehicle users’ safety-related and non-safety-related services.
  • SERVICE investigates SDN in HetVNET based on a Cloud-RAN architecture and proposes a hierarchical control layer for implementation.
  • The proposed architecture provides flexibility, centralized control, and open interfaces between functions and layers, enabling a unified and flexible network.
  • Many challenges remain, and the preliminary study of key control functions and applications requires further investigation before practical deployment.
Loading 1510.06579v1…