Dynamic source routing (DSR) is an on-demand reactive routing protocol designed to restrict the bandwidth consumed by control packets, by eliminating the periodic table update messages required in the table driven proactive approach. It uses source routing instead of relying on the routing table at each intermediate node. Route construction phase establishes a route by flooding route request (RR) packets in the network. An intermediate node, upon receiving a RR packet, checks the sequence number on the packet before forwarding it. The packet is forwarded only if it is not duplicate RR. The sequence number on the packet is used to prevent loop formation. RR packet updates itself with traversed nodes address, which will facilitate in path construction. The destination node, on receiving a RR packet, responds by sending a route reply (RP) packet to the source by using traversed addresses. Thus source will have the address to destination through intermediate nodes. Even though DSR protocol performs well in static and low mobility environment, the performance degrades rapidly with increasing mobility. To enhance the performance, we use modified DSR and call it as Mobility and QoS aware Anycast Routing in Mobile ad hoc Networks (MQAR). Our protocol (MQAR) works better under dynamic and high mobility environment, since we include stability model to identify more stable nodes, congestion model to check traffic on the channel dynamically and link expiry model to check duration of the link, so that selected path will stay for longer duration in anycast routing.
We modify Dynamic Source routing (DSR) by applying parameters supported by stability, congestion and route expiry models in route establishment phase. Routing considers the parameters at each node for route request propagation and path(s) finding between client and servers. It also uses routing information cache (RIC) at each node that facilitates route finding by providing path information from the existing database. RIC will reduce route request propagation overheads. This section presents databases, route request (RR) packets, route reply (RP) packets, route error (RE) packets, and RIC. Each node maintains a link data base which contains destination servers id, next hop node id, distance from the node to anycast servers, Where C1, C2 and C3 are client machines that generate anycast packets. I1 to I9 are the intermediate nodes and S1 to S3 are server machines that have the same anycast address A1. Connectivity of the network indicates distance on each link.
RR, RP and RE Packets
To create an anycast shortest route in a Wireless network from client to server, various control packets such as route request (RR), route reply (RP) and route error (RE) packets are used. In this section, we describe some of the control packet components required to create stable and non congestion paths. Some important fields of RR packet are as follows.
Client address: It is the address of the client from where the path needs to be established to one of nearest servers in the network.
Server address: It is the address of the server where packet has to be forwarded. It helps in accommodating the route created by RR packets and RP packets.
Next hop address: It is the address of the neighbor connected with in the transmission range for propagating RR.
The field is updated at every hop Sequence number: The sequence number assigned to every packet delivered by the client uniquely identifies the packet. It is used to avoid multiple transmission of the same RR packet.
Route record: It has the addresses of the visited previous nodes recorded in visiting sequence. This information will be used during the return journey to RR packet originator by corresponding RP packet.
Number of hops: It is the number of hops travelled by RR packet to reach the destination server, which is updated by one at every hop.
Time to live: It is the number of hops RR packet can travel. The field is decremented by one after every hop
The packet format for anycast routing is almost similar to RR packet with few changes in RR packet. The changes in RR packet to convert it into RP packet are as follows: When RR packet reaches the server from the designated client, client address and server address are interchanged, RR packet contains the list of nodes along the route it has travelled (route record is reversed). RP packet from the server is sent to client on a route given in its route record. Next hop address will be picked from the route record at every hop. RE packet is generated when a node is unable to send the packets either due to link failure or congestion. Some of the fields of this packet are client address, server address, route record and sequence number. Whenever a node identifies link failure, it generates RE packet to either client or server. If link failure occurs in forward journey of a RR packet (from client to server), RE packet is sent to the client. On the other hand if link failure occurs during journey of the RP packet (from server to the client), RE packet is sent to the server. Intermediate nodes receiving RE packet updates their route information cache by removing paths having failed links and also examine its route cache for an alternate path. If an alternate path is found, it modifies the route, otherwise forwards RE packet to server.
Routing Information Cache (RIC)
RIC is used to store the latest routes to servers learned through RR and RP packets. This avoids unnecessary route discovery operation each time when a data packet is to be transmitted. This reduces delay, bandwidth consumption, and route discovery overhead. A single route discovery may yield many routes to anycast server, due to intermediate nodes replying from local caches. When client node learns that a route to server node is broken, it can use another route from its local cache, if such a route to server exists in its cache. Otherwise, client node initiates route discovery by sending a route request. Use of RIC can speed up route discovery and it can reduce propagation of route requests. The contents of RIC will be removed at every periodic interval.
Anycast address: It is the anycast group address attached to different servers where packet has to be forwarded from required client (extracted from RP packet server address and route record). It helps in accommodating the routes for RR packets.
Path information: It represents a complete path (a sequence of links).
RET: It is the minimum value of LET of all intermediate nodes selected from client to the server.
Hops: It is number of hops required to reach the server via the path.
Recorded Timestamp: It contains the time at which RIC is updated by using RP packet.
3.1 Node Stability
The stable nodes are necessary in forwarding group to provide better packet delivery services. Node stability in terms of movement around its current position gives us an idea of stationary property of node. Node stability metrics are used to identify stable nodes in a path for forwarding packets from a source to anycast node. Two metrics are identified to represent node movement stability as the quality of connectivity: self stability, and neighbor nodes stability. The steps in finding the stability of a node are as follows. (1) All the nodes in wireless networks find the self movement stability, i.e, node movement relative to its previous position and, (2) find neighbor node movement stability of all the nodes in wireless networks by considering the neighbors self stability. Each node in a wireless networks will compute the node movement stability factor based on self and neighbor nodes movement stability. Self movement stability It can be defined as the node’s movement with respect to its previous position. A node is said to be stable if its movement is within given fraction of its transmission range. Consider the scenario, where a node with transmission range ‘r’ moves from position (xr ;yr) to(xn;yn) in a given time window by a distance ‘d’. When a node moves from its previous position, its movement stability relative to previous position keeps varying, and the
Distance of movement of a node (dti) in a time window ‘t’ can be measured by using given Eq
Based on the movement of the distance at every time window, the self stability metric (Ns(t)) can be estimated as given in Eq (Ns(t)) varies between 0 and 1. When the movement distance (dTi) of a node increases, the self stability value will decrease. For the requirement of the higher degree of movement stability, ‘r’ can be replaced by ‘r/2’ or ‘r/4’ or ‘r/8’ etc.
There are some limitations in calculation of self-stability due to the influence of GPS accuracy and resolution. Better results can be estimated with higher accuracy and resolution in GPS. This work assumes that GPS accuracy and resolution is limited to 95% and 7.8 m, respectively.
Neighbor node movement stability (Ns(t)) It can be defined as a node’s connectivity to its neighbor in terms of neighbor’s self-movement stability. Each node accumulates connectivity information and signal stability of one hop neighbors, and maintains a neighbor list.
The degree of a node ‘n’ is represented as number of links (or nodes) connected to it, and is denoted as ‘ND’. The neighbor node stability of a node (Ns(t)) with respect to neighbors at time ‘t’ can be expressed as
Where a is the weight age factor (lies between 0 and 1), Nsðt1Þis the recent neighbor node stability, and (Ss(t)) is the self-stability of neighbor node ‘i’. We are using the stability model to select nodes with higher self and neighbor stability values such that the selected path through such stable nodes stays for a longer duration. Node movement stability factor Ns(t): It defines the stability of a node associated with self and neighbor node movement stability in a given time interval ‘t’. This can be expressed as
The weight factor b denotes the relative importance of the quantities Ss(t) and Ns(t) which lies between 0 and 1. Indicate the weight age given to the terms in Ns(t) and Ns(t), respectively. The values chosen for them is between 0.6 and 0.7, since they have yielded better results in extensive simulations. In Ns(t), higher weightage is given to the first term, considering the fact that nodes are mobile and it is likely for a node to move with respect to its earlier position. Similarly, in Ns(t), higher weightage is given to first term. Stability factor of a node is computed only if self-stability and neighbor stability is greater than zero. Thus our scheme extracts the highly stable nodes and adjusts the network topology for routing restricted to stable nodes so as to reduce the probability of link failure.
3.2 Congestion Model
To address the congestion problem in WIRELESS NETWORKS, following two models are proposed: channel load model and buffer occupancy mode
Channel load Model:
Congestion in a network is measured based on rate of change in channel load (CL). This can be represented in Eq where T busy and T idle are busy and idle times of the channel measured in seconds in a given time window
As channel load increases, congestion in the network increases. Thus change in rate of channel load in a particular time window indicates change in congestion level. The change in channel load with respect to time can be represented by means of slope as min dicating either rise or fall in the congestion level.
Based on the A vem, Channel Congestion Factor (CCF) in a time window t can be interpreted by comparing it with allowed threshold value as decided by the administrator as given in Eq. The value of the CCF(t) varies between 0 (no congestion) and 1
Link Buffer Occupancy: (LBO) Model: A node should maintain an average buffer level to avoid congestion and frequent link failures. LBO is defined as the ratio of queue occupancy (QOCC) by a link to maximum queue size (QSIZE) of the buffer in a given time window at intermediate node
The average of intermediate node’s buffer occupancy (Ave_LBO) by all associated direct links of a node is given by
As similar to CCF(t), we estimate the Buffer Congestion Factor (BCF(t)) based on buffer occupancy in a given time window t. Our routing scheme uses CCF(t) and BCF(t) and computes link congestion factor (LCF) for QoS based applications to find route from a client to the server. It indicates the congestion of the direct link between intermediate nodes. LCF(t) (a normalized value) given in Eq helps in selecting non congested nodes with sufficient buffer capacity for routing in anycast networks. The smoothed value of LCF(t) denoted as CF(t) is given in Eq.(11). The weight factors wandð1wÞ denote the relative importance of the quantities of LCF in current and previous time windows.
Lower value of CF(t) denotes lesser congestion at a node.
3.3 Link/ route expire time
We propose the Link Expiration Time (LET) Model to reduce the data packets loss due to link failures. LET defines the lifetime of a link between intermediate nodes. In most existing protocols, a mobile host will keep using the route until the link is broken. In this model, we use a proactive method of finding the duration of time that two neighbors remain connected if the speed, direction, and radio propagation range are known. Predicting the LET along each hop on the route will facilitate the prediction of Route Expiration Time (RET). RET is defined as life time of route between client and server.
We modify Dynamic Source routing by applying parameters supported by stability, congestion and route expiry models in route establishment phase. Routing considers the parameters at each node for route request propagation and path(s) finding between client and servers. It also uses routing information cache at each node that facilitates route finding by providing path information from the existing database. RIC will reduce route request propagation overheads. This section presents databases, route request packets, route reply packets, route error packets, and RIC
Anycast QoS based path creation involves two phases; a request phase and a reply phase. Request phase invokes route discovery process to find routes to anycast servers through stable and non-congestion intermediate nodes. Reply phase involves updating of RIC and conforming the routes found in request phase. Stable nodes are the one who satisfy stability criteria and non-congestion requirement of an application, based on our stability and congestion models. These stable and Non-congestion nodes act as intermediate nodes and help to create anycast routes from client to server.
Additionally, NS-2 supports several algorithms in routing and queuing. LAN routing and broadcasts are part of routing algorithms. Queuing algorithm includes fair queuing, deficit round robin and FIFO.
Energy Consumption Ratio:
End-to-End Delay Ratio
Energy Efficiency Ratio
Packet Delivery Ratio
Average Throughput Ratio
In future, improve this process security as digital signature security frame work and our proposed security scheme for centralized topology networks, so in future we improve this security using digital signature security technique for decentralized large level networks topologies.
We would like to work on anycast routing protocols to check the efficiency under high throughput applications, e.g. multimedia applications by employing negotiation parameters in route request packet in finding nearest server through non congestion paths.
Node’s movement stability, channel load, node congestion level and route expiry time are the important QoS metrics among several QoS parameters for providing an efficient, low overhead QoS support for anycast routing in Wireless Networks. We proposed mobility and QoS based anycast routing in Wireless Networks. The proposed work is simulated for various wireless networks network environments to validate its performance. From the simulations, we observed that the proposed scheme performs better than traditional flooding, DSR and DIASD scheme in terms of control overhead, packet delivery ratio and end-to-end delay.
Simulation procedure for the proposed scheme is as follows. (1) Generate ad hoc network with given number of nodes. (2) Estimate neighbor stability based on self node movement stability and neighbor node movement stability. (3) Compute link congestion factor based on channel congestion and buffer