Source-linked AI summary
Wireless Sensor Network Virtualization: A Survey
Imran Khan, Fatna Belqasmi, Roch Glitho, Noel Crespi, Monique Morrow, Paul Polako
TL;DR
WSN virtualization addresses the challenge of sharing domain-specific sensor deployments among multiple applications. This paper surveys the field by organizing virtualization approaches, reviewing and evaluating existing work against scenario-derived requirements, and discussing projects and research issues. It concludes that WSN virtualization is relevant to IoT deployments supporting multiple applications concurrently, while a comprehensive solution remains unavailable.
Problem
Domain-specific WSN deployments need to support multiple applications concurrently, but existing surveys do not comprehensively address WSN virtualization or recent developments.
Method
The paper categorizes virtualization, reviews existing work and projects, evaluates solutions against scenario-derived requirements, and discusses research challenges with possible solutions.
Results
The survey provides a detailed overview and critical analysis of node-level, network-level, and hybrid virtualization, while identifying research challenges and possible solutions.
Takeaways & Limitations
WSN virtualization is relevant for IoT deployments in which small-scale devices are expected to provide services to multiple applications concurrently.
Abstract
from arXiv · showhide
Wireless Sensor Networks (WSNs) are the key components of the emerging Internet-of-Things (IoT) paradigm. They are now ubiquitous and used in a plurality of application domains. WSNs are still domain specific and usually deployed to support a specific application. However, as WSN nodes are becoming more and more powerful, it is getting more and more pertinent to research how multiple applications could share a very same WSN infrastructure. Virtualization is a technology that can potentially enable this sharing. This paper is a survey on WSN virtualization. It provides a comprehensive review of the state-of-the-art and an in-depth discussion of the research issues. We introduce the basics of WSN virtualization and motivate its pertinence with carefully selected scenarios. Existing works are presented in detail and critically evaluated using a set of requirements derived from the scenarios. The pertinent research projects are also reviewed. Several research issues are also discussed with hints on how they could be tackled.
I. INTRODUCTION
WSN virtualization addresses the inefficiency of domain-specific deployments by enabling multiple applications to share sensor infrastructure. The paper surveys this area through motivating scenarios, requirement-based evaluation, project reviews, and research directions.
- Current WSNs are domain-specific and task-oriented, causing inefficient redundant deployments when new applications are introduced.
- Virtualization abstracts physical WSN resources into logical units so multiple applications can coexist on the same deployment.
- Virtualized WSNs can support unforeseen applications, reduce coupling between applications and deployments, and broaden access for developers.
- The survey reviews WSN virtualization using real-world scenarios, recent state-of-the-art coverage, scenario-derived yardsticks, and proposed research directions.
- The review groups existing work into node-level, network-level, and hybrid virtualization and derives its analysis from motivating scenarios.
- Node-level virtualization supports multiple applications on one sensor node through sequential or time-sliced simultaneous execution, while network-level virtualization forms virtual sensor networks from node subsets or multiple WSNs.
A. Motivating Scenarios
The motivating scenarios show how virtualization can reuse distributed sensor deployments across owners and applications. They motivate requirements for concurrent, isolated, prioritized, platform-independent, discoverable, resource-aware, heterogeneous, and selective operation.
- The scenarios illustrate the motivation and benefits of using WSN virtualization in common WSN deployments.
- Fire Monitoring Scenario: Fire monitoring can combine city-owned and privately deployed nodes instead of duplicating coverage across streets, parks, and homes.
- Fire Monitoring Scenario: An overlay network is proposed to support distributed fire-contour processing when nodes in separate private domains cannot exchange data directly.
- Heritage Building Monitoring: Heritage-building monitoring illustrates how multiple organizations could reuse an existing sensor deployment during construction rather than rely on insufficient shared information or duplicate infrastructure.
- Requirements: The requirements include node- and network-level virtualization, application priority, platform independence, resource discovery, support for constrained and legacy nodes, heterogeneity, and sensor-node selection.
- Requirements: Sensor-node selection must account for applications’ spatial and temporal requirements when multiple applications use a deployment concurrently.
IV. STATE-OF-THE-ART
The survey reviews node-level virtualization systems and related operating systems, comparing their programming models, execution approaches, resource overheads, and practical limitations. Results show recurring trade-offs between programmability, concurrency, portability, and performance.
- Operating-system approaches: RIOT targets diverse IoT hardware with real-time multithreading, a C/C++ POSIX-like API, full TCP/IP support, and hardware abstraction.Its modular microkernel design supports 8-bit, 16-bit, and 32-bit processors, requiring 1.5kB of RAM and 5kB of ROM for a basic application.
- Operating-system approaches: SenSpire combines event-driven and thread-based programming with predictability, availability, hybrid programming, and efficiency for constrained nodes.Its interrupt latency is lower than TinyOS, but task scheduling incurs more delay than MANTIS while energy consumption is almost similar to TinyOS.
- Node-level virtualization systems: LiteOS separates applications from the operating system through callgates and supports concurrent application threads, dynamic task installation, and C programming.A 4KB file copy takes around 3 seconds over one hop and 7.5 seconds over two hops; LiteOS uses fewer source lines than TinyOS but more memory.
- Node-level virtualization systems: PAVENET and MANTIS offer thread-based programming in C, but PAVENET executes tasks sequentially and lacks application–OS separation, whereas MANTIS supports time-sliced multithreading.PAVENET uses more RAM than TinyOS, while its task-switching overhead is five times lower than MANTIS and comparable to TinyOS.
- Node-level virtualization systems: Maté, VMSTAR, and Agilla illustrate trade-offs among portability, execution cost, memory use, concurrency, and mobile-agent migration.VMSTAR performs better than Maté but worse than native TinyOS, while Agilla achieves 99% migration success up to 3 hops and exceeds 1.1 seconds at 5 hops.
B. Network-level Virtualization
Network-level virtualization is organized around virtual overlays or clusters that let applications use logical subsets and links over physical WSNs. The surveyed approaches demonstrate sharing concepts and scenarios, but several lack implementation detail or convincing performance evidence.
- Approach categories: Network-level virtualization approaches are grouped into virtual network/overlay-based solutions and cluster-based solutions.Overlays create logical networks over physical networks, whereas clustering groups physical nodes into connected groups.
- Virtual network/overlay-based solutions: Overlay solutions create application-specific virtual networks so nodes in different administrative domains can exchange data and support concurrent applications.The surveyed architecture abstracts simultaneous physical-sensor tasks as virtual sensors and places independent applications in overlays.
- Virtual network/overlay-based solutions: MENO and IoT-VN build virtual networks or links over physical networks to connect constrained and non-constrained devices to the Internet.IoT-VN uses neighbor detection and tunneling for constrained environments, and Click Router for non-constrained environments.
- Evaluation: Performance evidence is limited: some solutions provide no results, one uses a two-sensor test bed with little insight, while another simulation reports topology-dependent message behavior.The simulation found hops increased linearly with monitoring nodes; same-region unicast was unaffected by network size, whereas other-region multicast was affected.
- Cluster-based and VSN solutions: Agent-based and pioneering VSN approaches dynamically form application-specific node subsets or virtual topologies, allowing resource sharing across applications and changing phenomena.Nodes outside a subset can route data or sleep, while the pioneering work discusses geographically dispersed, heterogeneous, and dynamic-event applications.
C. Hybrid Solution
Hybrid solutions combine node- and network-level virtualization, using middleware, overlays, virtual machines, clusters, or dynamic grouping to support multiple applications. The reviewed approaches demonstrate both concurrent execution and resource-isolation trade-offs.
- Hybrid solutions combine node- and network-level virtualization mechanisms.
- They are grouped into middleware and cluster-based, middleware and virtual network/overlay-based, and virtual machine and dynamic grouping-based solutions.
- Middleware and Cluster-based Solutions: Sensomax uses middleware, concurrent application agents, and clusters to support multitasking, dynamic task modification, and runtime re-programming.
- Around 200ms processing time is observed for an agent running 30 concurrent applications, while dynamic update processing remains under 100ms.
- Middleware and Cluster-based Solutions: A multi-set agent architecture executes multiple applications in predefined order and adjusts functional parameters, while network subsets run applications through clustered nodes.
- Middleware and Virtual Network/Overlay-based Solutions: SenShare separates infrastructure owners from application developers and uses a hardware abstraction layer, multitasking runtime, and overlays for concurrent applications.
- Middleware and Virtual Network/Overlay-based Solutions: 28% lower sampling rate occurs with more concurrent applications, while extra overlay traffic decreases to around 10% of network traffic.
- Virtual Machine and Dynamic Grouping-based Solutions: Melete supports dynamic grouping but limits concurrent tasks, consumes more code and memory than Maté, and produces delays in the order of seconds.
D. Summary
The surveyed literature contains capable node-level virtualization systems, but network-level virtualization remains challenging and hybrid solutions are still developing. The authors organize the state of the art by virtualization level and implementation approach.
- The survey evaluates existing work against requirements identified earlier and finds several capable node-level virtualization solutions.
- Event-driven programming dominated early sensor nodes, while thread-based approaches enabled more complex and concurrent tasks.
- TinyOS and Contiki are described as popular platforms with strong community support, and Contiki is considered a platform for the IoT.
- Cluster management is challenging, and application-specific clusters must adapt to network and monitored-event dynamics.
- Overlay-based network virtualization is still largely unexplored, while recent research has increasingly focused on hybrid solutions.
- Some reviewed solutions are platform dependent, whereas others remain theoretical or conceptual.
Jayasumana et al
The listed Jayasumana et al. entries represent virtual-machine and cluster-based approaches with varied support across the summarized requirements.
- The entries include VM-based and cluster-based approaches, with support patterns differing across the listed requirements.
- Dilum et al. and Han et al. are both classified as cluster-based and share the same recorded requirement pattern.
Sensomax [66]
The supplied entry records a requirement-support pattern for Sensomax, but does not provide accompanying descriptive detail.
- Sensomax is represented by a binary requirement-support row in the supplied state-of-the-art summary.
SenShare [70]
The supplied characteristic entries for SenShare are recorded as two eight-item Yes/No-style sequences.
- The first listed sequence is Yes Yes No Yes Yes Yes No No.
- Across both sequences, the entries include Yes, No, and Predetermined classifications.
- The second listed sequence is Yes Yes Yes No No Yes No Predetermined.
Majeed et al. [68]
The supplied characteristic entries for Majeed et al. are represented by one eight-item sequence.
- The listed sequence is Yes Yes No No Yes Yes No Yes.
- No Predetermined label appears in the supplied sequence.
Melete [18]
The paper copy states that this work was accepted for publication in a forthcoming IEEE COMMUNICATION SURVEYS & TUTORIALS issue, but had not yet been proof-read.
- The paper had been accepted for publication in a forthcoming issue of IEEE COMMUNICATION SURVEYS & TUTORIALS.
- The content was described as final but not proof-read.
- The document was identified as an author copy intended for personal record only.
V. WSN VIRTUALIZATION RESEARCH PROJECTS
The paper reviews projects envisioning WSN use by multiple applications and summarizes them by stated project characteristics. Only FRESnel and VITRO directly target WSN virtualization; others have broader aims.
- This section introduces projects that envision utilizing WSNs by multiple applications.
- Table V lists the projects and summarizes them using specified characteristics.
- 1) Project Aim: FRESnel and VITRO are the only projects aimed directly at WSN virtualization.
- 1) Project Aim: The remaining projects have broader scopes, including smart cities, smart health in IoT, or large-scale network-research test beds.
2) Project Scope:
The reviewed projects span different forms and scopes of WSN virtualization, from direct node- and network-level approaches to broader IoT sensor-sharing platforms. Their evaluation setups and device capabilities vary substantially, while the authors distinguish true virtualization from gateway-based or indirect approaches.
- Project scope: FRESnel and VITRO target both node- and network-level virtualization, whereas CitySense, iCore, Butler, and ViSE support multiple applications without explicitly addressing WSN virtualization.The projects therefore cover both direct virtualization efforts and related sensor-sharing systems.
- Virtualization type: True WSN virtualization assigns virtualization tasks to sensor nodes, while gateway-based solutions connect WSNs to other networks through a single gateway.A gateway may still be present for communication, but it does not necessarily manage virtualization.
- Device types: FRESnel and VITRO use conventional sensor nodes, whereas CitySense, Butler, and ViSE rely on high-end devices complemented by computing, storage, power, and connectivity resources.The authors regard conventional sensor-node deployments as more relevant to WSN virtualization.
- Evaluation setup: All reviewed projects use real test beds, but their sizes range from ViSE’s 3 nodes and FRESnel’s 35-node in-campus setup to Smart Santander’s approximately 20,000 sensors across four European cities.The Smart Santander platform is also intended for research and evaluation, and the iCore project uses it as well.
- Overall comparison: ViSE and CitySense incorporate multi-application infrastructure sharing, Smart Santander, iCore, and Butler pursue IoT integration, while VITRO and FRESnel focus specifically on WSN virtualization.VITRO is gateway-based rather than a true realization; FRESnel addresses true virtualization but remains platform-specific.
- Overall comparison: The projects show that WSN virtualization attracts attention from academic, industrial, and telecommunications organizations.The project portfolio includes large European consortium efforts alongside university collaborations.
VI. RESEARCH ISSUES
The paper identifies research issues spanning virtualization architecture, resource discovery, task execution, energy, access, business models, and evaluation scenarios. It emphasizes that comprehensive, decentralized, and scalable solutions are still needed for heterogeneous and increasingly mobile WSN deployments.
- Advanced Node-level Virtualization: Node-level virtualization needs broader component support and mechanisms for installing or updating user tasks without disturbing existing applications.Existing approaches include multi-threaded operating systems and application-specific virtual machines, but some remain platform-specific or lack complete implementations.
- Network-level Virtualization: Network-level virtualization remains relatively underdeveloped, with existing solutions described as embryonic and opportunities for overlay-based approaches.Overlay networks are proposed because they can operate without changes to the underlying network.
- Discovery and Publication: Virtualized WSNs require efficient, robust, scalable, and manageable discovery and publication because virtual sensors are created and destroyed on demand.The paper notes that decentralized approaches such as peer-to-peer architectures could avoid reliance on a central discovery mechanism.
- Sensor Node Selection and Task Assignment: Sensor selection and task assignment must account for applications’ temporal and spatial requirements, particularly when multiple applications share sensor nodes.The authors connect appropriate node selection with improving Quality of Monitoring systems.
- Application Task Dissemination: New application tasks must be disseminated or updated seamlessly, without disrupting existing tasks or requiring sensor-node reboots.A cloud-based platform-as-a-service approach could provide tools to develop, verify, test, and deploy tasks across sensor platforms.
- Reference Designs and Architectures: A comprehensive virtualization platform should cover sensor data acquisition, end-to-end communication, data management, computation, and service composition.Such an integrated framework would allow relevant aspects to be modeled and evaluated together.
- Cross-cutting issues: Energy-efficient communication, discovery, routing, and applications remain necessary as WSN virtualization increases concurrent resource use.The paper also calls for new protocols, algorithms, simulation tools, business models, standardization, access control, authentication, accounting, and application test beds.
VII. CONCLUSION
The paper surveys WSN virtualization by categorizing it into node-level, network-level, and hybrid forms, critically evaluating existing work against scenario-derived requirements, and reviewing related projects and research challenges. It concludes that WSN virtualization is relevant to IoT’s need for concurrent multi-application services, but no comprehensive solution yet meets that challenge.
- Contribution: The survey categorizes WSN virtualization into node-level, network-level, and hybrid virtualization.It explains each category and evaluates the corresponding state of the art.
- Evaluation: Existing approaches are critically analyzed using requirements derived from motivating scenarios.The paper also reviews pertinent research projects and outlines possible solutions to identified challenges.
- Conclusion: WSN virtualization remains relevant because IoT is expected to use small-scale devices at unprecedented scale for concurrent services to multiple applications.The authors state that a comprehensive solution meeting this challenge has not yet been found.