Skip to content
/ posse Public
forked from dandoh/posse

Toolbox for developing, debugging and evaluating routing algorithms in the presence of holes in wireless sensor networks

Notifications You must be signed in to change notification settings

hieunch/posse

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

71 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

About

Posse is a toolbox for developing, debugging and evaluating routing algorithms in the presence of holes in wireless sensor networks. This is a part of my undergrad research topic. We published a paper with most of the programming and visualization works done by Posse Stable low-stretch routing scheme for wireless sensor networks with a large hole of complicated shape.

Components

The system consists of 3 parts:

  • Castalia (forked from Castalia) as a simulator for Wireless Sensor Networks. As described in the Castalia repo: "Castalia is a simulator for WSNs based on the OMNeT++ platform and can be used by researchers and developers who want to test their distributed algorithms and/or protocols in realistic wireless channel and radio models, with a realistic node behaviour especially relating to access of the radio".
  • A web app acts as a tool to facilitate the process of generating sensor networks, creating holes, selecting regions of communication, sending simulation requests and displaying results
  • Nodejs server act as a bridge from client and the simulator. Server receives simulation requests in the JSON format, transform the request into appropriate .ned Castalia network file, invoke the simulation, parse the result and send back to the client.

In this repo, some features are added to Castalia to support various types of logging, drawing and statistics aggregating. Several well-known routing algorithms in wireless sensor network dealing with the presence of holes in literature are also implemented.

Here is basically how the system works: Alt text

Implemented routing algorithms

  • byPassRouting and multipathRingsRouting, 2 default routing algorithm of Castalia
  • greedyRouting - Greedy routing
  • gpsrRouting - The famous Greedy Perimeter Stateless Routing (GPSR) propsed by Brad Karp and H. T. Kung
  • rollingBallRouting - Greedy Anti-void Routing (GAR) proposed by W. J. Liu and K. T. Feng using the idea of a rolling ball.
  • shortestPathRouting - Shortest Geometric Path Routing, route the packet along side the shortest geometric path which doesn't intersect routing holes.
  • stableRouting - Stable Routing, a routing protocol proposed by members of SEDIC Labs (including the author of the repo) to solve the problem of balancing traffics on the holes boundary and lengthening network lifetime.

The source codes of all routing algorithms are located in Castalia/Castalia/src/node/communication/routing directory.

Drawing and logging APIs

Belows are added APIs to Castalia to support drawing and debugging when developing new routing algorithms. Using a method in drawing APIs will yield the equivalent drawing on client app after submitting and receiving simulation result.

void debugLine(Point, Point, string color);

Draw a line segment between two point with given color

void debugCircle(Point, double, string color);

Draw a circle with given center, radius and color

void debugPoint(Point, string color);

Draw a point in a given location and color

void debugPolygon(vector<Point>, string color);

Draw a polygon given vertices and color

void debugPath(vector<Point>, string color);

Draw a geometric path given vertices and color

void debugArc(Point from, Point to, double radius, string color);

Draw an circle arc from one point to another given radius and color

Example of using drawing APIs: Alt text

Using Client

First step is to create a network Alt text

There are two modes, one is the debug mode, in which we will send simulation information and get the drawing and logging info (from drawing APIs above) from the algorithm we are developing and display on the screen.

Specify pairs of source and destination. Since we're in debug mode, each node will be sending only 1 packet: Alt text Get the drawing info back and render: Alt text

The other is real mode, in which we'll do experiments and evaluations with all of the implemented routing algorithms. In this mode, two regions of communication are selected. [10, 15, 20, 25, 30] communication sessions from A to B (source in A and destination in B) will be generated. The simulation scenario is those pairs of source and destination will constantly send and receive packets with the rate of 4 KB/s (should be customizable later). The result of estimated network lifetime, stretch ratio, heatmap, etc. of each routing algorithms under each network configuration is then displayed in client app.

First step is to select region A and region B: Alt text

Submit and get the result to compare between routing algorithms: Alt text

Installing

Prerequisites

  • Install OMNeT++ 4.6
  • Install Castalia (this modified Castalia on this repo) by following the instruction on the original Castalia repo
  • Install node.js and npm

Castalia

  • Located in Castalia/Castalia directory
  • After adding new routing algorithm or modify source code: $ ./makemake then make to rebuild Castalia (only takes seconds)
  • Make sure posse/Castalia/Castalia/bin is in your PATH by append this into your .bashrc: export PATH=[POSSE DIRECTORY PATH]/Castalia/Castalia/bin:$PATH

Client

  • Located in /client directory.
  • Install dependencies: $ yarn
  • Start the client: $ yarn start

Server

  • Located in /Castalia/Castalia/Simulations/server directory
  • Install dependencies: $ yarn
  • Make sure we have a directory logs and archives in server directory: mkdir logs && mkdir archives
  • Start the server: $ yarn start

About

Toolbox for developing, debugging and evaluating routing algorithms in the presence of holes in wireless sensor networks

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • JavaScript 55.5%
  • C++ 39.6%
  • Batchfile 2.4%
  • Python 1.7%
  • HTML 0.4%
  • Shell 0.2%
  • Other 0.2%