The proposed algorithm ant-based multi-objective QoS routing, AMQR inspired by ant food foraging intelligence, is an on-demand QoS routing algorithm for MANETs to face requirements of various applications that may vary time to time. The proposed approach has two phases, namely, route exploration and route maintenance phases. When a source node has data for passing to a destination node with QoS requirements, it starts with route discovery phase. Data transfer will take place once the route is found. While data transmission is going on, it is also required to maintain paths during route maintenance phase which is desirable and required in mobile ad hoc networks.
The proposed algorithm incorporates positive feedback, negative feedback, and randomness into routing computation. Ant-like packets, analogous to ant foragers, are used to locally find new paths. Artificial pheromone is laid on communication links between adjacent nodes and route reply and data packets are inclined toward strong pheromone, whereas next hop is chosen probabilistically. Positive feedback is initiated from destination nodes to reinforce existing pheromone on recently learned good paths. To prevent old routing solutions from remaining in the current network status, exponential pheromone decay is adopted as negative feedback.
Each node running this algorithm contains three tables, namely, neighbor, path preference, and routing. In neighbor table, each neighbor is listed along with pheromone substance indicating goodness of outgoing link to various destinations and available bandwidth of outgoing link from that neighbor. In routing table, desired destinations for which source node has data will be listed with best next hop. While in path preference table, each entry for a destination is associated with a list of neighbor nodes. A probability value in the list expresses goodness of a neighbor node as next hop on the path to destination. The neighbor node which has a higher path preference value will be copied to routing table for the related destination on desire.
4.1. Message formats
To implement proposed algorithm AMQR, following four control messages are used.
4.1.1. Hello message
The hello packet shown in Figure 1 consists of its starting time at current node. When it is broadcast, neighbors who receive it will advertise hello packet receiving time back to the actual sender. Based on starting time and receiving time of hello packet and also size of hello packet, current node will calculate available bandwidth of outgoing links. For each node from which hello packet receiving time has been reported, an entry is created in neighbor table along with calculated available bandwidth and initial pheromone of the neighborhood links. For subsequent hello messages, available bandwidth as well as pheromone will be updated to indicate current status of outgoing links.
4.1.2. Route request message
The route request message, RREQ_ANT of AMQR, is shown in Figure 2. In addition to exploring shortest path from source to destination, RREQ_ANT additionally senses the network environment-related factors like nodes visited, end-to-end delay from source to destination, and available bandwidth of the path through which it is propagated.
4.1.3. Route reply message
The route reply message, RREP_ANT of AMQR, is shown in Figure 3. From Req_Starting_Time and RREQ_ANT's arrival time, end-to-end delay experienced by RREQ_ANT is found and converted as the parameter, delay. RREP_ANT will bring route availability information in addition to parameters sensed by RREQ_ANT through the same path taken by RREQ_ANT in reverse direction.
4.1.4. Route error message
Whenever a node learns that it cannot reach a particular destination for which it has an entry in its routing table, the node updates its routing table and sends route error message, RERR in the format as shown in Figure 4. Upon receiving this message, intermediate nodes will update their routing table and path preference probability table for the unreachable destination.
4.2. Mathematical model
The objective function of proposed work is to find a path from source to destination through a neighbor with maximum path preference probability. As in [41], path preference probability from source i to destination d through i's neighbor j is calculated as
(1)
where N
i
is a set of neighbor nodes of i, τ
ij
relative weight of pheromone trail on link (i, j), D
ijd
is relative metric for delay on the path from i to d through j, η
ijd
Relative metric for number of nodes on the path from i to d through j, B
ijd
available bandwidth of the path from i to d through j, α, β, γ, and δ tunable parameters which represent the importance of pheromone decay, delay, number of hops and available bandwidth on the path from i to d through j.
4.2.2. Calculation of relative metrics
For calculating relative metrics, the additive metrics delay, hop count, and non-additive concave metric bandwidth are considered. Since additive metrics have to be minimized for shortest paths, reciprocal values are used while calculating relative metrics. Owing to the desire of maximizing bandwidth, it is considered as in (1).
(i) Delay
The delay between source and destination is considered as
(2)
where delay(path
j
(i d)) is experienced end-to-end delay from source i to destination d through neighbor j by route request message at the time of route exploration.
(ii) Hop count
The measure hop count indicates the number of nodes visited by route request message from source to destination. A destination node finds this from route request message it receives in which first 96 bits indicate source, destination identity, and QoS measure information whereas remaining bits contain list of nodes' IP addresses through which request message has traveled. Hop count can be measured as
(3)
The relative metric for number of intermediate nodes between source and destination is found as
(4)
where Hopcount(path
j
(i, d)) is the number of hops seen by route request message along the path i to d through j and found using (3).
(iii) Bandwidth
The available bandwidth of the path from i to d is calculated as minimum of available bandwidth of all links along that path.
(5)
whereas available bandwidth of a link is calculated as
(6)
where HPS is hello packet size, HPST is hello packet starting time, and HPRT is hello packet receiving time. Because hello messages are frequently transmitted to keep neighborhood alive connectivity, they can better reflect current available bandwidth of outgoing links rather than route exploration messages.
(iv) Pheromone
Initially when there is no neighborhood relation between i and j, pheromone on link (i, j) is made as τ
ij
= 0.0. When j is detected as neighbor of i through hello message, an initial pheromone is deposited as τ
ij
= 0.1. Whenever a route reply message is received from j to i, it is considered that link (i, j) contributes to a possible path from source i to destination d. So it is positively reinforced as
(7)
where Δτ
ij
= 0.05.
Though link (i, j) contributes for a possible path from i to d, if no data transmission is detected on that path, it is considered as a path with insufficient QoS requirements. In such case, pheromone on link (i, j) is decreased by a factor ρ as follows.
(8)
where V is set of nodes in mobile network and N
i
is set of neighbors of i.
4.3 Route exploration
When source node i has data to forward to a destination d, it searches its routing table for next best hop to reach destination. Since network follows on-demand routing approach, off the rack route will not be available in all cases. So node i initiates a route request message RREQ_ANT through all its neighbors about which it has learned from periodic hello messages. While traveling to destination, RREQ_ANT checks available capacity of each link, identity of hops it has visited. If available capacity of link visited is lower than that of in RREQ_ANT message, the available bandwidth field in RREQ_ANT message is updated by recently visited link's capacity. This will make request message to carry minimum available bandwidth of a link along the path it has traveled. Finally, when RRREQ_ANT reaches the destination, it will be converted as route reply message called RREP_ANT. The RREP_ANT will take same path of corresponding RREQ_ANT, but in reverse direction. For this, RREP_ANT replicates and converts stack of nodes visited by RREQ_ANT as stack of nodes to be visited. At every node from RREP_ANT's starting point, stack is popped to see next hop to forward RREP_ANT. At intermediate nodes and at source i, information coming along with RREP_ANT such as delay, bandwidth, and hop count are used to calculate path preference probability to reach destination. Source node i updates path preference probability to destination d through its entire neighbors provided, it has received RREP_ANT through these neighbors. The neighbor node which contributes a higher path preference probability over all neighbors of node i is selected as best next hop to reach destination d. Once routing table is updated with best next hop for desired destination d, data transmission starts through that best next hop.
4.4. Route maintenance
When data transmission is going on, paths are reinforced positively making it more desirable for further selection. Also when session is going on, load on selected paths may increase causing more delay and less available bandwidth which can be detected using periodic hello and route request messages. Also, nodes might have moved causing link failures. In such cases, path preference probability will automatically decrease and hence alternate routes can be used which are found during route discovery phase. In our proposed scheme, each node maintains an updated view of its immediate neighbors by periodically sensing neighbors. Hence, link failures can be detected as early as possible before they can lead to heavy transmission errors and subsequent packet loss. The presence of neighbor is envisioned by periodic hello message exchanges or sending and receiving unicast data messages. The desertion of neighbor node is detected when neighbor's presence is not sensed by hello messages for a predefined amount of period. When a neighbor desertion is detected, the node removes lost neighbor from its neighbor table, path preference probability table and also from routing table according to necessity. If data transmission was taking place through that failed link, alternate route with next best updated path preference probability will be selected for further transmission. In worst case, all available routes to destination might be lost and reinitialization of route exploration phase might be required.