Project topics and materials
Get Complete Project Material File(s) Now! »
Controller
The controller in SDWSN plays a very critical role as it holds the intelligence of the whole network. Its fundamental functionalities are flow rule generation, mapping functions, and programming interfaces. The SDN model allows for more functionality to be added. There are different implementations of the control plane: it could be centralised [56, 138–140] or distributed [87, 88, 92]. The use of centralised controllers in addition to local controllers is considered in [89,90,141]. Additionally, elastic solutions [58, 93, 94, 142] dynamically add or reduce controllers according to network load.
The SDWN architecture in [83] uses an embedded controller in a Linux system which is attached to a sink node through a serial connection. The sink node communicates with other sensor nodes on a wireless interface. The embedded system consists of an adaptation module, a virtualiser, and a controller. The adaptation module is used for message formatting. The virtualiser ensures that all information collected is collated to form a virtualisation of the network state to the controller [83, 143]. A major drawback of this approach is the fact that the serial communication between the sink and the controller limits the controller and the sink to a one-on-one relationship. This also poses a problem of scalability. Such architectures will only be viable in a small controllable network.
In other instances, the sink node also acts as a base station (BS), which also houses the controller, as in [144] and [27]. De Gante et al. [27] propose a BS based SDWSN which consists of five layers:
physical, medium access, NOS, middleware, and application. The middleware layer consists of a controller, mapping function, mapping information, and a flow table’s definition. The controller controls and manages the network and keeps the state and topology of the network up to date. It uses monitoring messages to acquire network information, such as sensor node energy levels, distance from the BS, node’s neighbour list and link status parameters, such as link quality, response time, etc. The mapping function processes the monitored data from the sensor nodes and creates a network map (topology view). The information acquired is stored in the mapping information module. The purpose of the application layer is to locate the sensed area, and therefore it consists of location and tracking algorithms to maintain accurate information about the node’s position.
Olivier et al. [144] propose a cluster-based SDWSN architecture, which also has a base station. They apply the SDN model in a clustered WSN for the formation of what they refer to as a softwaredefined cluster sensor network (SDCSN). The sensor network is organized in clusters (SDN domains) comprising sensor nodes and a gateway or cluster head. The cluster head herein referred to as SDN cluster head (SDNCH), controls and coordinates all sensor nodes in its domain. The SDNCH can implement its own security policies and thus secure the domain against outside attacks. The SDNCH has a partial view of the network and communicates with other SDNCHs through the gateway. It uses WE-Bridge [145] to exchange local data with other SDNCHs.
Tools
TinySDN is proposed in [86] and implemented like SDWN [83]. TinySDN is based on TinyOS [147, 148], a sensor-network-based OS. TinySDN aims to reduce the control traffic. The TinySDN architecture consists of two nodes, an SDN sensor node and an SDN controller. Sensor OpenFlow is proposed in [68], which there is a communication protocol between the control plane and the data plane [149]. Sensor OpenFlow is based on OpenFlow [128], which until recently was earmarked for enterprise and carrier networks [59]. Sensor OpenFlow also aims to achieve compatibility with other OpenFlow-based sensors. TinySDN was evaluated using a Cooja simulator. Cooja [146] is a simulator tool used to simulate sensor motes running Contiki OS. Mininet [150] is the most prevalent simulation tool used for SDN OpenFlow networks. However, Estinet [151] is purported to be better than Mininet in terms of performance and scalability though it remains proprietary [85]. Fs-SDN [49] is another SDN simulator which was developed to facilitate SDN controller application prototyping; POX [152] controller was used in development. Son et al. [153] developed CloudSimSDN to simulate and test SDN cloud services, since Mininet and other simulators cannot simulate cloud-specific features. Other simulators that support OpenFlow protocol are NS-3 [154] and Trema [155] which are implemented in C++ and C (and Ruby) respectively [156].
CHAPTER 1 INTRODUCTION
1.1 BACKGROUND
1.2 PROBLEM STATEMENT
1.3 RESEARCH OBJECTIVES AND QUESTIONS
1.4 HYPOTHESIS AND APPROACH
1.5 RESEARCH GOALS
1.6 RESEARCH CONTRIBUTION
1.7 RESEARCH OUTPUTS
1.8 DELINEATION AND LIMITATIONS
1.9 OVERVIEW OF STUDY
CHAPTER 2 LITERATURE STUDY
2.1 OVERVIEW OF SOFTWARE-DEFINED NETWORKS
2.2 WSN CHALLENGES
2.3 IMPORTANCE OF SDN IN WSN
2.4 RELATED CONCEPTS
2.5 SOFTWARE-DEFINED WIRELESS SENSOR NETWORKS
2.6 FUTURE RESEARCH CHALLENGES
2.7 DESIGN REQUIREMENTS
2.8 LESSONS LEARNT
2.9 CONCLUSION
CHAPTER 3 SOFTWARE-DEFINED WIRELESS SENSOR NETWORK CONTROL SYSTEM
3.1 SDN CONTROLLER IMPLEMENTATIONS
3.2 SDWSN CONTROLLER
3.3 CONCLUSION
CHAPTER 4 FRAGMENTATION-BASED DISTRIBUTED CONTROL SYSTEM FOR SOFTWARE DEFINED WIRELESS SENSOR NETWORKS
4.1 DISTRIBUTION
4.2 EPIDEMIC/GOSSIP PROTOCOLS
4.3 CONCLUSION
CHAPTER 5 RESULTS AND DISCUSSION
5.1 EXPERIMENTAL EVALUATION
5.2 RESULTS AND DISCUSSION
5.3 CHALLENGES
CHAPTER 6 EFFICIENT CONTROLLER PLACEMENT AND MASTER NODE RE-ELECTION
6.1 THE CONTROLLER PLACEMENT IN SDWSN
6.2 CONTROLLER RE-ELECTION PROBLEM
6.3 CONCLUSION
CHAPTER 7 CONCLUSION
7.1 CONCLUSION
7.2 FUTURE RESEARCH WORK
REFERENCES
