Professional Documents
Culture Documents
10-2012
Hwee-Pink TAN
Singapore Management University, hptan@smu.edu.sg
Tony Q. S. QUEK
Citation
LUO, Tie; TAN, Hwee-Pink; and QUEK, Tony Q. S.. Sensor OpenFlow: Enabling Software-Defined Wireless Sensor Networks.
(2012). IEEE Communications Letters. 16, (11), 1896-1899. Research Collection School Of Information Systems.
Available at: http://ink.library.smu.edu.sg/sis_research/2957
This Journal Article is brought to you for free and open access by the School of Information Systems at Institutional Knowledge at Singapore
Management University. It has been accepted for inclusion in Research Collection School Of Information Systems by an authorized administrator of
Institutional Knowledge at Singapore Management University. For more information, please email libIR@smu.edu.sg.
IEEE COMMUNICATIONS LETTERS, ACCEPTED FOR PUBLICATION 1
Facebook, HP, Deutsche Telekom, Verizon, Cisco, IBM, and data-centric—acquiring data of interest is more important than
Samsung. knowing who sent the data—and employ different addressing
In the academia, related research has recently heated up on such as attribute-based naming, e.g., “nodes whose sensing
a variety of topics [4]–[7]. These studies were all conducted temperature>30◦C”. SOF must cope with this in the first place
in the context of enterprise and carrier networks alike, such for flow creation.
as data centers, where SDN/OpenFlow originated from. In
stark contrast, WSN represent a sheerly distinct environment
and thereby confront concepts like SD-WSN and SOF with B. Control Plane: SOF Channel
significant challenges. An OpenFlow channel is an end-to-end connection used to
However, we deem it worth exploring to introduce the transmit control messages between a controller and a switch.
fundamental idea of SDN into WSN and tailor it into a An SOF channel is similarly defined. However, this channel
viable approach to solve WSN-inherent problems. Indeed, we must provide TCP/IP connectivity [8] for reliable end-to-
envisage SD-WSN to transform traditional WSN into networks end in-order message delivery, and the two end-parties are
that are: identified using IP addresses. These are generally unavailable
• Versatile: supporting multiple applications in a plug-and- in WSN and need to be addressed.
play manner; sensors are no longer application-dependent
but application-customizable. This is achieved by (i) the
programmable data plane which supports virtually all sorts C. Overhead of Control Traffic
of packet forwarding rules, and (ii) the control plane which SDN can (and usually would) host the OpenFlow channel
decouples upper applications from physical devices (i.e., sen- out of band, i.e., using a separate dedicated network. This is
sors) and provides a global, unified view of the underlying normally not practical for WSN and the SOF channel has to
network to the applications. be hosted in band, i.e., by the WSN itself. Thus, the resource-
• Flexible: easy to enforce policy changes throughout the constrained WSN will have to additionally carry control traffic
entire network, which used to be a tedious task and is prone between controllers and sensors. This is further exacerbated
to inconsistency. This is achieved by the centralized and by the fact that control traffic in WSN tends to be large due to
extremely granular network control in SD-WSN, where the the high network dynamics (node/link failures, energy-aware
granularity is supplied by the fully user-customizable flow routing, mobility, etc.). Hence, without a proper mechanism
tables. to curb control traffic overhead, the underlying WSN can be
• Easy to manage: building an NMS is no different from overloaded.
adding another application on top of the control plane, using
open APIs and without hassle of hacking existing code. In
addition, the centralized network view provided by the control D. Traffic Generation
plane is a great facility, as network administrators prefer End-users are considered peripheral to SDN and hence out
centralized NMS in practice. of the scope of OpenFlow. On the contrary, sensor nodes
behave like end-users by generating data packets, in addition
III. T ECHNICAL C HALLENGES to merely forwarding data as OpenFlow switches do.
The fundamental assumption that OpenFlow makes is that
the underlying network is composed of high-speed switches
such as Ethernet/MPLS switches and IP routers. OpenFlow E. In-Network Processing
was also designed as a wired protocol, and its typical use cases At times, WSN need to process data in-situ, e.g., perform
are data centers, cellular backhaul, enterprise WiFi backbone, data aggregation or decision fusion, in order to reduce data
and WANs. Compared to WSN, these represent significant redundancy and conserve network resource such as bandwidth
disparities and lead to major challenges in designing SOF. and energy. This is another feature absent in SDN.
Fig. 4. The (new) CAV format with one AV pair; multiple AV pairs shall
be concatenated.
Fig. 2. A flow entry with Match defined in the OXM format.