Discussion

Comparing to AODV, AOMDV performs well in end-to-end packet delay, packet delivery rate, and routing overhead. Since AOMDV maintains multiple paths to each destination, it always has alternate paths without re-generate RREQ message. This greatly reduces the frequency of global route discovery while providing fault tolerance to the network.

Consider the nature of WSNs, each sensor node has limited resources and will be deployed in an unstable environment. Design a reactive routing protocol with fault tolerance is necessary and, at the same time, consuming less resources of the networks and the sensor nodes. Obviously, AOMDV is more outstanding than AODV in all aspects if we want to develop a reliable routing protocol. Although AOMDV maintains multiple paths for each destination, it only uses single path to forward the packet. In other words, it provides fault tolerance to the node failure and link failure but not reliability to the data.

In the next chapter, we propose two reliable routing protocols for wireless sensor networks called SOMDV-R and AODV-R. The former is based on AOMDV which provides reliability to the data packets while achieves minimum routing overhead; the latter is modified from AODV in order to provide reliability to the data packet.

Chapter 3.

Reliable Routing Protocols in Wireless Sensor Networks

In this chapter, we propose two reliable routing protocols in wireless sensor networks called Sensor On-demand Multi-path Distance Vector Reliable Routing Protocol (SOMDV-R) and Ad hoc On-demand Distance Vector Reliable Routing Protocol (AODV-R). The former is discussed in Section 3.1; the latter is discussed in Section 3.2.

3.1 SOMDV-R

3.1.1 Protocol Overview

SOMDV-R is modified from AOMDV in order to provide reliability to the data forwarding. We define the reliability as “end-to-end successful transmission probability”. SOMDV-R shares several characteristics with AOMDV. They are both based on “on-demand and distance-vector” concept, hop-by-hop routing procedure, and multiple paths maintenance in routing table. The main difference lies in the estimation of reliable degree of each path and the data packet forwarding mechanism.

Link quality of each node is required for SOMDV-R to calculate the path reliability.

This information can obtain by hello drop rate in routing layer, beacon loss rate in MAC layer, or SNR ratio in physical layer…etc.

The goal is to design a protocol which is able to calculate the path reliability, and forward the packet according to the importance of each packet. Determine the importance of the generating data relies on the information-awareness technique; we skip this portion since it is out of the scope of this thesis. In order to maintain this

necessary information, using extra field in control packet header is needed. As we mentioned before, there is a trade-off between overhead and reliability; however, minimum overhead is also expected.

3.1.2 Routing Table Structure and Terminology

A. Routing Table Structure

The routing table structure is modified from AOMDV with only an extra field called “path estimation (PE)”. It is a reference value of the reliability of this path and plays an important role in data packet forwarding. Fig. 3-1 shows the content of the routing table. Each field in the routing table is described in the following subsection.

B. Terminology

This subsection defines some terminologies used in SOMDV-R:

(1) Sequence Number (Seqno): It is a monotonically increasing number related to each destination in routing table. Higher sequence number means the relatively fresher information. It is updated whenever it receives a fresher control packet or it decides to initiate a route discovery for the destination.

0~ 31 32~ 63 64~ 79 80~ 95 96 ~ 127 128~ 159 160~ 223 224~ 287

Figure 3-1 Routing table structure of SOMDV-R

(2) Advertised Hop Count (Adv. HC): It is the maximum hop count among all paths in each route, i.e. Adv. HC = MAX (HC1, HC2 …). It is used to determine the Route advertised rule and Route acceptance rule to avoid looping path as we discuss in Chapter 2.

(3) Reliability Demand of the source(RD_s): This parameter indicates the demand for the data delivery rate of the source. It is a value between 0 and 1 which representing the importance of the data. Determining the RD_s in each data packet is the technique about information-awareness which is out of the scope of this paper. We manually assign the RD_s in each data packet. By setting this value in the data packet header, SOMDV-R would forward this data packet according to its demand.

(4) Reliability Demand of the intermediate nodes(RDi): Since RDs would be updated in each intermediate node. We define this updated value as RD_i. (5) Link Quality (Qij): It is the link quality between node i and j. Link quality is

an essential information for estimating the path reliability. It is a value between 0 and 1 which is obtained by hello messages received from each neighbor in a time interval. Higher link quality means the link is better and more suitable for transmission. Link quality between node i and j can be calculated by: , where Hij is the number of hello messages node i has received from neighbor j and S _ij = number of hello message node i should receive from neighbor j in a time interval.

Figure 3-2 Calculation of PE and HC in each hop

(6) Path Estimation (PE): PE represents the reliable degree of the path. It is an estimating value between 0 and 1. The path with higher PE value means that it has higher end-to-end successful transmission probability. It is updated in each intermediate node as shown in (2) and Fig. 3-2.

PE(A→D) = QAB × QBC × QCD (2)

3.1.3 Protocol Operations

SOMDV-R consists of three components, i.e., route discovery, route maintenance, and data packet forwarding. The following subsections describe the operations of each component.

A. Route Discovery

In AOMDV, route discovery process is initiated whenever a traffic source node having a data packet to send with no valid path available in its routing table.

SOMDV-R initiates a route discovery if the source node has no path in the routing table or has paths that can not satisfy the packet’s demand. The traffic source then broadcasts a RREQ destined to the sink with initial hop count equal to 0 and path estimation equal to 1. Any intermediate nodes receiving this RREQ will update the hop count and path estimation in the control packet header, i.e., increment the hop count by 1 and multiply the PE by the link quality with the upstream node as shown in Fig. 3-2. After that, the node will form a reverse path toward the source node with the PE copied from the control packet header. This PE value means the successful transmission probability from current node to the traffic source.

Figure 3-3 Sending Route Reply

As shown in Fig. 3-3, any intermediate nodes receiving the RREQ will send an RREP back to the source via the reverse path if it has one or more valid and unexpired paths to the sink node (such as node C has a valid path to the sink with hop count equal to 2, PE equal to 0.8, and next hop D as shown in Fig. 3-3), the RREP represents a forward path that was not used in any other RREPs for this RREQ;

otherwise, it simply re-broadcasts the RREQ if it has not previously forwarded any other copy of this RREQ(such as A, B, and D).

When the sink node receives a RREQ, it simply forms a reverse path as the intermediate nodes do and generates a RREP in response to every RREQ which arrives at the source via a loop-free and node-disjoint path. Any intermediate nodes receiving an RREP will update the packet header including hop count and PE value, update the routing table if necessary, and then forms forward path to the sink. After that, it will forward the RREP if there are any reverse paths that have not previously used for this route discovery; else, it simply discards the RREP.

After the route discovery process, the source node may receive multiple RREPs sent from disjoint paths. All the nodes involving in this route discovery process will also update the forward and reverse path information.

B. Route Update and Maintenance

SOMDV-R adopts the same route update and maintenance rules in AODMV.

Each path has an expiration timeout field for the default lifetime of a path. The path will be purged if the timer has expired and the route will be marked as “DOWN” once all the paths are expired. Route update is invoked when a node receives a fresher control packet (including RREP, RREQ, and RERR) or receives a control packet with a shorter hop count and better PE to the sink node(including RREQ and RREP). Once

will be marked as “valid/invalid”, depending on the content of the control packet.

The local connectivity can be maintained either by link layer mechanisms or by routing layer mechanisms. In link layer protocols such as IEEE 802.11, each time a node receiving a CTS or ACK from a neighbor is able to confirm the connectivity. In routing layer, by proactively sending Hello messages to all immediate neighbors, SOMDV-R is able to maintain the local connectivity with each neighbor. Once a node can not receive any Hello messages from a specific neighbor for (ALLOWED_HELLO_LOSS × HELLO_INTERVAL), it will purge the neighbor from the neighboring table and declare the link as “broken”.

Depending on the distance of the broken link to the sink, route maintenance has two mechanisms:

(1) Local route repair mechanism is invoked if the intermediate node with a broken link is closer to the destination than the source node as shown in Fig.

3-4. The intermediate node D will buffer all the packets destined to the destination F and initiate another route discovery process. After receiving RREPs, the intermediate node D first updates the path information and then forwards all the buffered packets.

Figure 3-4 Local Route Repair

F igure 3-5 Forwarding RERR

(2) In Fig. 3-5, when the last path to the sink node of node A breaks and A can not initiate local route repair mechanism, i.e., the broken link is closer to the source than the destination, it will purge the route and locally broadcast a RERR to all its one-hop neighborhood (node E, B, and source). Each of its neighbors receiving the RERR will also purge the route if the last path to the destination does no longer exist and continue to forward the RERR to its immediate neighbors (node E). All the nodes having purged the route have to initiate another route discovery process if still needing the route to the destination.

C. Data Packet Forwarding

In the previous subsection, SOMDV-R establishes the basic knowledge of each path by route discovery process. Comparing to AODMV, data packet forwarding is more complex since the goal of SOMDV-R is to achieve reliability. In AOMDV, data packets are simply forwarded if there is at least one path to the destination; in SOMDV-R, we have to make the forwarding decision according to the relationship between RD and PE before we forwards each data packet.

of channel error rate is calculated by: path i. Once a sensor node senses an event according to the query from the sink, it will generate a data packet and assign a reliability demand (RDs) value to the packet header before sending it. The RD_s and RD_i value plays a key role in taking the forwarding decision. The following Table I summarizes the cases when forwarding data packet.

Each forwarding node will first find the path with maximum PE value in the routing table and compare it with the RD value. If the PE value is bigger than the RD value, it means this path is suitable for forwarding this packet as the case 1 in Table I.

So SOMDV-R uses single path mode to forward it, as the solid line shown in Fig. 3-6 (the dotted line means that it is an alternate path with PE2). If single path is not enough for the packet’s demand, SOMDV-R will forward the packet by multiple loop-free and node-disjoint paths, which means duplicating the packet and sending those duplicate packets via multiple paths, as shown in Fig. 3-7. The number of paths needed for this packet can be obtained from formula (4) and the upper bound of the

Table I. Forwarding Decision of SOMDV-R

Case Destination Reliability Action

1 Available Satisfied Forwards the packet directly 2 Available Unsatisfied Keep forwarding 3 Unavailable --- Generate RREQ

4 --- RDi>1 Keep forwarding

Figure 3-6 Forwarding packets using single path

Figure 3-7 Forwarding packets using multiple paths.

number of multiple paths used to forward a packet is defined as MAX_Paths.

In Case 2, if the number of paths required to forward the packet exceeding MAX_Paths or if the number of paths in the routing table is not enough to satisfy the packet’s demand, SOMDV-R would reset the RDi in the packet’s header as 0 and forward the packet via these multiple paths in order to increase the possibility of packet reaching the sink. In Case 3, the source node initiates the route discovery process if the route to the sink is not available.

Before forwarding the data packet, each intermediate node should adjust their hop count and RD value according to the reliability that the source expects it to provide from current node to sink as (5) and (6):

Hop Count = Hop Count + 1 (5) / Qij

RD=RD (6)

,where Qij is the link quality between the upstream node and the current node. In some quite unstable networks, the RD_i value may be over than 1 after updating if the packet has just traversed from a bad link, such as Case 4 in table I. Under this circumstance, SOMDV-R will never find any paths available for this abnormal RD, the better solution would be reset the RDi as 0 and forward it via multiple paths.

If a node decides to use multiple paths to forward the packet, it should reassign the RDi value in each duplicate packet’s header. The main idea is to let the paths share the reliability demand and the paths with higher PE value responsible for more reliability. Fig. 3-8 shows an example if a node decides to use two paths with PE1=0.6 and PE₂=0.3. After duplicating the packet, the RD_i value of each duplicate packet should be adjusted to RDi1 = 0.58 and RDi2= 0.29 according to the ratio of these two paths. The following shows a simple calculation of this procedure:

Figure 3-8 RD adjust mechanism

3.2 Modified Version of AODV: AODV-R

In this section, we modify the AODV routing protocol based on the mechanism of SOMDV-R. The only difference lies in the number of paths maintained for each route. The route discovery process of AODV-R is basically the same with SOMDV-R, including the flooding the RREQ with hop count and path estimation parameters.

Each intermediate node having fresher route can send RREP back to the source. Once the first RREQ has been propagated to the sink, the sink will generate a RREP back to the source. The other duplicates of the RREQ would simply be dropped at the sink.

The source could forward the packet if it has route to the sink and the PE value for the route is not less than the RD value in the data packet header; else, after RREQ_RETRY_TIMES, the packet would be dropped. In each intermediate node, if the route is not available or the route is not reliable enough, it would simply forward the packet via the unreliable path. We use AODV-R to compare with SOMDV-R about the overhead and the packet delivery ratio in the simulation.

Chapter 4.

Performance Evaluation

In this chapter, we evaluate our reliable routing protocol SOMDV-R, AOMDV, and AODV-R using ns-2 simulator [14]. The main objective is to observe the packet delivery rate of these three protocols under different channel error rate. Also, we show the relative overhead of forwarding a packet, the ratio of using single path, multiple paths, and no path.

4.1 Simulation Environment

We use a simulation tool based on ns-2 version 2.1b4a. Besides, IEEE 802.11 distributed coordination function (DCF) is used as the MAC layer protocol. We use the Lucent’s WaveLAN radio model with the modified transmission range 150meters.

50 sensor nodes are randomly deployed in a 670m×670m square area. We set the sink node as the 51th node and all the nodes are static. Channel error rate is normally distributed between 0 and e_max across the area. It is used to simulate the channel error while receiving any types of packets and all links are bi-directional.

The Hello interval is defined as 0.5s which means that each node would locally broadcast two Hello messages in every second. We set the ALLOWED_HELLO_LOSS as two, i.e., if a node is unable to receive two continuous Hello messages from its neighbors within 2*Hello interval, it will remove the corresponding entity from its neighboring table.

We use 10 ~50 CBR connections with different RDs in the simulations. These connections will last for 5 seconds with packet generating rate 0.5 pkt/s. Data packets

have a fixed size of 512 bytes. Each simulation is run for 60 seconds with the initial 5 seconds taken as the warm-up period to establish the link quality table. All connections start its traffic after warm-up. In each routing table entry, the number of paths maintained in each route is restricted to five. We set the MAX_Paths as two in our simulation.

4.2 Performance Metrics

We primarily consider the following four metrics:

(1) Packet delivery ratio (PDR): PDR is the end-to-end successful transmission probability calculated by the number of data packets received by the sink node dividing by the number of data packet generating in source node. PDR also represents the attained reliability in the protocol.

(2) Routing overhead: The control packets used in route discovery process and route maintenance such as RREQ, RREP, and RERR are routing overhead to the protocol. We define the routing overhead as formula (7):

Routing overhead = ^control

control data

P

P +P (7) , where P_control represents the amount of the control packets and P_data represents the amount of the data packets

(3) Mean latency: it is the average end-to-end latency for each successful transmission as formula (8):

T = T_RD + T_PD + TQD (8) , where TRD, TPD, TQD represent route discovery time, propagation delay, and queuing delay, respectively. When using multi-path, we consider the first duplicated packet with successful delivery only.

4.3 Simulation Results

4.3.1 Packet Delivery Ratio

Fig. 4-1 shows the PDR with varying channel error rate. We use 10 CBR connections without specifying packets’ RD_s. In SOMDV-R, data forwarding is achieved by using single path without specifying any RDs. In order to show the impact on PDR of a specific routing protocol, we use 10 connections which is a moderate load for the network to prevent the occurrence of buffer overflow. Since SOMDV-R is modified from AOMDV, with no reliability demand, our protocol has almost the same performance with AOMDV. From Fig. 4-1, it is obviously that the multiple path maintenance is more outstanding than single path maintenance in PDR.

They both increase the PDR 10% more than AODV-R in average. The difference increases with the raising of channel error rate.

Figure 4-1 PDR with no RDs

In Fig. 4-2, we simulate SOMDV-R and AODV-R with RD_s equal to 0.5 and 0.9 for each connection. Comparing to AODV-R, SOMDV-R has better packet delivery ratio due to multiple paths. For the curve of RD_s equal to 0.9 which is a quite high reliability demand, PDR of AODV-R drops suddenly if the channel error rate is larger

In Fig. 4-2, we simulate SOMDV-R and AODV-R with RD_s equal to 0.5 and 0.9 for each connection. Comparing to AODV-R, SOMDV-R has better packet delivery ratio due to multiple paths. For the curve of RD_s equal to 0.9 which is a quite high reliability demand, PDR of AODV-R drops suddenly if the channel error rate is larger