1. Introduction
2. Related study
-
Middleware making use of a distributed virtual shared space. Many approaches in this class are based on the tuple space shared memory model, which was notably used in Linda [19], or simply provide a shared repository to enable global coordination and execution of group algorithms. Solutions belonging to this category include TinyLIME [20] and FACTS [21].
-
Event-based approaches, which rely on publish/subscribe mechanisms for sensor data delivery (e.g., Mires [22], PSWare [23]). In this case, the middleware architecture allows sensor nodes to advertise the types of sensor data they can provide, client applications to select from the advertised services, and sensor nodes to publish their data to clients in accordance with their subscriptions.
-
Middleware targeting adaptability and reliability. In this category, the middleware approaches are designed with special consideration for the issues of adaptability to dynamic environments and self-organization, while some employ fault-tolerance mechanisms. Example solutions of this type of middleware include Impala [24], RUNES [25], and DARMA [26].
-
Middleware with special support for heterogeneity and scalability. The formation of VSNs and the collaboration of their heterogeneous smart nodes require middleware frameworks able to efficiently manage the underlying differentiation in terms of software and hardware resources and subsequently hide it from the applications. Scalability is also required as VSNs can be formed across multiple and heterogeneous WSNs possibly belonging to different administrative domains. Regarding single sensor networks, some representative approaches in this category are TinyDB, Cougar, and Agilla [27]. Multiple sensor network management is a concept supported by jWebdust [28], Hourglass [29], and Global Sensor Networks. This concept proposes the notion of a VSN comprised of a number of discrete sensor networks that can be managed as a single entity. Another project that enables the interconnection of multiple sensor networks is Sensor Web Enablement [30].
-
Middleware with explicit support for mobile nodes. These nodes could have the role of a mobile sensor, of a "data mule" node enabling or assisting communication across disconnected parts of the network or of a mobile sink node. TinyLIME is specifically designed to support mobile gateways and Impala is also designed to function in high mobility scenarios.
-
Middleware supporting connection to larger networks. Solutions in this category support the interconnection of WSN "islands" that export their resources and services to external networks (e.g., TCP/IP) in order to be shared and exploited by monitoring and controlling entities. The Sensor Web Enablement framework provides such interface to the Internet. A common characteristic in this class of middleware is that it operates on (peer-to-peer) network overlays formed over the participating sensor networks, where each network is represented by an application-level gateway node (e.g., ShareSense [31], Hourglass, Global Sensor Networks).
3. System design principles and architecture
3.1. Design principles
-
Advanced sensor design which is able to support advanced features in several fields (energy saving, routing capability, middleware support, etc.).
-
Middleware design to mediate between applications and sensors. Considering that a sensor does no longer know the application that will use it, and an application does no longer know the sensors that it will use, major issues that the system architecture must address are (a) how a new application finds the sensors that it needs, (b) how it negotiates for the right to use those sensors with the organizations who deployed and administer them, and (c) how an application reacts to changes in the network. In other terms, the mechanisms for matching between the applications (user) and the resources (used) have to be specified.
3.2. General architecture
-
Virtual Sensor Network (VSN): A VSN is the seamless grouping of WSNs also called Wireless Sensor Islands.
-
Wireless Sensor Island (WSI): A WSI is any grouping of one or more legacy, proprietary, or VSN-aware sensor networks which are able to communicate, respectively, via a legacy, proprietary, or VSN-aware gateway node. A WSI is an autonomous administrative domain offering at least one service (autonomous sensors, which are uniquely addressable from outside a WSI can be considered as a simplified WSI).
-
VSN service: Defined as any combination of one or more operational and/or supporting services. As operational service, we define any sensing capability offered individually by a sensor node or collectively by a WSI. As supporting services, we define functions that support the provisioning of the operational services. The supporting services may be offered by one or more WSIs or it may be hosted outside the WSI by external service providers. Many VSN services may be combined to offer new VSN services (as service mash-ups).
-
Resource: A resource is defined as any physical or logical entity of a sensor node or of a WSI, which can be allocated, utilized, and released in order to realize a service. As such, resources may be considered as service enablers.
3.3. Service provisioning
4. Wireless sensor islands
-
VSN-aware WSI: These are WSIs, which consist of VSN-aware Sensor Nodes (VaSN) and a VGW. It is assumed that within a VSN-aware WSI each node (sensor or gateway) is VSN-aware and has knowledge of the VSN service offerings. As it is shown in Figure 4, each VaSN may instantiate one or more virtual sensor nodes in the process of sharing its resources across multiple VSNs.
-
Proprietary WSI: These are WSIs, which consist of Proprietary Sensor Nodes (PSNs) interconnected via a Proprietary Gateway. Due to the complexity that they might inherit, in order to guarantee interconnection with the VSN network architecture, we assume that the proprietary gateway offers a VSN-compliant interface, so it is considered as VGW.
-
Legacy WSI: These are WSIs, which consist of Legacy Sensor Nodes (LSNs) interconnected via a Legacy Gateway (LGW). We assume that within a Legacy WSI, in order to offer interconnection with the VSN network architecture, an entity outside the WSI should offer a LGW IF. This interworking function should be offered either by the WSI Enabler or by a service provider. Alternatively, each VSN Service Provider should implement instantiations of VGW as interconnection functions for LGW.
4.1. Gateway architecture
-
VGW API Interface: this is an interface used by any external component to instantiate a VSN configuration within the WSI, retrieve the list of available resources/services, retrieve a history of data, or execute an action onto a specific node.
-
VSN controller: This module receives the instructions to configure, within the WSI, all aspects related to the enforcement of VSNs for supporting VSN services. It maintains various registries including a registry of the subscriptions per VSN to a set of operational and supporting services provided by the WSI, a registry of tasks that are deployable on the sensor nodes involved in the operation of a VSN, a data logger that maintains a history of the data published by nodes involved in an enforced VSN (e.g., measurements, alarms, etc.) and a registry of the routing instances configured in the WSI. The VSN controller embeds a component named WSI and Sensor Node Configurator to configure the functioning of individual sensor nodes or networking protocols at the scale of the WSI. When receiving the configuration instructions to instantiate a VSN, this configuration component interacts with: the Routing Engine (e.g., an RPL driver, in order to run an additional instance of the RPL protocol [38]), the WSI MAC Driver module, in order to instantiate a specific MAC scheduling and the Resource and Service controller, in order to subscribe to specific publishing services and manage the resources.
-
Resource and Service Controller: This module negotiates with the VSN Service Provider and keeps a registry of all available operational and supporting services and the status of all WSI available resources. It uses a scalable publish/subscribe engine in order to handle published events and inform the VSN Manager about the subscribed services and the allocated resources status, as well as pushing actions to specific nodes.
-
Routing Engine: it receives from the VSN controller the instructions to configure one or more routing instances (e.g., multiple RPL Destination-Oriented Directed Acyclic Graph instances), with one or many VSN applications per routing instance. This engine includes a WSI Routing Driver which is in charge of handling the operation of the WSI routing protocol(s), and handling for each protocol, the possibly multiple instances of routing plane. In addition, the engine encompasses a routing converter which is in charge of converting received packets from the WSI into the appropriate format to be sent over the legacy network.
4.2. Sensor node architecture
5. Interfaces between system components
-
Creation: During this phase, the user and the VSP negotiate and agree a "service contract". In this phase, the user describes to the VSP a desired service, and the VSP proposes its possible implementation based on the availability of VSN resources. This interactive cycle is repeated through successive adjustments of the description of the desired services, proceeding towards a more and more detailed qualification of the desired services and how it will be provided. At the end of this interactive negotiation, the user and the VSP agree on a detailed description of the application and of the conditions under which it is to be provided. When this agreement is reached, the creation phase is over and the service can begin.
-
Execution: During this second phase, the VSN provides the service requested, and the application consumes it. The execution of the service is taken care of by the network, automatically and transparently to the user. This phase can be very short (execution of a query and immediate return of the query result) or can be long lasting; in any case, while the service is being executed the VSN Manager takes care of its execution.
-
Termination: The end criteria for a service can be implicit in the service requested (this is the case, for instance, when the service is the execution of a single, immediate query), or the service can explicitly be terminated by the application (this typically happens for long-lasting services). Termination conditions may also be agreed at service negotiation (e.g., "for one day", or "until this predicate becomes true").
5.1. Interface between application and DVNS
-
Authenticate_User: This is used at the beginning of the application creation phase in order for the user to request authentication.
-
Browse_Services: the application uses this function repeatedly, to qualify in growing detail the desired service.
-
Start_Negotiation: this is a request sent by the application in order to declare that it wishes to proceed with negotiation for a specified service offered by the system.
5.2. Interface between DVNS and VSN manager
5.3. Interface between application and VSN manager
-
Negotiate_Service: It is used by user/application to negotiate service provisioning with the VSP. This function is also used for service renegotiation in case changes to the service parameters are requested by the application (e.g., extension of the planned duration, modification of the geographical scope of the service, change of the data gathering rate, etc.). It is also used to terminate a service explicitly.
-
Initiate_Service: This function is used by the Application after successful negotiation with the VSN Manager to denote intention for service execution.
-
Retrieve_Service_Data: It is used by the application to ask for data in a synchronous manner (i.e., on a request/response basis) according to the specified service.
-
Publish_Data: It is used by the VSN Manager to feed the application with the data that it has requested. This is particularly important for applications whose primary purpose is data gathering. However, this function is also used for other types of applications because it is through the Publish_Data function that the VSN Manager is able to communicate to the application relevant events like, for example, the inability to accomplish the required service.
5.4. Interface between DVNS and VGW
-
Publish_Services: When invoking it, the DVNS queries all known/registered VGWs for discovering new services, removing services not offered anymore or updating changes in the services provided by WSIs.
-
Update_Services: The DVNS provides this function in order to allow a VGW to asynchronously update the list of WSI supplied services. The function can be invoked on a periodic or on-demand basis.
-
Update_WSI: This provides the capability for new WSIs accessible by the service provider to be registered in the Services Registry (part of the DVNS) so that applications can access them.
5.5. Interface between VSN manager and VGW
-
Update_Status: The VGW provides this function to allow the VSN Manager to get an up-to-date view of the available operational services and resources at the involved WSI. Based on the VGW response, the VSN Manager can provide to the application further feedback to be used in the negotiation phase (e.g., for service parameter reconfiguration).
-
Initiate_WSI_Service: This function is used by the VSN Manager to communicate to the VGW requests for service initiation. Execution of this function involves the enforcement of a VSN at the WSI level.
-
Publish_WSI_Data: This function is used by the VGW to export data published by sensor nodes to the appropriate VSN Manager.
-
Retrieve_Service_Data: It is used to support data retrieval from the VGW on a request/response fashion.
-
Update_WSI_Status: This is used by the VGW to communicate to the VSN Manager changes in the status of the corresponding WSI supplied services and resources.
5.6. Interface between VGW and sensor node
-
Get_Supported_Services. This function is used by the VGW to query the services supported by the sensor node.
-
Get_Available_Resources: The function is used by the VGW to retrieve the list of resources provided by a sensor node.
-
Retrieve_Service_Data: This is used by the VGW to trigger data collection from sensor nodes in a synchronous manner.
-
Subscribe: The VGW uses this function to send requests for subscription to particular services of a sensor node. The requests can be sent in a unicast or broadcast fashion depending on the user query. The subscription request is expressed through a conjunction of constraints over attribute values, in a form of a tuple (attribute, operator, value).
-
Rcv_reconfiguration: Reconfiguration of basic functionalities such as scheduling schemes or routing algorithms is handled through this function. Besides the basic reconfiguration of certain parameters dealing with the communication protocols (e.g., MAC duty cycle), this function also deals with the reconfiguration of supporting services and resources (e.g., reconfiguration of the sampling rate for the sensed attribute).
-
Get_Status: This is used by the VGW to get current information on usage associated to a service or to the consumption of resources. Resource information may include, among others, the number of instances that a sensor node participates in (either as a router or as a sensing device) or memory/processor allocation.
-
Rcv_notification. When the constraints of the subscription to a service are satisfied, the VGW receives, through this function, a notification from the sensor node. The notification is of the form (attribute, value).
-
Notify_supported_services: Using this function a sensor node can proactively notify the VGW about its supported services.
-
Notify_available_resources. This is used by a sensor node to communicate to the VGW, in a proactively manner, its available resources.
6. Service registration, service negotiation, and session establishment
-
Specify the number of nodes to be used for the provisioning of the service (e.g., exact, maximum or minimum number of nodes).
-
Specify the operational services to be subscribed on the selected nodes.
-
Specify the parameters that must be communicated to the WSI Routing Driver of the VGW.