Statistics
| Branch: | Revision:

## mobicen / documents / old / simArchitecture.md @ 9110387b

 1 ---  header-includes:   - \usepackage{float}   - \usepackage{subcaption}   - \usepackage{float}   - \usepackage{textcomp}   - \usepackage{listings}   - \usepackage{graphicx}   - \usepackage{hyperref}  geometry: margin=2cm  ---  # Architecture of the Simulator for the study of Pop-Routing in Mobility with an abstract DV routing protocol  In this document I want to describe the model of routing protocol that will be "embodied" by  the logical architecture of the simulator. I want to add as much details as possible about the  implementation of the simulator, so to share a documentation of the tool that will be used to study  Pop-Routing in Mobility, thus enabling a later soundly-based interpretation of results.  ## Premise  As long as we want to highlight potential differences between a POP and a standard abstract DV routing protocol,  the simulator have to embodies the model of a neighbour-discovery process based on periodic timers. Moreover, obviously,  mobility should have an impact on this process and on the routing convergence speed (if it converges at all!). This said, the important implementation  details are:  - **Message/Channel model**: instantaneous? with probability of failure? tx range? all in broadcast? to physical or logical neigh?  - **States of a Node**: neighbour set, RTs, CentralityTable  - **Network Graph**: a global state parameter of the simulator?  - **Events definition and handling**: Hello and Housecleaning with the same timer? DV are triggered by detected topology change? If I receive a DV  from an unknown Node what should I do? Process or ignore?  ## Unsorted considerations  ### Simulator inputs  - mobility model: ["randomWayPoint", "?"]   - pymobility offers also others interesting model   Random Walk, Random Waypoint (RWP), Random Direction, Truncated Levy Walk, Gauss-Markov, Reference Point Group Mobility model, **Time-variant Community**   - maximum waiting time: For RWP the mobility package defines this parameter as max time a node can stay in the same position  - number of nodes  - simulation area: (MAX_X, MAX_Y)  - velocity: the mobility package ask for a min and max veloc and then uniformly distributes velocity values among nodes  - TXrange: a pure number?  - **mobility_timer**: new coordinates for node at every simulator event? better to set a timer that periodically fires  mobility events  - **hello_Housecleaning_timer**: default timer for hello and housecleaning with the nonPOP protocol. *General question: proportion between hello and housecleaning timer?*  - **DV_timer**: should exist? or only triggered DV? or aggregationTimer for new learned routes?  - duration: time limit for the simulation  ### Simulator fundamentals: main loop and events  Well... A classic DES: events are timestamped and put in a minHeap to be processed as fast as possible.  I imagine 2 kind of events: i) mobility events, ii) message/nodes events.  A generic event has these fields:  - type: Mobility (with blank originator), Hello, Housecleaning, DV?  - originator: a node identifier  - timestamp: float  ##### Mobility event  A mobility event (ME) is not processed by Nodes, should be processed "online" at the "global level"  of the simulator. In particular, every time a ME is fired, new coordinates for all nodes are generated by the mobility package.  Then, according to the TXrange parameter, edges are recomputed and the network_graph (a simulator parameter) is updated.  ##### Message/nodes events  3 kind of events: Hello, Housecleaning, DV. The way to process the first two characterize the "neigh-discovery" model. DV event can be  removed if we imagine they are always triggered (never periodically fired...at convergence they may be never fired but as long as nodes roam...)  - *Hello*: sent in broadcast to "physical neigh", i.e. to neighs of sender/originator according to the graph maintained at the simulator level.  When an Hello is fired, the simulator retrieve the physical neigh of the sender and call on them the "process()" method passing them  the event_descriptor. Basically, when processing "Hello from X", a receiver v should:   - add a neigh in its neighTable if X is new, record the last_heard attribute for v in its neighTable   - or just update the last_heard attribute otherwise   - *if new neighbour ==> send DV as response to detected new neigh*  - *Housecleaning*: when a Housecleaning event is fired, the originator inspects its NeighTable and, according to i) current time, ii) the last_heard  attributes of its neighs and to iii) **remove_interval**\footnote{IT SHOULD BE POP-OPTIMIZED}, removes old neighs.   - If some neigh is lost then ==> update RT (delete destination entries with deleted neigh as NH); then triggers sendDV()  - *DV*: is not actually an event. From the sender perspective, the sender should know how to prepare a DV and how to transmit it. The receiver should use it to update its RT and, if learned something new, decide to trigger sendDV().   - *sendDV*: when its triggered\footnote{Look at actions taken upon Hello and Housecleaning}, the sender node simply prepare the usual dictionary that maps each know destination with the known distance and **broadcast** it to physical neighs, potentially including some new neighs that do not know this sender!)   - *receiveDV*: when a node receive a DV...if the sender is known it's fine. If it's unknown we should interpret it as a Hello followed by a DV.   So what we should do only to process a DV is:   - Bellman-Ford to update RTs; **followed by Centrality Computation and Timers recalibration**\footnote{How to do Recalibration?}   - Keep track of new routing choices   - If there are, trigger a DV  ### Remarks  At present, I foresee a big effort in implementing all the above and there are for sure many ambiguities that will hamper interpretation/validity of results. Still, it can be done in an adequate amount of time if we agree on the model. The alternatives are:  1. Implement mobility in NePa and repeat "The Pop-Routing experiment", i.e. plainOLSR vs POP-OLSR but with nodes moved by NePa  2. Go back to Omnet++, choose a protocol that is implemented in Omnet++ (there is OLSR and now I found also Babel \href{https://arxiv.org/pdf/1609.05215.pdf}{paper}, \href{https://github.com/kvetak/ANSA}{gitRepo}), implement the POP version of the protocol for Omnet and perform "The PopR exp"  in Omnet++