ANEJOS: a Java based simulator for ad hoc networks

Future Generation Computer Systems 17 (2001) 573–583

Best of Websim99

ANEJOS: a Java based simulator for ad hoc networks

Miguel Sánchez∗, Pietro ManzoniDISCA — Departamento de Informática de Sistemas y Computadores, Universidad Politécnica de Valencia,

Camino de Vera, 14, 46071 Valencia, Spain

Abstract

Ad hoc networks are multi-hop wireless networks where mobile devices communicate using a shared, low power, lowbandwidth channel without any wired infrastructure: each node acts also as a router of its neighbors. Ad hoc networksprotocol design is still a new and growing research area; there currently is an IETF Working Group working on the definitionof a standard for such networks. Various proposals are being evaluated and the need for a common comparison frameworkarises. This paper presents a simulator called ANEJOS (ad hoc networks Java simulator). The simulator is written in Java andis based on the SimJava tool and allows to be adapted to various routing protocols. It also allows considering other relevantaspects to ad hoc networks, like mobility patterns and traffic generation patterns. ANEJOS shared our models with otherresearchers through the internet, we can use Java applets inside HTML pages containing the whole simulator. © 2001 ElsevierScience B.V. All rights reserved.

Keywords:Ad hoc networks; Mobility; Simulation environments; Java

1. Introduction

An ad hoc network is a multi-hop wireless networkwhere mobile devices communicate using a shared,low power, low bandwidth channel. These mobile de-vices can establish and maintain network connectionswhile moving inside the covered area. The networktopology may vary rapidly, typically due to node mi-gration and to signal interference and power outages.No wired backbone or any sort of centralized networkmanagement system is present. Control is distributedand every node is required to cooperate to support mes-sages routing. Due to either the high rate of changesin the network topology and the characteristics of the

∗ Corresponding author. Tel.:+34-96-387-9700;fax: +34-96-387-7579.E-mail addresses:[email protected] (M. Sanchez),[email protected] (P. Manzoni).

communication channel, it is not possible to employthe same routing algorithms used in static networks.

Various dedicated algorithms have been proposed tosolve routing issues for this environment (see [1,2]). In[3] we presented a dedicated routing protocol designedto provide communication support to a collection ofmobile robots. Our project consisted in arranging themobile robots over a lake to monitor water conditions.Each robot, powered by a solar panel, is provided witha micro-controller to execute all the processing. Insidethe robot there are a few sensors for temperature, pHlevel, and oxygen concentration and an air-pumpingdevice. Data transmission is carried out by a wirelessmodem operating at a common carrier frequency of433 MHz and with a short reaching range (a few hun-dreds of meters due to their low power, only 1 mW).The task of the robots was to pump air into the waterto rise the oxygen levels in required areas. Robotscould change their position due to the water drift, the

0167-739X/01/$ – see front matter © 2001 Elsevier Science B.V. All rights reserved.PII: S0167-739X(00)00040-6

574 M. Sanchez, P. Manzoni / Future Generation Computer Systems 17 (2001) 573–583

wind or human intervention. We wanted the system tobe able to react autonomously to the possible changesin the topology.

Ad hoc networks protocol design is still a newand growing research area; there currently is anIETF Working Group working on the definition of astandard for such networks. As said before, variousproposals are issued and the need for a commoncomparison framework arises. With this in mind wedesigned a simulator called ANEJOS (ad hoc net-works Java simulator). The simulator is written inJava and is structured to be extensible and adaptableto cope with the various routing protocols. As Section3 illustrates, ANEJOS is based on a few basic classeswhich models the communication medium, the mo-bile devices and the interchanged messages. Theseclasses can be implemented and extended dependingon the characteristics of the protocol to be analyzed.Other classes, namely the mobility class and the trafficgeneration class, provide complementary extensibilityaspects to the simulator. The mobility class allowsexperimenting with the behavior of the routing proto-col with different mobility patterns; in this work wepropose the details of three mobility patterns. Thetraffic generation class allows simulating the behaviorof the routing protocols with different data generationpatterns or even with transport or application layer pro-tocols, providing extensive features to the simulator.

The paper is organized as follows. Section 2 shortlypresents the WARP as an example of a routing protocolfor an ad hoc network. Section 3 presents the simulatorstructure. Section 4 illustrates the details of the usedmobility models. In Section 5, we demonstrate howthe simulator can be extended to analyze other rout-ing protocols, traffic generation patterns or data-linklayer protocols. Finally, Section 6 concludes the paperresuming the results obtained and the on-going work.

2. The routing protocol WARP

We designed an ad hoc networks routing protocolcalled WARP (wireless “Albufera” routing protocol).WARP is a lightweight protocol based on the activ-ity of a dedicated node called the coordinator. Thecoordinator is a fixed node that sends all the controlinformation required from the mobile devices to op-erate and that receives all the information collected

Fig. 1. The graph structure of an ad hoc network.

by the robots. The protocol constituted of two parts:the forward routingprotocol and thebackward rout-ing protocol. The forward routing protocol is used tosend data from the coordinator towards a destinationnode, while the backward routing protocol allows arobot to send data to the coordinator. All the nodestake part in the routing of packets toward a destina-tion node or toward the coordinator. A route betweennodev1 and nodevn is defined as a finite set ofdis-tinct nodesv∈V and a finite set ofdistinct links l∈E(t)for which v1l1v2l2 · · · ln−1vn is verified (see Fig. 1).WARP ensures that each node knows at each time theset of its neighbors while no node is required to knowthe complete lay-down of the network. A small set ofstatus variables is maintained in each node to allowthe protocol to work.

We defined a general structure for the packets usedin WARP. From the basic structure three sub-types arederived:data for regular data,hello to propagatetopology updates, andfrreq , frmain and frsecfor the routing protocols. We will not give the details ofthe forward and the backward routing. These two taskscan be defined as on-demand tasks since they are acti-vated when the coordinator wants to send data towardsa node or vice-versa. In WARP there are also periodictasks that are to be completed. The most important ofthese is the generation of thehello packets. Thesemessages are periodically sent and are used by the re-ceiving nodes to update their neighbor’s tables keep-ing also track of the quality of these links. We definethree quality levels for the links:strong , weak andloose ; by default, all links are marked asstrong .Before sending anhello packet, each node has tobrowse an internal status list. If the time elapsed from

M. Sanchez, P. Manzoni / Future Generation Computer Systems 17 (2001) 573–583 575

the lasthello packet received is greater than a prede-fined amount1 of hello intervals (which we heuris-tically define as 3), we decrease the value of qualityof the link. If the time elapsed from the last update isgreater than12 hello intervals the link is consid-ered lost and the correspondent node unreachable.

More details on the protocol can be found in [3].

3. The simulator structure

The starting point on building the simulator in Javawas the idea shown by the SimJava package authors[4]:

“You can builda simulator that lets otherpeopleview your results on their ownworkstation” .

SimJava is a process based discrete event simulationpackage for Java, similar to Jade’s Sim++, withanimation facilities that allow the user to see theprogress of the simulation [5]. This possibility provesto be very helpful when defining the details of a newpiece of software like, in our case, a routing proto-col. Also the Java language WORA (write once, runanywhere) feature seemed to be very interesting. Itallows to eliminate the difficulties often found whenusing different simulation packages, which are toodependent on a particular compiler type or version oron a particular machine architecture. Java allows dis-tributing the source code with the trust that potentialusers will encounter minimal difficulties on runningand modifying it.

Our simulator allows modeling a graph-based adhoc network, like the one used for WARP. The sim-ulator allows spreading a collection of mobile nodeson an area. Each node executes all the tasks relatedto a certain routing protocol and all the data trans-mission operations required from applications. At thesame time, each node is capable of moving on thetest area following a specified mobility pattern (seeSection 4). The data transmission system is built onwireless transmitters deploying radio waves (it couldalso be implemented by means of infrared beams).We are not trying to include in the simulator all thecharacteristics of the physical transmission, because ofthe increment on the complexity and because we arefocussing on the routing and mobility aspects.

The basic components of the simulator are nodes,links and the transmission medium. These componentsare modeled with the following Java classes:

• Node. Each instance of this class represents a node(i.e., a mobile robot). A simulation starts launch-ing any number of nodes you want. Every nodehas a spatial coordinate and sends to and receivespackets from anEther object. When a node re-ceives a packet, it performs a call to the abstractmethodprocess() of classPacket which re-sults in a call to the proper packet type treatmentroutine. Although every instance ofNode does thesame work, we use aget id() function to differ-entiate between regular nodes and the coordinator(which plays a special role in our protocol whilebeing another node).

• Ether . It is a static class representing the char-acteristics of the data transmission subsystem. Itmodels a wireless transmission with limited range.Ether needs to know the current position of anynetwork node. On receiving a packet from a node,Ether first checks which nodes are in the rangeof the source node. Then it sends a copy of thepacket to these in-range nodes. This class receivesmessages fromNode objects containing either thetransmitted packets or control events to inform theEther of a Node location change.

The relationship between these two classes isshown in Fig. 2. ANode instance requests packettransmission to theEther class and theEther

Fig. 2. The relationship between theEther and Node classes.


class handles the transmission to each of theclose-by nodes.

Some other classes are included in the simulatorto handle node location information, packet types(and processing) and mobility models:

• Pos. It is the class holding Cartesian coordinatesand the methods to deal with them (e.g., distancemeasurements).

• Packet . This is an abstract class, which is the baseclass for different packet types. It implements theCloneable interface and redefines theclone()method to let theEther class retransmit copies ofreceived packets to the other nodes. This class canbe extended in order to include each packet typeneeded by the routing protocol. Simulating WARPwe defined the following three subclasses:◦ DataPkt . This is the data packet class, intended

to send user data. It includes all the needed fieldsnot only present in thePacket class but alsothe code that a node must run when it receivesa data packet. This code includes all the routingfunctions to be performed by the node when thereceived packet is not destined to it.

◦ HelloPkt . This class is related to a periodicpacket used to maintain status information and in-tended to be sent only between neighbor nodes inorder to advertise our presence to establish a routeto the coordinator node. There is no forwardingcode because these packets are not routed.

◦ RoutePkt . The coordinator uses these packetsnode to discover a route to a certain node. Thereare different types of these packets labeled bythe value of thetype field. RoutePkt packetsare forwarded by nodes and can produce changesin the routing tables. To do this, node identity ispassed as parameter in the process method calls(in fact this is done in the super class and there-fore in the other two packet classes).

• Mobility . This abstract class holds the mobilitymodel structure and the methods that calculate themotion of nodes. Each new motion model extendsthis class.1

◦ Scan, Pursue and Nomadic . These aredescendents of mobility class, implementingthe different motion models described in the

1 The motion models presented in this paper can be found at:http//www.disca.upv.es/misan/mobmodel.htm.

next section. Start instantiating the desired mo-bility model, and then add the nodes usingaddNode() method. Then the current locationof this node with thegetLocation() func-tion or the new one withgetNewLocation()function is obtained. MethodsetTarget()and functiongetTarget() lets you change thetarget position of the model (where available).

• Comm. This is the main class, which basicallystarts all the objects of the simulator. It uses theSim system.initialise() method to startthe simulation engine and then adds all the en-tities (Node and Ether objects) by callingSim system.add() method. Eventually, whenall the entities have been added, it callsSimsystem.run() to actually run the simulation.

The whole simulator is built on top of the SimJavalibrary, which provides the basic threading mech-anism and the inter-thread messaging subsystem.Those classes performing concurrent work must ex-tend (inherit) theSim entity class. Thebody()method is rewritten with the code you want this entityto perform. Each entity has a unique identifier andthe methodsim schedule() lets you send mes-sages to any entity of the system (including yourself)with a programmed time delay. Thesim wait()method blocks the calling entity until there is a mes-sage (event) available. With all these pieces we builtthe data transmission subsystem and also some of thetime-triggered procedures.

We would like to point out that SimJava entities canonly process one event at a time. If several events occurat the same time, only one of them is returned by thesim wait() function. The other events are queuedfor deferred treatment. To overcome this behavior, weuse thesim get next() function that returns thenext available event independent of whether it is anormal event or a deferred event. In this way we donot miss any event.

Another worthwhile feature to remark is that,although SimJava includes several communication re-sources, such as the port structures, we choose not touse them because they are conceived for point-to-pointlinks. In our case, communication is based on broad-casts; therefore, an implementation based on pointto point links we will end-up with a complex anduncomfortable structure.


4. Mobility models

Testing protocol behavior in different scenarios ofmobility is what led us to include various mobilitypatterns in our model. In fact, we think that the mostimportant aspect to perform a comparative evaluationof several protocols is to test them in similar mobilityscenarios. Anyway, the lack of such kind of modelsalso led us to design some of them, trying to model realworld moving patterns associated to some commontask performed either by humans or by robots. Theidea was to put a mobility model in charge of tellingus where every node on the network is moving to, atpredefined or random time intervals.

We were only aware of two mobility models: theBrownian motion (described mathematically by Ein-stein in 1926), and the exponential correlated randommodel. The Brownian motion represents the motionof molecules inside a solution. At temperatures aboveabsolute zero, the individual atoms that constitute anysubstance are in movement. Indeed, the amount of thismovement is what constitutes temperature itself. Theresultant of this motion is sometimes called a randomwalk and has a zero mean, meaning that there is notreally a net movement. The average displacement in agiven direction is a linear function of the square rootof the time period (t) during which its movement ismeasured. The relationship is expressed as

1Y =√

kT

ft,

wherek is the Boltzmann constant,T the absolute tem-

Fig. 3. Brownian motion (left: motion schema, right: sample window).

perature andf the frictional coefficient of the particle.As can be seen, movement increases with temperatureand also with the time duration of the observation pe-riod (sample time) meaning that a longer observationperiod gives a longer displacement.

In the sample window of Fig. 3, we show the pathfollowed by only one node after a certain amount oftime. Because of the distribution we use in the code(normal bell-shaped Gauss distribution), the move-ment is usually of very short length, producing thisfuzzy result. Our sample code to implement suchmovement is as follows:

We choose a random distance to move (r from anormal distribution with mean=0 and variance=10).We select a random angle (alpha , from a uniformdistribution between 0 andπ ). Thex-axis andy-axisincrements are calculated by projecting the resultingvector in the two axes.

The second model was the exponential correlatedrandom model developed at BBN Systems and Tech-nologies in 1996. The model has groups of nodes.Each group is a circle containing nodes, which can bedescribed as having a certain number of nodes orig-


Fig. 4. An example of random orbit (left: motion schema, right: sample orbit).

inally centered at a specific coordinate with a groupspeed. The nodes can initially be spread out from thecenter. We describe each group by moving a deter-mined distance with a certain angle. The movementof the nodes inside a group is like Brownian motionmodel, but the whole group moves somehow linearlyin a certain direction. Group movement is performedaccording to the equation:

pppt+1 = pppt · e−1/τ + ϕϕϕ · X ·√

1 − (e−1/τ

)2

whereX is the random Gauss variable andϕϕϕ is therandom angle (unit vector) of the displacement. Thesetwo parameters are similar to the previousalphaand r . The latter parameter,τ , is a “filtering” func-tion factor which modulates the sharpness (or soft-ness) of movement. The kind of tasks that can bemodeled by this latter model could be troops move-ment in the battlefield, where each group represents aplatoon.

4.1. Our proposed models

Our models are based on the center idea of the “ran-dom orbit”. Each moving node has a home location(or reference point) and moves around it. Each move-ment is calculated by determining a randomx-axis andy-axis positive increments and then by comparing theactual location of the node with the home position. Ifthe actual position is above the home position (y-axis)then the new node position will be formed by applyingthey-axis increment to fall node position. The same istrue in thex-axis, if the node actual position is on the

left of the home position the node will suffer a rightdisplacement.

Fig. 4, shows the random orbit model in action.You can see that each new node position produces anew restriction on the space to be used on the nextmotion. On the right of Fig. 4 you can see an exampleof a random orbit with 500 movements. (If you takea closer look you will probably see that not all of theavailable points have been visited. This is due to therandom nature of the motion and the limited numberof samples.)

The second idea in our models is the group mo-tion. While each of the node moves in a random orbitaround its home location, the whole reference systemcan move following some known or unknown pattern.This is shown in Fig. 5.

Next, we will describe several node motion mod-els, which assume some form of target location. Thistarget can also move, but this motion is not defined

Fig. 5. The idea of group motion.


in the model. Therefore, we are only specifying themotion model at the node level and not at the targetlevel.

We have developed three new models trying to repli-cate other real world activities that could be useful inour target system. All of our models are based on akey idea. These activities are:

1. Scanning an area. In this model we have triedto represent the moving pattern of a row ofrobots moving in a certain direction. This behav-ior can be found on a searching activity (e.g.,anti-personal mines deactivation robots). But themodel is not limited to a forward direction normalto the row axis, but any angle could be possibleto, for example, form a “one behind the other”motion also present in some robotics activities(e.g., transportation convoy). We have called thisthe “column model”. This model is shown inFig. 6.

In the previous figure node zero is representingthe target direction of the column of nodes and thesmall dots represent the reference positions of eachnode (the plus sign represents the center of gravityof the five points).

To implement such behavior we have of line ref-erence points (“ref ” hash table) and each nodecurrent position is held in the “loc ” hash table.Nodes move randomly around its reference point.

Here the range of movement is proportional to thedistance to the reference point of the node. Furtherthe node is from its reference, the more movementcan it experience (greater range in the random num-ber). However, if we consider a true random move-ment (as the Bronwnian motion) it is possible fora node to reach a great distance from the referencepoint and therefore, the column of nodes woulddisappear. We introduce a modification on how weapply the random (positive) increments calculated.If we are on the left of the reference position weadd the increment to thex-axis. We do the samein the y-axis. Therefore, all the node movement issomething like a “random orbit” around its refer-ence point.

2. Pursue a target. Here we have a collection of robots(nodes) trying to catch a single target. This kindof behavior is found in multiple robotics activities(e.g., people or equipment tracking). Here we havetaken into account the fact that physics does notlet a pursuer robot to follow any position changeof the target but it is speed limited and so, thetracking is usually done with some error that mayalso be due to other factors like the environment. Inthis model we suppose also certain randomness ofmovement when the target is stopped and tracked.(For example, you have an apple-pie in your handand some flies are trying to land on it. You movethe pie to avoid them to reach it. This image coulddescribe better than any other model behavior. Fliesare the nodes.)

In Fig. 7, node zero is the target point and nodesnumber one to nine are trying to approach it. Thedot locations are merely the starting point of nodes(with the exception of the target). Again the plussign represents the center of gravity.

Similar to the random movement of the columnmodel, here the reference point is substituted by thetarget point. All the nodes try to reach this targetdoing random movements, but again, the random-ness is constrained by theisUp() andisLeft()functions. The second difference is the limited val-ues of the range multiplier (d) that limits the max-imum and minimum range of movement. The up-per limitation models the maximum speed limita-tion. While the lower bound limitation of “d” is tomaintain a certain “random orbit” around the targetpoint when it is reached.


Fig. 6. Column model (left: motion schema, right: sample window).

Fig. 7. The pursue model (left: motion schema, right: sample window).

Fig. 8. Nomadic community model (left: grid formation, right: sample window).


3. Nomadic community. In this model, all nodesmove, from time to time, from one location toanother. After the community is established in onetarget area, each node maintains its own privateone, inside of which the node moves more or lessrandomly. This motion pattern may be useful insome military operations and also (with a slowermovement) in agriculture robotics and is shown inFig. 8.

Sometimes we need to do an operation to an areaif each robot is capable of covering let us say onetenth, we can deploy 10 robots and devote each oneto a different part of the referred area. After the op-eration completes, the whole system is able to moveto another place to repeat its work. For the momentwe are not presenting a community moving-patternand we are experimenting with manual commu-nity moving. The calculations for this model areidentical to the ones used in the column model,because again each node “orbits” around its ref-erence position. The initial grid creation is doneby means of a square spiral whose code is shownbelow.

The turn right vector holds the position in-crements to turn “d” pixels to the right in any ofthe four directions (north, west, south, east). Thealgorithm always tries to turn to the right as thenext move, however, if it finds a busy place, thenit continues in the same current forward direc-tion. This builds the square spiral that serves us asreference points.

These three models enable us to simulate node com-munication in a known environment, where we canadjust all the parameters to evaluate its influences. Wehave also conceived a possible hierarchical extension.At the lower level you found nodes. Several nodescan be joined to build higher level entities which alsomove conforming some mobility model (e.g., if, atthe node level, you have a Brownian motion and eachgroup of nodes moves with the column model then youget something like the exponential correlated randommobility model).

5. Simulator extensions

The current model is only dealing with a certainrouting algorithm and let us choose the mobility pat-tern you want. The current structure allows users toimplement their own algorithms to measure their be-havior. However, several improvements are possiblein order to study other phenomena, like:


• Media access issues. In the current version, the sim-ulator does not take into account what is the realmedia access protocol. This means that we are notcovering the possible interactions between the rout-ing algorithm and the access method. We are nowconsidering fixed (or random) access time, whicheach packet suffers before it is successfully trans-mitted.

• Physical level problems. Wired data transmissionis not always error free, sometimes the transmittedsignal is corrupted by several physical effects andwhat really arrives at the destination is a garbledpacket. Wireless links are usually worse than theirwired counterparts, therefore a more accurate simu-lator should consider the different link impairmentscauses (and effects), which would lead to modelthe real signal propagation, attenuation and noiseissues.

• Realistic traffic patterns. Simulator traffic is usuallybuilt by a simple random traffic generator function.This approach allows studying the overall behav-ior of a protocol, however, real traffic conditionsare usually obtained from the execution of the realtransport protocols (and services) over the networksimulator. We are evaluating the implementation ofthe possibility to obtain real traffic patterns fromtraces or by running the applications and transportprotocols over the simulation network level.

Using a layered approach can extend this simula-tor. TheEther class is the one that deals with packettransmission. Although currently, it is not using a me-dia access protocol, theEther class is the properplace to include things like MAC or physical trans-mission issues.

We are developing aTraffic class to be attachedon top of the nodes to signal each node when it is timeto send a packet. In this implementation,Trafficobject will also beSim Entity object, running con-currently with other simulator’s threads.

We would like also to remark the graphic capabilityof the simulator. The Abstract Window Toolkit Javaclass library allows developing GUI applications thatrun smoothly in almost any platform. Up to now wehave not yet developed a proper graphic support, butwe are also working on those aspects. Our idea is toallow users to obtain an animated view of the sim-ulation progress. This kind of observation can help

users to quickly detect some kind of uncovered prob-lems and also to interact with the model, for exam-ple changing one node’s position at any moment toverify that the routing protocol is correctly handlingthis situation.

6. Conclusions and future work

Ad hoc networks protocol design is still a newand growing research area; there currently is an IETFWorking Group working on the definition of a stan-dard for such networks. Various proposals are issuedand the need for a common comparison frameworkarises. This paper presented a simulator called ANE-JOS (ad hoc networks Java simulator). The simulatoris written in Java and is structured to be extensible andadaptable to cope with the various routing protocols.Some researchers of ad hoc networks are working withother simulators, mainly written in C or C++. Most ofthem require you to download a huge compressed fileand build the whole code, which means “Makefiles”and recompilation, and sometimes strong computingpower. On the other hand, existing simulators are notalways dealing well with wireless links or with mov-ing nodes. But what is the more compelling reason forus to switch to Java is the ability to include your en-tire simulator on a web page and running it in almostany browser.

Java run-time performance is a hot issue. Beingan interpreted language you will found some perfor-mance penalty over C++ native code (ranging fromtwo to ten times slower). Just-in-time compilers (JIT)try to rise Java language to a better performer levelwith varying results. But we have specially found thefact that it lets you program with less effort and er-rors due to some library constructs (likeVector orHashtable classes) that eases some of the program-ming tasks.

It is difficult to estimate which is the benefit in de-veloping time with respect to other languages. TheSimJava class library also eases greatly programmingtasks of a simulator (because it is a porting from otherC++ library you can also work with if you are aC++ programmer). As we have said in the previoussection, our future work is aimed at developing lowerand higher levels support (MAC, a transport protocol)and also the graphical representation of the informa-


tion. For this task we probably use some of the usefulfeatures included in the SimJava package.

The other open path is user documentation and codedocumentation. Because of the rapid changes and thebeginning stage of the project, we do not plan to docu-ment it up to simulator structure which will be morestable.

An open problem is to develop the mobility patternof the several structures we use in the paper as ref-erence point’s grid or target points, because we haveshown only the evolution of the model and not themotivation and path of these references to follow. Forexample, what kind of movement is doing the target inthe pursue model. We have left open this because wethink it is not very important for us while the speed ofgrid motion is maintained low (in this case one nodehas, more or less, the same neighborhood).

References

[1] V. Park, S. Corson, A highly adaptive distributed routingalgorithm for mobile wireless networks, in: Proceedings ofthe INFOCOM’97, Kobe, Japan, 7–11 April 1997.

[2] C. Perkins, Ad hoc on demand distance vector (AODV)routing, IETF Internet Draft, Mobile Ad Hoc NetworkingWorking Group, 20 November 1997.

[3] M. Sanchez, P. Manzoni, A communication protocol forclouds of mobile robots, in: Proceedings of the 11thInternational Conference on Industrial and EngineeringApplications of Artificial Intelligence and Expert Systems,Benicassim, Spain, Tasks and Methods in Applied ArtificialIntelligence, Lecture Notes in Artificial Intelligence, Vol.1416, Springer, Berlin, June 1998.

[4] F. Howell, R. McNab, SimJava: a discrete event simulationpackage for Java with applications in computer systemsmodeling, in: Proceedings of the First InternationalConference on Web-based Modeling and Simulation, SanDiego, CA, Society for Computer Simulation, January 1998.

[5] A.H. Buss, K.A. Stork, Discrete event simulation on the worldwide web using Java, in: D. Morrice, J. Charnes, (Eds.),Proceedings of the 1996 Winter Simulation Conference,Coronado, CA, 8–11 December 1996, pp. 780–785.

Miguel Sánchez obtained his B.S. inComputer Science in 1988 and his M.S.in Computer Science in 1992, both fromthe Universidad Politecnica de Valencia,Spain, where he is now an Assistant Pro-fessor at the CS department. His currentresearch is in routing and media accesscontrol in ad hoc networks on which heis pursuing his Ph.D.

Pietro Manzoni received his M.Sc. de-gree in Computer Science from the “Uni-versitá degli Studi”, Milan, Italy, in 1989,and his Ph.D. degree in Computer Sciencefrom the “Politecnico di Milano”, Milan,Italy, in 1995. Since 1995, he is an Assis-tant Professor of Computer Networks atthe “Universidad Politecnica de Valencia”,Valencia, Spain. His research interests arein the theory, design and implementationof communication protocols.

ANEJOS: a Java based simulator for ad hoc networks

Documents

Transcript of ANEJOS: a Java based simulator for ad hoc networks