2017 VII Brazilian Symposium on Computing Systems Engineering

μSDN: An SDN-based Routing Architecture for

Wireless Sensor Networks
Leonardo Francisco da Silva Santosa, Francisco Ferreira de Mendonça Júniorb, Kelvin Lopes Diasc
Center of Informatics (CIn)
Federal University of Pernambuco (UFPE)
Recife, Brazil
E-mail: {lfss3a , ffmjb, kldc}@cin.ufpe.br

Abstract— Recently, the SDN paradigm, which splits the control and
data planes, initially defined for wired networks, has been considered
as a solution for the management of WSNs (Wireless Sensor
Networks). However, the adoption of OpenFlow protocol, the most
widely deployed SDN standard, directly into the WSNs may require
novel / customized hardware or incur significant signaling overhead.
This paper proposes a novel routing architecture for WSN, based on
SDN principles, by extending existing protocols, which allows its
deployment in legacy motes. A testbed based evaluation demonstrates
the comparable performance results regarding signaling overheads
and energy consumption to AODV and LQRP, routing protocols
widely used in WSN and extended in this papers as a means of
demonstrating the feasibility of a smooth transition to the future all-
SDN WSNs. Although a case study has been conducted on a
proprietary platform, the paper shows a viable path for similar
extensions on other solutions to benefit from flexible management
and programmability provided by the SDN paradigm.
Keywords—Wireless Sensor Networks, Software-Defined Networks,
Programmable Networks, Internet of Things.
I. INTRODUCTION
Wireless Sensor Networks (WSN) are a fundamental component
of IoT (Internet of Things) to get information about
environments and individuals, thus acting as a bridge between
physical and digital worlds [1]. WSN’s nodes are constrained
devices with restrictions with regard battery lifetime, processing
power, storage, and communication. Hence, WSN present
tightly coupling between hardware and software, which leads to
the design of application-specific sensor networks.
Recent applications require multi-hop communication, and
even Internet connections, so energy consumption becomes a
major concern for the survivability of applications and WSN.
Research efforts attempt to create energy-efficient routing
policies to optimize the utilization of wireless network
interfaces, which consumes most of the energy of sensor nodes.
Thus, proposals for multi-hop routing protocols have emerged.
Nonetheless, most of those policies still require adjustments to
fit the scenarios where WSNs work, so the application can find
the balance between performance and consumption of both
computing resources and energy [2].
Therefore, in the current scenario, the manager/administrator
of WSN still needs to test distinct routing protocols and choose
the most suitable for both the application and the characteristics
of the production network. In large deployment scenarios (smart
city sensors for smart grids, forest fire surveillance, natural
disaster monitoring,) and even in indoor environments
(industrial, automation, and smart homes) frequently changing
the firmware or operating systems of all sensors belonging to a
WSN may be infeasible and counterproductive. Nevertheless,
the process of changing the routing protocol in a WSN may
become cumbersome once it depends on using the
reprogramming method available for each platform. The
primary mechanisms for reprogramming WSN are: manual
reprogramming, which consists on rewriting the firmware on
each node, and remote reprogramming, also called Over the Air
(OTA), which consists of using the wireless interface. Each of
those methods has an associated operating cost, which is closely
related to consumption of computing resources and energy, as
well as the time spent during the reprogramming of network.
Such time may include the period where the system is entirely
or partially inactive so it may become problematic for critical
applications.
The problems related to the network management and
routing are also present in wired networks. Future Internet
design has driven the emergence of a new architectural paradigm
designed to create flexible networks, by allowing tests and
innovations without affecting production traffic [3]. The
Software-Defined Networking (SDN) paradigm proposes the
separation between the data and the control planes, turning
network equipment (e.g. switches) into simple packet
forwarding devices. The control plane regulates the behavior of
the entire network, and it is logically centralized software
running on commodity hardware. [3]
Some works have naturally shifted efforts to provide SDN
solutions for WSN, but differently from wired counterparts,
constrained devices and their specific routing requirements over
wireless links turn OpenFlow (OF) enabled sensors a
questionable solution. On the one hand, OF signaling from
conventional WSN’s sensors to a central SDN controller for
routing decision may be unpractical and require powerful
hardware, which may be unfeasible for sensor nodes. On the
other hand, legacy systems without hardware modification may
not interoperate with pure SDN solutions to improve flexibility
and adaptability.
Thus, the benefits SDN provide to WSN still require
complete evaluation, and this work presents evaluations
methods and results to demonstrate SDN may be suitable for
WSN. The improvements achieved with the utilization of SDN
in wired networks, the unresolved concerns, and the requirement
for a complete evaluation, motivated this work.

2324-7894/17 $31.00 © 2017 IEEE 63

DOI 10.1109/SBESC.2017.15
 This paper proposes an SDN-based routing approach, named
μSDN, which extends a legacy platform and well-known WSN
routing protocols. μSDN can reduce the time required to
reprogram an entire WSN, as it makes all the modifications in a
single node (the Controller).
The remainder of this article is organized as follows: Section
2 presents related work. Section 3 describes implementation
details. Section 4 delineates the evaluation of the proposal and
discusses the results. Finally, Section 5 concludes this paper and
highlights plans for future work.
II. RELATED WORKS
This section provides background on SDN-based solutions
for WSN in general, as well as ones focusing on routing.
Software-Defined Wireless Networks (SDWN) [4] is a seminal
work applying SDN to WSN. The authors proposed
requirements for SDWN, including support to duty cycles, data
aggregation, flexible rules, mobility, link unreliability and node
failure. Despite the proposal, mostly based on a network
operating system, they provide neither an implementation
platform nor evaluation.
The work in [5], Sensor OpenFlow (SOF), presented
technical challenges for the implementation of SDN in WSN and
examined some possible solutions. The paper claims there are
some key problems for the realization of SOF: the creation of
flows, the allocation of a communication channel between the
network devices and the controller, the overload introduced by
signaling, the traffic generation, in-network processing and
backward compatibility. Those concerns exist in current
implementations of SDN to WSN, but now emerges a new
discussion about standardization [6]. The proposed solution
relies on the adoption of specialized flow tables, which take into
account specific features of WSN such as addressing, duty
cycling, upward routing, and data aggregation. Although the
work adopts OpenFlow, the authors only presented a conceptual
architecture. Moreover, some problems arise from this platform
such as: the presence of several adaptations in the protocols, lack
of proposals for backward compatibility and lack of any
evaluations for the platform and no description of a scenario
where it can work.
The study in [7] also gives some theoretical contributions
while not provide any implementation details. The authors claim
SDN-based WSN, which they call Software-Defined Sensor
Networks (SDSN) or Programmable Sensor Networks (PSN),
are different from wired networks once there is no sensible
change in hardware and communication channels.
Flow-Sensor [8] provides IaaS (Infrastructure as a Service)
through virtualization of WSN aiming to make sensing services
available through the Internet. Despite adopting OpenFlow,
there is no specification on how they implemented or adapted it
for WSN. It is worth to mention there is neither comparison nor
evaluation of energy consumption, memory utilization, and
processing overhead, some of the most important metrics for
WSN.
Work in [9] categorizes nodes as follows. Master Node runs
the network routing strategy and controls the Center Node,
which forwards the data packets inside the network and has no
routing functions. They designate the other sensor as Normal
64
Nodes. Despite suggesting OpenFlow as the communication
protocol between the Master Nodes and the Center Nodes, the
paper does not provide any implementation or testbed. Although
they did not implement their application, they evaluate it
regarding energy consumption, lifecycle and load balancing
using mathematical modeling using MATLAB.
Work in [10] proposed a hybrid architecture for Software-
defined WSN, which kept some elements of the legacy network.
For instance, the dedicated router nodes could understand route
requests from the AODV protocol, based on policies defined in
the OpenFlow daemon. Nevertheless, this proposal requires the
router nodes to have a different, specialized and even a powerful
hardware. So, to make this strategy work, some nodes should be
replaced, or still, it may be necessary to add more nodes to the
network, but they did not evaluate such burden.
The work in [11] advocates the combination of context
awareness and routing policy for WSN, based on SDN. By
context, authors include information such as network status and
node conditions. The policy-based approach makes routing, as
well as the packet forwarding, dynamic and flexible, once it can
act according to the context. Despite the discussions, this work
was limited to the description of the architecture, considering the
use of OpenFlow, but did not provide an implementation or
evaluation of the proposed solution.
The author in [12] presented “a Software Defined
Networking (SDN) solution for WIreless SEnsor networks”
(SDN-WISE). Their goal was to control some messages through
an OpenFlow-based architecture, containing state array,
neighbors array, and flow table. They also corroborated the
requirements in [4]. Although they described the architecture
and platform, their controller required a physical connection to
a computer or a dedicated embedded system, that is, they kept
the need for specific hardware.
Not all SDN solutions for WSN consider OpenFlow as
protocol, primarily because it fits high-end networks and
devices, and may not be suitable for resource-constrained WSN.
To this end, [13] suggested a general architecture with five
layers: physical, medium access control, network operating
system, middleware, and application. The control logic runs in
the middleware layer so it can gather information from the entire
network. An adjacency matrix represents the network topology,
but the authors did not specify the SDN protocol nor the WSN
platform, and therefore, provided no evaluation about the impact
that such layered architecture may impose to a constrained
WSN.
The work of [14] presents an overview of the concepts that
involve the use of the SDN paradigm in WSN. Also, they point
to some key technologies for implementing Software-Defined
Sensor Network (SDSN), including software-defined radio and
OTA-based reprogramming techniques. The authors propose a
generic architecture of an SDSN and the description of a sensor
node prototype, necessary for the presented architecture to
operate. Although it is a complete framework, it seems
burdensome to incorporate these functionalities into the
commercially available sensors, as it may require the design of
new hardware for the motes. Even with this new hardware
offering more processing power and benefits of the SDN
paradigm in several layers, there is a need to replace the entire
WSN infrastructure, and that may impose economic issues.
Finally, [15] developed TinySDN, which is an SDN
framework for WSN based on TinyOS, a widely accepted OS
for WSN. It is one of the few related works that specifies an
operating system. Also, the architecture has hardware
independence and presents the possibility of an extension based
on multiple controllers. They implemented and tested the
solution using the COOJA network simulator. Despite, being a
distributed controller solution, it did not describe any
mechanisms to ensure that each of the controllers is aware of the
status of the entire network. It is also not possible to identify any
communication between controllers. Thus, each controller could
have only a partial view of the network so forcing the
programmer to make the changes in a decentralized way.
The authors in [2] extend the work of [15] by providing
relevant theoretical guidelines on how to integrate SDSN to IoT
through standardization of routing protocols, programming
interfaces, and backward compatibility. They also point out the
possibility of using Routing Protocol for Low power and Lossy
Networks (RPL), a widely known routing protocol for IoT, to
address some standardization issues.
Most of the proposals discussed in these related works are
limited to conceptual model, which is a recurrent weakness.
Many works did not provide a real implementation, and some of
those works are limited to simulation environments. Another
common drawback is the requirement for changes in the
hardware of the sensor nodes, either part of it or even the entire
network, to implement SDN in WSN. Table I summarizes the
information about related works.
TABLE I. RELATED WORKS
Implementation [15]
Simulation [8]
Modelling [8] [9]
Theoretical Contribution [4] [5] [11] [14] [7] [2]
OpenFlow [5] [8] [9] [11] [12]
Non-OpenFlow [13] [14] [15]
Operating System and Platform [15] [12]
New-hardware Required [10] [14] [12]
III. μSDN
The μSDN is a WSN routing architecture which reuses the
signaling procedure of existing protocols as a communication
channel between control and data planes. Routing control is
centralized, flexible and does not require any hardware
replacement or modification. μSDN requires only firmware
modification at the controller to implement new routing policies
after small extensions to the software of all WSN nodes. This
way, the software of ordinary nodes remain unchanged
regardless of future reprogramming needs for the entire network.
μSDN extends AODV (Ad hoc On-demand Distance
Vector) [16] and LQRP (Link-Quality Routing Protocol) [17] to
65
tackle the requirements for a centralized controller view as well
as to implement the exchange of messages between data and
control planes. AODV is a reactive routing protocol for ad hoc
networks whose main features are a quick response to network
changes, low energy consumption, and low memory footprint.
AODV fits better to WSN with nodes demanding dynamic route
requests. LQRP is a variant of AODV which adds the link
quality and the battery level of the nodes as routing criterion.
SDN may fit the requirements for being accepted as a
standard for IoT, once it is hardware and application
independent and still demonstrates a step towards backward
compatibility [2]. Figure 1 depicts the architecture of μSDN with
three layers: the Data Plane, the Communication Channel, and
Control Plane.
Fig. 1. Architecture of μSDN
A. Communication channel
μSDN uses the signaling messages of AODV and LQRP to
create a communication channel between the controller and the
other network elements. Such mechanism also promotes
communication between data and control planes, with almost no
impact on the performance of the network, and avoids the
requirement for a second network interface.
μSDN considers minor changes in the signaling procedure
of those routing protocols, such as the modification of messages
and the definition of new types of messages. The modifications
follow:
x Rule Request Message (RULE_REQ): SDN-enabled
nodes send this message to the controller-enabled node
to request a rule to communicate to another node, which
is not in the list of neighbors.
x Rule Request Response Message (RULE_RESP):
have different functions depending on the type of the
node. When the controller sends this kind of message, it
is the reply to RULE_REQ and contains the requested
rule, if it exists. On the other side, when a SDN-enabled
node sends this message to another SDN-enabled node,
it starts the neighbor discovery, and the receiver appends
the information about the sender to the neighboring list.
x Link Quality Request Message (LQREQ): This type
of message works the same way as LQRP determines.
All sorts of nodes periodically exchange this kind of
message so they can estimate the quality of the links
between them.
 x Link Quality Request Response Message (LQREP):
Just like LQREQ, messages of this type also remain
backward compatible. They are replies to LQREQ and
carry information used which helps estimate the quality
of the link between two nodes.
x Network View Update Message (NVUPDT): SDN-
enabled nodes send this type of message to the controller
so that it can update Network View. The message
contains the quality of the link between two nodes
(resulting from exchanging RULE_RESP messages) and
the value for the battery level of the node that is sending
the message.
B. Data Plane (a) Node B requests the controller for a route
towards node C
The data plane has two functions: query and request
Forwarding Rules. SDN-enabled nodes keep these rules in tables
and use them to forward the messages according to the logic
defined by the control plane at the controller. Table II portrays
the structure of the Forwarding Table. The column Orig (Origin
or Source) stores the address of the source of the packet and the
column Dest (Destination) stores the address of the final
destination. NextHop refers to the address of the neighbor to
which the SDN-enabled node should forward the packet so it can
reach its destination. Lifetime indicates the time interval (in ms)
that the rule should remain active and stored in the Forwarding
Table. The column TimeOut contains the timestamp (in ms)
after that the SDN-enabled node should remove the rule from
the Forwarding Table and corresponds to the sum of the time of (b) Controller responds to request and node
arrival and the value of the lifetime. At last, the rightmost C stores the rule in the Forwarding Table
column, Action, stores a code (integer) indicating an action to
be applied to the packet. Number 1 indicates that the SDN-
enabled node should forward the packet and number 2 indicates
it should discard the packet.

TABLE II. RULES TABLE

Orig Dest NextHop LifeTime TimeOut Action

TimeIn
5CF1 30C0 5CCF 30000 1
+LifeTime

C. Control Plane
The Controller represents the logical/control plane. Its role
is converting all forwarding decisions into rules, sending them (c) B sends data to A
to the data plane (i.e., sensor nodes) using the signaling
messages implemented as extensions of AODV and LQRP
protocols. The control plane also includes the Network View and
the Routing Algorithm set by the network manager. The Routing
Algorithm may or may not employ the Network View to set the
forwarding rules.
The Network View reproduces the status and topology of the
network along with some information, such as the connections
between nodes; the qualities of the links between nodes; and the
battery level of each node. Any routing algorithm set by the
Network Manager, which should determine the next hop in a
multi-hop network, may use the Network View. In the current
implementation, the Network View is a graph represented by an
adjacency matrix. Each row and each column header, in the (d) A forwards data to C
matrix, accounts for one of the nodes, while the values filling the
fields in the matrix represents the quality of the link between Fig. 2. Exchange of messages containing the rules in μSDN

66
nodes or even the lack of connection between them. In the
matrix, there is also a “battery vector” listing the battery level
for all network nodes.
D. Routing Mechanisms
The algorithms, planes, and protocols previously described
compose the core routing mechanisms for both single hop and
multi-hop communications. Furthermore, once the Network
Manager sets the routing protocol, the rules are not immutable
and he or she can rewrite the protocol at any time only by
replacing the firmware of the Controller. Thus, the whole
network will behave according to the new rules.
Single-hop communication works similarly to regular
AODV and LQRP operations and results from the “Neighbor
Discovery” process. Periodically, each node broadcasts
RULE_RESP messages to the neighbors. In the message, the
fields “next hop” and “destination address” are the addresses of
the sender itself. All nodes that receive those messages store the
rule in their forwarding tables. Single-hop communications can
start as soon as there is enough information to fill the forwarding
tables of all nodes.
As soon as two nodes have information about each other
after Neighbor Discovery, they exchange LQREQ and LQREP
messages to estimate and store the quality of the link between
them. After that, they can broadcast NVUPDT messages to the
Controller and update the Network View.
A node requires multi-hop communications when the
application requires communication with another node that is
not in their communication range or for which there is no rule
registered in the forwarding table. Thus, it needs to start the
process of obtaining a route, and then it sends a message of type
RULE_REQ to the Controller. As soon as the Controller
receives this message, it executes the Network Management
Algorithm (NMA) that determines the best next hop from one
node to another, based on the Network View, and replies with
RULE_RESP. With this feedback, the requesting node registers
the new rule, so it can efficiently send data packets. Figure 2
displays an example of multi-hop communication where node B
wants to communicate with node C. We assumed a complete
setup for single hop communication and that the controller
(CTLD) has a complete network view. In step (Figure 2a) node
B sends a RULE_REQ message to controller soliciting the
corresponding rule for the destination C. After that, in step
(Figure 2b), the controller replies to B with RULE_RESP, which
contains the next hop that node B can use to reach C. In the
following steps, B sends data to A (Figure 2c), which is the
intermediate node, and A forwards the data to C (Figure 2d).
E. Versions
We developed two versions of μSDN to help validate our
proposal against legacy protocols. μSDNv1 is the first version
of the solution created in this work and uses pre-programmed
static rules as a criterion for routing, whose are specifically set
up to this test scenario. μSDN v2 is a dynamic version which
uses an algorithm based on the Network View considering the
battery level of nodes to determine the next hop for packet
forwarding. Although both versions may work similarly in a
1
http://www.sunspotdev.org/
67
static environment, they present important differences regarding
the lifetime of the rules and the interval between messages of
neighbor discovering. Table III contains results from a
comparison between the versions of μSDN.
AODV and LQRP represented the legacy protocols for
comparison. AODV is the native protocol of SunSpot platform
and uses the hop count as a criterion for routing. LQRP is a
version of AODV, which calculates the costs of routes and, in
addition to the number of hops, also considers the lifetime of
nodes and the link quality between them.
TABLE III. USDN CONFIGURATION PARAMETERS
Interval Between
Lifetime of Rules Neighbors
(ms) Discovery
Protocol
Messages (ms)
μSDN v1 60 x 103 40 x 103
μSDN v2 30 x 103 15 x 103
IV. PERFORMANCE EVALUATION
The performance assessment had two stages. The first stage
aims to investigate the improvements that the reprogramming
time generated in the network when network manager uses
μSDN. The second stage aims to determine how the signaling
introduced by μSDN affects the performance of the network. For
this study, we used SunSpot1 platform which is a WSN platform
developed by Sun Microsystems. Its main feature is the
possibility to use Java as a programming language, which gives
it a high degree of abstraction and allows rapid development of
applications. Although Sun has finished supporting the platform;
some developers still use it for testing and research purposes.
The nodes have an ARM920T 180Mhz processor, 512KB of
RAM, 4MB of storage, 3.7V and 720mAh lithium-ion batteries
and 802.15.4 radios, which are widely adopted in Zigbee and
6loWPAN networks.
A. Reprogramming
Both reprogramming methods, OTA and manual (through
USB interface), are carried out ten times. As depicted in Table
IV, reprogramming time when network manager uses OTA is
approximately ten times greater than the reprogramming time
due to a manual approach. The USB interface, used in the
manual reprogramming, provides more throughput than the
wireless interface, used in the OTA reprogramming. The
maximum throughput provided by 802.15.4 wireless interface is
250 kbps [18] while the USB interface can achieve transmission
throughput up to 480 Mbps in the 2.0 specification [19].
The rightmost column of Table IV shows an estimate of
reprogramming times for a network with five nodes, so when
network manager uses μSDN, they can significantly reduce the
reprogramming time. With μSDN, the reprogramming is
approximately 22% of the time spent by the manual
reprogramming of the entire network, and roughly 2% of time
spent by reprogramming via OTA. The reduction happens
because μSDN allows the modification of the entire network
routing through the reprogramming of a single node, which
plays the role of Controller.
TABLE IV. REPROGRAMMING TIME A NETWORK WITH FIVE NODES
Number Individual Total
Reprogramming
of Time Reprogramming
Method
Updates Rescheduling Time
USB 5 44,3 s 221,5 s
OTA 5 431 s 2155 s
μSDN 1 44,3 s 44,3 s
B. Signaling and Network Performance
At this stage, the evaluation focuses on the ability of μSDN
to keep the network performance similar to the traditional
protocols. That may help to establish it as a viable solution, so
we proposed a hypothetical scenario for the evaluation. The
scenario has four nodes and a Base Station, which may refer to
a smart home application with light, temperature and presence
sensor. It is worth mention that the sensors are not transmitting
data all the time and they may work as routers and form multi-
hop networks. One of the nodes (transmitter) gathers
information about temperature and lighting and sends it to a
second node (receiver). The other two nodes are routers between
the transmitter and the receiver, while the base station is the
Controller.
The nodes stand on a flat surface, according to Figure 3, and
have had their transmission powers adjusted so the transmitter
would not be able to transmit packets directly to the receiver,
forcing the communication over multiple hops. The application
running on the nodes sends approximately 30 messages per
minute to the receiver.
Fig. 3. Evaluation Scenario
The results of the performance evaluations will be presented
depending on the roles played by the nodes. We evaluated
packet transmission in the transmitter; forwarding operation in
the intermediate node; and message reception in the receiver.
The average of metrics considers a 95% confidence interval and
there is no overlapping between compared metrics.
68
1) Transmitter
The performance indicators at the transmitter are energy
consumption and the number of sent packets.
Figure 4 compares four protocols according to the average
values for energy consumption and the number of packets sent.
Figure 4a displays that the protocols which induce the highest
utilization are μSDN v2 and AODV, consuming respectively
about 11% and 15% more energy than the lowest energy
consumption protocol, which was the LQRP.
μSDN v1 consumes less battery than the μSDN v2 due to
reduced frequency of updates in the Network View, which
reduces the signaling traffic. One can notice that the average
consumption remains close to all other experiments and
indicates that the energy consumed by μSDN remains close to
AODV. With regard the number of packets sent, displayed in
Figure 4b, all routing solutions generated an average of 290
packets sent during the test period.
(a) Energy consumption
(b) Packets Sent
Fig. 4. Results in the Transmitter
2) Receiver
In the Receiver, the performance indicators are energy
consumption and the number of messages received.
The results, depicted in Figure 5a, show that AODV caused
the highest average energy consumption, but still, the values the
consumption of all protocols remain close to each other. The
maximum difference among them is only 0,015 mAH,
indicating that μSDN v2 does not cause a significant increase in
energy consumption and it is only slightly greater than LQRP,
which does not require extra signaling for communicating to a
controller entity as SDN proposal does. Note that μSDN v1
reaches the lowest energy consumption.
 Regarding the number of received packets, AODV, μSDN
v1and μSDN v2 got the same results, while LQRP protocol
achieved a performance slightly below the others (receives more
messages). Figure 5b displays these results. The similarities in
the number of packets received indicate that even using the
μSDN, the performance of this metric remained similar to that
of other protocols.
The results, especially regarding energy consumption,
indicate the feasibility of using the static μSDN forwarding rules
in scenarios where the network tends not to have a dynamic
behavior. At the same time, it is possible to conclude that
dynamic version of μSDN can achieve better results than
traditional hop-only based protocols (AODV), as well as quite
similar gains to those of energy-aware protocols, such as LQRP.
(a) Energy consumption
(b) Packets Received
Fig. 5. Results in the receiver
3) Intermediate
The Intermediate nodes are the ones enabling multi-hop
communications. Therefore, nodes of this type suffer more
impact regarding the signaling procedure. The main
performance indicators for the intermediate node are energy
consumption; the number of forwarded packets; and the
relationship between the number of sent packets and the required
energy.
Figure 6a demonstrates a small difference in energy
consumption among the protocols. The results assert that μSDN
can deliver the benefits SDN promises and yet keeps
consumption close to those observed in AODV and LQRP
results even in intermediate nodes. Both LQRP and μSDN
versions require signaling for link quality discovery, while
AODV only relies on simple packet forwarding, what explains
its slightly better performance at the intermediate node.
69
The number of packets forwarded is a metric present only in
intermediate nodes. This metric, depicted in Figure 6b, considers
the number of packets that the node could forward during each
test. In this aspect μSDN v2 had the best performance, with an
average of 301 packets forwarded, while μSDN v1 allowed
forwarding of 290 packets, LQRP forwarded 284 packets, and
AODV forwarded 278.7. The values, result from the capacity
that the controller has to determine the next hop in both versions
of μSDN, that is, the control plane centralization, which allows
faster convergence and route set up for μSDN versions once
network view is available, thus increasing number of forwarded
data packets.
As the total number of packets sent and energy consumption
separately analyzed cannot determine the protocol efficiency, it
was necessary to establish a relationship between them to
ascertain the effectiveness of the protocols. The following
equation provides such value:
NFP
EE =
EC,
In the equation, EE is the Energy Efficiency, NFP is the
Number of Forwarded Packets, and EC is the Energy
Consumption (in mAh).
Figure 6c demonstrates that the results regarding energy
efficiency are similar, just like other metrics. However, even
with a small advantage, μSDN v2 is the protocol that performed
best in this metric, at a rate of approximately 61 packets
forwarded by mAh consumed.
V. CONCLUSIONS AND FUTURE WORK
This paper presented an original proposal, as we developed
a new routing architecture, based on SDN. Such architecture
allows the separation between the Data Plane and the Control
Plane without causing significant impact to the network and yet
keeping the legacy hardware. The implementation also
demonstrates important steps towards complete backward
compatibility once we have to reuse some types of messages
from legacy protocols.
The performance evaluation demonstrated that, with μSDN,
the energy consumption remained at levels close to traditional
protocols with low power consumption, despite an increase in
overhead of signaling compared to AODV and LQRP. That
allows us to state that the μSDN is a viable solution by which
the network manager can modify routing policies throughout the
network only by changing the firmware of the Controller. Thus
it is possible to reduce the total amount of unnecessary reinstalls,
and yet the total time to reprogram the network.
Future works may follow some strands regarding possible
improvements and further evaluations. We still can investigate
strategies for μSDN reuse more messages from legacy protocols
by using optional headers; create an API that allows the
modification of routing policies at the application level; expand
the information in the Network View; include support for
virtualization of WSN and multiple controllers. Further
evaluation may include scalability and resilience of μSDN; and
the construction of the Network View regarding convergence
time and the number of required messages; the reduction of
overload inflicted to the network.
(a) Energy consumption
(b) Packets Forwarded
(c) Efficiency
Fig. 6. Results at the Intermediate node
REFERENCES
[1] L. Atzori, A. Iera and G. & Morabito, "The Internet of things: A
survey," Computer networks, 54 (15), pp. 2787-2805, 2010.
[2] B. T. de Oliveira, R. C. A. Alves and C. B. Margi, " Software-defined
Wireless Sensor Networks and Internet of Things standardization
synergism," EEE Conference on Standards for Communications and
Networking (CSCN), pp. 60-65, 2015.
[3] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
J. Rexford and J. Turner, "OpenFlow: enabling innovation in campus
70
networks," ACM SIGCOMM Computer Communication Review, 38(2),
pp. 69-74, 2008.
[4] S. Costanzo, L. Galluccio, G. Morabito and S. Palazzo, "Software
defined wireless networks: Unbridling sdns," 2012 European Workshop
on Software Defined Networking (EWSDN), pp. 1-6, October 2012.
[5] T. Luo, H. Tan and T. Quek, "Sensor OpenFlow: Enabling software-
defined wireless sensor networks," Communications Letters, IEEE,
16(11), pp. 1896-1899.
[6] K. M. Modieginyane, B. B. Letswamotse, R. Malekian and A. M. Abu-
Mahfouz, "Software defined wireless sensor networks application
opportunities for efficient network management: A survey.," Computers
& Electrical Engineering, 2017.
[7] Y. Choi, Y. Choi and Y. G. Hong, "Study on coupling of software-
defined networking and wireless sensor networks," Eighth International
Conference on Ubiquitous and Future Networks (ICUFN), 2016. IEEE,
pp. 900-902, 2016.
[8] A. Mahmud, R. Rahmani and T. Kanter, "Deployment of Flow-Sensors
in Internet of Things' Virtualization via OpenFlow," Third FTRA
International Conference on Mobile, Ubiquitous, and Intelligent
Computing (MUSIC), 2012. IEEE, pp. 195-200, June 2012.
[9] Z. Han and W. Ren, "A Novel Wireless Sensor Networks Structure
Based on the SDN," International Journal of Distributed Sensor
Networks, 2014.
[10] A. Yuan, H. Fang and Q. Wu, "OpenFlow based hybrid routing in
Wireless Sensor Networks," 2014 IEEE Ninth International Conference
on Intelligent Sensors, Sensor Networks and Information Processing
(ISSNIP), pp. 1-5, April 2014.
[11] S. Shanmugapriya and M. Shivakumar, "Context Based Route Model
for Policy Based Routing in WSN using SDN approach," BGSIT
National Conference on Emerging Trends in Electronics and
Communication, 2015, 2015.
[12] L. Galluccio, S. Milardo, G. Morabito and S. Palazzo, "SDN-WISE:
Design, prototyping, and experimentation of a stateful SDN solution for
WIreless SEnsor network," IEEE Conference on Computer
Communications (INFOCOM), p. 513–521, 2015.
[13] A. De Gante, M. Aslan and A. Matrawy, "Smart wireless sensor
network management based on software-defined networking," 27th
Biennial Symposium on Communications (QBSC), pp. 71-75, 2014.
[14] D. Zeng, T. Miyazaki, S. Guo, T. Tsukahara, J. Kitamichi and T.
Hayashi, "Evolution of software-defined sensor networks," IEEE Ninth
International Conference on Mobile Ad-hoc and Sensor Networks
(MSN), pp. 410-413, 2013.
[15] B. T. de Oliveira, L. B. Gabriel and C. B. Margi, "Tinysdn: enabling
multiple controllers for software-defined wireless sensor networks,"
IEEE Latin America Transactions, 13(11), pp. 3690-3696, 2015.
[16] C. Perkins, E. Belding-Royer and S. Das, "Ad hoc on-demand distance
vector (AODV) routing," RFC 3561, 2003.
[17] A. Floros, M. Zennaro and B. & Pehrson, "Routing Protocols for SUN
Spots: Analysis, Comparison and Implementation of new Protocols,"
Skolan för information-och kommunikationsteknik, Kungliga Tekniska
högskolan., 2009.
[18] J. Zheng and M. J. Lee, "Will IEEE 802.15. 4 make ubiquitous
networking a reality?: a discussion on a potential low power, low bit
rate standard," IEEE Communications Magazine, 42(6), pp. 140-146,
2004.
[19] H. Wang, "USB Connector". Patent US Patent No. 7,155,545, 2006.