Comparative Analysis of Two Routing Protocols with Respect to: Network Throughput, End to End Delay and Normalized Routing Overhead

Comparative Analysis of Two Routing Protocols with Respect to: Network Throughput, End to End Delay and Normalized Routing Overhead

Kapil Saini 1, Deepak Dudeja2, Shayog Sharma3

Assistant Professor1, 2, 3

Geeta Engineering College, Naultha(Panipat)1,2,3

Abstract- To quantify the importance of a cross-layer design for better QoS support in wireless ad hoc networks, we present an analysis based on simulation. We compare CROSS LAYER Engine architecture using QoS-PAR, as a routing protocol, with the layered architecture with the AODV routing protocol , using the J-Sim simulator. We use J-Sim since it is suitable for cross-layer implementations. We used it to implement the whole CROSS LAYER Engine architecture, including the proposed routing protocol, QoS-PAR, and the LYMP protocol

Keywords: AODV, QOS, CROSS LAYER ENGINE, LVMP.

1. INTRODUCTION

   The worldwide success of the Internet, mainly determined by a layered architecture, has promoted the adoption of a similar solution for wireless ad hoc and sensor network. However, a strict layered design is not flexible enough to cope with the dynamics environments, and will thus prevent performance optimizations. It is because of the unpredictability and unreliability of the underlying wireless medium that research

   on cross-layer design in wireless ad hoc network and sensor networks has recently attracted a significant interest. A various number of research works have been conducted on different aspects of the cross-layer design. The key topractical cross-layer optimization is to find an approach abstraction of each layer and adequate coupling mechanism. According to the number of layers involved in optimizations (single, multiple or full), cross-layer design can be primarily subdivided into layer trigger scheme, joint optimization scheme, and full cross-layer design.

   1. Layer trigger scheme with strict layering

      Layer triggers-predefined signals to notify events such as data delivery failures between protocols-have been used extensively in both wired and wireless networks .

      Examples

      include the Explicit Congestion Notification mechanism, used to notify the receiver whenever congestion occurs in the network, and L2 trigger, added between the link and Internet protocol layer to efficiently detect changes in the wireless links status. The layer trigger approach provides optimization and enhancements by some vertical shortcut through the layers, keeping in background the existing protocol stack. These triggers may be initiated periodically by an adaptive control algorithm, or by network events. In

      such a trigger mechanism, even though more than two layers of the protocol stack may participate, only a specific- layer component is responsible for the optimization process while other components at upper or lower layer extract relevant parameters and offer it to the specified layer. For example, control loop based upon cross layer information shared between medium access and network layer is proposed, the physical layer transmission mode used to predict link stability and link lifetime is monitored, route rearrangement protocols is enabled to act timely and prevent route breaks and packet losses. TCP is the most dominant transport that serves as a basis for many other protocols in wired and wireless networks. However, TCPs performance in multi hop IEEE 802.11 is deteriorated by the poor end-to-end connectivity caused by the extended hidden-/exposed-terminal problem. To address these problems, cross-layer interaction of TCP and ad hoc routing protocols, such as the TCP fractional window increment scheme and the route-failure notification using bulk-loss trigger policy, is proposed in to distinguish congestion from other network events without modifying the basic TCP window or the wireless MAC mechanism.

   2. Joint optimization scheme cooperated between multiple layers

      In the case of joint optimization, usually two or three layers are involved in cross-layer optimizations (such as power control in ad hoc network and energy consumption in wireless sensor network), and QoS constraint and energy constraint are integrated. In order to meet the objectives, the QoS requirements, routing, scheduling, and power control in the different layer are jointly designed. For example, a cross-layer design framework for real-time video streaming is explored, where adaptive link layer techniques that adjust packet size, symbol rate, and constellation size according to channel conditions are used to improve link throughput. At the MAC and network layers, joint allocation of capacity and flow optimize the supportable traffic rate. Smart scheduling at the transport layer further protects the video stream from packet losses and ensures timely arrivals of the video packets without causing excessive network congestion. Knowledge of the video rate-distortion tradeoff and latency requirement at the application layer is used to select the most appropriate source rate for video delivery.

      An integrated energy and QoS aware wireless transmission system is developed for the WSN . Under the fixed or dynamic QoS constraints, the QoS requirements from the application layer, the modulation and transmission schemes in the data link layer and physical layer are jointly analyzed and integrated into a single framework, where the modulation level and transmit power of the cluster heads can be adjusted adaptively.

      Even though joint optimization scheme is concentrated more on the performances, it can produce unintended interactions among protocols, such as adaptation loops, that result in performance degradation.

   3. Full cross-layer design sharing the overall network status

   In the case of full cross-layer design, protocols that belong to different layers cooperate in sharing network-status information while still maintaining separation between the layers at the design level and use the state information flowing throughout the stack to adapt their behavior accordingly. For example, given current channel and network conditions, the physical layer can adapt rate, power, and coding to meet application requirements. The remainder of this paper is organized as follows. Section II gives a rapid survey of AODV design. Section III presents a detailed description of QoS-PAR. Section IV gives a brief overview of Cross layer engine. Before concluding, in Section

   VI, QoS-PAR over Cross layer engine is evaluated and compared with AODV over the classic layered architecture in SECTION V.

2. AODV DESIGN

   The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. Route Requests (RREQs), Route Replies (RREPs), and Route Errors (RERRs) are the message types defined by AODV. These message types are received via UDP, and normal IP header processing applies. So, for instance, the requesting node is expected to use its IP address as the Originator IP address for the messages. For broadcast messages, the IP limited broadcast address (255.255.255.255) is used. This means that such messages are not blindly forwarded. However, AODV operation does require certain messages (e.g., RREQ) to be diseminated widely, perhaps throughout the ad hoc network. The range of dissemination of such RREQs is indicated by the TTL in the IP header. Fragmentation is typically not required.

   Message Formats

   Route Request (RREQ) Message Format

   0 1 2 3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Type |J|R|G|D|U| Reserved | Hop Count |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | RREQ ID |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Destination IP Address |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Destination Sequence Number |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Originator IP Address |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Originator Sequence Number |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the Route Request message is illustrated above, and

   contains the following fields:

   Type 1

   J Join flag; reserved for multicast.

   R Repair flag; reserved for multicast.

   G Gratuitous RREP flag; indicates whether a gratuitous RREP should be unicast to the

   node specified in the Destination IP Address field (see sections 6.3, 6.6.3).

   D Destination only flag; indicates only the destination may respond to this RREQ (see section 6.5).

   U Unknown sequence number; indicates the destination sequence number is unknown (see section 6.3).

   Reserved Sent as 0; ignored on reception.

   Hop Count The number of hops from the Originator IP Address to the node handling the request.

   RREQ ID A sequence number uniquely identifying the particular RREQ when taken in conjunction with the originating node's IP address.

   Destination IP Address

   The IP address of the destination for which a route is desired.

   Destination Sequence Number

   The latest sequence number received in the past by the originator for any route towards the destination.

   Originator IP Address

   The IP address of the node which originated the Route Request.

   Originator Sequence Number

   The current sequence number to be used in the route entry pointing towards the originator of the route request.

   Route Reply (RREP) Message Format

   0 1 2 3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Type |R|A| Reserved |Prefix Size| Hop Count |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Destination IP address |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Destination Sequence Number |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Originator IP address |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Lifetime |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the Route Reply message is illustrated above, and

   contains the following fields:

   Type 2

   R Repair flag; used for multicast.

   A Acknowledgment required; see sections 5.4 and 6.7.

   Reserved Sent as 0; ignored on reception.

   Prefix Size If nonzero, the 5-bit Prefix Size specifies that the indicated next hop may be used for any nodes with the same routing prefix (as defined by the Prefix Size) as the requested destination.

   Hop Count

   The number of hops from the Originator IP Address to the Destination IP Address. For multicast route requests this indicates the number of hops to the multicast tree member sending the RREP.

   Destination IP Address

   The IP address of the destination for which a route is supplied.

   Destination Sequence Number

   The destination sequence number associated to

   the route.

   Originator IP Address

   The IP address of the node which originated the RREQ for which the route is supplied.

   Lifetime

   The time in milliseconds for which nodes receiving the RREP consider the route to be valid.

3. QOS – PAR

   A specific set of QoS parameters (delay, jitter, packet loss, etc) must be guaranteed for each real-time application. However, for most real-time applications of wireless ad hoc networks, intrinsic time-varying topological changes provides challenging issues in guaranteeing these stringent QoS requirements. To show the performance gain enabled by cross layer engine, we design a new routing protocol called the QoS-Position Aided Routing protocol (QoS- PAR). QoS-PAR differs from other QoS routing protocols by: (1) it makes use of, both, local cross-layer information and the network view for its admission control and resources reservation mechanisms and (2) it exploits the geographic position information (available from the network view) to optimize the generated routing overhead. The admission control considers two QoS metrics: the minimum required bandwidth and the maximum end to end delay. The bandwidth availability constraint takes into account: the interferences of one hop as well as carrier sensing neighbours and the intra-flow interference.

4. CROSS LAYER ENGINE

   We developed CROSS LAYER Engine according to many design principles, authors presenteda first general vision of an autonomic architecture. Cross layer engine is developed based on such vision . A CROSS LAYER Engine node is able to manage its internal behavior and its relationships with other CROSS LAYER Engine nodes in accordance with policies that humans or other nodes establish . However, cross-layer adaptations performed locally at each node may impact other competing nodes. Indeed , wireless networks features require that local cross-layer optimizations should consider the network-wide availability of resources and ' fairness' issues between nodes. Having a network view enables a node to evaluate its local status against the average network status. This allows it to take the right local optimizations by considering real network resources. Moreover, the network view is required to implement the autonomic feature as it denotes the capability of nodes to perceive their context, and to react to the network changes. To construct a network wide view, the nodes local views are exchanged using the Local View Management Protocol (LVMP). LVMP adopts a selective broadcast approach, where redundant nodes rebroadcasts are minimized , while assuring that every node receives the local view of every other node of the network.

   (a) J sim simulator

   Jmsim is a simulator written in the C language, intended to provide ad-hoc networking simulation for evaluation of an ad-hoc network reputation system. Jmsim was developed in a Linux environment, using the gcc compiler, along with other freely available GNU tools. The objective of Jmsim is to provide a simulation of the operation of an ad-hoc network, whose characteristics are driven by the guiding research project. This simulation will be used to aid in testing the effectiveness of a reputation system for an ad- hoc network. The simulator will be used to obtain metrics to judge the suitability of the reputation system for the context of an ad-hoc network. The metrics to be measured include the ratio of failed transmissions to total packets sent, average hopcount for transmissions, the degree to which nodes with good behavior have high reputations, and possibly others. The requirements for the simulator will be derived from the research project, in meetings with Professor Zhang. The meetings will be where the properties of the simulator are determined. Specifically, the necessary properties and capabilities of network nodes and the general design of the simulator will be determined by the associated research project. Design and implementation will be carried out after and along side research work aimed at determining the behavior of nodes in the reputation system being evaluated, and by the author.

   A key goal of Jmsim is to accurately model the essential characteristics of the ad-hoc network needed to provide an environment in which to test the reputation system being created in the larger research project. The simulator must model network nodes with unique identifiers, a set of appropriate buffers, battery constraints, and a strategy for handling traffic relay requests from other nodes. Various types of messages must be modeled for

   establishing the topology of the network, managing agreements and finally transmitting data packets.

   J sim must model selfish nodes to simulate the effect of uncooperative nodes within the network. These nodes hamper the ability of the network to provide routed packet delivery. The simulator must be capable of modeling the effect of various percentages of selfish nodes in the network on the ability of nodes to obtain traffic relay service.

5. PERFORMANCE EVALUATION

   1. Simulation set up

      We used it to implement the whole CROSS LAYER Engine architecture, including the proposed routing protocol, QoS-PAR. The number of mobile stations varies from 10 to 60 nodes. The nodes were placed randomly onto the plain and moving in an area of 600m x 600m according to the random way point mobility model with a speed of 2m/ s. Every node operates at IEEE 802.11b MAC layer with a transmission rate of 11 Mbps. We deactivate RTS/CTS mechanism. The number of admitted QoS flows is varied from 5 to 15. Each flow consists of a constant bit rate (CBR) source with 512byt e UDP packet and 62.5ms packet generation period to simulate audio streaming applications. The maximum end to end delay is fixed to 35ms.

   2. Simulation result

   We study the influence of the network size on many performances metrics, such that network throughput,end to end delay, normalized, routing/architecture overhead.

   • Network throughput Figure 1 compares throughput performance of QoS-PAR and AODV for varying network sizes and number of connections. Results show that QoS- PAR was capable of establishing and maintaining routes, for all admitted flows, with nearly the desired throughput of 64 Kbps. The average throughput reported was at least 93% of the desired throughput of 64 Kbps, regardless of the network size and the number of established QoS flows. Recall that, for QoS-PAR, the delay constraints of admitted flows are respected . Further, the throughput performance of QoS-PAR is slightly sensitive to the number of established flows. The observed slight throughput degradation

     Fig 1. Network throughput

     is due to the increased competition for bandwidth, causing occasional route breakdowns . When routes breakdown, intermediate nodes take more time to rebuild routes with sufficient available bandwidth; while source flows are still active and send packets. In this case, with 15 established flows, more packets are lost while they are waiting for routes to be rebuilt. However, QoS-PAR was always capable of achieving a good throughput, thanks to its admission control mechanism, which avoids the occurrence of congestion. In contrast, Figure 1 shows that the throughput performance of AODV over the layered architecture degrades rapidly with increasing network sizes. This comes as no surprise since AODV does not rely on any congestion prevention mechanism. Hence, as more flows are established, routing and data traffic increases, leading to more collisions and packet losses, which trigger more retransmissions. Such retransmissions have a direct impact on the throughput, especially when the network size increases.

   • End to end delay

     Figure 2 plots the average end-to-end delay for both QoS- PAR and AODY. Obtained results show that QoS-PAR outperforms AODV particularly when the network size and the number of established QoS flows increase. For example, for a network with 20 nodes, QoS-PAR achieves an average end to end delay of 2.68ms, while AODV achieves 66.28ms . The difference in the delay performance of both protocols increases with increasing network sizes and number of QoS flows. Indeed, during the route discovery, QoS-PAR maintains an admission control mechanism with two QoS constraints (the maximum delay and the minimum required bandwidth) , followed by a bandwidth reservation. Hence admitted QoS flows have the guarantee that the bandwidth will be available as long as the route is valid, while respecting the delay constraint.

     When data packets begin to violate the delay constraint, the QoS loss notification is triggered followed by shutting down routes if QoS-PAR fails to rebuild routes respecting QoS constraints. With QoS-PAR, the delay slightly increases when increasing the number of admitted flows for the same network size. Indeed, when the available bandwidth is shared between more flows, more time is spent to establish or repair routes having sufficient available resources. However, for AODV, since it uses the flooding mechanism for route discovery, the amount of sent routing packets increases as the network size and the number of QoS flows increase. As a result, the collision probability increases, which leads to increasing, both, the period of time to establish routes and the amount of data retransmissions. Consequently, the average delay increases too. Each simulation is running for 1000s . Each with a different seed entry and different random mobility scenarios. Results were obtained by averaging 10 simulations. Note also that as in , the delay estimation utilizes a constant processing time in the node equal to 3ms. In addition, a first order (£ = 1 i) variance correction is applied, and the optimum forgetting factor (X) is fixed to 0.2.

     Fig 2. end to end delay

   • Normalized routing overhead

   This metric is used to quantify the routing overhead. It is defined as the ratio between routing packets and data packets respecting the delay constraint. Figure 3 clearly shows that QoS-PAR outperforms AODV for all network size and number of established flows with a generated overhead is up to 50% lower. Specifically, using a network size of 40 nodes and 5 established QoS sessions, AODV sends 4 routing packets (on the average) to receive one data packet respecting the delay constraint, compared to 1.77 for QoS-PAR. This number grows when increasing the number of established sessions (that is 7 sent routing packets to receive one data packet) and the network size. With AODV, the obtained results increase much more rapidly than for QoS-PAR, as the network size increa ses. Indeed, the flooding technique used in AODV consists of broadcasting a received route request to all neighbors.

   While for QoS-PAR, obtained results are a consequence of the admission control mechanism and its geographic aspect. Both mechanisms assure load balancing belween QoS-PAR nodes . Specifically, every node outside the destination search zone , would not participate in the route discovery. Accordingly, the number of nodes participating in the route discovery is reduced, reducing hence the amount of re-broadcasted routing packets. Moreover, QoS- Pperforms an admission control with a bandwidth constraint, so it prevents route request packets from being propagated through heavily loaded nodes. This reduces congestion and interference caused by redundant routing packets transmissions. All these factors keep the QoS PAR overhead lower than that generated by AODV even if the number of connections and the network size increase

   Fig 3. Normalized overhead

6. CONCLUSION

QoS-PAR over CROSS LAYER Engine is compared with AODV over the layered architecture with respect to numerous metrics. QoS-PAR significantly outperforms AODV with respect to all metrics like: (i) Network Throughput , (ii) End to End Delay

(iii) Normalized Routing Overhead. Further, QoS-PAR performance was almost insensitive to network size and number of admitted flows, as compared to AODV whose performance degrades significantly when the network size or the number of flows are increased. If we compare QoS- PAR over CROSS LAYER Engine with AODV over the layered architecture, then the performance of Position Aided Routing Protocol was not sensitive to network size and number of flows that are admitted but the performance of AODV degrades significantly when the network size or the number of flows are increased.

REFERENCES

1. V.Srivastava, M.Motani. "Cross-Layer Design: A Survey and The Road Ahead" . IEEE Communications Magazine, Volume 43, Issue 12, Page(s): 112 – 119, Dec. 2005.

2. J-Sim simulator: http://www.j-sim.org

3. hakeres,E.M.Belding-Royer. "Determining Intra-Flow Contention along Multihop Paths in Wireless Networks." Proceedings of 1st IEEE

   roadnets Conference, San Jose, CA, October 2004.

4. A.Sobeih, W.Pcng Chen, J.e. Hou, L.Kung, N.Li, H.Lim, H.Ying.Tyan, HZhang. "J-Sim: a simulation and emulation environment for wireless sensor networks". IEEE Wireless Communications Magazine, vol. 13, num. 4, pp. 104-119, August 2006.

5. L. Luo, M. Gruteser, H. Liu, D. Raychaudhuri, K. Huang, S. Chen. "A

   QoS routing and admission control scheme for 802.11 ad hoc networks". In: Proceedings of D1WANS, Los Angeles, USA, 2006, pp. 19-28.

6. S. Lohier, S. Senouci, Y. M. Ghamri Doudane, G. Puj011e. "A reactive QoS Routing Protocol for Ad Hoc Networks". European Symposium on Ambient Intelligence (EUSAI'2003), Eindhoven, Netherlands, November 2003. Lecture Notes in Computer Science, Springer Verlag.

7. R. Madan, S. Cui, S. Lall, et al., Modeling and Optimization of Transmission Schemes in Energy- Constrained Wireless Sensor Networks, IEEE/ACM Transactions on Networking, vol. 15, no. 6, pp. 1359- 1372, Dec. 2007.

8. L. Gavrilovska. Cross-Layering Approaches in Wireless Ad Hoc Networks, Wireless Personal Communications, vol. 37, no. 3, pp. 271- 290, May 2006.

9. X. Shugong and T. Saadawi, Does the IEEE 802.11 MAC Protocol