A Framework for Real Time Communication in Sensor Networks

M. Y Aalsalem School of Computer Science

Jazan University, Saudi Arabia aalsalem.m@jazanu.edu.sa

Javid Taheri School of Information Technologies

The University of Sydney Sydney, NSW 2006, Australia

j.taheri@usyd.edu.au

Albert Y. Zomaya School of Information Technologies

The University of Sydney Sydney, NSW 2006, Australia

a.zomaya@usyd.edu.au

Abstract—The introduction of real time communication has created additional challenges in the wireless networks area with different communication constraints. Sensor nodes spend most of their lifetime functioning as a small router to deliver packets from one node to another until the packet reaches the sink. Since sensor networks represent a new generation of time-critical applications, it is often necessary for communication to meet real time constraints as well as other constrains. Nevertheless, research dealing with providing QoS guarantees for real time traffic in sensor networks is still in its infancy. This paper presents a novel packet delivery mechanism, namely Multiple Level Stateless Protocol (MLSP), as a real time protocol for sensor networks to guarantee the quality of traffic in wireless Sensor Networks. MLSP improves the packet loss rate and handles holes in sensor networks. This paper also introduces the k-limited polling model. This model is used in a sensor network by the implementation of two queues served according to a 2-limited polling model in a sensor node. Here, two different classes of traffic are considered and the exact packet delay for each corresponding class is calculated. The analytical results are validated through an extensive simulation study.

Keywords-Real time communication, Wireless sensor networks

I. INTRODUCTION Wireless communications, applications and/or underlying

technologies are among today's most dynamic areas of technology development. Sensor networks can be assumed as distributed computing platforms with severe constraints, including limited CPU speeds, memory sizes, low power consumption, and narrow bandwidth; nevertheless, they are suitable for a wide range of civil and military applications [1-3]. Sensor networks offer new challenges from two perspectives: (1) building communication protocols and (2) developing appropriate queuing and scheduling models. These challenges occur due to their large scale, independent operations, and extraordinarily parallel connections with a spatially distributed physical environment as well as a more strict set of resource constraints. Data gathering in a timely and reliable fashion has been a key concern here.

Wireless sensor networks are particularly related to military and/or time-critical applications. Since sensor networks represent a new generation of time-critical applications including habitat monitoring, pollution detection, weather forecasting, and disaster monitoring, it is often necessary for

communication to meet real time constraints. However, researches dealing with providing QoS guarantees for real time traffic in sensor networks are still very immature.

Many excellent protocols have already been developed for ad-hoc networks[4]. They can be categorized into three groups: (1) flat routing, (2) hierarchical routing, and (3) geographical (location based) routing [5-9]. In flat routing, all routes have equal responsibility of maintaining routing information. Routing algorithms in this category can be further classified into two groups: (1) Proactive, (2) Reactive [8]. Proactive routing [10] algorithms, on the other hand, maintain routes continuously for all reachable nodes. They usually require periodic dissemination of routing updates. Reactive routing [11] algorithms establish and maintain nodes only if they are needed for communication. New routes are acquired when a new connection is set up and is to be maintained throughout the lifetime of connection despite of the topology changes. Geographical routing protocols utilize location information for routing decisions.

Sensor networks have additional requirements that were not specifically addressed before. For example, providing end-to-end real time guarantee is a challenging problem in sensor networks.

Furthermore, the provision of real time assurances in sensor networks requires the solving of a number of problems. For example, the forming of a cluster (of nodes) depends on a number of factors, such as, communication range, number and type of deployed sensors, and their geographical locations. In such networks, the location of the sink (the node that collects information from the network) can significantly affect the network’s lifetime. Therefore, sensor nodes need elegant and uncomplicated real time protocols to prolong the network’s lifetime as much as possible. Although in many applications, the collected sensor data must be delivered within time constraints to make appropriate actions possible [12], most of current QoS provisioning protocols [13-16] in wireless sensor and ad-hoc networks are just based on end-to-end path discovery and path recovery. Also, most of the existing researches are only focused on reliability and lack the ability to differentiate multiple classes of data traffic that may have different time constraints [17-19]. As a result, current forwarding systems do not appropriately support many

categories of real time applications that require strict bounds on factors, such as, data rate, delay and jitter.

To deal with the abovementioned shortcomings of the current approaches, an attempt was made in this paper to provide appropriate network protocols to ensure real time traffic in sensor networks. This paper proposes a real time framework, namely Multiple Level Stateless Protocol (MLSP), that enables sensor data to be delivered within time constraints to make suitable real-time actions possible. MLSP’s main characteristics are: (1) It improves the packet loss rate to properly handle holes in a sensor network and supports multiple dynamic routes with minimum state information to deal with any route failure, (2) It provides superior results (when compared with other approaches) for end-to-end real time communication using its localized forwarding decision making process, (3) It incorporates an anycast MAC layer scheme to assist its routing. This yields to additional advantages in reducing the number of back-offs; and thus, reducing the waiting time for data transmission, (4) It introduces the k-limited polling model for the first time and then uses it in sensor network by implementation of two queues served according to a 2-limited polling model in a sensor node. Our framework chooses the 2-limited polling model as queuing model with the shortest elapsed (Time to Live TTL) packets time to calculate the best possible average waiting time and therefore significantly minimizes the number of dropping packets, and (5) It presents extensive simulations to verify the results in order to provide guaranteed QoS to different traffic scenarios in sensor networks.

The rest of the paper is organized as follow. Section II gives summary information about the related works. The design details of MLSP are presented in section III. Simulation and Results are provided in section IV. The discussion and analysis is presented in section V followed by conclusions in Section VI.

II. RELATED WORK Sensor networks need novel communication protocols to

support higher level services, and also adaptive to avoid unpredictable congestion and holes in sensor networks.

RAP [20] is a multi-layer real time communication architecture for sensor networks. It provides a set of convenient high level query and event services and is based on novel location addressed communication models supported by a light weight network stack. The network stack in RAP consists of (1) a transport layer location addressed protocol (LAP), (2) a geographic routing protocol, (3) a velocity monotonic scheduling (VMS) layer, and (4) a contention based MAC that supports prioritization. VMS is a concept of novel packets requested velocity that reproduces both distance and timing constraints of sensor networks. Two versions of this algorithm are implemented. The static VMS computes a fixed requested velocity at the sender of each packet as follows:

, , , ⁄ where , , , is the geographic distance between a sender and a destination and is an end-to-end deadline. Unlike static VMS that its requested velocity is fixed, dynamic VMS recalculates the requested velocity of a packet upon its arrival at each intermediate node as follows: , , , ⁄ . Here, the requested velocity of a packet will be adjusted based on its actual velocity.

SPEED [18] is an adaptive, location based real time routing/communication protocol that aims to reduce the end-to-end deadline miss ratio in sensor network. It support soft real time communication based on feedback control and stateless algorithms. It also provides three types of real time communication services as uncast, multicast and anycast. SPEED utilizes geographical locations to make localized routing decisions. In addition, it is capable of handling congestion and therefore provides soft real time communication that other location based protocols cannot provide. Because route discovery broadcasts in reactive routing algorithms can lead to significant delays in sensor networks, SPEED only maintains immediate neighbor information. Therefore, it does not need any information regarding routing tables (like DSDV), per-destination states (like AODV), or deadlines. In spite of that, it provides real time guarantees by providing a uniform packet delivery speed across the sensor network so that the end-to-end delay of the packet is proportional to the distance between the source and destination. Furthermore, SPEED does not require specialized MAC support and therefore can work with many existing best MAC protocols due to its feedback control scheme. Also, because all distributed operations in SPEED are highly localized, any action invoked by a node cannot affect the whole system.

MMSPEED [21] is a packet delivery mechanism for wireless sensor networks to grant service differentiation and probabilistic QoS guarantees in timeliness and reliability domains. For the timeliness domain, it provides multiple network wide speed options so that various traffic types can dynamically choose an appropriate speed. Although both SPEED and MMSPEED use fixed transmission power, MMSPEED shows more efficiency when compared with

001 0011 010 1100100 1100100

Sink Number Level Area Power Buffer

Figure 1:Simple counter assigned to each node Figure 2: Hierarchical level based scheme

SPEED. [21].

RPAR [22] is different from the above protocols in the following significant respects: (1) RPAR is the only protocol that combines power control and real time routing for supporting energy efficient real time communication as it allows the application to control the trade-off between energy utilization and communication delay by specifying packet deadlines, (2) RPAR is designed to handle less reliable links, and (3) RPAR utilizes a novel neighborhood management mechanism that is more efficient than the periodic beacons scheme adopted by LAPC, SPEED and MMSPEED. The main features of RPAP are dynamic transmission power adjustment and routing decision making to minimize miss ratios. The RPAP’s transmission power generates greater results for delivery ratios as it improves wireless link quality and decreases the required number of transmission to deliver a packet at the same time. However, transmitting a packet at high power level has a side effect of decreasing throughput due to increasing channel contention and interference.

III. DESIGN OF MLSP The novelty of this framework consists of the following

sections/elements.

A. Self-organization mechanism This mechanism consists of labels being assigned to the

nodes to indicate their information. Each node maintains several counters to register the sink number, its belonging level and area, and its power and buffer status as shown in Figure 1. For instance, with a 4, 5 or 6 bit demonstration for a level in this registry, each node can stores up to 16, 32 or 64 levels from any particular sink, respectively. In MLSP, each node in the network belongs to a certain level with respect to a particular sink (because multiple sinks may exist in a network). Here, the level represents the distance (in terms of hop count) to the assigned sink.

In MLSP, the area is divided into four areas: Red, Orange, Green, and Free areas as shown in Figure 2. Red area is the closest area to the sink. It is usually a very busy area and needs special load balancing techniques to minimize its congestion. Based on imperial results from sensor networks, nodes closer to the sink are fastest dying nodes compare with other nodes in

the network. Orange area is the second area and most of the congestion and packet droppings are happening in this area. This area needs to improve the congestion control and should also avoid the real time packet droppings as much as possible. Green area is the third area where most of the action happens. The most important problem in this area (usually involves congestion problems) is to find the path and to handle holes should they exist. Free area is the rest of a network to cover all faraway nodes. In MLSP, each area consists of a different number of hops, depending on the sink configuration. We assume that the number of hops in each area is static and is configured during the sink configuration phase. Each sensor node is responsible to update its power and buffer information in the associated field of its registry.

When the self organization process starts, nodes are unaware of their distance to any given sink. Therefore, after a node assigns itself to a particular level/area, it will calculate how many hops it is away from a given sink. In this framework, without lose of generality, only one sink is used.

The tagging process as shown in Figure 2 is always initiated by the sink. The message contains Sink Number, and Level/Area to report to the sensor nodes. Each node that receives this message will assign itself the level/area it belongs to (with respect to sink number). After receiving the message, each node broadcasts a message to report that it belongs to level one. All other nodes that listen to this message and do not have this information yet, will increase the value of the received level by one, assign themselves to this level and check their area before they broadcast this new level. This procedure continues until all nodes belong to a level and are assigned to an area. Once a node has assigned itself to a level and an area, it ignores all future broadcasts with level and area information. The tagging technique has designed to handle the holes and to route the packet in case the routing technique fails to find a path. This will eliminate the overhead due to route queries or updating.

B. Neighborhood Manager MLSP features a novel neighborhood manger that

dynamically discovers eligible forwarding choices with the ability to received and forward real time packets as well as managing the neighborhood table. The neighborhood manager

Figure 3: Total packets sent

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

44.9 57.8 64.8 76.2 88.3 146.1 242.9 440.4 639.9 832

Time  (Second)

Total Packets (MLSP) Total Packets (MMSPEED)

Figure 4: Total packets missed

0

500

1000

1500

2000

2500

3000

3500

44.9 57.8 64.8 76.2 88.3 146.1 242.9 440.4 639.9 832

Time  (Second)

Real Time (MMSPED)

Non Real Time (MMSPEED)

Real Time (MLSP)

Non Real time (MLSP)

is invoked whenever no eligible forwarding choice exists in the neighborhood table (to forward a packet). To overcome the worst case scenario in geographical forward routing in which finding a path may fail even if one exists, MLSP consists of three parts: (1) neighbor discovery, (2) power control, and (3) neighborhood table management.

1) Neighbor discovery When the self-organization process has finished, the

neighbor discovery is invoked. Here, a periodic beacon packet is sent to possible neighbors until a response is received. This periodic beaconing is only used to exchange location information, power level and available buffers between neighbors without any extra overhead (because it uses same packet). It obtains the power and buffer information from the counter. Comparing with other protocols, MLSP uses the power level and free buffer space as two important factors to choose the target nodes.

In the worst case scenario, if a node does not belong to any level or area for any reason, the neighbor discovery of this specific node will broadcast a beacon packet with normal power to find a neighbor. If no response is received from any neighbor, it means there is a hole in the network. In this case, this node will broadcast another beacon with a higher power and follows the similar steps until it receives a response from a neighbor. The level and the area of this node can then be determined based on its received/transmitted power level. From the location information of the neighbor nodes, it can calculate its distance from the sink. If it is closer than its assigned level/area information, it updates its network/location

information.

2) Power control Power control is invoked when a node needs to (1) send a

packet one or more hops away, (2) find a path throughout the holes by increasing the power level, or (3) meet its deadlines or avoid network congestions for its real time packets.

3) Neighborhood Table Management This procedure is similar to greedy geographical forward

routing algorithms in which each node has only one table to store the location of its immediate neighbors. This procedure is responsible to check the information in each node’s routing table. Then it reorders the forwarding nodes in the table based on the Choice Factors (CF) as will be described in the forwarding policy. If the Neighborhood table is empty and the node has a message to be sent, it will not wait for the routing queries and table updating. It can directly invoke the functionality of any casting at the MAC layer as will be described in the MAC layer support section.

C. Forwarding policy Forwarding policy is very critical to guarantee packet

delivery. It is also very important to reduce/raise the traffic flow to balance the load throughout of the whole network. MLSP makes the forwarding choices on a packet-by-packet basis. MLSP forwards the packets to the most forwarding choice node that meets the packets delivery requirements. The CF involves several parameters: (1) the power level of the source node, (2) area, and (3) buffer of the destination node. CF is computed as follows:

, , , 1

The available buffer is a critical factor, because if a node sends a packet to another node with not enough available memory, there is a high possibility that the transmitted packet will be dropped. The motivation for using the power level factoring calculating CF plays an important role in the selection of the node with a higher power level. Other protocols select the destination node based on the Geographical forwarding (GF)[23] routing algorithm which could lead to choosing the node with the least power while a neighbor node may have more power to use. The CF in our protocol allows the nodes to dynamically select the best available destination node and therefore avoid such drawbacks. MLSP can also lead to better load balancing and congestion minimization as shown in the results section.

D. Traffic Load Balancing and Congestion Manger MLSP uses the power level and the available buffer of the

destination nodes as important factors for choosing the appropriate nodes among the nodes in the forwarding table. MLSP also allows a node to simultaneously forward/send its packets to deferent suitable nodes to minimize congestions. If congestions occur for any reason, the node will not send the new packet to that node as its buffer is probably full.

E. MAC layer support MLSP does not need real time or QoS aware MAC support.

It only uses the anycast MAC layer to find new paths to (1)

Figure 5: Delay (seconds) for Non Real Time and Real Time packets in

MMSPEED

00.51

1.52

2.53

3.54

4.55

37 65 96 126 157 187 218

Time (Second)

Non Real Time Linear (Non Real Time)

0

0.1

0.2

0.3

0.4

0.5

0.6

37 65 96 126 157 187 218

Time (Second)

Delay in Real Time Linear (Delay in Real Time)

overcome the GF route failure and also to (2) pass the packet throughout the holes without any overhead due to routing queries and updates. When a node has a message that it needs to send to the next nodes, it first broadcasts an RTS messages to the node with a reduction of the level. If the sender node does not receive any response (CTS), it will resend the RTS messages again with more power to reach the nodes with two hops or two levels away. If one or several nodes reply with CTS, the sender node will choose one of these nodes as the destination node and then send the information message directly to it. Because the receiver node would be the node that is awake, the method essentially grants robustness and reduces the possibility of back-offs at links. Followed by this handshaking, the sender node identifies the selected destination node and sends the information packet to it. The MAC address has been chosen as the node identifier in this scenario.

F. Queuing Model Queuing and scheduling have a direct impact on QoS

characteristics. Regardless of its numerous limitations, SPEED protocol uses First-In-First-Out (FIFO) as the queuing regime. FIFO is the default queuing algorithm in several topologies that requires no configuration. Most importantly, FIFO queuing makes no decision about packet priority. FIFO queuing involves storing packets and forwarding them in order of arrival. Explode sources can also cause extended delays in

delivering the packets for time sensitive applications. Although FIFO queuing seems to be an effective network traffic controller, it is not always satisfactory and therefore recent complex networks need more sophisticated algorithms. Furthermore, in FIFO, a full queue will drop high-priority packets as it cannot differentiate packets based on their priority levels.

To overcome the limitations of FIFO queuing, MMSPEED uses priority queuing (PQ) with FIFO scheduling in each queue. PQ is suggested as one of the applicable solutions to meet the desired QoS for real time traffic. In MMSPPED, two queues in a sensor node are considered; high-priority and low-priority. The scheduler uses strict priority logic, i.e., it always serves the high-priority queue first. If there is no packet waiting in high-priority queue, it will serve the low-priority queue. In this technique, because the scheduler of the sensor node is serving different output queues simultaneously, it behaves similar to a multiple queue/single server system [24]. However, the main drawback of MMSPEED is related to the handling of the PQ. In MMSPEED, as long as packets exist in the high priority queue, they will be extracted first. As a result, other queues could easily overflow. This can lead to massive drops of non-priority packets in the network.

The study of polling models is important since it gives good insight into the qualitative behavior of many queuing methods and forms the basis to derive closed form expressions of different QoS parameters such as delay, jitter and throughput. The basic polling model is a queuing model composed of a set of queues and a single server that serves the queues in cyclic order [25]. Polling models can be classified as exhaustive, gated and limited services.

Here we only explain the limited service polling model [26]. In the limited service system, a queue is served until either the buffer is emptied or a specified number of packets are served, whichever occurs first. If at most k packets are served in one cycle, it is referred to as a k-limited polling model. In the k = 1 case, the simplest model is referred to as 1-limited polling model in which the server serves one packet from each queue in an alternating fashion during each cycle.

G. Handling Holes Greedy geographical forwarding algorithms have several

Figure 7: Number of missing packets using Priority and Polling queue methods in MLSP

0

200

400

600

800

1000

1200

1400

44.9 88.3 146.1 242.9 440.4 832

Time  (Second)

MLSP Real Time (PQ)

MLSP Non Real Time (PQ)

MLSP Real Time (Polling)

MLSP Non Real Time (Polling)

Figure 6: Delay (seconds) for Non Real Time and Real Time packets in MLSP

0.000

0.005

0.010

0.015

0.020

0.025

0.030

36 64 95 125 156 186 217

Time (Second)

Non Real Time Linear (Non Real Time)

0.000

0.005

0.010

0.015

0.020

0.025

0.030

36 64 95 125 156 186 217

Time (Second)

Real Time Linear (Real Time)

advantages over traditional MANET routing algorithms for real time sensor network applications; because, they do not suffer from route discovery delays and tend to select the shortest path to the destination. However, a well known problem with greedy geographical forwarding algorithms is related to possible failure of discovering a route when holes exist in the network. In fact, in extreme cases, they may fail to find paths even when they exist. To prevent such actions, MLSP neighborhood manager is specifically designed to find neighbor nodes for future forwarding.

IV. SIMULATION AND RESULT To gauge the efficiency of MLSP, J-Sim [27] is used for

simulation and the results compared with MMSPEED as the benchmark. J-Sim is a software package that provides a high fidelity simulation for wireless communication with detailed propagation, radio and MAC layer properties.

A. Environmental Setup A square shape network (200m, 200m) is selected to

validate the accuracy of the protocol. 100 nodes with 40m radio range are generated to operate in this network. For each node, a free space propagation channel model is assumed with the transmission speed of 250kbps, total packet length of 40 byte for both real time and non real time packets with 15 packet capacity for buffer sizes. These parameters are based on experimental results from [28] [29] [30]. For each node in the sensing state, packets are generated at a constant rate of 1 packet per second. The real time packet generation rate is 3 packets per seconds.

B. Simulation Results Figures 3 and 4 show the total packets sent and missed in

MMSPEED and MLSP, respectively. Figures 5 and 6 demonstrate the delay which has been calculated for real time traffic and non real time traffic (using MMSPEED and MLSP), respectively, for a randomly selected node (other nodes showed similar results). The simulation is repeated 15 times and the averaged values are shown in the figures.

V. DISCUSSION AND ANALYSIS The horizontal axis in Figure 3 shows the time in units of

seconds. The vertical axis shows the range of total number of

sent packets. This figure shows the differences in total sent packets of the MMSPEED and MLSP protocols. As it can be seen in Figure 3, the differences increase with time. MLSP minimizes the total number of sent packets which leads to more power savings as compared with MMSPEED.

Although the total number of packets for real time and non real time packets is identical for MMSPEED and MLSP, MLSP shows better performance. MLSP managed to minimize the number of control packets, update location, back pressure, and new path finding packets as well as reducing the number of missing packets. These are major factors in determining the overall QoS (Figure 4). MLSP decreases the number of missed real and non real time packets.

The superiority of MLSP is due to several reasons: (1) its queuing model (polling) is more efficient, (2) it minimizes retransmission of packets, (3) it requires less time to find a new path to forward packets, (4) it decreases the congestion and, therefore, allows data to move smother. It is important to note that MLSP’s polling model allows the dynamic selection of real time and non real time packets in each cycle. Figure 7 shows results of using different polling methods in MLSP.

Figures 5 and 6 show the online delays for the same amount of time for both MMSPEED and MLSP, respectively. In MMSPEED, the delay for non real time packets is very high and extremely sensitive to nodes’ congestions. The delay is varies over time and it increases with time for non real time traffic.

Figure 8 demonstrates the power consumption for both protocols. MLSP improve the power consumption of the sensor network through the time. Initially, there is only a small difference in power consumption between MLSP and MMSPEED; mainly because, MLSP has a tagging process for all nodes in the initial phase which leads to sending extra packets. However, in the long run, this figure shows that MLSP’s power consumption is significantly more efficient. This is mainly because MLSP has an intelligent congestion control and forwarding policy.

VI. CONCLUSION This paper presented a novel algorithm to enable delivery

of sensor data within time constraints. A novel k-limited polling model is introduced in this work to improve the packet loss rate in the network. The analytical results have been verified through extensive simulations.

VII. REFERENCES [1] Kahn, J. M., R. H. Katz, and K. S. J. Pister, "Next Century Challenges:

Mobile Networking for Smart Dust," in Proceedings of the Fifth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MOBICOM '99), Seattle , Washington , USA, August 1999, pp. 271-278.

[2] I. F. Akyildiz, W. Su, Y. Sankarasubramaiam, and E. Cayirci, "A Survey on Sensor Networks," in IEEE Communication Magazine. vol. 40, no 8, August 2002, pp. 102-114.

[3] G. J. Pottie and W. J. Kaiser, "Wireless Integrated Network Sensors," Communication of the ACM, vol. 43, pp. 51-58, May 2000.

[4] J. N. Al-Karaki and A. E. Kamal, "Routing techniques in wireless sensor networks: a survey," in Wireless Communications, IEEE. vol. 11, 2004, pp. 6-28.

Figure 8: Power consumption for MMSPEED vs. MLSP

98.4

98.6

98.8

99.0

99.2

99.4

99.6

99.8

100.0

44.9 88.3 146.1 242.9 440.4 832

Time  (Second)

Power (MMSPEED) Power (MLSP)

[5] S. R. Das, R. Castaneda, and J. Yan, "Simulation Based Performance Evaluation of Mobile, Ad Hoc Network Routing Protocols," ACM/Baltzer Mobile Networks and Applications (MONET) Journal, pp. 179-189, July, 2000.

[6] E. M. Royer and C.-K. Toh, "A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks," in IEEE Personal Communications Magazine, April 1999, pp. pp. 46-55.

[7] C. Santivanez, R. Ramanathan, and I. Stavrakakis, "Making Link-State Routing Scale for Ad Hoc Networks," in The 2001 ACM International Symposium on Mobile Ad Hoc Networking and Computing (Mobihoc2001), Long Beach, California, Oct. 2001.

[8] J. Stankovic, T. Abdelzaher, L. Chenyang, L. Sha, and J. C. Hou, "Real Time Communication and Coordination in Embedded Sensor Networks," IEEE, vol. 91 No.7, July 2003.

[9] B. Karp and H. T. Kung, "GPSR: Greedy Perimeter Stateless Routing for Wireless Networks," in 6th Annual International Conference on Mobile Computing and Networking (MobiCom 2000), Boston, MA, USA, 2000, pp. 243-254.

[10] Charles E. Perkins, Ad Hoc Networking. Addision Wesley, 2001. [11] Tseng Y.C, Shen C.C, and Chen W.T, "Mobile ip and ad hoc networks:

An integration and implementation experience. Technical report, Dept. of Comput. Sci. and Inf. Eng., Nat. Chiao Tung Univ., Hsinchu,, Taiwan, ," 2003.

[12] J. A. Stankovic, "Research Challenges for Wireless Sensor Networks," SIGBED Review: Special Issue on Embedded Sensor Networks and Wireless Computing, 1(2), July 2004.

[13] T. Chen, J. Tsai, and M.Gerla, "QoS Routing Performance in Multihop Multimedia Wireless Networks," in IEEE Sixth International Conference of Universal Personal Communications, 1997, pp. 557–561.

[14] R. Sivakumar, P. Sinha, and V. Bharghavan, "CEDAR: Core Extraction Distributed Ad Hoc Routing Algorithm," IEEE Journal on Selected Areas of Communications, vol. 17, pp. 1454–1465, 1999.

[15] S. Chen and K. Nahrstedt, "Distributed Quality-of-Service Routing in Ad Hoc Networks," IEEE Journal on Selected Areas of Communications, vol. 17, pp. 1488–1505, 1999.

[16] B. Hughesand and V. Cahill, "Achievingreal-timeguaranteesinmobileadhocwirelessnetworks," in Proceedings of the Work-in-Progress session of the 24th IEEE Real-Time Systems Symposium, December 2003.

[17] B. Deb, S. Bhatnagar, and B. Nath, "ReInForm: Reliable Information Forwarding Using Multiple Paths in Sensor Networks," in Proceedings of IEEE International Conferenceon Local Computer Networks., pp. 406 – 415.

[18] T. He, J. Stankovic, C. Lu, and T. Abdelzaher, "SPEED: AStateless Protocol for Real-Time Communication in Sensor Networks," in Proceedings of IEEE International Conference on Distributed Computing Systems, 2003, pp. 46 – 55.

[19] F. Stann and J. Heidemann, "RMST: Reliable Data Transport in Sensor Networks," in Proceedings of IEEE International Workshop on Sensor Network Protocols and Applications, 2003, pp. 102–112.

[20] C. Lu, B. Blum, T. Abdelzaher, J. Stankovic, and T. He, "RAP: A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks," in Eighth IEEE Real-Time andEmbedded Technology and Applications Symposum (RTAS '02), Sept 2002, pp. 55-66.

[21] E. Felemban, C.-G. Lee, E. Ekici, R. Boder, and S. Vural, "MMSPEED: multipath Multi-SPEED protocol for QoS guarantee of reliability and. Timeliness in wireless," in IEEE transactions on mobile computing (IEEE trans. mob. comput.) , vol. 5, no6, pp. 738-754 2006.

[22] O. Chipara, Z. He, G. Xing, Q. Chen, X. Wang, C. Lu, J. Stankovic, and T. Abdelzaher, "Real-time Power Aware Routing in Wireless Sensor Networks " in Technical Report WUSEAS-2005-31, Washington University in St. Louis, . July 2005.

[23] I. Stojmenovic and X. Lin, "GEDIR: Loop-Free Location Based Routing in Wireless Networks," IASTED Int. Conf. on Parallel and Distributed Computing and Systems. Boston, MA,USA., Nov. 3-6, 1999.

[24] M. Y. Aalsalem, J. Taheri, M. Iftikhar, and A. Y. Zomaya, "Providing QoS Guarantees to Multiple Classes of Traffic in Wireless Sensor Networks," in The sixth ACS/IEEE International Conference on Computer Systems and Applications (AICCSA-08), Doha, Qatar, March 31 - April 4, 2008

[25] A. Jan, "Analysis and Optimization of Polling Models," PhD Thesis, Feb. 1992.

[26] M. Y. Aalsalem, M. Iftikhar, J. Taheri, and A. Y. Zomaya, "On the Provisioning of Guaranteed QoS in Wireless Sensor Networks through Limited Service Polling Models," in The fifth IEEE and IFIP International Conference on wireless and Optical communications Networks (WOCN2008) Surabaya, East Java Indonesia: IEEE, 2008.

[27] "http://sites.google.com/site/jsimofficial/.", visited 2008. [28] J. B. Andresen, T. S. Rappaport, and S. Yoshida, "Propagation

Measurements and Models for Wireless Communications Channels," in IEEE Communications Magazine. vol. 33, January 1995.

[29] M. Gerla, G. Pei, and S.-J. Lee, "Wireless, Mobile Ad-Hoc Network Routing," in Proceedings of IEEE/ACM FOCUS'99, New Brunswick, NJ, , May 1999.

[30] "Data sheet for the Acoustic Ballistic Module," SenTech Inc., http://www.sentechacoustic.com, visited 2008.