BOB-RED queue management for IEEE 802.15.4 wireless sensor networks

Abstract

Multimedia services over resource constrained wireless sensor networks (WSNs) face a performance bottleneck issue from the gateway node to the sink node. Therefore, the queue management at the gateway node is crucial for diversified messages conveyed from the front nodes to the sink node. In this article, beacon order-based random early detection (BOB-RED) queue management is proposed. BOB-RED is a dynamic adaptation scheme based on adjusting beacon interval and superframe duration in the IEEE 802.15.4 MAC superframe accompanied with RED queue management scheme to increase the transmission efficiency of multimedia over WSNs. We focus on the performance improvement upon different traffic loads over WSNs. Evaluation metrics include end-to-end delay, packet delivery ratio, and energy consumption in IEEE 802.15.4 beacon enabled mode. Simulation results show that BOB-RED can effectively decrease end-to-end delay and energy consumption compared to the DropTail scheme.

1. Introduction

IEEE 802.15.4 standard [1] defines the protocol and interconnection of devices via radio communication in a wireless personal area network (WPAN). The standard uses CSMA/CA medium access mechanism and supports star as well as peer-to-peer topologies. It provides applications such as home entertainment and control, security alarms, industrial monitoring and control, personal mobile healthcare and tele-assist, etc. Two types of device called the full function device (FFD) and the reduced function device (RFD) are used in a LR-WPAN network. FFD is a fully functional device which can be a PAN coordinator, a coordinator, or just a device. RFD is a device with reduced functionality which can only function as an end device. It cannot communicate with any other device in addition to coordinator. We talk about the PAN-coordinator, which acts as a coordinator for the entire WPAN. It is authorized to provide synchronization services in an established network.

Little researches study transmission image or video over IEEE 802.15.4 networks [2–6]. The CMUcam project provides simple vision capabilities to small embedded systems in the form of an intelligent sensor. The CMUcam3 extends upon this idea by providing a flexible and easy to use open source development environment that complements a low cost hardware platform [7]. It can be used for environment surveillance, robotics, interactive toys, or object recognition and tracking. Traffic loads on multimedia services over resource constrained wireless sensor networks (WSNs) sometimes are huge and bursty. Transmission of image or video data requires careful handling to ensure that end-to-end delay is within acceptable range. So, queue management algorithm on a gateway node should allow temporary bursty traffic and prevent high delay. Up to now, there are many popular queuing management algorithms and packet scheduling mechanisms are proposed. As popular known, various scheduling mechanisms such as round-robin (RR), weighted round-robin (WRR), or weighted fair queuing (WFQ) are different from queue managements. Scheduling schemes focus on the sequence and timing of packet transmission, and queue management is obviously about managing queues in forwarding devices such as router or relay node. Queue managements can separate into passive queue management (PQM) and active queue management (AQM). DropTail can be classified as a PQM algorithm since it is basically a simple first in first out (FIFO) mechanism where packets are dropped when queue length exceed buffer length. Random early detection (RED) is the most commonly used queue management algorithm in AQM class [8, 9]. Patel et al. [10] proposed comparison between two queuing management system RED and DropTail for avoiding the congestion in high speed packet switched networks. Epiphaniou [11] focuses on three different mechanisms, namely, DropTail (FIFO), RED, and DiffServ, and their effects on realtime voice traffic. Flow RED is an extended version of RED. It behaves just like RED, but maintains per-flow states for all flows in the gateway node. Using this per-flow state, FRED preferentially drops the packets of flows that have queue sizes larger than the average per-flow queue size [12]. Deficit Round Robin is a variant of WFQ discipline. It allows WFQ to handle variable packet sizes in a fair manner. It guarantees nearly perfect fairness for flows that have at least one packet in the router buffer. Longest queue drop is used as a packet drop strategy [13]. Ali Ahammed and Banu analyze the performance of AQM algorithms including FRED, BLUE, SFB, and CHOKe. They aim at a thorough evaluation among these algorithms and illustrations of their characteristics by simulation [14]. Le et al. [15] evaluate the performance of their analytical on M/M/1 queuing model for IEEE 802.15.4 non-beacon-enabled mode at the 2.4 GHz in NS-2 network simulator. Misic and Misic [16] analyze the performance of a personal area network operating under the IEEE Standard 802.15.4 in the beacon-enabled mode, and derive the probability distribution of packet access delay and calculate the throughput. Buratti [17] proposed a mathematical model for the beacon-enabled mode of IEEE 802.15.4. Gao and He [18] proposed an individual beacon order adaptation (IBOA) algorithm for IEEE 802.15.4 networks, which can individually adapt the beacon interval (BI) and duty cycle of each node at the same time to the node's individual performance requirements. Jeon et al. [19] proposed a new duty-cycle adaptation algorithm for IEEE 802.15.4 beacon-enabled networks. They modify the reserved frame control field in the MAC layer header to deliver the end device's buffer occupancy and queuing delay.

Despite many researches study about the applications of 802.15.4 on industrial and MAC protocol, but little attention in the past has been given to how different queuing management algorithms, such as DropTail and RED, perform in terms of different settings of beacon order (BO), superframe order (SO) parameters on the multimedia service over IEEE 802.15.4 WSNs. As per our literature search, only a few studies have so far analyzed the impact of BO, SO value on IEEE 802.15.4 operation. But, none article invested RED queue management accompanied with BO, SO value for IEEE 802.15.4 WSNs. Moreover, most current gateway nodes use DropTail as a queue management scheme, which does not guarantee fairness and delay bound. There has been no motivation for realtime applications to use end-to-end congestion avoidance mechanisms for IEEE 802.15.4 WSNs. We study the performance evaluation of different queue management algorithms, such as DropTail, RED on gateway node in this article.

In this study, we focus on the performance improvement upon different traffic loads over WSNs. Figure 1 shows a typical multimedia application over WSNs that a front sensor node equipped with a camera sends an emergent message containing the surveillance image to the sink node once it detects an urgent or intrusive event. Different traffic types demand different packet delivery ratios and end-to-end delays. Urgent messages always have a first priority with a minimum end-to-end delay. On the other hand, keep-alive messages carrying small periodic data have a comparatively low priority which can tolerate a longer delay. Hence, a dynamic adaptation scheme based on adjusting BI and superframe duration (SD) in the IEEE 802.15.4 MAC superframe is proposed to increase the transmission efficiency of multimedia over WSNs.

Figure 1

Multimedia service over IEEE 802.15.4 wireless sensor networks.

This article presents beacon-order based RED (BOB-RED) queue management for congestion avoidance in IEEE 802.15.4 WSNs. The proposed scheme consists of a virtual threshold function, a dynamic adjusted per-flow drop probability, a dynamic modification of BO and SO strategy that decrease end-to-end delay, energy consumption, and increase throughput when there are different traffic type flows through the gateway node.

A comprehensive simulation for the proposed scheme using the NS-2 network simulator is also presented in this study. Evaluation metrics include end-to-end delay, packet delivery ratio, and energy consumption using the beacon-enabled and non-beacon-enabled mode in IEEE 802.15.4 WSNs. Distinct network topologies like star, tree, and chain architectures comprising one coordinator and some stationary nodes are considered in the simulation. Simulation results show that a suitable queuing management scheme accompanied with an appropriate setting of BO, SO can effectively achieve a better performance. If the BO value is fixed, a smaller SO value would incur a higher end-to-end delay and a lower packet delivery ratio. If the BO value is equal to the SO value, a larger BO can achieve a higher packet delivery ratio and a lower average end-to-end delay. Besides, the BOB-RED queue management scheme can decrease end-to-end delay compared to the DropTail scheme.

The remainder of the article is structured as follows: in Section 2 we introduce IEEE 802.15.4 MAC superframe structure and the concepts of RED. In Section 3, we describe the BOB-RED algorithm in detail. In Section 4, we describe network configuration and assumptions. In Section 5, we present the results of our simulations. Finally, in Section 6, we present our main conclusions and suggest a number of areas for further study.

2. IEEE 802.15.4 MAC superframe structure and RED

2.1 IEEE 802.15.4 MAC superframe structure

IEEE 802.15.4 MAC protocol supports the beacon-enabled and non-beacon-enabled modes. In beacon-enabled mode, the access to the channel is managed through a superframe, starting with the beacon packet transmitted by the PAN coordinator. The superframe is subdivided into a contention access period (CAP), contention-free period (CFP), and an inactive part. Nodes in CAP use a slotted CSMA/CA to contention for channel and CAP containing a number of GTSs that can be allocated by the PAN coordinator to specific nodes. In the non-beacon-enabled mode, there are no regular beacons, but the coordinator may unicast beacons to a soliciting device. Communication among devices in the non-beacon-enabled mode uses unslotted CSMA/CA for decentralized access. This article considers CAP and inactive period only when the beacon-enabled mode is used. Figure 2 shows the IEEE 802.15.4 MAC superframe structure [20].

Figure 2

IEEE 802.15.4 MAC superframe structure.

The structure of this superframe is described by the values of macBeaconOrder (BO) and macSuperframeOrder (SO). The MAC PIB attribute macBeaconOrder describes the interval at which the coordinator shall transmit its beacon frames. The superframe order is the variable which is used to determine the length of the SD which is divided into 16 time slots. Similarly, the BI is determined by the variable BO.

Since the time of the SD cannot exceed the time of a BI, the condition for both parameters is 0 ≤ SO ≤ BO ≤ 14. When BO is greater than SO, it indicates that there is an inactive portion present in the superframe. Also for SO = BO, the BI is same as the SD indicating there is no inactive portion.

The values of macBeaconOrder, BO, and the BI are related as follows:

$$\mathsf{\text{BI}}=\mathsf{\text{aBaseSuperframeDuration}}\times {\mathsf{\text{2}}}^{\mathsf{\text{BO}}}$$

$$\mathsf{\text{SD}}=\mathsf{\text{aBaseSuperframeDuration}}\times {\mathsf{\text{2}}}^{\mathsf{\text{SO}}}$$

• BaseSuperframeDuration = 960 symbols = 15.36 ms, each time slot has a duration of 15.36/16 = 0.96 ms.

• Non-beacon-enabled mode: BO = SO = 15. If BO = 15, the coordinator will not transmit beacon frames except when requested to do so, such as on receipt of a beacon request command. The value of macSuperframeOrder shall be ignored if BO = 15.

Three topologies are proposed in IEEE 802.15.4 protocol standard. In a star topology, data transmission can from a device to the coordinator or from the coordinator to the device (Figure 3) [1].

Figure 3

Data transmission from device to coordinator.

Following shows part of NS2 trace file in the beacon-enabled mode (BO = SO = 3). Node 0 is the coordinator and node 1 is an FFD that sends constant bit rate (CBR) traffic to node 0. We set the values of BO, SO equal to 3 so the value of BI is 15.36 ms × 2³ = 122.88 ms. From trace file, we can observe node 0 sends BCN (beacon) every 122.88 ms (1.775232000 - 1.652352000).

s 1.652352000_0_MAC--0 BCN 12 [0 ffffffff 0 0]

s 1.775232000_0_MAC--0 BCN 12 [0 ffffffff 0 0]

s 1.789120000_1_MAC--0 CM1 17 [0 0 1 0]

r 1.789856033_0_MAC--0 CM1 17 [0 0 1 0]

s 1.790272000_0_MAC--0 ACK 5 [0 1 0 0]

r 1.790624033_1_MAC--0 ACK 5 [0 1 0 0]

s 1.898112000_0_MAC--0 BCN 20 [0 ffffffff 0 0]

In the tree topology, data transmission can from a device to the coordinator or from the coordinator to the device. Following shows node 1 sends an association request (CM1) to node 0.

s 1.789120000_1_MAC--0 CM1 17 [0 0 1 0]

r 1.789856033_0_MAC--0 CM1 17 [0 0 1 0]

s 1.790272000_0_MAC--0 ACK 5 [0 1 0 0]

r 1.790624033_1_MAC--0 ACK 5 [0 1 0 0]

............................................................

s 2.282144033_1_MAC--0 CM4 16 [0 0 1 0]

r 2.282848067_0_MAC--0 CM4 16 [0 0 1 0]

s 2.283072000_0_MAC--0 ACK 5 [0 1 0 0]

r 2.283424033_1_MAC--0 ACK 5 [0 1 0 0]

s 2.283712000_0_MAC--0 CM2 25 [0 1 0 0]

r 2.284704033_1_MAC--0 CM2 25 [0 1 0 0]

s 2.284896033_1_MAC--0 ACK 5 [0 0 1 0]

r 2.285248067 _0_ MAC--0 ACK 5 [0 0 1 0]

After that node 0 receives the request and sends back an ACK. Connection is established. Then node 1 sends a data request (CM4) and node 0 sends an ACK. Node 0 sends an association response (CM2) and node 1 sends back an ACK [1] (Figure 4).

Figure 4

Data transmission from coordinator to device.

2.2 Random early detection

RED, also known as random early discard or random early drop, is an AQM algorithm. The operation of RED queue management is shown in Figure 5.

Figure 5

The operation of RED [8].

When packets income, it calculates their current-occupied average queue length (Avr).

It estimates the average queue size as follows.

$$\text{Avr}=(1-{\text{w}}_q)\times \text{Avr}+{\text{w}}_q\times \text{q}$$

where q is the instantaneous queue size, w_q is the time constant of the low pass filter.

• (2) If the Avr is smaller than MinThreshold (MinThres), the packet will be kept and sent to the queue waiting for the transmission.

• (3) If the Avr is longer than MaxThreshold (MaxThres), all packets will be dropped.

• (4) If the Avr is between MinThres and MaxThres, the initial packet drop probability (P _b) of the packet will be a linear function of a number between 0 and Max_P (default value of max. packet drop probability).

  $$P_{\mathsf{\text{b}}}=\mathsf{\text{Ma}}{\mathsf{\text{x}}}_{\mathsf{\text{P}}}\times \left(\mathsf{\text{Avr}}-\mathsf{\text{MinThres}}\right)∕\left(\mathsf{\text{MaxThres}}-\mathsf{\text{MinThres}}\right)$$

The actual probability (P_a) is a function of the P_b and count of the number of packets enqueued since the last packet was dropped. P_a= P_b/(1 - count × P_b)

Figure 6 shows the drop probability of RED. RED's performance is highly dependent on the settings of its control parameters. We choose several control parameters offered by NS2, which includes qlen, Max _P , Min _th , Max _th and q_w that users may according the requirements to adjust RED's performance. However, the impact of the individual parameter on the queue's performance is dependent on the others too. A set of parameters are listed as below.

Figure 6

The drop probability of RED.

• 1. qlen: queue length.

• 2. Max _th : maximum threshold for queue, Max _th = qlen /2.

• 3. Min _th : minimum threshold for queue, Min _th = Max _th /3.

• 4. Max _P : maximum value for P_b, Max _P = 2 * packet_loss_rate. NS-2 default value is 0.1.

• 5. q_w: queue weight, NS-2 default value is 0.002.

RED is the simplest queue management and comprehensively used in most routers. Despite RED algorithm is designed to accompany a transport-layer congestion control protocol such as TCP in IP Networks. We try to apply RED mechanism in IEEE 802.15.4 WSNs.

3. BOB-RED algorithm

3.1 Description of BOB-RED

Figure 7 shows the network topology with real-time traffic and non-real-time traffic in multihop IEEE 802.15.4 WSNs. Gateway node collects all the data from relay nodes and sends them to sink. Taking the IBOA [18] and DCA [19] for references, the BOB-RED adapts BO, SO of each gateway node individually to meet the needs of each gateway node working in a WSN. Unlike a unique BO, SO applied to all of the nodes, the BOB-RED assigns BO _i , SO _i for each neighbor node(i) (i ∈ [1, N], N is the number of nodes working in the network) which nearby the coordinator.

Figure 7

Network topology with real-time traffic and non-real-time traffic in multihop WSNs.

BOB-RED algorithm can also be applied to large number of sensor nodes because it only runs on coordinator or gateway nodes. Multiple gateway nodes forward packets from end devices hop-by-hop to coordinator. Even though in a large-scale sensor networks, only a few relay nodes which around the coordinator or gateway nodes can transfer data directly to them. Owing to the gateway nodes must be FFDs in IEEE 802.15.4 WSNs, every gateway node can dynamic adapt the BO, SO values. If we apply BOB-RED algorithm to all gateway nodes, we must consider whether gateway nodes can communicate with the coordinator. Rapidly or continually adapt their BO, SO values may incur the link broken. In addition, large hop counts will increase large loss rate in our simulation. For simplify the complexity, only one gateway node is implemented in all our simulations.

The flowchart of BOB-RED algorithm is shown in Figures 8 and 9.

Figure 8

BOB-RED algorithm.

Figure 9

BOB-RED algorithm.

The operation of BOB-RED algorithm is very similar to RED queue management. Figure 10 shows the state transition diagram of BOB-RED. We describe the states of a gateway node as follows:

Figure 10

State transition diagram of BOB-RED algorithm.

State 0: The coordinator first sets the initially min_th, max_th, max_p, q_w, BO and SO values. If we set BO and SO values as 3, then the coordinator begins to broadcast beacons. The gateway node calculates the average queue length avg_q.

State 1: If the avg_q is smaller than min_th, then BO and SO values decrease 1. If the avg_q is between min_th and k, the BOB-RED moves to State 2. If the BO and SO values are less than or equal to the BO _min , SO _min , the BOB-RED moves to State 3.

State 2: If the avg_q is between min_th and k, BO and SO values increase 1. If the avg_q is less than min_th, the BOB-RED moves to State 1. If the BO and SO values are greater than or equal to the BO _max , SO _max , the BOB-RED moves to State 4.

State 3: In this state gateway node operates using BO _min , SO _min values. If the avg_q is greater than min_th, the BOB-RED moves to State 2.

State 4: If the avg_q is greater max_th, all of packets will be dropped. If BO is still bigger than BO _min , the MAC decreases BO and SO values by 1, and adds the update information on BO and SO values to the next beacon. If BO, SO values has reached BO _max , SO _max , the BOB-RED returns to State 1.

Figure 11 shows that the buffer size B is divided into four regions by thresholds min_th, k, max_th, where min_th, k, max_th < B. When packet arrives, the gateway node computes the average queue length. When the average queue length exceeds a preset threshold k, the gateway drops or marks each arriving packet with a certain probability, where the exact probability is a function of the average queue length. P _ij is the dropping probability, where i and j denote the number of real-time and non-real-time packets in the buffer, respectively.

Figure 11

Queuing model of BOB-RED.

The value of P _ij can be dynamically calculated based on the number of rear-time and non-real-time packets in the queue, i.e.,

$$Pij=\left\{\begin{array}{c}\hfill 0\hfill \\ \hfill \frac{\left(i+j\right)-k+1}{max\text{\_}th-k+1}\hfill \end{array}\right.$$

(1)

where P _{loss, rt} denotes the drop probability of real-time packet and P _{loss, nrt} denotes the drop probability of non-real-time packet, respectively.

Drop probability of real-time packet lists as in Equation 2.

$$Ploss,rt=\left\{\begin{array}{c}\hfill 0\hfill \\ \hfill 0\hfill \\ \hfill \sum _{i=0}^B\frac{\lambda rt}{\lambda rt+\lambda nrt}pi,B-i\hfill \\ \hfill 1\hfill \end{array}\right.\begin{array}{c}\hfill avg\text{\_}q<min\text{\_}th\hfill \\ \hfill min\text{\_}th\le avg\text{\_}q<k\hfill \\ \hfill k\le avg\text{\_}q<max\text{\_}th\hfill \\ \hfill max\text{\_}th\le avg\text{\_}q\le B\hfill \end{array}$$

(2)

Drop probability of non-real-time packet lists as in Equation 3.

$$Ploss,nrt=\left\{\begin{array}{c}\hfill 0\hfill \\ \hfill \sum _{i=0}^B\sum _{j=0}^{B-i}\frac{\left(1-\alpha i,j\right)\lambda nrt}{\lambda rt+\lambda nrt}pi,j\hfill \\ \hfill Pij\hfill \\ \hfill 1\hfill \end{array}\right.\begin{array}{c}\hfill avg\text{\_}q<min\text{\_}th\hfill \\ \hfill min\text{\_}th\le avg\text{\_}q<k\hfill \\ \hfill k\le avg\text{\_}q<max\text{\_}th\hfill \\ \hfill max\text{\_}th\le avg\text{\_}q\le B\hfill \end{array}$$

(3)

Table 1 lists the dropping strategy with real-time and non-real-time traffics under different buffer occupancy.

Table 1 BOB-RED dropping strategy

Following shows the pseudocode of BOB-RED algorithm.

for each packet arrival (class _rt )

calculate the average queue size avg_q _rt

if min_th ≦ avg_q _rt < k

accepted with probability 1

else if k ≦ avg_q _rt < max_th

calculate probability with probability $Ploss,rt=\sum _{i=0}^B\frac{\lambda rt}{\lambda rt+\lambda nrt}pi,B-i$

mark the arriving packet

else if max_th ≦ avg_q _rt

drop the packet

for each packet arrival (class _nrt )

calculate the average queue size avg_q _nrt

if min_th ≦ avg_q _nrt < k

calculate probability with probability $Ploss,nrt=\sum _{i=0}^B\sum _{j=0}^{B-i}\frac{\left(1-\alpha i,j\right)\lambda nrt}{\lambda rt+\lambda nrt}pi,j$

mark the arriving packet

else if k ≦ avg_q _nrt < max_th

calculate probability with probability $Pij=\frac{\left(i+j\right)-k+1}{B-k+1}$

mark the arriving packet

else if max_th ≦ avg_ _nrt

drop the packet

3.2 Queuing model of BOB-RED

It is noted that, in Figure 11, we have both real-time and non-real-time traffic coexistings in the network. The queuing model is specifically designed in each gateway node.

We use Table 2 to summarize most of the notation we will use in the formulation.

Table 2 Notation table

The waiting time W _rt and W _nrt of real-time and non-real-time traffic at a gateway node i can be calculated according to Little's formula [21] as follows:

$$Wrt=\frac{{\sum }_{i=1}^B{\sum }_{j=0}^{B-i}ipi,j}{\lambda rt\left(1-Ploss,rt\right)}$$

(4)

$$Wnrt=\frac{{\sum }_{i=0}^B{\sum }_{j=1}^{B-i}jpi,j}{\lambda nrt\left(1-Ploss,nrt\right)}$$

(5)

where P _ij is the steady-state probability, where i and j denote the number of real-time and non-real-time packets in the buffer, respectively. The loss probabilities P _{loss, rt} and P _{loss, nrt} of real-time and non-real-time packets at a gateway node i are given as follows.

$$Ploss,rt=\sum _{i=0}^B\frac{\lambda rt}{\lambda rt+\lambda nrt}pi,B-i$$

(6)

$$Ploss,nrt=\sum _{i=0}^B\sum _{j=0}^{B-i}\frac{\left(1-\alpha i,j\right)\lambda nrt}{\lambda rt+\lambda nrt}pi,j$$

(7)

Since we ignore the propagation delay, the end-to-end queuing delay of real-time traffic for a particular path is

$$\begin{array}{c}Tend-end=\sum _{\forall i\in path}{Q}_{rt}^i=\sum _{\forall i\in path}\frac{1}{u_{rt}^i-{\lambda }_{rt}^i}\\ =\sum _{\forall i\in path}\frac{1}{urt-si{\lambda }_{rt}-{\sum }_{j=1}^{ri}sj{\lambda }_{rt}^i}\end{array}$$

(8)

Since the multimedia service is time-constrained. We expect the end-to-end delay along a path under a threshold value.

3.3 The relationship of BO, SO, traffic load against the performance metrics

We use virtual queues for the two different types of traffic, real-time traffic and non-real-time traffic, whose packets are labeled as different flow number accordingly. On gateway node, there is an agent which determines the order of packets to be transmitted from the queues according to the BOB-RED algorithm. It also checks the type of the incoming packet and sends it to the appropriate queue according to average queue size avg_q, BO, SO, min_th, max_th, max_p parameters.

Table 3 concludes the relationship of BO, SO, traffic load against the performance metrics of delay, throughput and power consumption from many articles.

Table 3 The relationship of BO, SO, traffic load against the performance metrics

From many times of experiments, we find somewhat relationship between qualities of services with all the parameters.

We divide all the factors that affect end-to-end delay into five levels from vary parameters. For example, BO, SO values are from 0 to 15. If we set BO, SO value from 0 to 2, the level in spiderchart is 0.

Figure 12 shows the spiderchart of achieving QoS constrained in end-to-end delay. From Figure 12, BO and SO obviously affect the end-to-end delay. Buffer size is not helpful to decrease end-to-end delay. Threshold k is helpful to increase throughputs.

Figure 12

Spiderchart of QoS capability end-to-end delay constrained.

4. Network configuration and assumptions

The solution performance evaluation is carried out under the NS2 simulator [22]. We use the ns2 module developed by Zheng and Lee for IEEE 802.15.4 (NS-2.28) in our simulation. In all simulation, we have considered the followings.

• 1. The physical layer consists of IEEE 802.15.4 compliant radio transmitter (tx) and receiver (rx) that operate in the ISM band at 2.4 GHz, with raw data rate 250 kbps. The modulation technique is Quadrature Phase Shift Keying (QPSK).

• 2. The MAC sub-layer implements the slotted/unslotted CSMA/CA.

• 3. The application layer includes three CBR traffic sources with different data rate and one sink in this article.

• 4. Different scenarios may have different parameter values setting.

• 5. Burst traffic is generated from the camera that capturing event photo and sending it to sink immediately. We dynamically adapt BO, SO value to investigate the performance.

Performance metrics measured in this article are the following.

4.1 Average end-to-end delay

Average end-to-end delay is one of the most important metrics to emergent events. In WSNs, the end-to-end delay is the total time delay to deliver a packet from source to sink node. It is the sum of delays at all links within the end-to-end path. The delay at an intermediate node usually includes the following components: processing delay, queuing delay, transmission delay, propagation delay, and retransmission delay. We mainly consider the average end-to-end delay for all source traffic along a multihop path to sink node. By decreasing the packet retransmission, we can decrease the average end-to-end delay.

4.2 Packet delivery ratio

Packet loss may occur at any stage of a network transmission, mainly due to link failures, CSMA/CA channel access mechanism, RED problems. We use packet delivery ratio (PDR) to denote the performance.

$$\mathsf{\text{PDR}}=\mathsf{\text{received}}\mathsf{\text{packets}}∕\mathsf{\text{sent}}\mathsf{\text{packets}}$$

4.3 Energy consumption

The coordinator consumes the energy when it transmits beacon and ACK packet, receives data packet, and listens the channel. Where rxPower is power consumption in receiving a packet, txPower is power consumption in transmitting a packet, sleepPower is power consumption in sleep state, and idlePower is power consumption in idle state. To measure the energy consumption in our scenarios, we use the energy model in NS-2. For accelerating the power consumption in our simulation, we modify the default values of the NS2 default value [17]. We only measure the energy consumption on coordinator node in beacon-enabled/non-beacon-enabled modes.

5. Performance evaluation

There are three scenarios in this study, namely, chain topology, tree topology, and star topology. The simulation parameters are summarized in Table 4. Simulation duration is set to 60 s of which the first 5 s allow the nodes to associate with the PAN coordinator, and the remaining time is used for sending application traffic.

Table 4 Simulation parameters

5.1 Chain topology

Figure 13 illustrates the network topology with two FFD nodes (n1, n2) and one PAN coordinator (node 0). Each sensor node is set 20-m away from the other nodes. Three CBR traffic flows (Cbr1, Cbr2, and Cbr 3) enter node 1 and then be sent with the average data rate (2 packets/s) through the coordinator (node 0) to the sink node (node 2). Each node's queue size is set to 50 packets.

Figure 13

Chain topology.

5.2 Impact of different BO, SO for traffic loads (beacon-enabled mode)

For each configuration, we vary the inter-arrival time of the flows in source node to have different offered loads, assuming a constant packet size. With high offered loads, it causes higher packet loss because of the queue full. With low offered loads, it causes the increase in the average end-to-end delay.

Table 5 shows the PDR and average end-to-end delay (Avg. delay) using DropTail queue management scheme when SO value is fixed to 0. The PDR values are all zero when BO is greater than 5. Source node cannot transmit data successfully due to long BI and inactive period.

Table 5 PDR and average delay (droptail, 2 pkts/s, SO = 0)

We run the simulation for different values of SO (and BO = SO) as shown in Table 6. When BO equals to SO, less SO value will result in average end-to-end delay increased. When BO value is small, the probability of collision is increased. The bottom of Table 6 shows when BO is fixed, higher SO values have lower average end-to-end delay because of inactive period decreased. Sensor nodes do not change into sleep mode when BO equals to SO.

Table 6 Impact of traffic loads (droptail)

5.3 Impact of traffic loads (non-beacon-enabled mode)

In this simulation, we send a CBR packet every 5 s for keep-alive traffic, the traffic with data rate 2 packets/s stands for normal traffic, and the traffic which sending 20 packets/s is defined as emergent multimedia traffic load. We set BO, SO value to 15 to evaluate the performance in the non-beacon-enabled mode. Simulation time is 60 s and queue size is 50 packets.

Table 7 shows that all metrics (packet delivery ratio, end-to-end delay, and energy consumption) have not any differences between DropTail and BOB-RED algorithm. Due to unslotted CSMA/CA does not use beacon to coordinate devices. Node which acquires the channel can transmit data immediately, so the queue length always is empty. BOB-RED mechanism does not work in the non-beacon-enabled mode. The PDR value is only 39.27% with 20 packets/s traffic load because of the energy of node 0 runs out at 26.808665200 s.

Table 7 Droptail vs. BOB-RED with different traffic loads

5.4 Tree topology

In the second set of experiments, we study the effect of dynamic adaptation scheme. Figure 14 illustrates the network topology with four nodes defined using NS-2 (n0, n1, n2, n3). Each sensor node is set 20 m away from the other nodes. We assume node 1, node 2 does not affect each other. Simulation parameters are all the same as shown in Table 4.

Figure 14

Tree topology.

We run the simulation for different values of BO, SO where BO equals to SO from 0 to 9 with burst traffic. DropTail is the queue management scheme. Node 2 sends CBR traffic to node 0 with 2 packets/s from 10 to 55 seconds. Following node 1 sends burst traffic with 100 packets/s from 25 to 45 s. All nodes are setting the same BO = SO = 3 value in default simulation. Dynamic adaptation scheme changes vary BO, SO values when burst traffic load comes.

Table 8 shows the comparison of default BO, SO value with dynamic adaptation scheme in the average end-to-end delay, PDR, and energy consumption metrics. The average end-to-end delay is 0.313196 s and PDR is 0.2597 in default scheme. We observe that when setting BO = SO = 6, PDR is similar with default scheme but average end-to-end delay can effectively decrease in dynamic adaptation scheme. When the simulation ends, coordinator node 0 still remains 3.655319 J power in dynamic adaptation scheme. Conversely, residual energy of coordinator node 0 runs out at 33.130784000 s in default scheme. Simulation result shows suitably chooses BO, SO value can get longer lifetime and less average end to end delay than default setting of BO, SO values.

Table 8 Performance of dynamic adaptation scheme

5.5 Star topology

For investigating the effect of our scheme in multihop environment, the modified star topology is used. We design three traffic flows along coordinator to sink node not only one hop to coordinator like standard. The topology of this scenario is shown in Figure 15. Four FFDs (nodes 1 to 4) are placed symmetrically around the PAN coordinator (node 0) with an equal distance of 20 m. The traffics generated by nodes 1, 2, and 3 send CBR traffics with 50 packets/s along coordinator (node 0) to sink node (node 4). Node 1 sends CBR traffic from 10 to 55 s. Node 2 sends CBR traffic from 25 to 40 s. Node 3 sends CBR traffic from 40 to 55 s. The focus of the experiment is the head of the bottleneck link between n0, n4 and its buffer in particular. Node 0 is the intermediate gateway node with DropTail or BOB-RED queue implemented, with a buffer capacity of 50 packets and a queue fully monitored during the simulation.

Figure 15

Star topology.

5.6 Simulation study in queue management scheme

A similar investigation has been conducted by changing the actual queue mechanism to BOB-RED for all nodes. BOB-RED operation is based on the principle that as the probability of a packet being dropped increases, the possibility of this packet being enqueued decreases. Figure 16 shows the BOB-RED scheme has lower queue length than DropTail. We observe queue length at the gateway node 0 which is closest to the sink node and measuring the end-to-end delay from source node to sink node. By measuring the queue length of coordinator node (n0), we can observe that queue occupy is not heavy. If the traffic load is getting heavier, the amount of packets stay in the queue will increase. BOB-RED can lessen the congestion by early detecting the queue status to drop packet to decrease the retransmission of arriving packets.

Figure 16

Queue length of coordinator node, traffic load 50 packets/s.

5.7 Simulation study in PDR, average end-to-end delay

Simulation results show that light traffic load with BOB-RED can get the same as DropTail in PDR and average end-to-end delay. When traffic load is getting heavier, despite the PDR is slightly lower than DropTail, but BOB-RED can get lower average end-to-end delay than DropTail. Table 9 shows the results.

Table 9 Droptail VS. BOB-RED with different traffic loads

5.8 Simulation study in energy consumption

Figure 17 shows the energy consumption with different queue management scheme.

Figure 17

Comparing the energy consumption of BOB-RED with DropTail.

The traffic load is 100 packets/s; the total simulation time is 60 s. When the traffic load is light (from 10 to 25 s), the energy consumption of DropTail is the same as BOB-RED. Conversely, both two mechanisms consume energy rapidly when traffic load is getting heavier (from 25 to 40 s). Then, we can observe that residual energy of coordinator node 0 is higher than DropTail if using BOB-RED mechanism. This is because BOB-RED can lessen traffic congestion to decrease the energy consumption. As simulation result shows, using BOB-RED can get better energy consumption than DropTail when traffic load is getting heavier.

6. Conclusions

In this article, we evaluate several queue management algorithms with respect to their abilities of maintaining high resource utilization and low energy consumption in IEEE 802.15.4 beacon-enabled and non-beacon-enabled modes.

We compare the performance of BOB-RED and DropTail on simulation results, using DropTail as the evaluation baseline. The characteristics of different algorithms are also discussed and compared. We evaluate the impact of the following parameters on the performance of slotted CSMA/CA: (1) the beacon order and the superframe order, (2) queuing management scheme such as RED and DropTail, (3) different traffic loads with dynamic adaptation scheme. Simulation results show that RED queue management scheme accompanied with an appropriate setting of BO, SO can effectively achieve a better performance. Besides, the BOB-RED can decrease end-to-end delay and energy consumption compared to the DropTail scheme.

Despite the vary kinds of experiments have done in this article, how to correctly decide the BOB-RED parameters and BO, SO values according different kind of traffic loads is still an issue. In our future study, we will observe mobile sink and sensor nodes as possible. How the nodes mobility model and velocity to affect the end-to-end delay, packet delivery ratio, and better energy consumption in multimedia services over IEEE 802.15.4 wireless sensor networks is the direction of study.