Statistics
| Branch: | Revision:

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

History | View | Annotate | Download (6.75 KB)

1
---
2
header-includes:
3
  - \usepackage{float}
4
  - \usepackage{subcaption}
5
  - \usepackage{float}
6
  - \usepackage{textcomp}
7
  - \usepackage{listings}
8
  - \usepackage{graphicx}
9
  - \usepackage{hyperref}
10
geometry: margin=2cm
11
---
12

    
13
# Architecture of the Simulator for the study of Pop-Routing in Mobility with an abstract DV routing protocol
14

    
15
In this document I want to describe the model of routing protocol that will be "embodied" by
16
the logical architecture of the simulator. I want to add as much details as possible about the
17
implementation of the simulator, so to share a documentation of the tool that will be used to study
18
Pop-Routing in Mobility, thus enabling a later soundly-based interpretation of results.
19

    
20
## Premise
21

    
22
As long as we want to highlight potential differences between a POP and a standard abstract DV routing protocol,
23
the simulator have to embodies the model of a neighbour-discovery process based on periodic timers. Moreover, obviously,
24
mobility should have an impact on this process and on the routing convergence speed (if it converges at all!). This said, the important implementation
25
details are:
26

    
27
- **Message/Channel model**: instantaneous? with probability of failure? tx range? all in broadcast? to physical or logical neigh?
28
- **States of a Node**: neighbour set, RTs, CentralityTable
29
- **Network Graph**: a global state parameter of the simulator?
30
- **Events definition and handling**: Hello and Housecleaning with the same timer? DV are triggered by detected topology change? If I receive a DV
31
from an unknown Node what should I do? Process or ignore?
32

    
33
## Unsorted considerations
34

    
35
### Simulator inputs
36

    
37
- mobility model: ["randomWayPoint", "?"] 
38
  - pymobility offers also others interesting model
39
  Random Walk, Random Waypoint (RWP), Random Direction, Truncated Levy Walk, Gauss-Markov, Reference Point Group Mobility model, **Time-variant Community**
40
  - maximum waiting time: For RWP the mobility package defines this parameter as max time a node can stay in the same position
41
- number of nodes
42
- simulation area: (MAX_X, MAX_Y)
43
- velocity: the mobility package ask for a min and max veloc and then uniformly distributes velocity values among nodes
44
- TXrange: a pure number?
45
- **mobility_timer**: new coordinates for node at every simulator event? better to set a timer that periodically fires
46
mobility events
47
- **hello_Housecleaning_timer**: default timer for hello and housecleaning with the nonPOP protocol. *General question: proportion between hello and housecleaning timer?*
48
- **DV_timer**: should exist? or only triggered DV? or aggregationTimer for new learned routes?
49
- duration: time limit for the simulation
50

    
51
### Simulator fundamentals: main loop and events
52

    
53
Well... A classic DES: events are timestamped and put in a minHeap to be processed as fast as possible.
54
I imagine 2 kind of events: i) mobility events, ii) message/nodes events.
55

    
56
A generic event has these fields:
57

    
58
- type: Mobility (with blank originator), Hello, Housecleaning, DV?
59
- originator: a node identifier
60
- timestamp: float
61

    
62
##### Mobility event
63

    
64
A mobility event (ME) is not processed by Nodes, should be processed "online" at the "global level"
65
of the simulator. In particular, every time a ME is fired, new coordinates for all nodes are generated by the mobility package.
66
Then, according to the TXrange parameter, edges are recomputed and the network_graph (a simulator parameter) is updated.
67

    
68
##### Message/nodes events
69

    
70
3 kind of events: Hello, Housecleaning, DV. The way to process the first two characterize the "neigh-discovery" model. DV event can be
71
removed if we imagine they are always triggered (never periodically fired...at convergence they may be never fired but as long as nodes roam...)
72

    
73
- *Hello*: sent in broadcast to "physical neigh", i.e. to neighs of sender/originator according to the graph maintained at the simulator level.
74
When an Hello is fired, the simulator retrieve the physical neigh of the sender and call on them the "process()" method passing them
75
the event_descriptor. Basically, when processing "Hello from X", a receiver v should:
76
  - add a neigh in its neighTable if X is new, record the last_heard attribute for v in its neighTable
77
  - or just update the last_heard attribute otherwise
78
  - *if new neighbour ==> send DV as response to detected new neigh*
79

    
80
- *Housecleaning*: when a Housecleaning event is fired, the originator inspects its NeighTable and, according to i) current time, ii) the last_heard
81
attributes of its neighs and to iii) **remove_interval**\footnote{IT SHOULD BE POP-OPTIMIZED}, removes old neighs. 
82
  - If some neigh is lost then ==> update RT (delete destination entries with deleted neigh as NH); then triggers sendDV()
83

    
84
- *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().
85
  - *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!)
86
  - *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.
87
  So what we should do only to process a DV is:
88
    - Bellman-Ford to update RTs; **followed by Centrality Computation and Timers recalibration**\footnote{How to do Recalibration?}
89
    - Keep track of new routing choices
90
    - If there are, trigger a DV
91

    
92
### Remarks
93

    
94
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:
95

    
96
1. Implement mobility in NePa and repeat "The Pop-Routing experiment", i.e. plainOLSR vs POP-OLSR but with nodes moved by NePa
97
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"
98
in Omnet++ 
99

    
100

    
101

    
102

    
103

    
104
<!--
105
\begin{center}
106
\setlength{\unitlength}{1cm}
107
\begin{picture}(6,6)(-3,-3)
108
\put(-1.5,0){\vector(1,0){3}}
109
\put(2.7,-0.1){$\chi$}
110
\put(0,-1.5){\vector(0,1){3}}
111
\multiput(-2.5,1)(0.4,0){13}
112
{\line(1,0){0.2}}
113
\multiput(-2.5,-1)(0.4,0){13}
114
{\line(1,0){0.2}}
115
\put(0.2,1.4)
116
{$\beta=v/c=\tanh\chi$}
117
\qbezier(0,0)(0.8853,0.8853)
118
(2,0.9640)
119
\qbezier(0,0)(-0.8853,-0.8853)
120
(-2,-0.9640)
121
\put(-3,-2){\circle*{0.2}}
122
\end{picture}
123
\end{center}
124

    
125

    
126
\begin{figure}
127
  \caption{A picture of a gull.}
128
  \centering
129
    \includegraphics[width=0.5\textwidth]{gull}
130
\end{figure}
131
-->