This AODV sample scenario has 18 wireless  lan based stations in thead hoc network configuration.   Nodes move around in a rectangular area whose boundaries ([grid_XMIN - grid_XMAX] x [grid_YMIN - grid_YMAX]) are defined by the user at the node level.     The mobility scheme is very  limited and is activated by setting theMOBILITY attribute (node level) to "Enabled".  The movement is asequence of discretized events and no acceleration is possible. At each interval I,  a node chooses a direction based  on a  given  distribution and  move along a distance D.  The values of I (mobil_POS_TIMER)  and  D(mobil_STEP_DIST) are defined by the user at the node level.  Each timea node encounters a boundary, it reflects on it (billiard scheme).    As far  as packet  generation is  concerned, a node's source trafficactivity  is  determined by the INTERLOCUTOR attribute.  If it is set to"None", the  node  remains silent (but still  performs its  routing func-tion)  during  the  simulation  time.  If  INTERLOCUTOR  is  set  to "Multiple",  node  may  sequentially  `converse`  with  multiple  nodes (each  time a packet is  received at the app_manager from the source,  adestination is randomly computed and attributed to it  before it is sentto  the  routing  layer).  Finally,  it  is  possible  to define a mono-interlocutor by  indicating its address in the sub-network.  All packets generated at the source are then destined for the specified node.    To enable the Hello Mode,  the user  needs  to  set  the  HELLO_MODE attribute  (node level)  to the "Enabled" value. The use of hello  message exchange  to maintain local connectivity  leads to longertime of execution.    The GRAT_RATIO attribute (node level) indicates the ratio of gratui-tous  requests  for  each  node.  If  set  to "O", no gratuitous mode is requested.   As far as statistics  are  concerned,  users are invited to implement their own. However, some data are written into a log file (output_file)at the end of each simulation run: intput (nb of pks), output (nb of pks).   Finally,  it is possible to trace the simulation execution by printingshort messages on the screen.  For each node,  messages can be printed in along  the  simulation  time  in  order  to  track  its  evolution within the  network.  As a matter of fact,  these  messages  provide information about its position, its current state on the process, and its response tothe  current  events.  This  feature is controlled by the DEBUG attribute (node level)  whose  value  indicates  the quantity  of information to be displayed on the screen (DEBUG = "second_level" is recommended). If DEBUGis set to "None", no messages will be printed.