Sage Journals: Discover world-class research

Abstract

Applications supporting various multimedia data in wireless multimedia sensor networks (WMSNs) have specific QoS requirements on bandwidth, delay, and/or packet loss. Perception of applications' QoS requirements and detection of link states are indispensable for the design of QoS-aware routing mechanism. Software defined networking (SDN) is suitable for the purpose since it provides visibility of network resources and programmable interfaces. OpenFlow is the most recognized realization of SDN. We propose a QoS-aware routing mechanism for OpenFlow-enabled WMSNs. The mechanism consists of a framework and routing algorithms on SDN controller. The framework includes two functions: detection of link states among OpenFlow-enabled nodes and determination of flow's QoS requirements. The routing algorithms are achieved in two steps. First, the SDN controller seeks the feasible paths that satisfy QoS requirements of a flow. If there is no path which satisfies the required QoS, the path will be decided by the proposed algorithms depending on flow types: delay-sensitive, bandwidth-sensitive, and best-effort traffic. We conducted experiments on a SDN testbed to evaluate our mechanism and compared the results with conventional routing protocols. The results show that proposed routing mechanism increases the throughput by 43% for video data and reduces the delay by more than 30% for audio data.

1. Introduction

Recent advances in cost-efficient hardware technology have set new stage for the deployment of wireless sensor networks (WSNs) with powerful sensor nodes in reasonable cost. The paradigm is changing from scalar services (temperature, humidity, etc.) to real-time multimedia applications (video, audio, imaging, etc.). Examples of such wireless multimedia sensor network (WMSN) [1] applications include target tracking, environmental video/imaging surveillance, telemedicine, video vehicle detection, and battlefield intelligence [2–5].

Real-time multimedia applications usually require QoS assurances on bandwidth or delay but are tolerant to packet loss, unlike reliability requirement of scalar sensor data. High bandwidth and low delay requirements are major challenges for WMSNs and efficient QoS routing mechanisms are urgently needed to realize envisioned multimedia applications. Many QoS routing mechanisms and protocols [1] are proposed on optimizing network resource utilization, avoiding traffic congestion, and balancing network traffic. Most of them focus on calculating the optimal path with best network conditions without considering QoS requirements of applications. An application may consist of various types of flows, such as video, voice, text, and sensing data. Path decision could be made for each flow according to its QoS requirements and network conditions, which is conducive to network resource orchestration and QoS guarantee.

Software defined networking (SDN) [6] paradigm seems to be promising to present better network resource management, traffic control, and application classification in order to design an efficient QoS-aware routing mechanism. SDN separates the network into data plane and control plane and introduces centralized controllers to abstract control functions for the network. Programmable APIs in SDN controllers (Floodlight, OpenDaylight, Ryu, etc.) [7] are especially suitable to realize QoS-aware routing. As the most recognized realization of SDN, OpenFlow [8] has many in-built functions such as traffic statistics collection, access control, and network configuration. Some explorations on fusion of SDN and WSN have been carried out, such as Flow Sensor [9], Sensor OpenFlow [10], and Software Defined Wireless Network (SDWN) [11]. There are still many issues that need to be addressed, such as sensor network topology discovery, efficient self-organized routing mechanism, and network resource management.

In this paper, we propose a routing mechanism for WMSNs based on SDN technology. In the network architecture, OpenFlow-enabled nodes (OFNs) act as cluster headers, maintain connections with neighbor OFNs, and forward packets on behalf of sensor nodes. The mechanism consists of QoS-aware routing framework and algorithms. The framework is constructed at the application layer of SDN controller with five components cooperated to achieve the proposed mechanism.

The rest of this paper is organized as follows. In Section 2, we discuss related studies on QoS routing in WSNs as well as the exploration of SDN in WSNs. In Section 3, we propose a QoS-aware routing mechanism with algorithms in detail. In Section 4, we evaluate the performance of our mechanism with experimental results. Finally, we summarize our experimental results and point out the future research directions in Section 5.

2. Related Works

QoS routing mechanisms in WSNs employ QoS metric-based path decisions. For multimedia data transmission, bandwidth, delay, packet loss, and energy efficiency are usually taken as the major concern in QoS metrics. Collaborative QoS Routing (CQR) [12] was proposed to achieve efficient bandwidth utilization for real-time flows. Based on Reliable Energy Efficient routing Protocol (REEP) [13], Multimedia REEP (MREEP) [14] was designed as constraint-based routing for real-time and non-real-time traffic. Extended from SPEED [15], Power Adaptive SPEED (PASPEED) protocol [16] achieves energy efficiency by satisfying application-specific delay with minimum transmission cost. PASPEED selects the most energy efficient node among possible next-hop nodes to provide the demanded delivery speed. For nodes with multiple network interfaces, if network capability cannot fulfill on-going flow's QoS requirements, the node can use other interfaces to transmit data for better QoS assurances [17].

Many QoS routing mechanisms have been presented for cluster-based WSNs. Cluster-Based Real-Time Protocol (CBRP-L) [18] combined LEACH [19] and CBRP [20], which discards high delay links and running LEACH to form clusters. The complexity of CBRP-L on uneven grid-based clustering and header selection algorithms result in excessive power consumption. Cluster-based ASARC [21] actuated multimedia sensors to maximize event information and minimize the level of redundancy. Some mechanisms focused on suppression of message flooding and data aggregation to reserve network resource. GRMR [22] proposed a data centric routing mechanism including efficient regional multicast tree construction and data aggregation at the border node to offer QoS assurances.

Some explorations have been conducted in the area of extending SDN to WSNs. Sensor OpenFlow [10] proposed a Software-Defined WSN architecture and tried to address some key challenges, such as flow creation, in-networking processing, and backward and peer compatibility. A novel SDN-based WSN architecture was introduced in [23], where master node acts as the SDN controller and center nodes are OFNs. Center nodes request master node for the route of the first received packet of a flow. Then the master node calculates the route based on network topology and network conditions. SDWN [11] was presented as an extension of WSN, including the main idea, on-going researches, and open issues. OpenRoads [24] envisions a world where users can move freely among SDWNs.

Although above literatures have better performance in some specific scenarios than compared mechanisms, they are still suffering from some shortcomings. Conventional QoS routing mechanisms mostly attempt to select the path with best network conditions without considering the flow's QoS requirements. For cluster-based QoS routing mechanisms, the election of cluster header and clustering process are energy consuming. SDN-enabled routing mechanisms currently are still the initial step and far from completion. This paper focuses on the satisfaction of flow's QoS requirements, in order to guarantee the QoS of data delivery in resource-constrained OpenFlow-enabled WMSNs.

3. QoS-Aware Routing in OpenFlow-Enabled WMSNs

In WSNs, data is transmitted through multihop nodes to destination commonly. Some of the intermediate nodes are powerful enough to endow with important roles, such as clustering and data aggregation. In this paper, we assume that some intermediate nodes are OpenFlow-enabled nodes (OFNs). Each OFN maintains a control interface and several flow tables as defined in OpenFlow protocol [8]. Control interface is responsible for OpenFlow message exchange with SDN controller. Flow tables store flow-oriented forwarding rules issued by controller. Controller is the core network component, which maintains a centralized control plane to manage all OFNs of the network. We present a QoS-aware routing mechanism for OpenFlow-enabled WMSNs, including routing framework and flow-based QoS-aware routing algorithms. This mechanism focuses on link selection among OFNs to provide optimal QoS guarantee and network resource utilization.

3.1. Network Structure and Topology Discovery

As illustrated in Figure 1, the multihop sensor network consists of sensor nodes, a sink node at the bottom right corner, OFNs acting as cluster headers, and a SDN controller. Sensor nodes are only aware of the route to its cluster header (OFN). The controller maintains an overlay network among OFNs through multihop connections. All sensor nodes are clustered to their nearest OFN in hop count. Each OFN is elected as a cluster header automatically and maintains connections with adjacent OFNs. All traffic in a cluster is converged to OFNs before being injected to the network. OFNs forward the traffic according to their flow table rules or ask the controller for action. This architecture simplifies access control, network management, and data aggregation.

Figure 1

OpenFlow-enabled WMSN structure.

To build the overlay network composed of OFNs, topology discovery should be performed firstly. Link Layer Discovery Protocol (LLDP) [25] is the inherent network topology discovery protocol in OpenFlow, which is a Layer 2 protocol to advertise and receive information from its adjacent OFNs. LLDP was designed for single-hop link discovery between OFNs. It is hard to directly apply LLDP to WSNs since most of the sensor nodes are not OpenFlow-enabled due to resource constraints. For hybrid OpenFlow networks, Broadcast Domain Discovery Protocol (BDDP) [25] was derived from LLDP and had been programmed in some open source controllers, such as Floodlight and OpenDayLight. BDDP has same packet format with LLDP, but destination MAC address is changed from multicast address to broadcast address (ff:ff:ff:ff:ff:ff). Therefore, BDDP messages can be penetrated through OpenFlow indirect links.

The problem is that ad hoc feature of WSN may result in BDDP message diffusing to the whole WSN, which leads to traffic overhead and energy inefficiency. Therefore, it is infeasible to apply BDDP directly for topology discovery in WSNs. To avoid flooding of BDDP messages, we propose gradual topology discovery mechanism. This mechanism limits the relay hops of BDDP messages by managing the Time-to-Live (TTL) field.

In initial phase, controller sends a BDDP message (TTL value = 1) encapsulated in Packet-Out message to all OFNs in the network. After decapsulating the received Packet-Out message, OFNs advertise the BDDP message to their neighbor nodes. The neighbor nodes could be OFNs or conventional sensor nodes. If the neighbor is an OFN, it encapsulates this BDDP message in Packet-In message and sends it to controller. If not, it will notice that the TTL value is 1 and discard the message. After that, the controller gathers all the one-hop links among OFNs. Subsequently, the controller injects a new BDDP message with increased TTL value to the network to find the collection of routes with multihop links among OFNs. This process is completed until all OFNs have at least one route with other OFNs. Not only the shortest route but also multiple routes could be collected between each two OFNs. Finally, the route collection can be used to draw a network graph which includes all the OFNs. Optimal routes with best QoS conditions among OFNs are selected as the edges in the graph. Controller adjusts the graph dynamically according to link events. For example, edges among OFNs can be changed when a link goes down or a new link comes up.

3.2. Routing Framework

SDN architecture [26] consists of three layers: forwarding layer, control layer, and application layer, as shown in Figure 2. The forwarding layer is made up of physical OFNs, which performs data forwarding according to the rules in flow tables. Control layer is responsible for the implementation of routing decision, topology discovery, traffic classification, and network configuration.

Figure 2

SDN architecture for QoS-aware routing mechanism.

The proposed framework, as illustrated in Figure 2, consists of five components: link state detection, flow classification, flow management, QoS-aware routing, and per-flow routing policy. Those components work together based on the information collected from the control layer, such as topology and flow statistics. Link state detection is responsible for detecting up-to-date link states among OFNs, including delay and bandwidth, using traffic monitoring tool sFlow [27] or NetFlow [28]. Flow classification classifies online traffic [29] based on analyzing the flow statistics information using data mining technique, such as K-medoids algorithm [30]. Flow management maintains flows' QoS requirements. QoS-aware routing is in charge of path determination depending on link states and flow's QoS requirements. Finally, routing decision is issued to control layer by per-flow routing policy and distributed to OFNs located on the delivery path.

The routing modeling can be explained as follows. An OpenFlow-enabled WSN can be modeled as a network graph $G = (O F N s, E)$ , where OFNs represent OpenFlow-enabled nodes and $E = (e_{1}, e_{2}, e_{3}, \dots, e_{n})$ is the link set among OFNs. Link states of edge $e_{i}$ are indicated by vector $(c, d, u)$ , where “c” is the link capacity, “d” is the link delay, and “u” is the link bandwidth utilization rate. Accordingly, we use c _{e_i} and d _{e_i} to represent link capacity and link delay of edge e _i, respectively. For a given source-destination pair ( $s, t$ ), controller lists out all available paths with respective QoS metrics. Delay of a path $d_{p}$ is an additive metric while capacity $c_{p}$ is an extremum metric. States of each path can be represented by the vectors ( $d_{p}, c_{p}$ ) according to

\begin{matrix} d_{p} = \sum_{i = 1}^{n} d_{e_i}, \\ c_{p} = \min_{e_i \in p} c_{e_i} . \end{matrix}

(1)

The utilization rate of a link can be calculated by (2). Here, $b_{u_i}$ is the bandwidth usage which can be obtained from sFlow by monitoring the traffic of the link. Consider

\begin{matrix} u_{e_i} = \frac{b_{u_i}}{c_{e_i}} . \end{matrix}

(2)

The available bandwidth of each path can be computed by

\begin{matrix} b_{a} = \min_{1 \leq i \leq n} (c_{e_i} - b_{u_i}) . \end{matrix}

(3)

Our mechanism attempts to avoid traffic congestion when new flow is added to the link. Cost of a link is calculated according to link capacity ${(c}_{e_i})$ , link usage ( $b_{u_i}$ ), and required bandwidth ( $b_{r e q}$ ) of the new flow. Equation (4) is derived from the M/M/1 formula [31]. We consider not only the used bandwidth but also the required bandwidth of the new flow. Bandwidth cost function for each path is defined as a piecewise-linear approximation of the M/M/1 formula. This formula ensures that the link with lower utilization rate has smaller cost value. When link utilization approaches the link capacity, it becomes expensive to use this link:

\begin{matrix} φ (b_{u_i} + b_{r e q}, c_{e_i}) = \{\begin{cases} 1, & 0 \leq \frac{b_{u_i} + b_{r e q}}{c_{e_i}} < \frac{1}{3} \\ 3, & \frac{1}{3} \leq \frac{b_{u_i} + b_{r e q}}{c_{e_i}} < \frac{2}{3} \\ 10, & \frac{2}{3} \leq \frac{b_{u_i} + b_{r e q}}{c_{e_i}} < \frac{9}{10} \\ 70, & \frac{9}{10} \leq \frac{b_{u_i} + b_{r e q}}{c_{e_i}} < 1 \\ 500, & 1 \leq \frac{b_{u_i} + b_{r e q}}{c_{e_i}} < \frac{11}{10} \\ 5000, & \frac{11}{10} \leq \frac{b_{u_i} + b_{r e q}}{c_{e_i}} < \infty . \end{cases} \end{matrix}

(4)

The optimal path is the one with minimum bandwidth cost presented by sum function of each link cost:

\begin{matrix} {c o s t}_{b p} = \sum_{i = 1}^{n} φ (b_{u_i} + b_{r e q}, c_{e_i}) . \end{matrix}

(5)

3.3. Flow-Based QoS-Aware Routing Algorithms

The routing algorithms are committed to find the most feasible path for specific QoS requirements. A feasible path is the one that can provide sufficient resource to satisfy all QoS requirements of the flow. For conventional multiconstrained QoS routing algorithms, if there is no path satisfying QoS constraints, the flow would be simply dropped. However, in many scenarios of WMSNs, such as emergence scene monitoring, it is helpful to receive real-time multimedia data as much as possible regardless of packet loss rate. Therefore, in the case of the fact that feasible path cannot be found, the proposed algorithms give the flow an optimal path which provides best effort on QoS satisfaction.

The algorithm is divided into two steps. The first step is to find feasible paths which can assure flow's QoS requirements, while the second step is to find a best-effort path when feasible path does not exist. If feasible paths exist, one of the paths will be selected to transmit the flow. In the situation of multimedia data transmission, it could be difficult to find a feasible path in resource-constraint sensor networks. If feasible path does not exist, it means that flow's QoS requirements cannot be guaranteed during data transmission. Then, the routing algorithm is differentiated depending on flow types: bandwidth-sensitive traffic, delay-sensitive traffic, and best-effort traffic. This algorithm is to supply QoS assurances to the flow as much as possible. The detailed procedure is explained in Figure 3.

Figure 3

QoS-aware routing algorithm.

Initially, when a packet is received by an OFN, the OFN first checks its flow table entries. If no flow table entry is matched, this packet will be sent to the controller using Packet-Out message. After receiving the Packet-Out message, the controller first applies an OSPF [32] path to the packet and following packets that are affiliated with the same flow. Simultaneously, the controller starts QoS-aware routing mechanism by collecting statistics information of the flow for a short period. Applying the flow classification mechanism, controller can classify the flow to a specific type, such as real-time video/audio/imaging, common data retrieval, or scalar sensor data. QoS requirements of each flow type are predefined to the controller following ITU standard definition [29]. Then, controller builds a table for the flow with six tuple pieces of information {flow ID, {src, dst}, flow type, required bandwidth, required delay, and flag} as shown in Table 1. Flow ID is used to represent the flow from same application with same QoS requirements. {src, dst} pair denotes the connection from source to destination. Flow type is obtained after flow classification as the basis to specify the QoS requirements. Flow's QoS requirements are the predefined values for each flow type. Flag is set to identify whether the flow is bandwidth-sensitive, delay-sensitive, or best-effort traffic. Best-effort traffic is the flows that prefer higher bandwidth and delay tolerant, such as data backup from source to data storage (like FTP).

Table 1

Flow classification.

Flow ID	$\{s r c d s t\}$	Flow type	Flow's QoS requirements		Flag
Flow ID	$\{s r c d s t\}$	Flow type	Bandwidth	Delay	Flag
f1	( $s_{1}, t_{1}$ )	Real-time audio	128 Kbps	<100 ms	Delay-sensitive
f2	( $s_{2}, t_{2}$ )	Real-time video	5 Mbps	<150 ms	Bandwidth-sensitive & delay-sensitive
f3	( $s_{3}, t_{3}$ )	Best-effort	High	—	Delay tolerant

To find an optimal QoS path, the two steps of the routing algorithm are elaborated as follows.

Step 1 (finding a feasible path satisfying QoS requirements of the flow).

Feasible paths should satisfy flow's bandwidth and delay constraints. Result of (5) gives the bandwidth cost of each path for each flow. Pseudocode is shown as Algorithm 1. The path that can satisfy flow's bandwidth and delay and has the lowest cost is selected as the optimal path.

If there is no feasible path found, the routing algorithm will go to Step 2 to find a best-effort path on QoS satisfaction.

Algorithm 1: Finding a feasible path. Variables: n: number of available paths; $b_{r e q}$ : required bandwidth; $d_{r e q}$ : required delay; $b_{p a i}$ : available bandwith of path i; $p_{i}$ : the ith path; ${c o s t}_{b p i}$ : bandwidth cost of path i.

given a session pair

Loop

for ( $i = 0$ , $i \leq n$ , $i + +$ )

if ( $b_{r e q} \leq b_{p a i}$ && $d_{r e q} \geq d_{p i}$ )

if ( ${c o s t}_{b p i} > {c o s t}_{b p i + 1}$ )

$p = p_{i + 1}$

$i + +$ ;

end Loop

Step 2 (finding an optimal path when no feasible path exists).

Due to the instability and the resource restriction of WSNs, more attentions should be paid to the case that no path satisfies the flow's QoS requirements. In this case, the algorithm is divided into three cases depending on the categories of the flow: bandwidth sensitive, delay sensitive, and best effort, in order to supply QoS assurances to the flow as much as possible.

Case 1 (routing algorithm for bandwidth-sensitive flows).

Bandwidth satisfaction is more meaningful than delay for many applications. For instance, bandwidth guarantee for multimedia data retrieval from accident site could provide smooth and high definition video/images. For bandwidth-sensitive flows, priority of bandwidth is much higher than latency. If there are paths satisfying bandwidth requirement while dissatisfying delay requirement, the path with lowest delay cost is selected as the optimal path. Delay cost is defined as hop counts of the path by (6). In this situation, among bandwidth satisfied paths, the one that has smallest hop count is selected. If there is no path that can satisfy bandwidth requirement, the path with largest available bandwidth will be selected. Consider

\begin{matrix} {c o s t}_{d_{e_i}} = 1, (e_i \in p) \\ {c o s t}_{d e} = 0, o t h e r w i s e, \\ {c o s t}_{d_{p}} = \sum_{i = 1}^{n} {c o s t}_{d_{e_i}} . \end{matrix}

(6)

Algorithm 2 illustrates the path selection process for bandwidth-sensitive flows when no feasible path is found.

Algorithm 2: Finding a path for bandwidth-sensitive flows. Variables: n: number of available paths; $b_{r e q}$ : required bandwidth; $d_{r e q}$ : required delay; $b_{p a i}$ : available bandwith of path i; $p_{i}$ : the ith path; ${c o s t}_{d p i} :$ delay cost of path i.

given a session pair

Loop

for ( $i = 0$ , $i \leq n$ , $i + +$ )

if ( $b_{r e q} \leq b_{p a i}$ && $d_{r e q} \leq d_{p i}$ )

if ( ${c o s t}_{d p i} > {c o s t}_{d p i + 1}$ )

$p = p_{i + 1}$

else if ( $b_{r e q} \geq b_{p a i}$ )

if ( $b_{p a i} < b_{p a i + 1}$ )

$p = p_{i + 1}$

$i + +$ ;

end Loop

Case 2 (routing algorithm for delay-sensitive flows).

For delay-sensitive flows, delay has more impact on data transmission performance than bandwidth. Therefore, if there are paths satisfying delay requirement but dissatisfying bandwidth requirement, the path with lowest bandwidth cost will be selected as the optimal path. If there is no path satisfying the delay requirement, the path with lowest delay will be selected. The routing process is shown in Algorithm 3.

Algorithm 3: Finding a path for delay-sensitive flows. Variables: n: number of available paths; $b_{r e q}$ : required bandwidth; $d_{r e q}$ : required delay; $d_{p i}$ : delay of path i; $p_{i}$ : the ith path; ${c o s t}_{d p i}$ : delay cost of path i.

given a session pair

Loop

For ( $i = 0$ , $i \leq n$ , $i + +$ )

if ( $d_{r e q} \leq d_{p i}$ && $b_{r e q} \geq b_{p i}$ )

if ( ${c o s t}_{b p i} > {c o s t}_{b p i + 1}$ )

$p = p_{i + 1}$

else if ( $d_{r e q} \geq d_{p i}$ )

if ( $d_{p i} > d_{p i + 1}$ )

$p = p_{i + 1}$

$i + +$ ;

end Loop

Case 3 (routing algorithm for best-effort flows).

Best-effort flows are nondetrimental traffic that is not sensitive to QoS metrics. Typical applications would be peer-to-peer file sharing, historical data retrieval, and data backup. Best-effort flows usually have lowest priority, so that network resource should be allocated to other QoS sensitive applications preferentially. The residual network resource can be used for data transmission of best-effort applications. If new applications with higher priority are injected to the network, best-effort flows should be confined to release enough resource for QoS assurance of the new applications.

4. Experiments and Performance Evaluation

There are some SDN/OpenFlow simulators, such as Mininet [33] and EstiNet [34]. And there are some well-known simulators for routing protocols, such as NS2 [35] and OPNET [36]. The problem is that SDN/OpenFlow simulators do not support the implementation of new routing mechanisms, while well-known routing simulators usually are not compatible with OpenFlow protocol. Therefore, we built a physical network testbed using virtual machines (VMs) and Open vSwitch software [37] installed at OFNs. Three typical flow types (video, audio, and file sharing) were selected to evaluate the performance of proposed QoS-aware routing mechanism. The comparison was conducted with traditional routing algorithms, OSPF and RIP.

4.1. Experiment Environment

As shown in Figure 4, the overlay network testbed was made up of OFNs, source, sink, and controller. OFNs were built using Open vSwitch software (version 2.0.2). Ubuntu servers (14.0.4.4 LTS) deployed with VLC server, VLC client, and Ryu controller (Release 1.0) [38] in VMs using Virtualbox (version 5.0.10) act as the source, sink, and controller, respectively. The software Quagga [39] was used to build Linux Routers for the implementation of routing protocols RIP and OSPF with the same network topology. Delay and bandwidth of each link were set by Linux command tc.

Figure 4

Testbed for OpenFlow-enabled WMSN.

4.2. Methodology

When a sensor node (source in Figure 4) starts a new flow to sink, OFN1 will receive the first packet of the flow. Without previously installed rules for the incoming flow, OFN1 forwards the first packet to the controller. If the controller cannot determine the flow type, it applies an OSPF path to the flow and observes the flow statistics information. After the success of flow classification, the controller assigns a new path to the flow according to the proposed routing algorithms.

We tested the performance of RIP, OSPF, and proposed QoS-aware routing mechanism for real-time video (bandwidth-sensitive and delay-sensitive), audio (delay-sensitive), and file sharing (best-effort traffic). Real-time video flow was emulated by 3 Mbps streaming traffic from source to sink using VLC player. Real-time audio flow was emulated by 100 Kbps UDP traffic using iperf, where only delay was evaluated since the available bandwidth of any link can satisfy the bandwidth requirement. File sharing was emulated by TCP traffic with buffer length 2 Mbps, window size 56 Kbytes, and max segment size 512 bytes. The link states are indicated in Figure 3 with bandwidth, delay, bandwidth cost, and delay cost.

In the experiments, all traffic went through path (source, OFN1, OFN4, OFN5, and sink) for RIP, which has the smallest hop counts. QoS metrics of the path is as follows: 1.8, 160, 73, 7. Path (source, OFN1, OFN4, OFN2, OFN3, OFN5, and sink) with QoS metrics (10, 245, 10, 14) was selected as the default path of OSPF, which has the highest bandwidth. Paths for different flows were different for QoS-aware routing mechanism depending on the comparison between flow's QoS requirements and network conditions. Take 3 Mbps real-time video streaming as an example; path (source, OFN1, OFN2, OFN3, OFN5, and sink) was determined as the route with QoS metrics (5, 115, 16, 9), which has higher bandwidth than RIP path and lower delay than OSPF path.

4.3. Tests and Evaluation Results

In the experiments, for bandwidth-sensitive and delay-sensitive video data transmission, both throughput and delay were evaluated. For delay-sensitive audio data transmission, only delay was evaluated. For best-effort file sharing, only bandwidth was compared since bandwidth is dominative to overall transmission speed.

4.3.1. Real-Time Video Data Transmission

Video streaming server was put on source and client was on sink. Video data transmission through RIP, OSPF, and QoS-aware routing paths was tested, as shown in Figures 5, 6, and 7. Bandwidth of RIP path is 1.8 Mbps. To transmit 3 Mbps streaming, 41% packet loss rate results in low video quality (Figure 5). Bandwidth of OSPF path is adequate for the streaming but delay is around 248 ms which is longer than requirement (150 ms). Thereby in Figure 6, the frames of both sides reveal apparent time difference, which may result in low quality of experience for interactive applications. Streaming through QoS-aware routing path is displayed in Figure 7, where both frames are nearly the same with no packet loss and small one-way delay (115 ms).

Figure 5

Video quality through RIP path.

Figure 6

Video quality through OSPF path.

Figure 7

Video quality through QoS-aware path.

We also tested the throughput variation when the path switched from RIP path to QoS-aware routing path. The throughput is significantly increased from around 1.73 Mbps to 3 Mbps, and jitter is reduced from around 6 ms to 1 ms (Figure 8). Consequently, quality of video data transmission through QoS-aware routing path is much better than RIP path and OSPF path.

Figure 8

Path switching from RIP path to QoS-aware path.

4.3.2. Real-Time Audio Data Transmission

Generally, packet size of audio data is small and data rate is much lower than video. Transmission of audio data requires little bandwidth but is sensitive to delay. Therefore, we emulate audio streaming by 100 Kbps UDP traffic with packet size of 300 bytes. Test results in Figure 9 indicate that the average delay is 165 ms for RIP path, 249 ms for OSPF path, and 63 ms for QoS-aware routing path, respectively. According to the definition in Table 1, only the QoS-aware path can satisfy the delay requirement (100 ms).

Figure 9

Delay test for audio data transmission.

4.3.3. File Sharing Data Transmission

File sharing applications have lower priority than other applications. It desires higher bandwidth for fast data transmission. Therefore, the path with highest available bandwidth is usually assigned to those applications. In our scenario, bandwidth of RIP path is 1.8 Mbps, while OSPF path is 10 Mbps. Without regard to other flows, QoS-aware routing path is the same path with OSPF. Test result indicates that when path switching from RIP path to QoS-aware routing path, throughput increases 5.5 times from 1.73 Mbps to 9.64 Mbps as shown in Figure 10. Within 60 seconds, the transmitted data size is 12.4 Mbytes through RIP path, while it is 68.8 Mbytes through QoS-aware routing path.

Figure 10

Performance improvement from RIP path to QoS-aware path.

4.3.4. Summary

Performance evaluation was conducted with implementations of OSPF, RIP, and proposed QoS-aware routing mechanism in a SDN testbed. Experiment results show that QoS-aware routing mechanism increased the throughput by 43% compared to RIP for video data transmission and reduced the delay by 30% and 54% compared to RIP and OSPF for audio data transmission, respectively. QoS-aware routing algorithm has advantages in QoS satisfaction for different types of flows. The advantages are derived from adopting SDN technology, which allows us to decide per-flow routing policy to mostly satisfy the QoS requirements.

5. Conclusion

In today's wireless sensor networks, more and more complex applications are deployed and QoS-sensitive multimedia data is growing in the network. The SDN technology allows us to find the optimal path that can provide per-flow QoS assurance as much as possible. In this paper, we proposed a QoS-aware routing mechanism for OpenFlow-enabled WMSNs, which includes a QoS routing framework and algorithms. The framework, located at the application layer of SDN architecture, is composed of five components: link state detection, flow classification, flow management, QoS-aware routing algorithms, and per-flow routing policy. The routing algorithms seek feasible paths that can satisfy flow's QoS requirements, if they exist. Otherwise, the routing algorithm decides optimal path depending on the flow types: delay-sensitive, bandwidth-sensitive, and best-effort traffic.

We built a SDN overlay network testbed made up of OFNs using Open vSwitch and SDN controller using Ryu controller. A series of experiments were conducted to compare the routing performances for multimedia data transmission. The result shows that the proposed routing algorithm has overall advantage in QoS satisfaction for different types of flows.

This mechanism can be widely applied to WMSN applications, such as telemedicine, intervehicle communications, and environmental monitoring. In the future, we will further investigate introducing other QoS parameters into QoS metrics, such as packet loss, reliability, and node power level. We will also take sensor node mobility into consideration on routing decision.

Footnotes

Competing Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgments

This work was supported by ICT R&D program of MSIP/IITP, Republic of Korea (no. B0126-16-1078, Creation of PEP based on automatic protocol behavior analysis and Resource management for hyper connected for IoT Services).

References

Akyildiz

I. F.

Melodia

Chowdhury

K. R.

A survey on wireless multimedia sensor networks

Computer Networks 2006 51 4 921 960

10.1016/j.comnet.2006.10.002

Paek

Hicks

Coe

Govindan

Image-based environmental monitoring sensor application using an embedded wireless sensor network

Sensors 2014 14 9 15981 16002

10.3390/s140915981

2-s2.0-84931826061

Bhatt

Datta

A two-tier strategy for priority based critical event surveillance with wireless multimedia sensors

Wireless Networks 2016 22 1 267 284

Youssif

A. A. A.

Ghalwash

A. Z.

Abd El Kader

M. E. E. D.

ACWSN: an adaptive cross layer framework for video transmission over wireless sensor networks

Wireless Networks 2015 21 8 2693 2710

10.1007/s11276-015-0939-7

2-s2.0-84945260298

Bruno

Nurchis

Efficient data collection in multimedia vehicular sensing platforms

Pervasive and Mobile Computing 2015 16 78 95

10.1016/j.pmcj.2014.05.003

2-s2.0-84921067120

Kim

Feamster

Improving network management with software defined networking

IEEE Communications Magazine 2013 51 2 114 119

10.1109/MCOM.2013.6461195

2-s2.0-84873897891

Kreutz

Ramos

F. M. V.

Verissimo

P. Esteves

Rothenberg

C. Esteve

Azodolmolky

Uhlig

Software-defined networking: a comprehensive survey

Proceedings of the IEEE 2015 103 1 14 76

10.1109/jproc.2014.2371999

2-s2.0-84919935425

McKeown

Anderson

Balakrishnan

Parulkar

Peterson

Rexford

Shenker

Turner

OpenFlow: enabling innovation in campus networks

ACM SIGCOMM Computer Communication Review 2008 38 2 69 74

Mahmud

Rahmani

Exploitation of OpenFlow in wireless sensor networks

Proceedings of the International Conference on Computer Science and Network Technology (ICCSNT '11)

December 2011

Harbin, China

594 600

10.1109/iccsnt.2011.6182029

2-s2.0-84860468008

10.

Luo

Tan

H.-P.

Quek

T. Q. S.

Sensor openflow: enabling software-defined wireless sensor networks

IEEE Communications Letters 2012 16 11 1896 1899

10.1109/lcomm.2012.092812.121712

2-s2.0-84870572145

11.

Costanzo

Galluccio

Morabito

Palazzo

Software defined wireless networks: unbridling SDNs

Proceedings of the European Workshop on Software Defined Networking (EWSDN '12)

October 2012

Darmstadt, Germany

1 6

12.

Xia

Hong-Yi

Gang

Bandwidth efficient collaborative quality of service routing for real-time flow in wireless multimedia sensor networks

Proceedings of the IEEE Asia-Pacific Services Computing Conference (APSCC '10)

December 2010

Hangzhou, China

509 515

10.1109/apscc.2010.20

2-s2.0-79952385004

13.

Zabin

Misra

Woungang

Rashvand

H. F.

N.-W.

Ali

M. A.

REEP: data-centric, energy-efficient and reliable routing protocol for wireless sensor networks

IET Communications 2008 2 8 995 1008

10.1049/iet-com:20070424

2-s2.0-50249085943

14.

Mohajerzadeh

A. H.

Yaghmaee

M. H.

Toroghi

N. N.

Parvizy

Torshizi

A. H.

MREEP: a QoS based routing protocol for wireless multimedia sensor networks

Proceedings of the IEEE 19th Iranian Conference on Electrical Engineering (ICEE '11)

May 2011

Tehran, Iran

1 6

15.

Stankovic

J. A.

Abdelzaher

SPEED: a stateless protocol for real-time communication in sensor networks

Proceedings of the 23th IEEE International Conference on Distributed Computing Systems

May 2003

IEEE

46 55

2-s2.0-0037968893

16.

Ukani

Kothari

Zaveri

An energy efficient routing protocol for wireless multimedia sensor network

Proceedings of the International Conference on Devices, Circuits and Communications (ICDCCom '14)

September 2014

Ranchi, India

1 6

10.1109/icdccom.2014.7024694

2-s2.0-84933575842

17.

Han

Sun

Joo

Han

QoS-based path switching mechanism in mobile SCTP

International Journal of Distributed Sensor Networks 2014 2014 12

282181

10.1155/2014/282181

2-s2.0-84935000172

18.

A novel cluster-based routing protocol in wireless multimedia sensor network

Proceedings of the 4th IEEE International Conference on Broadband Network and Multimedia Technology (IC-BNMT '11)

October 2011

Shenzhen, China

126 129

19.

Heinzelman

W. R.

Chandrakasan

Balakrishnan

Energy-efficient communication protocol for wireless microsensor networks

Proceedings of the 33rd Annual Hawaii International Conference on System Sciences

January 2000

Maui, Hawaii, USA

10.1109/HICSS.2000.926982

20.

Qin

S. H.

Cao

J. N.

Huang

Y. P.

Real-time clustering routing protocol for multimedia sensor networks

Computer Engineering 2010 36 17 129 131

21.

Vithya

Vinayagasundaram

Actuation sensor with adaptive routing and QOS aware checkpoint arrangement on wireless multimedia sensor network

Proceedings of the International Conference on Recent Trends in Information Technology (ICRTIT '11)

June 2011

Chennai, India

444 449

10.1109/icrtit.2011.5972331

2-s2.0-80052224918

22.

Sun

Han

GRMR: greedy regional multicast routing for wireless sensor networks

IEICE Transactions on Information and Systems 2016 E99.D 1 21 29

10.1587/transinf.2015ntp0014

23.

Han

Z.-J.

Ren

A novel wireless sensor networks structure based on the SDN

International Journal of Distributed Sensor Networks 2014 2014 7

874047

10.1155/2014/874047

2-s2.0-84896467920

24.

Yap

K.-K.

Kobayashi

Sherwood

Huang

T.-Y.

Chan

Handigol

McKeown

Openroads: empowering research in mobile networks

ACM SIGCOMM Computer Communication Review 2010 40 1 125 126

10.1145/1672308.1672331

25.

Ochoa-Aday

Cervelló-Pastor

Fernández-Fernández

Current trends of topology discovery in OpenFlow-based software defined networks

External Research Report 2015

26.

Braun

Menth

Software-defined networking using OpenFlow: protocols, applications and architectural design choices

Future Internet 2014 6 2 302 336

10.3390/fi6020302

27.

Phaal

Panchen

McKee

InMon Corporation's sFlow: a method for monitoring traffic in switched and routed networks

IETF RFC 2001 3176

28.

Berk

Murphy

Understanding Netflow Monitoring, Security, and Forensics 2013

Process Query Systems, LLC

29.

Chen

Farley

QoS requirements of network applications on the Internet

Information Knowledge Systems Management 2004 4 1 55 76

30.

Karim

Ahmad

Jami

S. I.

Sarwar

Cluster analysis of traffic flows on a campus network

Proceedings of the 24th IASTED International Conference on Artificial Intelligence and Applications (ATA '06)

2006

Anaheim, Calif, USA

416 421

31.

Fortz

Thorup

Internet traffic engineering by optimizing OSPF weights

Proceedings of the 19th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '00)

March 2000

Tel-Aviv, Israel

519 528

32.

Moy

OSPF version 2

IETF RFC 1998 2328

33.

Lantz

Heller

McKeown

A network in a laptop: rapid prototyping for software-defined networks

Proceedings of the 9th ACM Workshop on Hot Topics in Networks

October 2010

Monterey, Calif, USA

34.

Wang

S.-Y.

Chou

C.-L.

Yang

C.-M.

EstiNet openflow network simulator and emulator

IEEE Communications Magazine 2013 51 9 110 117

10.1109/MCOM.2013.6588659

2-s2.0-84883807883

35.

Issariyakul

Hossain

Introduction to Network Simulator NS2 2010

New York, NY, USA

Springer Publishing Company, Incorporated

36.

Chang

Network simulations with OPNET

Proceedings of the 31st Conference on Winter Simulation: Simulation—A Bridge To The Future (WSC '99)

December 1999

Phoenix, Ariz, USA

307 314

10.1145/324138.324232

37.

Pfaff

Pettit

Koponen

The design and implementation of Open vSwitch

Proceedings of the 12th USENIX Conference on Networked Systems Design and Implementation (NSDI '15)

May 2015

Oakland, CA, USA

USENIX Association

117 130

38.

Ryu Project Team

Ryu SDN framework, release 1.0

https://osrg.github.io/ryu-book/en/Ryubook.pdf

39.

Quagga Routing Software Suite, GPL Licensed, http://www.nongnu.org/quagga

QoS-Aware Routing Mechanism in OpenFlow-Enabled Wireless Multimedia Sensor Networks

Abstract

1. Introduction

2. Related Works

3. QoS-Aware Routing in OpenFlow-Enabled WMSNs

3.1. Network Structure and Topology Discovery

3.2. Routing Framework

3.3. Flow-Based QoS-Aware Routing Algorithms

Step 1 (finding a feasible path satisfying QoS requirements of the flow).

Algorithm 1: Finding a feasible path. Variables: n: number of available paths; b r e q : required bandwidth; d r e q : required delay; b p a i : available bandwith of path i; p i : the ith path; c o s t b p i : bandwidth cost of path i.

Step 2 (finding an optimal path when no feasible path exists).

Case 1 (routing algorithm for bandwidth-sensitive flows).

Algorithm 2: Finding a path for bandwidth-sensitive flows. Variables: n: number of available paths; b r e q : required bandwidth; d r e q : required delay; b p a i : available bandwith of path i; p i : the ith path; c o s t d p i : delay cost of path i.

Case 2 (routing algorithm for delay-sensitive flows).

Algorithm 3: Finding a path for delay-sensitive flows. Variables: n: number of available paths; b r e q : required bandwidth; d r e q : required delay; d p i : delay of path i; p i : the ith path; c o s t d p i : delay cost of path i.

Case 3 (routing algorithm for best-effort flows).

4. Experiments and Performance Evaluation

4.1. Experiment Environment

4.2. Methodology

4.3. Tests and Evaluation Results

4.3.1. Real-Time Video Data Transmission

4.3.2. Real-Time Audio Data Transmission

4.3.3. File Sharing Data Transmission

4.3.4. Summary

5. Conclusion

Footnotes

Competing Interests

Acknowledgments

References

Algorithm 1: Finding a feasible path. Variables: n: number of available paths; $b_{r e q}$ : required bandwidth; $d_{r e q}$ : required delay; $b_{p a i}$ : available bandwith of path i; $p_{i}$ : the ith path; ${c o s t}_{b p i}$ : bandwidth cost of path i.

Algorithm 2: Finding a path for bandwidth-sensitive flows. Variables: n: number of available paths; $b_{r e q}$ : required bandwidth; $d_{r e q}$ : required delay; $b_{p a i}$ : available bandwith of path i; $p_{i}$ : the ith path; ${c o s t}_{d p i} :$ delay cost of path i.

Algorithm 3: Finding a path for delay-sensitive flows. Variables: n: number of available paths; $b_{r e q}$ : required bandwidth; $d_{r e q}$ : required delay; $d_{p i}$ : delay of path i; $p_{i}$ : the ith path; ${c o s t}_{d p i}$ : delay cost of path i.