Ubiquitous Virtual Private Network: A Solution for WSN Seamless Integration

1. Introduction

The integration of sensor networks in enterprise information systems is still problematic and unnatural. The interaction between applications and sensor services usually requires specific mechanisms that are often centralized on application-level gateways. Usually, the access to sensor data in the literature is performed through a single node with two interfaces, one for the sensor data (e.g., a 802.15.4 wireless interface) and another for the enterprise information network (e.g., the Ethernet). In many situations, this gateway presents specific software for the adaptation of the protocol stack from the sensor domain to the enterprise domain. However, this type of infrastructure implies a single point of failure. From an engineering point of view, a single gateway implies a single point of failure, associated with a specific application, which could lead to a difficult and inefficient network topology; i.e., the network topology between the domains could be arbitrary and not dependent on the logical integration infrastructure (Figure 1).

Figure 1. Integrating infrastructure should not constrain the topological structure.

At the logical level, this type of infrastructure is inconvenient for the actor/actuator nodes (hereinafter, the term “sensor node” is applied to refer to any actor/actuator devices.) and complicates, or just makes impossible, free interaction among applications and sensor nodes and, particularly, interaction among sensor nodes.

This paper introduces a novel approach to achieve a more flexible and decoupled way to provide and request sensor services that support several gateways among sensor and enterprise domains (sometimes called a multi-sink). By means of a common application-level protocol, the sensor nodes and the applications can interact in any scenario, even among sensor nodes belonging to remote networks.

Instead of designing a new application protocol from scratch, we focus our attention on the protocols used by object-oriented middlewares, i.e., CORBA (Common Object Request Broker Architecture) or ZeroC Ice (Internet Communication Engine). These middlewares have traditionally been used in scalable and efficient distributed heterogeneous applications, so we start with well-known and tested protocols. The application protocol used in these middlewares is able to marshall and unmarshall invocation messages between distributed objects. These types of protocols are already integrated into wireless sensor networks [1], but always inside of the same sensor network domain. Of course, this makes it possible to use an object-oriented middleware, which transforms the sensor network integration in the case of distributed heterogeneous programming.

2. Related Work

In a way, H. Dai [2] aims at similar goals: “Unlike application-level gateways, that require semantic knowledge of each application in order to make a routing decision, the overlay gateway routes based on sensor network layer information”. They propose an overlay network to interconnect applications with sensor nodes, extending the sensor network internal protocol over the Internet. This process functions as a virtual sensor network thanks to overlay gateways. In these researchers' words: “It is a sensor network overlaying IP (Internet Protocol)” (see Figure 2). The gateway encapsulates the sensor network protocol packets (including the network; and the transport and the application headers) on the TCP (Transport Control Protocol) or the UDP (User Datagram Protocol) segments. As the sensor network stack is preserved, the components at hosts (the virtual sensors) must process all of these strange headers at the application layer to maintain the illusion of a single flat network.

Figure 2. Architectures for integrating sensor networks with the Internet: (a) application gateway or NAT (Network Address Translation); (b) IP overlaying sensor network and (c) sensor network overlaying IP.

SenseWrap [3] follows another approach. In it, virtual sensors are referred to the wrapped versions of the actual sensors. It focuses on self-configuration providing a standard Zeroconf to discover and find the sensor services. It is a middleware to get IP overlaying to the sensor network. SensorWrap is, in many senses, similar to OSGi (Open Services Gateway Initiative) [4], which is the paradigm of a semantic application-level single gateway and, therefore, the model that we try to avoid. Tenet [5] is a more sophisticated network architecture that divides the sensor network into a set of tiers. Each tier has a master and several nodes. Most of the processing and application-specific tasks run in the masters. Hence, it is a multi-gateway approach that avoids a single point of failure, but may significantly degrade the network performance if some of the masters fail. Other approaches, such as [6], provide families of middlewares to address heterogeneity, although they are more geared toward solving the problem with devices rather than communications.

The “all over IP” approach could solve the problem, but introduces overhead, even in the most the low-footprint implementations (i.e., uIP (microIP) [7]) and is not affordable for some sensor domains. Other protocols, such as message queue telemetry transport protocol [8] (MQTT) from IBM, are for telemetry applications, so they do not support actuators and individual sensor-to-actuator interactions. 6LowPAN (IPv6 over Low power Wireless Personal Area Networks), CoAP (Constrained Application Protocol) and similar protocols follow the same idea. They imply additional overheading and do not avoid using protocol translation between the sensor network and the trunk network.

As we will see in the following sections, our approach uses the network and the transport protocol stack most appropriate at each domain; we use a common protocol only at the application level. As far as we know, none of the existing approaches provide an integrating mechanism with such flexibility and, integrating in a transparent way, with different domains and applications.

2.2. Object-Oriented Communication Middlewares

Object-oriented communication middleware has been a well-known concept for more than ten years. Some examples are CORBA [11], ZeroC Ice [12], Java RMI (Remote Method Invocation) [13], etc. Figure 3 shows the essential behavior of this type of middleware. From a programmer point of view, the invocation occurs as usual in the object-oriented paradigm (dotted arrow). In reality, it does not happen in this way. The client invokes over a reference of the remote object: the proxy. Using the communication core, the invocation is coded (the marshalling process) to the specific binary protocol and transmitted to a server using the underlying network. At the server side, the invocation is re-built (unmarshalling) and finally arrives at the object; the reply goes back to the client in the same manner.

Figure 3. Object-oriented middleware invocation mechanism.

The server side implements a well-defined interface shared by the clients. Interfaces are usually defined using an interface description language, such as IDL (Interface Definition Language) in CORBA or Slice in Ice. That is, the concrete invocation message format depends on a set of interfaces specified by each distributed application designer. Both the proxy and the skeleton parts are dependent on the interface and may be generated by tools, usually provided by middleware vendors.

This communication is feasible thanks to the object request broker (ORB), or just broker. The ORB is usually a library that provides to clients transparent references to remote objects (proxies). The interaction between the client and the object requires data communication between local and remote ORBs. To assure interoperability, the protocol and the rules to communicate these ORBs (the inter-ORB protocol) must be standardized.

In any case, the middleware provides a uniform, generic and fully specified application protocol to transport invocation messages and their corresponding replies, errors, etc. We can say that the middleware protocol is more similar to an invocation transport protocol than an application protocol. We propose the middleware protocol as a common message format for all of the entities participating in the communication (sensor node or applications).

3. Ubiquitous Virtual Private Network (UVPN) for Sensor Networks

Our approach, called the ubiquitous virtual private network (UVPN), uses the same VPN concept available in TCP/IP networks, although implemented at a higher abstraction layer. Each host may have one or more object adapters. An object adapter is responsible for exposing local objects to the network. Each object adapter is accessible through endpoints, i.e., logical network connection points. In the general purpose middlewares, these endpoints provide support for the TCP/IP protocol suite, and they are associated with IP addresses and ports by means of sockets or other programming artifacts. Emulating the conventional VPN model, we assign homogeneous addresses to all the involved components, regardless of whether they are physical sensor nodes or PC applications. To achieve this, we require a new type of endpoint (a UVPN endpoint), encapsulating the specific addressing. Note that the UVPN endpoint, as the conventional VPN counterpart, uses the same underlying transports, i.e., TCP, UDP or SSL, in the Internet case. We are using ZeroC Ice [14] in our current prototypes, although any other object-oriented middleware could be used instead. Sensor nodes with a minimal footprint are able to process application messages using the underlying middleware protocol (IceP (Ice Protocol) for Ice [14]) thanks to the picoObject approach.

Of course, these virtual logic addresses need to be mapped to the corresponding underlying address scheme by some translation mechanism (equivalent to neighbor discovery in conventional protocols). Because this type of translation may be expensive and complex for a sensor network, our approach here uses a shared address scheme (not translated or mapped) to the node link technology. In this way, the endpoint can deliver the invocation directly to the corresponding node. Obviously, this shortcut couples the protocol with a concrete physical communication technology, but even so, it is an interesting improvement to achieve a seamless network interconnection. Our approach may be perceived as a virtual private network, because the components outside the sensor network have addresses belonging to the sensor network space address. Regardless, this limitation may be overcome by defining a general purpose address scheme, assuming the cost of the appointed address mapping. This more ambitious approach is now a work in progress.

Although conventional gateways and UVPN switches are physically similar (both are devices connected to two or more heterogeneous networks), they have very different behaviors. Conventional gateways expose sensors to the trunk network applications as virtual artifacts (delegates) using the protocol and the specific communication technology of the trunk network (for example, web services). A software service at the gateway provides these delegates and addresses the sensor network using a specific protocol (example: Crossbow motes). The gateway is a stateful engine, and this makes the multi-sink complex.

The UVPN switch just forwards the middleware protocol messages (for example, GIOP (General Inter-ORB Protocol) or IceP) between the switch ports using the source and the destination addresses. In some aspects, its behavior is similar to that of an Ethernet bridge switching frames among heterogeneous LANs. With our approach, both applications and devices can address the middleware messages. The UVPN switch is stateless, and this makes it possible to cause several of them to interconnect two networks, providing redundancy. Certainly, this redundancy causes cycle problems, but it can be solved using the same techniques typical of switched networks.

UVPN along with the middleware protocol provides a good level of interoperability among heterogeneous networks. The source node (client) creates a standard middleware request that is encapsulated in the corresponding protocol stack (most likely TCP/IP). The request arrives to the UVPN switch, and it is unencapsulated. The switch determines the destination node (depending on the UVPN address) and encapsulates the request using the destination port stack; the reply message is managed in the same way. This is similar to the behavior of an IP gateway or an Ethernet hybrid bridge. Note that both the source of the request (the client) and destination (the object) can be computer applications or WSN nodes.

3.2. Functional Components

The main component of the UVPN architecture is the UVPN switch, a service that should reside in a host that has physical interfaces to both networks: sensor and trunk. Its goal is similar to a conventional VPN switch. The switch knows all compatible remote object adapters; that is, those that have an endpoint supporting UVPN addressing. For this, each of these adapters must register themselves in the switch. The switch is a conventional distributed object implementing the UVPN::Switch interface shown below:

module UVPN {

class Address {};

interface Transceiver {

void send(Address addr, ByteSeq payload);

};

interface Switch extends Transceiver {

void add(Address addr, Transceiver* prx);

void remove(Address addr);

Transceiver* find(Address addr);

};

};

For better transparency, the UVPN endpoint (on the conventional computer side) performs the registration on behalf of the adapter. When an endpoint is instantiated, it invokes the Switch.add() method in the designated remote switch to bind a sensor network address (addr) to a callback object provided by the UVPN endpoint. Later, the switch can resolve remote virtual sensor nodes using these associations between the addresses and the endpoints. This mechanism is functionally equivalent to the creation of a tunnel in a conventional VPN.

Therefore, to make the virtual network usable, it requires:

• At least one switch connected to the trunk network and at least to one sensor network, and

• At least an application or a service in the trunk network (e.g., on a desktop computer) that has the UVPN endpoint.

A set of sensor nodes and the corresponding network interfaces are required, too. See Figure 4 for an example.

Figure 4. Ubiquitous virtual private network (UVPN) essential components and encapsulation.

4. Use Cases

This section discusses the different communication scenarios between node services and applications or between nodes themselves (see Figure 5).

Figure 5. Possible invocation scenarios involving sensor nodes and applications in an heterogeneous inter-network.

4.4. Node to Non-Neighbor Node

There is a more interesting case, which is very rare in previous works. Two or more distant sensor networks (with their respective UVPN switches) can be connected to the same trunk network (which may be the Internet). In this situation (see Figure 6), a sensor node may invoke other remote sensor node (in a different network) using switches to forward the message towards the trunk network. As explained before, this requires that the local switch knows whether the remote object is accessible through its own switch. This implies the registration of all sensor nodes in a central switch (the root switch). Obviously, we are talking about a hierarchical switching protocol. Local switches have a fallback switch (a default path) that knows where each sensor node is.

Figure 6. Invocation from a sensor node to a remote node using UVPN.

Figure 6 makes it clear that UVPN works as a tunneling protocol; so, in this case, just as in the previous one, a similar concept of conventional TCP/IP VPN protocols is used. The major difference is that the UVPN is based on an application-level protocol instead of a link or a network layer protocol.

The switch operation is a bit more complex when more than one sensor network participates in the communication. When a sensor node (such as a client) wants to send a message to another node, it builds the message as if the destination node were a neighbor, although it is in a different physical network. The local switch will receive the message, and it will check whether the destination address is registered on its table. If so, it sends the message using the associated transceiver. Otherwise, it will use the fallback switch to send the message (using the method, Transceiver.send()).

When this fallback switch (or the root switch, as stated above) receives a message, it will check if its destination is a registered one. If so, it sends the message again, using the matching transceiver. If the destination is unknown, then it will deliver the message to the rest of the configured transceivers, one on each gate (flooding). It only discards the arriving gate (to avoid loops).

When the last switch receives the message, it will check its table. If the destination is registered as a virtual node, it will send the message using the given transceiver. If not, the message will be sent to the other interfaces (i.e., the radio interface, or to other registered switches, which are different from the arrival one).

5. Simulation and Results

Several simulations have been built to demonstrate the correct operation of UVPN. They have been built in the OMNet++ ( http://www.omnetpp.org/doc/omnetpp/manual/usman.html) discrete event simulator. An example smart-grid application was modeled to illustrate the operation of a network of sensor/actuator nodes (electrical sockets and bump lights) and an IP-based network, including conventional computers.

This smart-grid application (see Figure 7) monitors the total electrical consumption of a house to avoid current overload. Each socket measures the current through it and is able to interrupt the electrical line to turn the load connected to it on/off.

Figure 7. UVPN simulation with a smart-grid application example.

Three load states are defined:

• NORMAL: The total consumption is less than 70%.

• WARNING: The total consumption is between 70% and 90%.

• CRITICAL: The total consumption is greater than 90%.

Each time a user physically plugs/unplugs an appliance in a socket, the device sends a message to a monitor service (loadMonitor) running on a computer (server in the figure). The loadMonitor receives that message and decides the new state. It communicates load-state changes by sending messages to a specific event channel (using object-method invocations, too). It may include subscribers of any type (computer applications or sensor nodes), because all of them are perceived as distributed objects. Let us explain in detail the event sequence occurring in the simulation:

• In the initial state (NORMAL), there are four unplugged sockets.

• An appliance is plugged into the socket nodel. The socket measures the current and sends a message to the loadMonitor service.

• The loadMonitor service receives the message. It estimates that the system load exceeded the WARNING threshold, so it sets the load state to WARNING. An application (an event channel subscriber) running in a mobile device, tablet, etc., may advise people (see the user shape) of the new state.

• Another appliance is plugged into socket node2. Again, the socket sends a notification. The loadMonitor detects that the load is above the CRITICAL threshold, so it sets the load state to CRITICAL. The sockets (that are channel subscribers) receive the message. Those that have nothing plugged into them immediately cut the line and turn on a red LED (Light-Emitting Diode) to visually advertise their state to the users. This can avoid the addition of a greater electrical load to the line, preventing overload.

• When some of the appliances are unplugged (or turned off), the loadMonitor can set the load state to lower states, allowing new appliances to be plugged or activated.

This example illustrates UVPN direct and duplex communication between sensor/actuator nodes and application objects running on conventional computers in the trunk network. The communication may be initiated by any party, and they all may act as clients or objects. Additionally, sensor nodes may act as publishers or subscribers of event channels.

There is a more complete simulation involving two sensor networks connected to the same IP network through their corresponding UVPN switches (see Figure 8). This represents the same smart-grid application, introducing bulbs and electrical switches that are new electrical loads. To illustrate the communication among remote sensor/actuator nodes, the switch, node5, sends messages, set() true/false, to turn on/off the bulb, node1. As in the previous case, nodes 1–4 send load messages to the loadMonitor service and receive load state messages from the event channel. There are other nodes (e.g., user) that receive notifications from the loadMonitor service. In this case, the user will alert people about an overload.

Figure 8. UVPN simulation: direct remote communication among sensor nodes in distant networks.

The simulations source code, brief documentation and screencasts are available for download and watching at ( http://arco.esi.uclm.es/uvpn).

The simulations attempt to provide an empirical validation of the proposed communication approach. The simulations use abstractions and message formats very close to those used in any object-oriented middleware, so it is relatively easy to build a functional implementation on an actual environment similar to the prototype described in Section 6. Although it is possible to take valuable measures about communication overhead or the number of messages, there are no equivalent approaches to compare under similar conditions.

6. Prototypes

UVPN has been implemented with the ZeroC Ice middleware in a demonstration kit called Motebox (see Figure 9). It is composed of a set of four Crossbow Iris motes, several hot-pluggable sensors and actuators, a programmer, a radio base station and a small PC for running common services and the switch software. The virtual node, which holds the clients and the servers, runs in a conventional laptop.

Figure 9. Motebox demonstration kit using UVPN.

This kit is used to show various features upon access and interconnection between PC applications, middleware services and sensor nodes. More information and screencasts may be found at ( http://arco.esi.uclm.es/motebox).

7. Conclusions and Future Work

It is interesting to analyze the differences in relation to [2]. It encapsulates the entire sensor network protocol stack, which implies the requirement of providing specific support for each sensor network protocol stack at virtual nodes. With UVPN, it does not matter which sensor network protocol stack is used, as long as all peers use the same inter-ORB protocol (at the application layer) and the same addressing scheme; that is, the typical requirements of an inter-network protocol. Thus, UVPN is, in many senses, an object network protocol.

Furthermore, using the inter-ORB protocol (by means of an object-oriented middleware), provides a high-level, well-known, well-documented programming paradigm and an application-specific API (Application Programming Interface), but keeps the gateways generic and straightforward. The middleware also provides valuable common services, such as object persistence, indirect binding, location transparency, server deployment and many other advanced features.

As far as we know, UVPN is the first solution able to facilitate the communication between sensor or actuator nodes with software objects running on conventional computers in a seamless and decoupled way, without the application-specific delegates, application bridges or ad hoc protocols, despite the heterogeneous networks and protocols that interconnect sensor network fragments (including the Internet). However, there is a constraint: all sensor nodes must use the same physical addressing scheme. As ongoing work, we are interested in solving that limitation by generalizing the UVPN approach using a global addressing scheme (see Section 3) and providing homogeneous dynamic routing mechanisms through massively heterogeneous networks.

References

1. Moya, F.; Villa, D.; Villanueva, F.J.; Barba, J.; Rincón, F.; López, J.C. Embedding standard distributed object-oriented middlewares in wireless sensor networks. Wirel. Commun. Mob. Comput. 2009, 9, 335–345. [Google Scholar]
2. Dai, H.; Han, R. Unifying Micro Sensor Networks with the Internet via Overlay Networking. Proceedings of the 29th IEEE International Conference on Local Computer Networks (LCN‘04’), Tampa, FL, USA, 16–18 November 2004.
3. Evensen, P.; Meling, H. SenseWrap: A Service Oriented Middleware with Sensor Virtualization and Self-Configuration. Proceedings of the 2009 5th International Conference on Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), Melbourne, Australia, 7–10 December 2009; pp. 261–266.
4. Alliance, O. OSGi Service Platform, Core Specification Release 4; Version 4.0.1; Technical Report; Open Service Gateway Initiative: San Ramon, CA, USA, 2006. [Google Scholar]
5. Paek, J.; Greenstein, B.; Gnawali, O.; Jang, K.Y.; Joki, A.; Vieira, M.; Hicks, J.; Estrin, D.; Govindan, R.; Kohler, E. The tenet architecture for tiered sensor networks. ACM Trans. Sens. Netw. TOSN 2010, 6. [Google Scholar] [CrossRef]
6. Gamez, N.; Fuentes, L. FamiWare: A family of event-based middleware for ambient intelligence. Pers. Ubiquitous Comput. 2011, 15, 329–339. [Google Scholar]
7. Dunkels, A.; Voigt, T.; Alonso, J.; Ritter, H.; Schiller, J. Connecting Wireless Sensornets with TCP/IP Networks. Proceedings of the Second International Conference on Wired/Wireless Internet Communications (WWIC2004), Frankfurt (Oder), Germany, 4–6 February 2004; pp. 143–152.
8. Hunkeler, U.; Truong, H.L.; Stanford-Clark, A. MQTT-S—A Publish/Subscribe Protocol for Wireless Sensor Networks. Proceedings of the IEEE COMSWARE, Bangalore, Indian, 6–10 January 2008; pp. 791–798.
9. Jayasumana, A.; Han, Q.; Illangasekare, T. Virtual Sensor Networks a Resource Efficient Approach for Concurrent Applications. Proceedings of the International Conference on Information Technology, Las Vegas, NV, USA, 2–4 April 2007.
10. Global Environment for Network Innovations (GENI) Project. Available online: http://www.geni.net/ (accessed on 27 February 2013).
11. Object Management Group. The Common Object Request Broker: Architecture and Specification, Version 3.1; OMG: Needham, MA, USA, 2008. [Google Scholar]
12. Henning, M.; Spruiell, M. Distributed Programming with Ice; ZeroC, Inc.: Jupiter, FL, USA, 2013. [Google Scholar]
13. Sun Microsystems Inc. Java Remote Method Invocation (Java RMI); Sun Microsystems: Palo Alto, CA, USA, 2006. [Google Scholar]
14. Henning, M.; Spruiell, M. Distributed Programming with Ice; Revision 3.3.0; ZeroC Inc.: Jupiter, FL, USA, 2008. [Google Scholar]
15. Levis, P.; Culler, D. Mate: A Tiny Virtual Machine for Sensor Networks. Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, USA, 5–9 October 2002.
16. Yao, Y.; Gehrke, J. The Cougar approach to in-network query processing in sensor networks. SIGMOD Record 31.
17. Madden, S.R.; Franklin, M.J.; Hellerstein, J.M.; Hong, W. TinyDB: An acquisitional query processing system for sensor networks. ACM Trans. Database Syst. 2005, 30, 122–173. [Google Scholar]