Fuck manet text
This commit is contained in:
parent
4d8aa169e5
commit
1d85158b8e
31
notes.org
31
notes.org
|
@ -281,6 +281,7 @@ than one hop away from the destination), but there is no routing table entry. As
|
|||
- A backhoe is unlikely to take out a major part of the system – at least if we store at k closest nodes
|
||||
|
||||
* Mobile Ad-hoc Networks and Wireless Sensor Networks
|
||||
TODO : READ COOPERATION WITH OTHER PROTOCOLS IN MANET TEXT
|
||||
** Routing in Mobile Ad-hoc Networks
|
||||
*** Introduction
|
||||
- Routing is the process of passing some data, a message, along in a network.
|
||||
|
@ -581,9 +582,35 @@ than one hop away from the destination), but there is no routing table entry. As
|
|||
- Favours nodes in dense areas, due to N, which is amount_of_neighbours.
|
||||
- When number_of_retrans isn't changed, but the sleep time is, packets might be lost. A fix could be to make this variable as well.
|
||||
- Apparently doubles the overall lifetime, as network density rises.
|
||||
|
||||
**** Span
|
||||
|
||||
- Power-save approach based on notion of connected dominating sets (CDSs).
|
||||
- A CDS is a connected subgraph S of G, such that every vertex u in G is either in S or adjacent to some vertex v in S.
|
||||
- So all nodes can be reached from the CDS
|
||||
- A CDS is ideal for routing purposes since the defnition of a CDS means that all nodes of the network can be reached from it. It is therefore possible to use the nodes in the CDS as the only routers in the network.
|
||||
- These are called coordinators. They are the routing backbone.
|
||||
- Non-coordinator nodes are thus not used for routing purposes and they may therefore spend some of their time sleeping.
|
||||
- A coordinator selection scheme attempts to distribute the coordinator responsibility among the nodes.
|
||||
- Nodes have battery capacity and utility. Utility being it's reach in the network.
|
||||
- The coordinator selection algorithm is invoked periodically at every non-coordinator node
|
||||
- So is a coordinator-withdrawal algorithm, at the coordinators.
|
||||
- the potential coordinator node needs information about its one and two-hop neighbours, and for each neighbour also whether that neighbour is a coordinator. This information is maintained pro-actively by using a standard HELLO message approach, as the one described, where each HELLO message contains information about neighbours and coordinators of the sending node.
|
||||
- As mentioned both the utility of the node and the remaining energy is taken into consideration when finding new coordinators. The way that it is implemented is by using a randomised back-off delay that the node uses before announcing itself as a new coordinator.
|
||||
- This ensures there is a somewhat linear relation between energy capacity and willingness to become a coordinator.
|
||||
- Additionally, nodes that offer a good connectivity of the routing backbone are preferred, which means less coordinators overall.
|
||||
- Also, there is a random part, such that the coordinator announcements are evenly distributed.
|
||||
- After waiting for the calculated amount of time two things may have happened:
|
||||
1) Another node in the vicinity may have announced that it wants to become a coordinator
|
||||
2) No one announcements have been heard and the node thus announces that it's now a coordinator.
|
||||
- Nodes can withdraw if everything is connected regardless of it being there or if anything can partly reach each other. Then the node becomes a tentative coordinator, who wants to leave and they aren't considered coordinators, for the coordinator selection algorithm.
|
||||
- Span isn't a routing protocol.
|
||||
- Span doesn't play nicely with AODV, since the neighbourhoods which can be used change often, as only the CDS may forward messages in Span, which results in a lot links breaking constantly. It's fine for geographic forwarding (a greedy GPS dependent protocol) though.
|
||||
*** Span on BECA/AFECA
|
||||
- Span needs to work with another power saving algorithm, that actually puts the nodes to sleep
|
||||
- The neighbourhood information needed by Span can be piggybacked on the HELLO messages used by AODV.
|
||||
- This can be used to build the CDS backbone
|
||||
- We make coordinators be the only nodes who can forward RREQ. RREP simply follow the reverse path, as such no need to worry there.
|
||||
- There is no need to perform retransmissions, since the coordinator nodes are always awake.
|
||||
- A larger ratio between T_l and T_s is allowed, which results in lower energy consumption.
|
||||
* Accessing and Developing WoT
|
||||
** Chapter 6
|
||||
*** REST STUFF
|
||||
|
|
Loading…
Reference in New Issue
Block a user