Friday 17 January 2014

Greedy Perimeter Stateless Routing (GPSR)

In wireless networks comprised of numerous mobile stations, the routing problem of finding paths from a traffic source to a traffic destination through a series of intermediate forwarding nodes is particularly challenging. When nodes move, the topology of the network can change rapidly. Such networks require a responsive routing algorithm that finds valid routes quickly as the topology changes and old routes break. Yet the limited capacity of the network channel demands efficient routing algorithms and protocols, that do not drive the network into a congested state as they learn new routes. The tension between these two goals, responsiveness and bandwidth efficiency, is the essence of the mobile routing problem.
Greedy Perimeter Stateless Routing, GPSR, is a responsive and efficient routing protocol for mobile, wireless networks. Unlike established routing algorithms before it, which use graph-theoretic notions of shortest paths and transitive reachability to find routes, GPSR exploits the correspondence between geographic position and connectivity in a wireless network, by using the positions of nodes to make packet forwarding decisions. GPSR uses greedy forwarding to forward packets to nodes that are always progressively closer to the destination. In regions of the network where such a greedy path does not exist (i.e., the only path requires that one move temporarily farther away from the destination), GPSR recovers by forwarding in perimeter mode, in which a packet traverses successively closer faces of a planar subgraph of the full radio network connectivity graph, until reaching a node closer to the destination, where greedy forwarding resumes.
GPSR will allow the building of networks that cannot scale using prior routing algorithms for wired and wireless networks. Such classes of networks include:


  • Sensor networks: potentially mobile, potentially great density, vast numbers of nodes, impoverished per-node resources
  • Rooftop networks: fixed, dense deployment of vast numbers of nodes
  • Vehicular networks: mobile, non-power-constrained, widely varying density
  • Ad-hoc networks: mobile, varying density, no fixed infrastructure
  •       Extending GPSR:



  • Obstacles and localization errors: We have investigated GPSR's behavior in the presence of obstacles to radio propagation and node localization errors, which introduce the risk that the planar subgraph used by GPSR's perimeter mode may not be connected. We initially investigated the "mutual witness" proposal, a heuristic for preserving the connectivity of the planar subgraph, mentioned in the thesis and DIMACS talk below. More recently (2004), we've developed the Crossing Link Detection Protocol (CLDP), which allows provably correct geographic routing on any connected network, i.e., even on networks where obstacles, irregularly shaped radio ranges, and localization errors occur. CLDP is described in the NSDI 2005 paper below.
  • Geographic provisioning: We use geographic forwarding via a waypoint not on the path found by naive GPSR to distribute load on the network. This approach is promising because on a wireless network, position and capacity are correlated; distributing load geographically leverages spatial reuse, and cuts the average load in regions where traffic is concentrated.
  • ns-2 simulation code    for GPSR


    A rough list of what's GPSR-specific in this ns-2 tarball:
    File(s)Description
    gpsr/{gpsr.cc,h}C++ code for the GPSR routing agent.
    gpsr/paper-cmu.tclTCL script for simulations used in 50-node cases in MobiCom 2000 paper. GPSR parameters set in this script.
    gpsr/paper-cmu.plPerl script for iterating over several simulations, all 50-node cases from the MobiCom 2000 paper.
    tcl/mobility/gpsr.tclTCL library code for GPSR.
    locdbase.{cc,h}C++ code for the idealized (omniscient) location database.
    There are also minor modifications to ip.h, cmu-trace.h, and packet.h, for underlying support required by GPSR.
    A table of the TCL variables used to configure the behavior of the ns-2 GPSR implementation follows. The values used in the MobiCom 2000 paper are given below, for reference.
    N.B. that you should set all these parameters in your simulation script; the defaults may not be appropriate for the simulation you want to run!
    TCL Configuration VariableMobiCom 2000 ValueFunction
    bint_{1.0, 1.5, 3.0}Beaconing interval (seconds)
    bdesync_0.5Random component magnitude (percentage) in beaconing interval, to avoid synchronized beaconing by neighbors
    bexp_3 * (bint_ + bdesync_ * bint_)Beacon expiration interval (seconds) before timing out neighbor from neighbor list
    use_implicit_beacon_1When set to 1, treat data packets as beacons; receive promiscuously and reset neighbor expiration timer for every received unicast packet from a neighbor, and reset the beacon transmission timer whenever transmitting a unicast packet
    use_mac_1When set to 1, use link breakage detection from failed MAC retransmit to remove neighbors from neighbor list
    use_peri_1When set to 1, forward packets in perimeter mode when greedy forwarding impossible
    use_planar_1When set to 1, enables planarization in perimeter mode
    use_timed_plnrz_0When set to 1, enables periodic replanarization, on the basis of a timer

    Traffic generation in ns

     Applications objects

    An application object may be of two types, a traffic generator or a simulated application. Traffic generator objects generate traffic and can be of four types, namely, exponential, pareto, CBR and traffic trace.
    Application/Traffic/Exponential objects
    Exponential traffic objects generate On/Off traffic. During "on" periods, packets are generated at a constant burst rate. During "off" periods, no traffic is generated. Burst times and idle times are taken from exponential distributions. Configuration parameters are:
    PacketSize_
    constant size of packets generated.
    burst_time_
    average on time for generator.
    idle_time_
    average off time for generator.
    rate_
    sending rate during on time.
    Application/Traffic/Pareto
    Application/Traffic/Pareto objects generate On/Off traffic with burst times and idle times taken from pareto distributions. Configuration parameters are:
    PacketSize_
    constant size of packets generated.
    burst_time_
    average on time for generator.
    idle_time_
    average off time for generator.
    rate_
    sending rate during on time.
    shape_
    the shape parameter used by pareto distribution.
    Application/Traffic/CBR
    CBR objects generate packets at a constant bit rate.$cbr start
    Causes the source to start generating packets.
    $cbr stop
    Causes the source to stop generating packets.
    Configuration parameters are:
    PacketSize_
    constant size of packets generated.
    rate_
    sending rate.
    interval_
    (optional) interval between packets.
    random_
    whether or not to introduce random noise in the scheduled departure times. defualt is off.
    maxpkts_
    maximum number of packets to send.
    Application/Traffic/Trace
    Application/Traffic/Trace objects are used to generate traffic from a trace file. $trace attach-tracefile tfile
    Attach the Tracefile object tfile to this trace. The Tracefile object specifies the trace file from which the traffic data is to be read. Multiple Application/Traffic/Trace objects can be attached to the same Tracefile object. A random starting place within the Tracefile is chosen for each Application/Traffic/Trace object.
    There are no configuration parameters for this object.
    TRACEFILE OBJECTS Tracefile objects are used to specify the trace file that is to be used for generating traffic (see Application/Traffic/Trace objects described earlier in this section). $tracefile is an instance of the Tracefile Object.
    $tracefile filename trace-input
    Set the filename from which the traffic trace data is to be read to trace-input.
    There are no configuration parameters for this object. A trace file consists of any number of fixed length records. Each record consists of 2 32 bit fields. The first indicates the interval until the next packet is generated in microseconds. The second indicates the length of the next packet in bytes.

    A simple tcl file (tg.tcl) to demonstrate different traffic sources is provided.

    Some trace files:
    Star Wars

    UM-OLSR patch for ns2

     

    UM-OLSR

    UM-OLSR is an implementation of the OLSR (Optimized Link State Routing) protocol for the ns-2 Network Simulator. The code is released under the terms of the GNU General Public License (GPL). Due to lack of time this project is not maintained by myself any more, feel free to take over the task of maintenance if you are interested.
    UM-OLSR complies with IETF RFC 3626 and supports all core functionalities of OLSR plus the link-layer feedback option. The software has been successfully tested on ns-2, and patches for several versions of the simulator are provided. It is widely employed by the wireless communications research community, as the high number of references in research papers reveal. In addition, it was ported to ns-3 by Gustavo Carneiro (INESC Porto) and to Omnet++ by Alfonso Ariza (Universidad de Málaga). Thus, you can also run OLSR simulations in modern network simulators.

    Features

    • Compliant with core OLSR (as described in RFC 3626).
    • Support for link-layer feedback.
    • Highly configurable from TCL scripts, i.e., without the need of recompiling the whole simulator. You can:
      • Activate/deactivate debug mode.
      • Change the interval at which every message type is sent.
      • Change nodes’ willingness for forwarding data packets on behalf of other nodes.
      • Print whatever data structure managed by a node at a certain time.

    Download

    The source code of UM-OLSR in hosted on SourceForge.net: download.

    Contributed patches

    Here you can find a sample script for configuring a simulation, as well as some UM-OLSR patches for different versions of ns-2 that were contributed by different people. Thanks a lot to all of them.

    Installation

    I assume that you have downloaded and unpackaged the allinone distribution of ns-2 (any of the versions supported by UM-OLSR). Copy um-olsr-0.8.8.tgz (substitute “0.8.8″ for your UM-OLSR version number) into ns-allinone-2.29/ns-2.29/ (substitute “2.29″ for your ns-2 version number), and then do:
    $ cd ns-allinone-2.29/ns-2.29/
    $ tar zxvf um-olsr-0.8.8.tgz
    $ ln -s ./um-olsr-0.8.8 ./olsr
    $ patch -p1 < olsr/um-olsr_ns-2.29_v0.8.8.patch
    If you had not installed ns-2 yet, then do the following:
    $ cd ..
    $ ./install
    On the other hand, if you are installing UM-OLSR on a running installation of ns-2:
    $ ./configure
    $ make distclean
    $ ./configure
    $ make