Ad-hoc Wireless Multi
Point Relay Simulation
CS 293 Project – Final
Submission
Vipul Singh 100050057
Ashwin Paranjape 100050056
Introduction to ‘name’





Ad-hoc – No previous knowledge of network
design assumed
Wireless – All messages broadcasted and no
overall control
Multi-point – Large network (not a clique)
Relay – Information can be transferred to
non-neighbours
Simulator !! (phew …such a long name)
Why to do it?




Ad-hoc-ness – Ability to transfer data
efficiently without prior common infrastructure
Robustness – Control not concentrated at
one place
Scalability – Can extend to any number of
nodes
Its fun !!
What is it all about?


Its about designing protocols to maximize
data transfer with out loss
Make a Simulator to verify the protocols and
algorithms
What have we done ?


Designed 2 independent protocols systems
Feasibilty protocols




RTS-CTS-DTS-DNR
Assuming - Transfer pairs ( Neighbours)
Maximize utiization of available bandwidth
Preprocessing protocols




DBSN-IASN-PSN-FTL
A random map of nodes to Simulator
Nodes preprocess the map (in ~ linear time)
Path from any-node to any other can be found
Inputs and outputs

Inputs



Number of nodes
Time and load factor (RTS-CTS)
Output


All messages as they would be broadcast in
ASCII format
Some special events
Hierarchy of Code
Simulator Class
Node Class
Map Class
GUI
Packet Design
(not class)
Data Stuctures Used






All STL structures
Priority queues (for scheduling)
Adjacency matrix in Simulator (over all coordination)
Vector based adjacency lists (for each node)
Stringstream (emulate string transfers over wireless
as streams and their associated processing)
Lists (storing of trunk-line on SuperNodes – easy
reversal)
Packages Used


Graphwhiz – An excellent graphics package
to show graphs
GNU libplot – X Window GUI, used for
simulating in real time
High level program flow
Feasibility protocols



Map - initialize positions, calculate
bandwidths
Assign initial data transfer pairs
Role of Simulator




reduceed to popping, pushing events
Convaying messages as required by Nodes
Printing statements
Then the Sim world takes care of itself!
(How?)
Properties of Simulator world




There are many nodes which have different
connectivity with some of the other nodes
Different files are scheduled to be transferred
from one node to another
Nodes don’t know the map only Simulator
does
Simulator doesn’t schedule events only
Nodes do.
Map Class


Responsible for generating an initial random
graph and modifying it over time
Also responsible for simulating addition and
deletion of nodes
Improved Feasibilty Protocols




RTS – Request to send
CTS – Clear to send
DTS – Denial to send
DNR – Do not Receive
Problems without any protocol

Extremely dense connectivty and large
number of collisions exp in Ad-hoc networks
Problems with CTS/RTS

Large number of unutilized nodes



Many nodes neighbours of 2 nodes
Need to block all neighbours even if 1 RTS/CTS
without actual data transfer
No Synchronisation (collisions)


CTS and RTS occur along with data transfer
mismatch and collisions of RTS/CTS with data
thus reducing throughput
Solution (Part A)

Time Windows





Request Interval – Demarcate a certain time
interval
Only requests and replies to these requests are
made
Ensures that any non-response is not due to data
transfer happening there but only because certain
decisions are pending on the other side
Random send times for RTS(in request
Window) ideally meaning no collisions
Thus in RI there has to be mechanism which
ensures that schedules maximum throughput
Problems (Part B)


If CTS is not received in response to RTS
then that then the RTS sender has no clue
and can only timeout. Also, the neighbours of
the RTS sender have no way of knowing
whether the RTS sender is going to transfer
data for sure, thus needing to block itself for
the worst case(Pending 2)
Also if the node receives another RTS in this
time interval it has no authority to send CTS
back(Pending 1), leading to a chain of such
dependancies
Problems (Part B)



SMS → All of these protocols taken together
are short messages
Undirected → its nodeID is not there is the
message. In other words the SMS was not
meant for it.
Directed → SMS was meant for it
Solutions (Part B)



Designed 2 new protocols
DTS (Denial to send) – This ensures that if
the node is sure to communicate it will atleast
not block any other node
DNR(Do not recieve) – This ensures that if
certain nodes get RTS, have a determisitic
way of knowing their and there dependants
fates
How it solves the problems



If a node receives send and RTS then it is
bound to receive a CTS or DTS in the
Request window
Thus any RTS sent to it can be replied back
with a DTS/CTS
Undirected CTS means confirmed
communication and the receiver of undirected
CTS needs prevent any further RTS from
being sent. Had it sent an RTS before then
the CTS sender would not have confirmed in
the first place and would have waited for DNR
Preprocessing Protocols





Finding Supernodes and routing algorithm
DBSN – Don’t be a Super Node
IASN – I am Super Node
PSN – Path to Super Node
FTL – Find Trunk Lines
Presentation of Ideas
All the algorithms are presented in
chronological order as they would happen
Many time windows are required

Finding Supernodes (Checking
candidature of a node for a super)



Supernode coefficient calculated, depending
on its bandwidths with neighbours
One with Maximum Supernode coeff. Tells
upto a depth of 2 nodes not be a
supernode(DBSN)
Done by timing DBSN’s so that max-sq Nodes
send first with slight randomness to ward of
neighbouring nodes with same coeffs
Avoiding supernode clusters


DBSN (Don't become super node)sent
immediately to all nodes within a distance of 2
edges
Disables covered nodes from becoming
supernodes in future
Partitioning map into groups





TellSuperNodes function
All supernodes broadcast IASN (I am super
node) with messages delayed according to
bandwidth (to ensure breadth 1st search)
Better knows as Djikstra’s algorithm
Node records 1st such arrival and stores path
to supernode. Also propagates the same with
modified path
All subsequent IASNs discarded and stopped
Database formation in
supernode (PSN)


In a time window, all nodes at random times
start sending their path to supernode (PSN)
At the end of this window, each supernode will
have a complete database of all its children
nodes and the shortest paths to reach them
Finding trunk lines and
information exchange



Confirmed supernode sends FTL , this can
keep propagating and when it reaches a preexisting supernode, trunk line is formed
Also communicated back via same path
Along with this, supernodes share list of
nodes under them with each other through
trunk lines
Data Transfer and routing



In data transfer window, random pairs are
generated
These become source-destination
For already occurring data transfers, further
RTS-CTS occur and accordingly, data transfer
continues
Starting with an initial path


Suppose A and B are chosen source and
destination
Initial path is A → supernode of A (via path
stored in A) → supernode of B (via trunk line)
→ B (via path stored in B's database)
Challenging aspects

Thinking like a node (Node-centric)




Blindfold communication
Understanding the response to evoke (330 LOC)
 Depending upon pending states, whether they are possible
 Whether we are a Super Node
 Implementing proper scheduling for time windows
 Bottom up approach
 Correct BFT (using explicit time delays)
 Extracting proper information from String messages and
putting it in order again
Not letting Simulator have any role in scheduling
Debugging huge outputs
What took time





Everything !!
Analysing algorithms and Forecasting
responses
Avoiding complete flooding, message clashes
Debugging > 6000 lines of output
Designing Algorithms ( 2 week approx. )
Distribution




All algorithmic design after long (and heated)
debated and discussions (taking up most of
time)
Respond function (heart of it all) done
together
Overall input ~ 80-90 hrs hrs each
LOC - ~ 1700 of functional code
Distribution





Map
IASN
PSN
FTL
Event handler





DBSN
RTS
CTS
GUI
Simulator
Further Extenstions
and unimplemented ideas

Shortening of paths
Shortening the initial path (not
implemented)




Trunk lines tend to remain busy, hence get
heated up
So, we shorten paths wherever possible,
mostly around trunk lines
Start from node previous to A's supernode,
send out BFT (upto depth 3) and end up at a
node whose neighbour is on trunk line
Next start from this node, go on till supernode
of B is crossed
Assumptions for designing
Algorithm (subject to review)
There are two modes of transmitting data
from each node



Broadcasting – Data transfer without specifying
recipient node, to be used mainly for
communication between nodes( and not data
transfer), finding shortest paths and checking
connectivity.
Directed – Data transfer with a particular
recipient mentioned in the header of frame
Assumptions for designing
Algorithm (subject to review)



Each node may either receive or send
signals.
When it receives signals from one node it
should neglect signals send by another
node (under review)
It takes finite amount of time to establish
connection and data transfer speed is
proportional to connectivity
Overview of algorithm

To send signals over a single file of nodes we
need to alternate data transfer between
nodes
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Analysis of previous case



Recipient and sender remains idle for atleast
half the amount of time
Initial wait before data starts reaching is
directly proportional to no of nodes in
between and inversely proportional to packet
size (being large)
But the smaller the packet size time overhead
increases to switch between nodes
Another case with two parallel
paths

Connectivity graph
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Source
Destination
Analysis of previous algorithm



The sender and receiver remain busy except
at end and beginning respectively
Data transfer speed approaches to that the
speed of direct connection as packet size
decreases irrespective of no of hops to be
performed
But as switching has a constant cost
associated with it so there exists an optimal
packet size
Overview of Routing algorithm

Motivations




Searching for a file inside a node will require
flooding the whole network, which would create a
lot of congestion
Storing optimal paths to each node from one
particular node is expensive
Due to the dynamism of the situation the optimal
paths are likely to change
Frequent addition or deletion of nodes will cause
unnecessary flooding of the graph
Overview of Routing algorithm

Solution


Construct a hierarchy of nodes, the nodes choose
some representative nodes ( referred to as super
nodes), inspired by hierarchical governance
system
These super-nodes have the task of storing the
indexes of all files around it, it does not participate
in major data transfer activity except its personal
file transfer requirements
Overview of Routing algorithm

Solution




All super-nodes find and store trunk line connecting all
other super nodes
Trunk lines are dedicated to super-node communication
and do not handle other file transfers
Any search request by a node is directed to nearest supernode which then communicates this to other super-nodes
through trunk lines
When a data transfer request from one node to another is
made then it is redirected to nearest super-node, which is
turn asks all super-nodes whether they have the target in
their vicinity. Thus a path is established albeit long one
which passes through the trunk lines
Overview of Routing algorithm

Solution

This path is then shortened by finding bridges
between two nodes.
Analysis of the previous
algorithm




The Super- nodes and trunk line become free of file
transfer and a small route is established
If super-nodes and trunk line are involved in large
quantity of data transfer then their place is taken by
other nodes and they are relieved to prevent battery
consumption
All the metadata stored by super-nodes is archived
in other nodes to prevent loss due to abrupt
disconnection of super-nodes
This idea is to be extended to many levels of
hierarchy thus making it scalable
Initial housekeeping (Ommited
from simulation)


Background – There had been a previous
data transfer going on due to which certain
nodes were occupied. It is important to
maintain continuity of path for them and
exclude them from participation in further
routing
If such a node (which has a data packet with
itself) is seen to have lost connectivity then
BFT is done and first node reached on the
further path is connected to
Checking lost connectivity


Initial connectivity
Red path is the data transfer path
Checking lost connectivity

Previous data transfers
Checking lost connectivity


One path broken
Red path is the data transfer path
Checking lost connectivity

Finding the broken path
Checking lost connectivity

Finding the broken path
NO CTS
SENT
BACK
Checking lost connectivity

Knows its path is broken so starts BFT to find
another node on the path following after it
Checking lost connectivity

Knows its path is broken so starts BFT to find
another node on the path following after it
Checking lost connectivity

This path becomes the new path
Checking lost connectivity


Sends an RTS to the first node expexting a
CTS
Communication on the cutoff (black) node
continues till all data is transferred
Checking lost connectivity
Rebuilding the heirarchy


Every change (mentioned in previuos slides)
has a weight associated with it, cumulative
value of all changes kept track of by
supernodes
When exceeding a certain value, find super
nodes run again on entire graph
Mending broken edges in a tree




Unoccupied node – disconnected from
supernode due to random movements or
deletion
Broadcasts BFT (inclusive of bandwidth)
First in own group to receive replies becomes
new next node
(GROUP – all nodes which are under the
jurisdiction of a single supernode)
Handling direct disconnection to
Supernode






Node sends a HI to supernode
Can be replied with 0 connectivity also
If reply received, node sends BFT and finds
alternate path to supernode
Else, node knows supernode got deleted
Now, FSN (findsupernode) run on all nodes
with that group number only
New supernode found for that group