Printer Friendly

Impact of queue buffer size awareness on single and multi service real-time routing protocols for WSNs.

1. Introduction

Wireless sensor networks (WSNs) represent a technological revolution resulting from convergence of electronic and wireless communication systems. A WSN is composed from a large number of nodes equipped with embedded processor, sensors and radio. These nodes collaborate to accomplish a common task by collecting data, performing local processing and then routing the results to destination node named sink using short-range transmissions [1]. WSNs' constraints differ from those of other networks. The energy consumption should be taken into account [2] and routing protocols have to be with low complexity since nodes' computation capabilities are very limited. WSNs have been applied to many areas such as military applications [3], health care [4], traffic surveillance [5], environmental monitoring [6], habitat [7] and many other areas [8]. In WSNs, QoS requirements are various and identifying the parameters that influence QoS relies on the study of the specific requirements of the application. These lasts let know about the degree of tolerance to a given parameter and reflect the importance of each one. Hence, QoS in WSNs can be characterized by reliability, timeliness, robustness, availability, security, etc. [9]. The throughput, delay, jitter, and packet loss rate are the most fundamental parameters [9] to measure the satisfaction degree of these services.

The growing interest for applications requiring assured end-to-end QoS guarantees have raised additional challenges to QoS-based routing in WSNs cited in [10], [11] and [12]. Such applications have revealed a new challenge: QoS and energy trade-off. For instance, to deal with the high error rate in wireless communication and to provide reliability, some protocols use the multicast transmission which consumes significant power due to more number of receivers being on for longer period [10]. Without loss of generality, RT QoS guarantees can be categorized into two classes as developed in [13]: hard real-time (HRT) and soft real-time (SRT). In HRT system, deterministic end-to-end delay bound should be supported. The arrival of a message after its deadline is considered as failure of the system. While in SRT system, a probabilistic guarantee is required and some lateness is tolerable. To meet the required QoS of RT applications, many new routing protocols were developed to fit within WSNs' constraints discussed mainly in [10] and [13].

SPEED and Multipath Multi-SPEED (MMSPEED) are two QoS-based SRT routing protocols developed for this purpose. The motivation of choosing these two SRT routing protocols as case of study is due to their characteristics concerning the support of only one type of traffic for SPEED and multiple classes of traffic for MMSPEED. This point is important for our analysis since it enables us to study the approach in case of a single service and multiservice protocols. In addition, several routing protocols (outlined in Section 2) were proposed to improve SPEED's and MMSPEED's QoS. Nevertheless, to the best of our knowledge, none of them addressed the problem of the queue buffer size that is usually considered as infinite [14].

The reminder of this paper is as follows. Section 2 reports a brief study of existing QoS based routing protocols. In section 3, an overview of SPEED and MMSPEED protocols is presented. Section 4 explains the proposed scheme based on queue size awareness to enhance the QoS in routing protocols. Section 5 discusses the experimental results and finally section 6 concludes the paper.

2. Related Work

The aim of our work is to evaluate the impact of the queue buffer size awareness on time constraints routing protocols. In order to accomplish a complete study regarding the QoS, we chose two different protocols in terms of the number of supported services, namely SPEED and MMSPEED. The first one provides one type of service while the second one can manage multiple classes of traffic. Therefore, in this section we expose different approaches that have improved SPEED and MMSPEED.

Actually SPEED protocol, introduced in [15] and discussed in section 3.1, is classified among the location and QoS based routing protocols [12]. To guarantee an adequate delay to application's requirements, SPEED tries to maintain a desired packets' Progression Speed (PS) at each hop named SetSpeed by using only local information. Thus, the end-to-end delay can be deduced by dividing SetSpeed by the distance which separates the source node from the sink node. Routing decisions are made in a local way since all information that a node requires are related to its neighbors. This information are recorded in a neighbor table such that each record is composed of the neighbor's identifier (ID), its position, the delay towards it as well as the validity of this record. Furthermore, SPEED manages congestion, detects voids and bypasses them thanks to its Backpressure module. The first proposition to improve SPEED protocol was presented in [16]. In fact, Fault Tolerant SPEED (FT-SPEED) uses the same greedy forwarding scheme exploited by SPEED to manage the RT constrained packets. However, it introduces an alternative void-bypass scheme where the packets at stuck nodes are routed by boundaries ones using the two sides. When facing a void, FT-SPEED RT constraints are no longer the main requirement to be provided during the routing decision.

In [17], the authors focused on the energy consumption issue in SPEED protocol. Therefore, they proposed to consider the residual energy during the routing decision. It is based on a weight function, which is a combination of three factors: delay, energy and speed. Then, the node with the greatest cost is selected as the next forwarding hop.

In [18] extending network lifetime issue was also addressed. The contribution of this work is about using data aggregation by one node in each region. The geographical organization and management of each region is done via the Geographical Adaptive Fidelity (GAF) protocol presented in [19].

The Multipath Multi SPEED presented in [14] is an extension and improvement of SPEED protocol. It allows routing of packets with various speeds and reliability levels according to their priority. This protocol is more detailed in subsection 3.2.

As done in [17], the authors of [20] proposed an energy aware version of MMSPEED protocol. The new protocol includes the criteria of the residual energy of neighbor nodes during the routing decision. Actually, neighbor nodes whose progression speed is higher than (or equal to) the speed of the chosen speed layer for a given packet are sorted in descending order of residual energy, meaning receivers with higher energy levels are chosen first. Then, the packet is delivered to the selected forwarding nodes.

Another improvement of MMSPEED protocol is presented in [21] which have changed the classical contention window mechanism implemented in the Enhanced Distribution Channel Access protocol (EDCA) by the contention window adapter mechanism.

In the next section we introduce an overview on the studied protocols namely SPEED and MMSPEED.

3. SPEED and MMSPEED overview

3.1 SPEED protocol

To accomplish its tasks, SPEED relies on the interoperability of several modules as illustrated on Figure 1.


Based on local information contained in neighbor table, in addition to the position and the ID of destination node k, each node i determines the next hop j thanks to the Non-deterministic Geographic Forwarding module (NGF). Node i starts by establishing the Forwarding Set [FS.sub.i](k) which is the subset of neighbors set [NS.sub.i] that contains nodes j closer to destination k than node i (see Figure 2). Formally,

[FS.sub.i] (k) = {j [member of] [NS.sub.i]/dist(i, k)-dist(j, k) > 0} where dist(i,k) and dist(j,k) are Euclidean distances between i and k, j and k respectively. If [FS.sub.i](k) is not empty, node i calculates the PS toward destination k for each node j of [FS.sub.i](k) by equation (1):

[Speed.sub.ij] (k) = dist(i,k)-dist(j,k)/[Delay.sub.ij] (1)

where [Delay.sub.ij] is the estimated delay between nodes i and j during RTS/CTS/DATA/ACK process. Next, node i subdivides [FS.sub.i](k) in two subsets. In a subset named [FS.sub.i]Inf(k) (resp. [FS.sub.i]Sup(k)), node i puts nodes j having [Speed.sub.ij](k) lower (resp. higher) than the desired SetSpeed. Then, for each node of [FS.sub.i]Sup(k), the probability to be chosen is calculated according to a discrete exponential distribution by equation (2):

P(x = j) = [Speed.sub.ij.,](k)'/[N.summation over (l=1)] [][(k).sup.r] (2)

Where N is the size of [FS.sub.i]Sup(k) and 0<r<1. Node j with highest probability is the next hop.


3.2 MMSPEED protocol

The Multipath Multi SPEED presented in [14] is an extension and improvement of SPEED [15] protocol that guarantees an adequate delay to application's requirements by trying to maintain a desired packets' Progression Speed (PS) at each hop, named SetSpeed and using only local information.

3.2.1 MMSPEED in timeliness domain

In the timeliness domain, MMSPEED is very similar to SPEED. The difference lies on subdividing the network layer in several virtual layers offering each one only one PS noted [SetSpeed.sub.l] and presented by relation (3):

[SetSpeed.sub.1] < [SetSpeed.sub.2] < ... < [SetSpeed.sub.n] (3)

where n is the number of allowed PSs.

To assign to a packet X the adequate layer l, the classifier of the source node i calculates ReqSpeed(X), the needed speed to meet desired end-to-end delay Deadline(X) defined by equation (4):

ReqSpeed (X) = dist(i,k)/Deadline(X) (4)

where dist(i,k) is the distance between i and destination k. Then, the classifier selects starting from the virtual layer 1, the first layer l that satisfies:

[SetSpeed.sub.l] [greater than or equal to] > ReqSpeed(X) (5)

In order to select next hops, node i uses NGF module presented in Section 3.1.

3.2.2 MMSPEED in reliability domain

MMSPEED offers several levels of reliability thanks to a multipath routing. To find out necessary nodes number to guarantee the desired Packets Delivery Ratio (PDR) noted Preq, node i calculates Reaching Probability (RP). This measurement indicates the probability that the packet reaches k if i relays the packet to node j and it is given by equation (6):

[RP.sup.k.sub.i,j] = (1 - [e.sub.ij])[(1 - [e.sub.ij]).sup.[dist(i,k)/dist(i,j)]] (6)

where ej is the rate of lost packets sent from i to j. Then, a variable Total Reaching probability (TRP) is initialized at 0 and is updated using equation (7):

TRP = 1 - (1 - TRP)(1 - [RP.sup.k.sub.i,j]) (7)

By injecting each time TRP's old value and a new node represented by its [RP.sup.k.sub.i,j] until TRP reaches desired [P.sup.req]. Finally, the packet is sent to all nodes which participate to make TRP greater or equal than [P.sup.req]. To guarantee intra-node differentiation, MMSPEED uses EDCF protocol (Enhanced Distributed Coordination Function) in MAC layer, proposed by IEEE 802.11e standard.

It is well known that in RT environments the ratio of data generation rate to transmission rate is important. For this reason, node's buffers are quickly saturated leading to congestion and dropping packets and this makes buffer management and prioritization an important problem in most multi-hop wireless networks. Hence, taking into account the neighbors' queue buffer size in routing decision can enhance the QoS provided by RT routing protocols in two quality domains at the same time: timeliness and reliability. In the next section we expose the proposed approach based on the above mentioned observation.

4. Proposed scheme

4.1 Network Model and assumptions

In this paper, we consider an homogeneous geographic network. The representation of the considered WSN can be made by a connected, undirected and weighted graphG = (V,E), where V = {[v.sub.1], [v.sub.2], ..., [v.sub.n]} refers to the set of nodes in the network (Vertexes) and E = {[e.sub.12], [e.sub.13], ..., [e.sub.nm]} denotes the set of bi-directional links between nodes (Edges). Given a communication radius r, two nodes [v.sub.i] and [v.sub.j] (i [not equal to] j) are connected if they are at distance lower or equal to r. In this case, [e.sub.ij] [member of] E and ([v.sub.i], [v.sub.j]) is a pair of adjacent nodes (neighbours). The weight of each edge is given by a proposed weighting function based on two metrics detailed in subsection 4.3. Figure 3 illustrates the introduced notations.

In this work, we assume that nodes are randomly deployed over a bi-dimensional plane. Also, the sink is not mobile and considered to be a powerful node endowed with enhanced communication and computation capabilities and no energy constraints. In addition, sensor nodes are not mobile and are aware of their coordinates and those of sink node.


4.2 Formulation

In RT applications the ratio of data generation rate to transmission rate is important and the nodes operate as routers during a large part of their life-time. Hence, the nodes need to hold in a buffer the incoming packets during all the time required to process previous ones.

Since memory is limited in such nodes, buffering a large number of packets is not possible. Therefore, the queue buffer size should be considered in the routing process. On the other hand, the time elapsed by a packet in a node includes the waiting time spent in its queue. Thus, considering the queue buffer size in the routing decision can reduce the delay experienced by the packet.

The considered queue in this paper is a priority queue (See Figure 4) composed of multiple virtual queues where each one follows a M/G/1 queuing system [22].

This kind of queue is characterized by an arrival according to a Poisson process [23] with mean packet arrival rate of [lambda] and the service time distribution is considered as exponential with mean service rate of [mu]. The queuing discipline is First In First Out (FIFO) where packets are processed according to their arrival time: a packet that arrives first will be processed first as soon as the processor is free. When a packet arrives at a node i, and thanks to its type of service field, node's i classifier allocates this packet to a virtual queue at level l that is appropriate to the packet's class of traffic. The packets with higher priority are served first, the lower second, and so on, according to FIFO discipline.


4.3 The Weighting Function

The proposed routing decision is based on two metrics: the neighbours' PS in addition to their available queue buffer space. Each node is aware of the available space in its neighbours' buffer thanks to the delay control packets, where information about the buffer size is now injected. Hence there are no additional control packets. When node i needs to chose next hop j, and after calculating [Speed.sub.ij](k) for each node in [FS.sub.i](k), node i assigns a value to each edge [e.sub.ij] of its neighbours using equation (8):

[e.sub.ij] = [alpha] x [Speed.sub.ij](k) + (1-[alpha]) x [ABS.sub.l], (j) (8)

where, [alpha] is a weighting coefficient to be fixed and [ABS.sub.l] is the information about the available buffer space in node's j queue at level l. Actually, when a node receives a delay control packet (or delay beacon), it extracts the information about the sending node j and updates its neighbourhood table (See Table 2) that now contains the information about the [ABS.sub.l] (See Table 1).

The available queue buffer size is updated using an Exponentially Weighted Moving Average (EWMA) [24] by equation (9):

[ABS.sub.l], (j, n) = [gamma] x[] (j) + (1 - [gamma]) x [ABS.sub.l], (j, n-1) (9)

where, [delta] is a constant smoothing factor between 0 and 1, [] (j) is the value extracted from the received delay control packet. So, each node i knows about the ABS at each level l of its neighbours j. Using EWMA enables to update the value of [ABS.sub.l] of node j at instant n [ABS.sub.l](j,n) with the consideration of the old value [ABS.sub.l](j,n-1) in order to decrease the strong fluctuation of [ABS.sub.l]. On the other hand, when a node wants to send a delay beacon, it injects the information about its ABS for each l.

4.4 Adaptation to SPEED and MMSPEED protocols

4.4.1 Toward QBSA-SPEED protocol

As cited in section 2, SPEED protocol can manage only one class of traffic. Therefore, in QBSA-SPEED the above mentioned priority queue acts as one queue with FIFO discipline. Hence, when a node i needs to choose the next hop j and after establishing the value of each edge [e.sub.ij] of its neighbours according to equation (8), it chooses node j that satisfies the equation (10):

[e.sub.ij] = [max.sub.p [member of] FSi(k)] [e.sub.ip] (10)

QBSA-SPEED does not use the two subsets [FS.sub.i]Sup(k) and [FS.sub.i]Inf(k). Actually, this protocol is aware of the degree of next hop's congestion by the consideration of its buffer size. Thus, QBSA-SPEED tries to forward the packet to the best node according to its PS and ABS in order to respect the desired SetSpeed and to keep nodes out of congestion. From an energy point of view, this protocol is also capable of load balancing. Since even if we consider the fact that node's PS may stay constant for a while, node's ABS cannot and especially in case of continuous transmission. Thus, node's score is always changing which provides a load balancing.

4.4.2 Toward QBSA-MMSPEED protocol

The proposed protocol MMSPEED in [14] can be considered as a generalization of SPEED protocol. This is due to the fact that it is able to manage many classes of traffic. Therefore, the priority queue is used to enable a differentiation between packets and to serve each one with respect to its constraints. Consequently, in QBSA-MMSPEED protocol if a node i looks for a forwarding node j it calculates the value of [e.sub.ij] of each of its neighbors according to equation (8) and thanks to the information about the [ABS.sub.l] stored in neighborhood table as shown in Table 2. Then, the neighbors are sorted according to these values thus calculated in the descending order. Thereafter, each neighbor is injected in equation (7) until TRP reaches the desired [P.sup.req] as explained in part 3.3.2.

5. Experimental Results

5.1 Methodology

In order to evaluate the efficiency of the proposed scheme and hence QBSA-SPEED and QBSA-MMSPEED, simulations were conducted using Java Simulator (J-SIM) [25] and [26] dealing with different types of traffics.

The aim of all these simulations is to observe the effect of the proposed approaches on the two QoS domains: timeliness and reliability.

To fix the value of a, many simulations have been executed. The value 0.8 of a has produced the best performances for QBSA-SPEED protocol while for QBSA-MMSPEED 0.7 is the optimal one.

Table 3 and Table 4 summarize all simulations' settings inspired from [14].

5.2 Impact of Setspeed's value on SPEED'S performances

In this experiment, we study the influence of SetSpeed's value on packet's delay and delivery ratio. It consists on fixing 10 flows among 100 nodes uniformly deployed as reported in Table 3 and varying SetSpeed. Figure 5 shows that the delay decreases for PSs between 500m/s and 2000m/s. But beyond this threshold value (2000m/s), the delay starts to ascend. This unexpected result can be explained by the incapacity of the nodes to relay packets with higher PSs which corresponds to an empty [FS.sub.i]Sup(k). This leads to a backpressure procedure that includes sending packets. Therefore, latency is introduced caused by network congestion and illustrated by the increasing delay.

The influence of this experiment on PDR is reported in Figure 6. The curve's shape indicates that PDR decreases when PS increases.

In other words, if SetSpeed exceeds topology's speed threshold, the probability to find the set [FS.sup.i]Sup(k) empty increases as well as the probability to reject packets.



5.3 Timeliness-reliability trade-off in MMSPEED protocol

In order to attest reliability and timeliness trade-off, we conduct the following experiment by fixing number of flows at 14, required delay at 1 second and PS at 1000m/s. Figure 7 depicts that it is difficult for MMSPEED protocol to guarantee a strict delay when traffic requires a high level of reliability. As can be seen, this trade-off affects protocol performances.


5.4 Evaluation of the proposed protocols

In the following experiments for fair comparison, we incur congestion at various points. For this purpose, 50% of the nodes are chosen close to each other and start generating packets at the same time.

5.4.1 End-to-end delay

We study the variation of the average end-to-end delay while increasing the number of flows for both protocols QBSA-SPEED and QBSA-MMSPEED. For each number of flows, 10 simulations have been done for each protocol and are represented in the figure by the average value.


Figure 8 reports the results of this experiment for SPEED and QBSA-SPEED. As can be seen, delay increases while adding source nodes due to the important number of packets to be buffered processed and then transmitted.

This figure shows also that QBSA-SPEED protocol outperforms SPEED protocol in timeliness domain. This result can be explained by the fact that by the consideration of the next hop's queue buffer size of QBSA-SPEED. This is illustrated by the difference between the two curves that increases up to 33% for 20 flows.


For the experiment conducted to compare MMSPEED and QBSA-MMSPEED, the flow is divided into two groups having different delay requirements. The first group (Prio) has a requirement of 1.5 seconds while the second one (N-Prio) needs 0.5 seconds. Both groups need PDR of 0.5. MMSPEED and QBSA-MMSPEED use two virtual layers with 250 m/s as PS for non-urgent flow and 1000 m/s for the urgent one. Figure 9 shows the variation of the average delay while increasing the number of flows.

This figure reports that both protocols are able to differentiate packets according to their priority thanks to the differentiation services implemented in MAC and network layers, and respect flows' requirements. In addition, it is clear that beyond 12 flows QBSA-MMSPEED outperforms MMSPEED protocol for both types of flows.



This result can be explained by the fact that between 2 and 12 source nodes, there is no enough traffic to fulfil nodes' buffers. Beyond this number of flows, buffers start to be out of space and then QBSA-MMSPEED chooses nodes with acceptable PS and emptier buffers. On the other hand, MMSPEED protocol still prefers nodes with high PS and do not consider the factor of packets' number in next hops' buffers.

5.4.2 Packet delivery ratio

In this part, we study the variation of the average on-time PDR while increasing the number of flows for both protocols QBSA-SPEED and QBSA-MMSPEED. For each number of flows, 10 simulations have been done for each protocol and are represented in the figure by the average value. Note that the evaluation concerns the on-time PDR since we deal with time-critical applications where late incoming packets are useless.


For the reliability domain, as shown on Figure 10, QBSA-SPEED outperforms SPEED by an average of 20%. This is a result of QBSA-SPEED's awareness of the available space in next hops' buffer, while SPEED nodes are obliged to not consider the incoming packets and to drop them. In addition, when nodes are congested they start sending control packets (see subsection 3.1) which increases packets delay as well as the probability to be dropped. So, QBSA-SPEED which tries to forward packets to more appropriate nodes, will encounter congestion situations less frequently than SPEED.



Concerning reliability domain, both protocols do not respect the required reaching probability of 0.5 as shown on Figure 11. Also, it is clear that reliability provided by both protocols to packets claiming delay of 1.5 seconds is higher than reliability provided to those requiring delay of 0.5. It is observed that QBSA-MMSPEED is capable of maintaining the desired PDR up to 16 flows while MMSPEED protocol can do it only up to 12 flows. This is a result of QBSA-MMSPEED's awareness of the available space in next hops' buffer.

In fact, when nodes are congested they start sending control packets (see part 3.2.1) which increases packets delay as well as the probability to be dropped. So as QBSA-SPEED, QBSA-MMSPEED that chooses the less congested nodes with the consideration of the required PS.


6. Conclusion

Nodes in WSNs have very limited resources. These lasts should be wisely used while trying to provide an acceptable QoS that varies from an application to other. For example, in RT applications, delay and PDR are the most important requirements to be provided. In this paper, we have presented and proved the efficiency of queue buffer size awareness for two real time routing protocols for WSNs. This feature, as simulations have demonstrated, improves the QoS in both domains: timeliness and reliability. Nevertheless, in case of a single service protocol the improvement was more significant than the one seen in case of multiservice protocol.

Routing performance depends largely on the choice of [alpha], and that in turn depends on network conditions. If there is high amount of congestion [alpha] has to be small and vice versa. To deal with complexity of the routing problem, a fixed weighting technique is not the best solution. We can investigate a technique that is adaptive and varies [alpha] at run time depending on the traffic rate i.e. find relation between [alpha] and traffic rate.


[1] Akyildiz, I.F., Su, W., Sankarasubramaniam, Y. and Cayirci, E. (2002), "Wireless sensor networks: a survey", Computer Networks, Vol. 38, pp. 393-422.

[2] Zytoune, O., Fakhri, Y. and Aboutajdine, D. (2010), "A fairly balanced clustering algorithm for routing in wireless sensor networks", Sensor Review, Vol. 30 No. 3, pp. 242-249

[3] Lee, S.H., Lee, S., Song, H. and Lee, H.S. (2009), "Wireless sensor network design for tactical military applications: remote large-scale environments", in Military Communications Conference, 2009, MILCOM 2009, IEEE, pp. 1-7.

[4] Chen, S.L., Lee, H.Y., Chen, C.A., Huang, H.Y. and Luo, C.H. (2009), "Wireless body sensor network with adaptive low-power design for biometrics and healthcare applications", Systems Journal, Vol. 3 No. 4, pp. 398-409.

[5] Tubaishat, M., Zhuang, P., Qi, Q. and Shang, Y. (2009), "Wireless sensor networks in intelligent transportation systems", Wireless Communications and Mobile Computing, Vol. 9 No. 3, pp. 287-302.

[6] Oliveira, L.M. and Rodrigues, J.J. (2011), "Wireless Sensor Networks: a Survey on Environmental Monitoring", Journal of Communications, Vol. 6 No. 2, pp. 143-151.

[7] Naumowicz, T.N., Freeman, R.F., Kirk, H.K., Dean, B.D., Calsyn, M.C., Liers, A.L., Braendle, A.B., Guilford, T.G. and Schiller, J.S. (2010), "Wireless sensor network for habitat monitoring on skomer island", in IEEE 35th Conference on Local Computer Networks (LCN), Berlin, Germany, pp. 882-889.

[8] Kapoor, N., Bhatia N., Kumar S. and Kaur S. (2011), "Wireless Sensor Networks: A Profound Technology", International Journal of Computer Science and Technology IJCST, Vol. 2 Issue. 4.

[9] Muthukarpagam S., Niveditta V., Neduncheliyan S. (2010), "Design issues, Topology issues, Quality of Service Support for Wireless Sensor Networks: Survey and Research Challenges", International Journal of Computer Applications, Vol. 1 No. 6, pp. 1-4.

[10] An-dong Z., Tian-yin X., Gui-hai C., Bao-liu Y. and Sanglu L. (2008), "A survey on real-time routing protocols for wireless sensor networks", Chinese Journal of Computer Science, pp. 234-238.

[11] Al-karaki, J.N. and Kamal A.E. (2004), "Routing Techniques in Wireless Sensor Networks: A Survey", IEEE Wireless Communications, Vol. 11, pp. 6-28.

[12] Akkaya K. and Younis M. (2005), "A survey on routing protocols for wireless sensor networks", Ad Hoc Networks, Vol.3, pp. 325-349.

[13] Li, Y., Chen, C.S. and Song, Y.Q. (2007), "A Technical Review of Real-time QoS Protocols in Wireless Sensor Networks",

[14] Felemban, E., Lee, C.G. and Ekici, E. (2006), "MMSPEED: Multipath multi-SPEED protocol for QoS guarantee of reliability and timeliness in wireless sensor networks", IEEE Transactions on Mobile Computing, pp. 738-754.

[15] He, T., Stankovic, J.A., Lu, C. and Abdelzaher, T.F. (2005), "A spatiotemporal communication protocol for wireless sensor networks", IEEE Transactions on Parallel and Distributed Systems, pp. 995-1006.

[16] Zhao, L., Kan, B., Xu, Y. and Li, X. (2007), "FT-SPEED: a fault-tolerant, real-time routing protocol for wireless sensor networks", International Conference on Wireless Communications, Networking and Mobile Computing (WiCom), Beijing, China, 2007, pp. 2531-2534.

[17] Kordafshari, M.S., Pourkabirian, A., Faez, K. and Rahimabadi, A.M. (2009), "Energy-Efficient SPEED Routing Protocol for Wireless Sensor Networks", Proceedings of the Fifth Advanced International Conference on Telecommunications, Washington, DC, USA, 2009, pp. 267-271.

[18] Roustaei, R., Fakhr, F.Y. and Movaghar, A. (2010), "The Addition of Data Aggregation to SPEED Routing Algorithm While Keeping the Functionality of Available Techniques", Second International Conference on Future Networks, Malayer, Iran, pp. 349-353.

[19] Xu, Y., Heidemann, J. and Estrin, D. (2001), "Geography-informed energy conservation for ad hoc routing", Proceedings of the 7th annual international conference on Mobile computing and networking, ACM New York, NY, USA, pp. 70-84.

[20] Sanati, S., Yaghmaee, M.H. and Beheshti, A. (2009), "Energy aware multi-path and multi-SPEED routing protocol in wireless sensor networks", 14th International CSI Computer Conference CSICC, 2009, pp. 640-645.

[21] Jaballah, W.B. and Tabbane, N. (2009), "Multi path multi speed contention window adapter", International Journal of Computer Science and Network Security IJCSNS, Vol. 9 No. 2, pp. 113-118.

[22] Adan, I. and Resing, J. (2002), "Queueing theory",

[23] Kingman, J.F.C. (1993), Poisson processes, Encyclopedia of Biostatistics, Wiley Online Library.

[24] Kurose, J. and Ross, K. (2005), "Computer networks: A top down approach featuring the internet", Pearson Addison Wesley.

[25] Sobeih, A., Hou, J.C., Kung, L.C., Li, N., Zhang, H., Chen, W.P., Tyan, H.Y. and Lim, H.J (2006), "JSim: a simulation and emulation environment for wireless sensor networks", IEEE Wireless Communications, Vol. 13 No. 4, pp. 104-119.

[26] J-Sim Official (2004),

Othmane Alaoui Fdili (1), Youssef Fakhri (1,2) and Driss Aboutajdine (1)

(1) LRIT-CNRST URAC 29, Universite Mohammed V-Agdal, Rabat, Morocco

(2) LARIT equipe reseaux et Telecommunications, Universite Ibn Tofail, Kenitra, Morocco,,
Table 1. Packet structure

Delay    ID       Sender   Dela   TTL   Buffer
Beacon   Sender   Area     y            Size

Table 2. Example of neighbourhood table with a priority
queue of 3 levels

Neighbour ID   Location    Delay   Buffer Size

4              (22,11,0)   0.5     (12,30,4)

Table 3. General setting

Terrain             200mx200m

Nodes number        100
Deployment          Uniform
ID of sink node     1
Bandwidth           200 Kbps
Payload             32 bytes
Rate of flow        5 packets / second
Traffic type        VBR (Poisson)
Propagation model   Two ray Ground
EWMA's [gamma]      0.8
QBSA-SPEED          [alpha]=0.8
QBSA-MMSPEED        [alpha]=0.7
Buffer size         100 packets

Table 4. EDCF MAC setting

Priority Classes               2 (Class 1,Class 2)

SIFS                           10 [micro]s
Time slot                      20 [micro]s
Persistent Factor(PF)          2
AIFS 1, AIFS 2                 2,4 time slots
[CW.sub.min]1, [CW.sub.min]2   15,31 time slots
[CW.sub.max]1, [CW.sub.max]2   255,511 time slots
COPYRIGHT 2012 Kohat University of Science and Technology
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2012 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:wireless sensor networks
Author:Fdili, Othmane Alaoui; Fakhri, Youssef; Aboutajdine, Driss
Publication:International Journal of Communication Networks and Information Security (IJCNIS)
Article Type:Report
Date:Aug 1, 2012
Previous Article:A novel radio mode identification approach for spectrum sensing in cognitive radios.
Next Article:Fair packet distribution on multi-interfaced mobile router for mobile networks.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters