Anycast Routing Protocol using Swarm Intelligence for Ad Hoc Pervasive Network Cheng-Chang Hoh, Chiung-Ying Wang and Ren-Hung Hwang Dept. of Computer Science and Information Engineering, National Chung-Cheng University, Taiwan, R.O.C

{ahcc93, wjy, rhhwang}@cs.ccu.edu.tw Consider a simple example of regional information querying involving a user going to a shopping mall. A user drives a car and wants to find a parking area, and adopts a mobile device to query the information of the parking area while the car is approaching its destination. Several parking areas may surround the shopping mall. The user contacts the nearest server to obtain current local information, including a guide map and the number of remaining parking spaces, based on his whereabouts. Although replicate servers may be deployed anywhere in the ubiquitous environment, this work assumes that only the nearest server can provide the latest information due to synchronization jitter among servers. Consequently, the ability of a mobile user to maintain continuous contact with the nearest regional service provider is a critical issue.

ABSTRACT In a pervasive environment, regional servers with local information may be deployed everywhere and pervasive computing devices may require connecting to the nearest service server to download the most up-to-date information. This study investigates the problem of routing packets to the nearest server in a pervasive environment. An anycast routing protocol based on Swarm Intelligence and anycast service, called Anycast Routing Protocol using Swarm Intelligence (ARPSI), is proposed to route packets dynamically to a nearby server in a mobile, ad hoc, wireless network. ARPSI applies the behavior of the real ant colonies to find a shorter path to a neighboring server efficiently and quickly. Simulation results show that ARPSI achieves a higher packet delivery ratio, shorter routing path to anycast servers, and lower control packet overhead than A-AODV protocol. To our knowledge, this is the first work to integrate swarm intelligence and anycast service to solve anycast routing in a mobile ad hoc network with servers deployed at stationary locations.

The problem to be addressed herein is formally defined as follows. The pervasive environment under consideration is a wireless ad hoc network environment comprising mobile nodes and service servers. Mobile nodes communicate with each other via multi-hop routing. The servers form a backbone network, either via long distance wireless network interface, such as WiMAX, or wired network interface, such as fiber. Servers are also equipped with local area wireless interfaces for communicating with mobile nodes. Servers can be mobile or stationary. The stationary case is considered here. Servers can accumulate current information from the local environment, and periodically broadcast it to other servers. In the macro time-scale, information at servers may be viewed in synchronized form. However, in a micro time-scale, timely local information may only be stored in regional servers. A mobile node needs to access information from any server when it moves. The nearest server is preferred, since it generally has the most up to date information about local environment, as well as low transmission latency. Therefore, the problem is finding a routing path for a mobile node to connect to a nearby server.

Categories and Subject Descriptors C.2.2 [Computer-Communication Networks]: Network Protocols— routing protocols

General Terms Algorithms

Keywords MANET, swarm intelligence, anycast routing, pervasive networks

1. INTRODUCTION Owing to the recently rising popularity in pervasive computing [1-2] and communications, an efficient server discovery service is needed to locate service providers quickly. Pervasive computing is a novel means of providing mobile data access to mobile users, subsequently changing the way that individuals use devices to interact with the environment. Mobile users use a variety of small intelligent mobile computing devices with power dissipation anytime and anywhere. Therefore, how to communicate with the nearest service provider such that transmission latency, message overhead, and power consumption can be minimized becomes an important issue.

In wireless ad hoc networks, an innovative means of finding the nearest server is server push, which advertises the server location information to mobile nodes. However, flooding a server advertisement to all nodes in the network may cause the broadcast storm problem. Hop-limited flooding may solve this problem, but the number of hop counts is hard to determine. Another possible method is anycast [3-4], which allows a host to communicate with one among a cluster of servers. A virtue of anycast is that it is transparent to the user, since the same IP address, shared by multiple servers, can be used from anywhere, and the routing subsystem automatically routes the packet to the nearest server. Consequently, anycast is useful for locating the server, through which the sender host can communicate with the closest service provider chosen from multiple anycast servers by specifying a unique anycast server address. Only a few protocols, such as AODV-Based Anycast Protocol (A-AODV) [5] and Anycast

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IWCMC’06, July 3-6, 2006, Vancouver, British Columbia, Canada. Copyright 2006 ACM 1-59593-306-9/06/0007...$5.00.

815

discovery and route maintenance. In the routing discovery process, a mobile node launches QUERY packets (forward ants) to find multiple paths to anycast servers (food sources). If an anycast server is found, a REPLY packet (backward ant) is returned from the anycast server to the mobile node to set up the paths (lay pheromone). Anycast packets are then routed stochastically according to pheromone intensity. Once the anycast routing paths are established. In the routing maintenance process periodically sends EXPLORE packets to anycast servers to monitor the quality of existing routes, and to explore new routes to anycast servers.

Routing based on DSR Protocol (ARDSR) [6] , which require Ad Hoc On-demand Distance Vector Routing Protocol (AODV) [7] and Dynamic Source Routing Protocol (DSR) [8], respectively, have been proposed to support anycast routing at the network layer in MANET. Both A-AODV and ARDSR are on-demand anycast routing protocols, and do not have to exchange the routing table periodically. However, A-AODV and ARDSR suffer the typical drawbacks of on-demand routing, such as high routing overhead and low scalability. Additionally, they cannot support anycast routing in MANET with stationary servers. Therefore, further study is needed on this issue. The goal of this paper is to propose a novel approach based on swarm intelligence to solve the anycast routing problem in mobile wireless networks.

2.1 The Ant Format ARPSI has four ant packet types, namely QUERY, REPLY, EXPLORE and HELLO. All ant packets are control packets. The functions of the packets are described later. All control packets share the same packet format, as shown in Table І. The type field indicates the packet type. The fields src_id and dst_id denote the identifier (address) of source and destination, respectively. The next two fields are the sequence number (seq_num) followed by the hop_cnt, which denotes the hop count between the destination and the packet holder. Finally, vn_num denotes the number of nodes that the packet has visited, and v_node1, …, v_nodevn_num are these visited nodes.

Swarm intelligence has been adopted to design a probabilistic algorithm for robustness and maximum throughput routing [9]. Ant-Colony-Based Routing Algorithm (ARA) [10] and Termite [11] are two typical examples of swarm intelligence-based unicast routing protocols. These protocols usually consist of two processes, namely routing discovery and route maintenance. During route discovery, individually biological swarms, such as ants, move in random directions and leave pheromones on the road when they go to the food source or return to the nest. As the ants getting more food source back to the nest, the shortest optimal path is found, without understanding global information, in a decentralized, self-organized manner. In the route maintenance phase, swarms can find other paths while an obstacle is placed on the path from the food source back to the nest. Moreover, swarms can adapt to changing or mobile topologies, leading to the possibility of finding food sources closer to the nest.

Table 1. Ant Packet Format

2.2 The Pheromone Table Each node has a pheromone table (routing table), which records the intensity of pheromone on each neighbor link. Intuitively, the pheromone intensity of a neighbor link denotes the probability of routing an anycast packet via that neighbor; a higher pheromone

This work presents an anycast routing protocol using swarm intelligence, denoted as ARPSI. ARPSI is specifically designed for mobile, wireless ad hoc networks. To our knowledge, no other researchers have tried to integrate both notions to find the nearest anycast server in mobile, wireless ubiquitous networks. ARPSI comprises routing discovery and route maintenance processes. The routing discovery process finds multiple paths to anycast servers by launching request packets. The route maintenance process monitors the quality of existing paths, and explores new paths.

intensity signifies a higher probability. TableⅡ shows an example of a pheromone table, where each row denotes an anycast server, and each column denotes a neighbor. The entries of the pheromone table denote the pheromone intensities of different neighbor links. Control and data packets are routed based on pheromone intensity. In the following table, the pheromone intensity is denoted by pvn,s, where n denotes the neighbor node, and s represents the address of an anycast server. Therefore, pvn,s denotes the intensity of pheromone to anycast server s via neighbor n.

The performance of the proposed ARPSI was evaluated via simulations. The performance metrics of interest include the packet delivery ratio, number of hops and control packet overhead, which are evaluated under various numbers of nodes and mobility speeds. The simulation results indicate that the proposed ARPSI outperforms a well-known protocol, A-AODV [5], on these metrics. Specifically, our simulation results show that ARPSI yields a shorter path with lower control overhead and higher throughput than A-AODV.

Notably, if an anycast server s is the node’s neighbor n, then the pvn,s should approach infinity. Hence, in ARPSI, if an anycast server is the node’s neighbor, then the node sends packets directly to that server regardless of the value of pvn,s. Table 2. Pheromone Table

The remainder of this paper is organized as follows. Section 2 presents the proposed anycast routing protocol using swarm intelligence. Section 3 then compares the analytical results of the proposed protocol with A-AODV. Conclusions are finally drawn in Section 4.

2.2.1 Pheromone Update When a forward ant arrives at an anycast server, the anycast server returns a backward ant to the source of the forward ant by the reverse path. The backward ant deposits an amount of pheromone given by Δ at each visited node. Equation (1) describes the calculation of Δ, where c denotes a design parameter; MAX_hop_cnt denotes a threshold estimating the maximum hop count to an anycast server, and hop_cnts denotes the distance of the ant from the

2. Overview of Protocol ARPSI adopts the behavior of a real ant colony to find a path to the nearest anycast server efficiently and quickly, and with low overhead. ARPSI consists of two processes, namely routing

816

When the node receives a QUERY packet, it appends its id to the QUERY packet and forwards it according to the routing probability in Eq. (4). A node that cannot forward the QUERY packet simply drops it. (See also Figure 1 (a)-(b).) Once an anycast server receives a QUERY packet, it creates a REPLY packet and returns it to the sender of the QUERY packet along the reverse path. Each intermediate node along the reverse path updates pvn,s of the pheromone table based on Eq. (2) when it receives and forwards the REPLY packet. The path is established and data packets can be sent when the REPLY packet reaches the sender. If the sender does not receive a REPLY packet within a fixed time interval, then it continues sending QUERY packets until it receives a REPLY packet. (See Figure 2 (a)-(b).) Figure 3 illustrates an example of the routing discovery process. Node S sends QUERY packets to an anycast address. The QUERY packet carries the identifiers of nodes that it has visited. When the anycast server receives the QUERY packet, the REPLY packet follows the reverse path to S and lays the pheromone. In this case, the network has two anycast servers. Node S sends data packets via node A to the anycast server, because the node A has higher pheromone intensity than node B. Consequently, node S can connect to a nearby anycast server.

anycast server (which can be obtained from the control packet). Therefore, the pheromone laid by a backward ant becomes stronger the closer it is to the anycast server.

Δ = c ∗ (MAX _ hop _ cnt − hop _ cnt s )

(1)

Meanwhile, when the node receives a backward ant from anycast server s delivered from neighbor n, it updates pvn,s as in Eq. (2), where γ is a design parameter [10-13].

pv n ,s = γ ∗ pv n ,s + (1 − γ ) ∗ Δ, γ ∈ [0,1]

(2 )

2.2.2 Pheromone Evaporate ARPSI emulates the real pheromone laid by biological ants by making the pheromone evaporate over time to reduce the probability that the packet forwards to old trails. Equation (3) presents the formula for pheromone evaporation. Each entry in the pheromone table is regularly multiplied by the evaporation rate τ. The evaporation rate sets the speed of pheromone evaporation as fast or slow. A higher evaporation rate signifies that the pheromone intensity falls more quickly. ⎧DEF _ PV , if pvn, s * τ <= DEF _ PV pvn, s = ⎨ ,τ ∈ [0,1] (3) ⎩ pvn, s * τ , if pvn, s * τ > DEF _ PV The pheromone intensity cannot fall to zero or a negative value. Equation (3) stipulates that no pheromone intensity is allowed to be smaller than DEF_PV. The parameter DEF_PV denotes the lower bound of pheromone intensity, and ensures that each neighbor can potentially become the next-hop for the anycast server. If pvn,s ≤ 0, the neighbor n can never be chosen as the next-hop for anycast routing, thus violating the concept of Swarm Intelligence. Moreover, DEF_PV also refers to the initial pheromone intensity. When a node discovers a new neighbor n′, a new pvn′,s is created, and pvn′,s is initialized as DEF_PV.

2.3 Stochastic Routing When a control packet p arrives at a node m, a packet with anycast destination address s is routed randomly with the probability Pn,s, which denotes the probability of routing to anycast server s via neighbor n. Equation (4) describes how to transform the pheromone intensity pvn,s into the probability Pn,s.

Pn , s

⎧ ( pvn , s )α , α ≥ 1, if n ∉ vn p ⎪ ⎪ = ⎨ ∑ i∈ N − vn ( pvi , s )α m p ⎪ ⎪⎩ 0 , Otherwise

Figure 1. Flow chart of sending and receiving QUERY.

(4)

The constant α is adopted to adjust the variation of the pheromone intensity, Nm denotes neighbors of m and vnp denotes the set of nodes already visited by packet p. Equation (4) puts a constraint on that a packet will not be forwarded to nodes that it has visited. Note that node will route control packets by stochastic routing. However, data packets will only be forwarded to the next-hop that has the highest probability Pn,s.

2.4 Routing Discovery Process If a node wishes to send an anycast packet to anycast address s and finds that all the corresponding entries in the pheromone table equal DEF_PV, then it performs the routing discovery process by sending QUERY packets to anycast address s via randomly chosen neighbors as next hops. The number of packets (NUM_ QUERY) to be transmitted depends on the current network status.

Figure 2. Flow chart of sending and receiving REPLY.

817

The mobility speed of the mobile nodes was varied from 2m/s to 10m/s. Four fixed anycast servers (of the same anycast address) were uniformly placed in a simulation area. Each mobile node generated query messages to the anycast server based on an exponential distribution with a mean of 5 seconds. Table III shows the detailed simulation parameters of ARPSI. Those design parameters of equations (1)-(4) were set based on [10-11] and fine tuned based on our preliminary results. Multiple runs, each for 600 simulation times, were performed for each scenario. The collected results were averaged over all runs, and the 95% confidence intervals were calculated. Table 3. Simulation Parameters

Parameter

MAX_hop_cnt c δ γ τ α DEF_PV MAX_PV MIN_PV NUM_ QUERY NUM_EXPLORE EXPLORE_INTERVAL

Figure 3. Routing discovery process.

2.5 Route Maintenance Process The aim of route maintenance process is to ensure that a mobile node can communicate with the nearest anycast server. To achieve this goal, each node sends out EXPLORE packets every EXPLORE_INTERVAL seconds to each anycast address, and chooses the next hop based on the pheromone intensity similar to the routing discovery process. Differently, at each intermediate node, the EXPLORE packet is forwarded randomly by a total uniform distribution with a small probability δ, and is forwarded according to the pheromone intensity with probability 1−δ. This behavior helps find new paths toward a nearby anycast server. Once the anycast server receives the EXPLORE packet, it replies with a REPLY packet to the source using the reverse path. The subsequent process is the same as that of the routing discovery process.

Value

12 hops 30000 0.1 0.7 0.8 1 3000 c*8 c* 5 3 packets 2 packets 5 seconds

3.2 Simulation Method In the simulation, the performance of ARPSI was compared with that of A-AODV [5]. A-AODV protocol modifies AODV to support anycast routing. A new field, “Anycast Group ID”, was added to the RREQ to represent the group of anycast servers. When routing an anycast packet, a node first checks if there exists at least one routing entry for the anycast address. If yes, the packet is routed according to the entry with minimum cost (hop count). Otherwise, a RREQ packet is broadcast to its neighbor nodes. A server with the anycast address in the “Anycast Group ID” field of the RREQ packet will return a RREP packet. Other route discovery and maintenance operations are similar to AODV.

Although EXPLORE packet enhances the chance of finding a nearer server, it is also the main overhead of the proposed protocol. Therefore, this overhead must be reduced. In the proposed protocol, when a mobile node sends a EXPLORE packet, it first checks that whether the maximum of pvn,s is higher than a certain threshold MAX_PV, in which case it does not issue any EXPLORE packet. Conversely, if the maximum of pvn,s is lower than the threshold MIN_PV, then the node broadcasts the EXPLORE packet to all neighbors. Otherwise, the node only sends NUM_EXPLORE unicast EXPLORE packets.

Throughput, transmission latency, and power consumption are the most critical performance concerns of mobile nodes. Hence, the performance metrics of interest include packet delivery ratio, number of hops on the routing path and control packet overhead. These performance metrics were measured under various scenarios, e.g. (a) various number of nodes and (b) various mobility speeds, to analyze the impact of mobility and node density. The performance metric, packet delivery ratio, is defined as the ratio between the number of data packets received by the anycast servers and the number of data packets originated by the each node. The hop count of a routing path is defined as the average number of hops traversed from the sender node to the anycast server. This metric reflects whether each node communicates with nearby anycast servers. Finally, the control packet overhead of ARPSI is defined as the total number of control packets sent, including QUERY, REPLY, EXPLORE and HELLO packets. Control packets of A-AODV include RREQ, RREP, RERR and HELLO packets.

To route the EXPLORE packet efficiently, it is necessary to maintain the relationship between two neighbor nodes. Each node, including anycast servers, periodically sends a HELLO packet to its neighbors. A node recognizes the loss of connectivity to a neighbor node if it does not receive HELLO packets from that neighbor node for three consecutive time intervals of HELLO packets. The node will then remove related information of that neighbor from its pheromone table.

3. Simulation and Performance Analysis 3.1 Simulation Environment This section describes simulations performed by the Qualnet network simulator [14]. The simulation modeled a network of 25– 150 mobile nodes placed within a 1500×1500 area. The radio propagation range was 200 meters, and the channel capacity was 11Mbits/sec. The Random Way Point model was adopted as the mobility model, in which the pause time was set to 60 seconds.

818

3.3 Simulation Results

300

Control Packet * 1000

The experimental results from simulating the proposed ARPSI and A-AODV from different aspects are given below. Unless otherwise stated, the mobility speed was 2m/s and number of nodes was 100.

200 150

3.3.1 Node Density Effect

100

Figure 4 shows the delivery ratio of ARPSI and A-AODV under various network densities. From Figure 3, we observe that the proposed ARPSI achieves better packet delivery ratio than AAODV, especially when the network is sparse. The intuitive rationale is that as the network becomes denser, it also becomes easier to find a route. However, ARPSI still performs slightly better than A-AODV in dense networks.

25

100

Delivery Ratio (%)

150

3.3.2 Mobility Speed Effect Figure 7 reports that mobility reduces delivery ratio since the network topology changes more frequently. The comparison shown in Figure 7 is for networks of 150 nodes. Figure 7 shows that the effect of mobility on the delivery ratio of ARPSI is slightly more significant than that of A-AODV. This is because that A-AODV will re-broadcast request packets when it finds a route failure. Nevertheless, this approach incurs much higher control overhead than ARPSI, as shown in Figure 9. Figure 8 shows the average number of hop count of route paths to anycast servers of two protocols under various mobility speeds. The average route length achieved by ARPSI is independent of mobility speed. However, an increase in mobility speed causes A-AODV to yield a longer routing path due to the same reason that A-AODV does not proactively search for better routes. In other words, ARPSI can find closer anycast servers than A-AODV through the use of QUERY and EXPLORE packets.

A-AODV ARPSI

50

50 100 Number of Nodes

Figure 6. Control Packet vs. Node Density.

Figure 6 indicates that the proposed ARPSI yields fewer control packets than A-AODV. The proposed ARPSI performs reasonably well on the control overhead. Notably, ARPSI only forwards unicast control packets and broadcast control packets to neighbors that are one hop away. However, A-AODV floods request packets to find the route to the anycast server based on original AODV. Therefore, A-AODV has a higher control overhead.

25

50 0

Figure 5 indicates that ARPSI obviously has a smaller hopcount than A-AODV method under various node densities. The main reason is that ARPSI launches QUERY packets to discover a route initially and regularly sends EXPLORE packets to find nearby anycast servers. However, A-AODV does not proactively search for better routes to nearby anycast servers as long as there is at least one valid routing entry in the routing table.

1 0.95 0.9 0.85 0.8 0.75 0.7 0.65 0.6

A-AODV ARPSI

250

Figure 9 also indicates that the rise in mobility speed causes a significant broadcast storm problem in A-AODV. High mobility makes the network highly dynamic, causing route failures in AAODV, and therefore also increases the number of control AAODV packets flooded to find new routes. Conversely, an increase in mobility doesn’t increase the number of control packets in ARPSI, since it only sends control packets periodically regardless of mobility speed.

150

Number of Nodes

A-AODV ARPSI

2.9

Hop Count (hops)

Delivery Ratio (%)

Figure 4. Delivery Ratio vs. Node Density.

2.7 2.5 2.3 2.1 1.9

A-AODV ARPSI

0.99 0.97 0.95 0.93 0.91 0.89 0.87 0.85 2

1.7 1.5 25

50

100

Number of Nodes

150

4

6 8 Mobility Speed (m/s)

Figure 7. Delivery Ratio vs. Mobility.

Figure 5. Hop Count vs. Node Density.

819

10

A-AODV ARPSI

Hop Count (hops)

2.9 2.7

6. REFERENCES [1] Saha, D. and Mukherjee, A. Pervasive Computing: A Paradigm for the 21st Century. IEEE Computer, IEEE Computer Society Press, pp. 25-31, Mar. 2003.

2.5 2.3

[2] Satyanarayanan, M. Pervasive Computing: Vision and Challenges. IEEE Personal Communication, Vol. 8, pp. 10 – 17, Aug. 2001.

2.1 1.9 1.7

[3] Partridge, C., Mendez, T. and Milliken, W. Host Anycasting Service. RFC 1546, IETF, Nov. 1993.

1.5 2

4

6 Mobility Speed (m/s)

8

10

[4] Johnson D. and Deering, S. Reserved IPv6 Subnet AnycastAddresses. RFC 2526, March 1999.

Figure 8. Hop Count vs. Mobility.

Control Packet * 1000

130

[5] Wang, J., Zheng, Y. and Jia, W. An AODV-based anycast protocol in mobile ad hoc network. IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, vol. 1-3, pp. 221-225, 2003.

A-AODV ARPSI

110

[6] Peng, G., Yang, J. and Gao, C. ARDSR: an anycast routing protocol for mobile ad hoc network. IEEE Circuits and Systems Symposium, vol. 2, pp. 505 – 508, June 2004.

90 70

[7] Perkins, C. E., Royer, E. M. and Das, S. Ad hoc On-Demand Distance Vector (AODV) Routing. RFC 3561, IETF, July 2003.

50 30 2

4

6 8 Mobility Speed (m/s)

[8] Johnson, D. B., Maltz, D. A. and. Hu, Y. C. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR). IETF draft, draft-ietfmanet-dsr-10.txt, (work in progress), July 2004.

10

Figure 9. Control Packet vs. Mobility.

[9] Bonabeau, E., Dorigo, M. and Theraulaz, G. Swarm Intelligence: From natural to artificial systems. Oxford University Press, 1999.

4. Conclusion and Future Works This study considers server discovery in a mobile wireless environment such as MANET or a pervasive environment. A simple, effective, and efficient anycast routing protocol based on the swarm intelligence and anycast service, called ARPSI, is presented. Due to the swarm intelligence, ARPSI can adapt to mobility, and continues to find nearby anycast servers proactively. Simulation results indicate that ARPSI can find shorter routing path and achieve a better packet delivery ratio than A-AODV. Moreover, ARPSI also achieves a small control packet overhead, which is very important for power-limited mobile devices in pervasive computing environments.

[10] Gunes, M., Sorges, U. and Bouazizm, I. ARA-the ant-colony based routing algorithm for MANETs. In Proceedings of the ICPP International Workshop on Ad Hoc Networks (IWAHN), vol. 1, 28-30, pp. 79 – 85, Aug. 2002. [11] Roth, M. and Wicker, S. Termite: Ad-Hoc Networking with Stigmergy. Global Telecommunications Conference, pp.2937 – 2941, Dec. 2003. [12] Ducatelle, F., Caro, G. D. and Gambardella, L. M. Ant Agents for Hybrid Multipath Routing in Mobile Ad Hoc Networks. In Proceedings of the Second Annual

Several issues of ARPSI need further research. These issues include dynamically tuning ARPSI parameters for different wireless environments, and further improving the routing by using positioning techniques such as GPS, RFID or ZigBee. Applications based on anycast service in a pervasive environment are also being studied.

Conference on Wireless On demand Network Systems and Services (WONS), 2005. [13] Caro, G. D., Ducatelle, F. and Gambardella, L. M. AntHocNet: An Ant-Based Hybrid Routing Algorithm for Mobile Ad Hoc Networks. In Proceedings of Parallel

Problem Solving from Nature (PPSN), LNCS 3242. Springer-Verlag, 2004.

5. ACKNOWLEDGMENTS This research is partially supported by National Science Council of Taiwan under grant number NSC 94-2213-E-194-001.

[14] Bajaj, L., Takai, M., Ahuja, R., Tang, K., Nagrodia, R. and Gerla, M. GlomoSim: A Scalable Networks Simulation Environments. Technical Report UCLA Computer Science Departments, 900027, May 1999.

820