Adhoc Wireless Multi Point Relay Simulation CS 293

Ad-hoc Wireless Multi Point Relay Simulation CS 293 Project – Final Submission Vipul Singh 100050057 Ashwin Paranjape 100050056

Introduction to ‘name’ l l l 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? l l 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? l l Its about designing protocols to maximize data transfer with out loss Make a Simulator to verify the protocols and algorithms

What have we done ? l l Designed 2 independent protocols systems Feasibilty protocols l l RTS-CTS-DNR Assuming - Transfer pairs ( Neighbours) Maximize utiization of available bandwidth Preprocessing protocols l l 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 l Inputs l l l Number of nodes Time and load factor (RTS-CTS) Output l l 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 l l l 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 Super. Nodes – easy reversal)

Packages Used l l 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 l l l Map - initialize positions, calculate bandwidths Assign initial data transfer pairs Role of Simulator l l 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 l l 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 doesn’t schedule events only Nodes do.

Map Class l l Responsible for generating an initial random graph and modifying it over time Also responsible for simulating addition and deletion of nodes

Improved Feasibilty Protocols l l 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 node. ID 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 l l l 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 Tell. Super. Nodes function All supernodes broadcast IASN (I am super node) with messages delayed according to bandwidth (to ensure breadth 1 st search) Better knows as Djikstra’s algorithm Node records 1 st 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 l Thinking like a node (Node-centric) l l Blindfold communication Understanding the response to evoke (330 LOC) l Depending upon pending states, whether they are possible l Whether we are a Super Node l Implementing proper scheduling for time windows l Bottom up approach l Correct BFT (using explicit time delays) l 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 l l l Everything !! Analysing algorithms and Forecasting responses Avoiding complete flooding, message clashes Debugging > 6000 lines of output Designing Algorithms ( 2 week approx. )

Distribution l l 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 each LOC - ~ 1700 of functional code

Distribution l l l Map IASN PSN FTL Event handler l l l DBSN RTS CTS GUI Simulator

Further Extenstions and unimplemented ideas l 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 l l l 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) l l l 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 l 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 l l l 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 l 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 l l l 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 l Motivations l l 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 l Solution l l 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 l Solution l l 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 l Solution l This path is then shortened by finding bridges between two nodes.

Analysis of the previous algorithm l l 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 RTS

Checking lost connectivity Finding the broken path NO CTS SENT BACK CT S

Checking lost connectivity Knows its path is broken so starts BFT to find another node on the path following after it RTS

Checking lost connectivity Knows its path is broken so starts BFT to find another node on the path following after it RTS

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 S RT

Checking lost connectivity S CT

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