Download Report

Reprogramming Wireless Sensor Networks by
Using SDN-WISE: a Hands-On Demo
Laura Galluccio∗ , Sebastiano Milardo† , Giacomo Morabito∗ , Sergio Palazzo∗
∗ University
† CNIT
of Catania, Catania, Italy
Research Unit Catania, Catania, Italy
Abstract—SDN-WISE is a Software Defined Networking solution for Wireless Sensor Networks (WSNs). The aim of SDNWISE is to simplify the management of the network, the
development of novel applications, and the experimentation of
new networking solutions in WSNs. Objectives of this demo are
to demonstrate how different logical WSNs can coexist exploiting
the same sensor nodes and show how easy is it to program the
behavior of sensor nodes by few lines of code.
Laptop Sink Node Sensor Node APPLICATION APPLICATION INPP T D FWD APPLICATION INPP T D FWD CONTROLLER WISE-‐VISOR ADAPTATION MAC ADAPT. PHY PHY MAC PHY I. I NTRODUCTION
The Software Defined Networking (SDN) approach radically
changes the way network management is conceived [6]. The
idea of concentrating all the management functionalities of a
network, that is the Control Plane, in a single logical entity,
called Controller, makes possible to change the behavior of
the network by simply installing a new software component
[7]. Despite the obvious benefits of such an approach, which
already promoted the success of SDN in both wired and cellular networks [4], only a few works have, recently, addressed
the Wireless Sensor Networks (WSN) [5][2]. SDN-WISE is a
SDN solution for WSNs that exploits the flexibility and ease
of management that are implicit in the SDN paradigm. SDNWISE is an evolution of a previous work on SDN for WSNs,
called SDWN [2].
SDN-WISE goes further SDWN by introducing some novel
functions which are particularly convenient in WSNs. In fact,
while the clear separation of the Control Plane from the Data
Plane remains unchanged [6], the peculiar characteristics of
the WSNs, such as the limitations in terms of computing
power or energy availability, require ad hoc solutions. In
SDN-WISE a stateful approach is introduced as suggested by
Bianchi et al. [1] for wired networks. The possibility to have
sensor nodes that respond to incoming messages depending
on state variables reduces the amount of messages exchanged
between each sensor node and the Controller, thus reducing
the number of packets sent over the network and the total
energy consumption. Furthermore, SDN-WISE includes a new
network virtualization system, called WISE-Visor, which can
abstract network resources and create several virtual sensor
networks that can be assigned to different Controllers.
Architecture and protocol details of SDN-WISE will be presented during the INFOCOM technical sessions (specifically,
in Session “Sensor networks 2”) [3]. The purpose of this demo
is to show some peculiarity of SDN-WISE, and how easy it is
programming the behavior of a WSN by exploiting the SDNWISE features.
Fig. 1: SDN-WISE@INFOCOM testbed and protocol stack.
II. D ESIGN AND I MPLEMENTATION
In this section we provide the major characteristics of SDNWISE, more details can be found in [3]. According to the SDN
paradigm, SDN-WISE clearly decouples the Data plane from
the Control plane. In general the Control plane is run outside
the WSN while the Data plane is run by the sensor nodes.
These nodes operate using the PHY and MAC layer of IEEE
802.15.4.
The SDN-WISE functions running in the sensor nodes are
built on top of the IEEE 802.15.4 layers. From a functional
point of view, such SDN-WISE functions are organized into
three layers: the Forwarding layer (FWD), the In-Network
Packet Processing layer (INPP), and the Topology Discovery
layer (TD) (Fig. 1). The Forwarding layer handles incoming
packets as stated by the entries contained in a data structure
called WISE Flow Table. Each entry of the WISE Flow Table
has three parts: a set of conditions, an action and the statistical
information. If the conditions expressed in the first part are
satisfied, the corresponding action is executed. The statistical
information is used to decide when to delete a rule that is stale.
According to the possible values of the action field, some of
the incoming messages can be sent to the In-Network Packet
Processing layer. The most relevant operation of this layer is
data aggregation. The Topology Discovery layer is used to
gather information about neighbor nodes which is sent to the
Controller that creates an accurate representation of the WSN.
The functions of the Control Plane running in the Controller can be divided into three layers as well: Adaptation
Layer, WISE-Visor, and Control layer. The Adaptation Layer
modifies packets coming from sensor nodes so that they can
2
be transported by a traditional TCP-UDP/IP network, and
viceversa. The FlowVisor manages the operations of several
virtual WSNs which may apply different routing policies over
the same physical network. Finally, the Control layer controls
the behavior of each sensor node and responds to Request
messages coming from the network. When a node receives
a packet which does not fit any entry of its WISE Flow
Table, it sets a flag in the header of the packet and sends
it to the Controller. Usually, the Controller responds with
a message containing one or more rules to manage packets
having characteristics similar to the ones of the packet that
was previously not recognized.
III. D EMO D ESCRIPTION
The testbed is composed of 6 wireless sensor nodes, one
of them is the sink of the network and is connected to a
laptop that will host the Control Plane. All the nodes are
Embit EMB-Z2530PA. These devices provide IEEE 802.15.4
wireless connectivity in the 2.4 GHz ISM band. They are
based on Texas Instruments CC2530 which is an 8051 8bit controller. Each node is equipped with 8kB of RAM
and 256 kB of Flash memory. Regarding the software, the
testbed is made by two components. First, the firmware on
the nodes, that is written in C and implements the SDNWISE protocol and a simple Application Layer that echoes the
messages received. Second, the Control Plane that is written
in Java and is made of 30 classes. In particular, one of
them is the Controller abstract class, which provides all the
methods needed to get information on the network topology
(e.g., number of nodes, neighbors, battery level, etc.) and two
abstract methods that must be implemented in order to obtain
a fully working Controller. The first one is used at the network
start-up to send preliminary rules to the nodes, while the
second one is run every time the controller receives a request
from the network. Finally, we will set the WISE-Visor in such
a way that two Control layers will be supported, each of which
will have a different view of the same physical network.
The demo itself will be divided into two phases. Objective
of the first phase is to show the major characteristics of the
SDN-WISE protocol, whereas in the second phase we will
demonstrate that programming the behavior of a node is very
easy and can be accomplished with a few lines of code.
In the first phase, at the start-up all nodes will be turned
on in sequence to show how the two different Control layers
create two different representations of the same network. More
specifically, one of the Control layer will see a random network
whereas the other will see a ring network. To show this feature
we have implemented the GUI presented in Fig. 2. Then,
we will start an application which generates packets in the
sink and sends them to a sensor node randomly chosen. As
regards the routing policy, both Control layers will apply a
Dijkstra routing algorithm whose JAVA implementation has
been downloaded from the Internet. Nevertheless, since the
Control layers have different views of the same network, actual
routing of packets will be different. Sensor nodes have been
programmed in such a way that they turn a led on when they
forward a packet and turn it off after 5 s. In this way it will
be possible to observe the route of each packet.
Fig. 2: Screenshot of the topologies of the same physical
network observed by two different Controllers.
During the second phase we will show how easy is it
programming the behavior of sensor nodes. To this purpose
we will start from the implementation of a Control layer and
modify it. Then, we will invite attendees to try themselves
to develop the code which further modifies the behavior of
the sensor nodes. To foster the involvement of the audience
we will reward volunteers with typical Italian almond paste
cookies.
IV. C ONCLUSIONS
SDN-WISE is a Software Defined Networking solution
for WIreless SEnsor networks. An overview of SDN-WISE
protocol stack has been provided along with a description of
a physical testbed which implements the proposed solution. As
compared to the state-of-art SDN-WISE reduces the amount
of information exchanged between sensors and the SDN
controllers by using a stateful approach and provides a new
level of abstraction which allows several logical WSNs to
coexist over the same set of sensor nodes.
ACKNOWLEDGMENTS
This work was supported by the 7th Framework Program
of the European Commission within the NEWCOM# project
and by MIUR under the SIGMA contract.
R EFERENCES
[1] G. Bianchi, M. Bonola, A. Capone, and C. Cascone. OpenState: Programming Platform-independent Stateful OpenFlow Applications Inside
the Switch. ACM Computer Communication Review. Apr. 2014.
[2] S. Costanzo, L. Galluccio, G. Morabito, and S. Palazzo. Software
Defined Wireless Networks: Unbridling SDNs. EWSDN 2012. Oct. 2012.
[3] L. Galluccio, S. Milardo, G. Morabito, and S. Palazzo. SDN-WISE:
Design, prototyping and experimentation of a stateful SDN solution for
Wireless Sensor networks. IEEE Infocom 2015. Apr. 2015.
[4] L.E. Li, Z. M. Mao, J. Rexford. Toward Software-Defined Cellular
Networks EWSDN 2012. Oct. 2012.
[5] T. Luo, H. Tan, and T. Quek. Sensor OpenFlow: Enabling SoftwareDefined Wireless Sensor Networks. IEEE Comm. Letters. Nov. 2012.
[6] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
J. Rexford, S. Shenker, and J. Turner. OpenFlow: Enabling Innovation
in Campus Networks. White paper. Mar. 2008.
[7] B. Pfaff et al.. OpenFlow Switch Specification – Version 1.1.0 (Wire
Protocol 0x02). Feb. 2011.