Only missing span from MANET text
This commit is contained in:
parent
10c2d2f2b7
commit
4d8aa169e5
313
notes.org
313
notes.org
|
@ -1,5 +1,5 @@
|
||||||
* Structured P2P Networks
|
* Structured P2P Networks
|
||||||
TODO, potentially read all of the experiments performed in pastry. Potentially not, who cares.
|
TODO, potentially read all of the experiments performed in pastry. Potentially not, who cares. Also the math in Kademlia.
|
||||||
** Chord
|
** Chord
|
||||||
*** Introduction
|
*** Introduction
|
||||||
- A fundamental problem that confronts peer-to-peer applications is to efficiently locate the node that stores a particular data item.
|
- A fundamental problem that confronts peer-to-peer applications is to efficiently locate the node that stores a particular data item.
|
||||||
|
@ -273,6 +273,317 @@ than one hop away from the destination), but there is no routing table entry. As
|
||||||
- This also changes the XOR-based routing apparently.
|
- This also changes the XOR-based routing apparently.
|
||||||
*** Summary
|
*** Summary
|
||||||
- With its novel XOR-based metric topology, Kademlia is the first peer-to-peer system to combine provable consistency and performance, latency-minimizingrouting, and a symmetric, unidirectional topology. Kademlia furthermore introduces a concurrency parameter, α, that lets people trade a constant factor in bandwidth for asynchronous lowest-latency hop selection and delay-free fault recovery. Finally, Kademlia is the first peer-to-peer system to exploit the fact that node failures are inversely related to uptime.
|
- With its novel XOR-based metric topology, Kademlia is the first peer-to-peer system to combine provable consistency and performance, latency-minimizingrouting, and a symmetric, unidirectional topology. Kademlia furthermore introduces a concurrency parameter, α, that lets people trade a constant factor in bandwidth for asynchronous lowest-latency hop selection and delay-free fault recovery. Finally, Kademlia is the first peer-to-peer system to exploit the fact that node failures are inversely related to uptime.
|
||||||
|
** Bouvin notes
|
||||||
|
- While first generation of structured P2P networks were largely application specific and had few guarantees, usually using worst case O(N) time, the second generation is based on structured network overlays. They are typically capable of guaranteeing O(log N) time and space and exact matches.
|
||||||
|
- Much more scalable than unstructured P2P networks measured in number of hops for routing However, churn results in control traffic; slow peers can slowdown entire system (especially in Chord); weak peers may be overwhelmed by control traffic
|
||||||
|
- The load is evenly distributed across the network, based on the uniformness of the ID space More powerful peers can choose to host several virtual peers
|
||||||
|
- Most systems have various provisions for maintaining proper routing and defending against malicious peers
|
||||||
|
- 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
|
||||||
|
** Routing in Mobile Ad-hoc Networks
|
||||||
|
*** Introduction
|
||||||
|
- Routing is the process of passing some data, a message, along in a network.
|
||||||
|
- The message originates from a source host, travels through intermediary hosts and ends up at a destination host.
|
||||||
|
- Intermediary hosts are called routers
|
||||||
|
- Usually a few questions has to be answered when a message is routed:
|
||||||
|
1) How do the hosts acting as routers know which way to send the message?
|
||||||
|
2) What should be done if multiple paths connect the sender and receiver?
|
||||||
|
3) Does an answer to the message have to follow the same path as the original message?
|
||||||
|
- Simple solution: Broadcast message, i.e. send it to every single person you know, every time.
|
||||||
|
- Creates a lot of traffic, it's also known as flooding.
|
||||||
|
- The responsibility of a routing protocol is to answer the three questions posed.
|
||||||
|
*** Basic Routing Protocols
|
||||||
|
- A routing protocol must enable a path or route to be found, through the network
|
||||||
|
- A network is usually modelled as a graph, inside the computers.
|
||||||
|
- This allows for edges to be weighted. Can either be distance, traffic or some metric like that
|
||||||
|
- There are two classes, Link State (LS) and Distance Vector (DS). Main difference being whether or not they use global information.
|
||||||
|
- Algorithms using global information are "Link State", as all nodes need to maintain state information about all links in the network.
|
||||||
|
- Distance Vector algorithms do not rely on global information.
|
||||||
|
**** Link State
|
||||||
|
- All nodes and links with weights are known to all nodes.
|
||||||
|
- This makes the problem a SSSP problem (single-source shortest path)
|
||||||
|
***** Djikstra
|
||||||
|
- A set W is initialised, containing only the source node v.
|
||||||
|
- In each iteration, the edge e with the lowest cost connecting W with a node u which isn't in W, is chosen and u is added to the set.
|
||||||
|
- Algorithm loops n-1 times, and then the shortest path to all other nodes have been found.
|
||||||
|
- Requires each router to have complete knowledge of the network.
|
||||||
|
- Can be accomplished by broadcasting the identities and costs of all of the outgoing links to all other routers in the network. This has to be done, every time a weight or link changes.
|
||||||
|
- Unrealistic for anything but very small networks.
|
||||||
|
- Works great for small stable networks however.
|
||||||
|
**** Distance Vector
|
||||||
|
- No global knowledge is needed
|
||||||
|
- The shortest distance to any given node is calculated in cooperation between the nodes.
|
||||||
|
- Based on Bellman-Ford.
|
||||||
|
- Apparently original Bellman-Ford requires global knowledge. This is a knock-off algorithm.
|
||||||
|
***** Bellman-Ford
|
||||||
|
- Decentralised, no global information is needed
|
||||||
|
- Requires the information of the neighbours and the link costs between them and the node
|
||||||
|
- Each node stores a distance table
|
||||||
|
- The distance table is just a mapping between a node name and the distance to it. It's over all known nodes, so not just neighbours.
|
||||||
|
- When a new node is encountered, this is simply added
|
||||||
|
- Node sends updates to its neighbours. This message states that the distance from the node v to node u has changed. As such, the neighbours can compute their distance to this node u as well and update their table.
|
||||||
|
- This update may cause a chain of updates, as the neighbours might discover that this new distance is better than what they currently had.
|
||||||
|
- The route calculation is bootstrapped by having all nodes broadcast their distances to their neighbours, when the network is created.
|
||||||
|
- Algorithm
|
||||||
|
1) Distance table is initialised for node x
|
||||||
|
2) Node x sends initial updates to neighbours
|
||||||
|
3) The algorithm loops, waiting for updates or link cost changes of directly connected links (neighbours (?))
|
||||||
|
4) Whenever either event is received, the appropriate actions are taken, such as sending updates or changing values in the distance table
|
||||||
|
- Generates less traffic, since only neighbours are needed to be known.
|
||||||
|
- Doesn't need global knowledge, general advantage in large networks or networks with high churn rate
|
||||||
|
- Doesn't have to recompute the entire distance table whenever a single value changes, as Djikstras algorithm has to.
|
||||||
|
- Suffers from the "Count-to-infinity" problem, which happens when a route pass twice through the same node and a link starts going towards infinity. If there is a network A - B - C - D. A dies. B sets the distance to infinity. When tables are shared, B sees that C knows a route to A of distance 2, as such it updates its distance to 3. (1 to C, 2 from C to A). C then has to update its distance to A to 4 and so it goes.
|
||||||
|
- A way of avoiding this, is only sending information to the neighbours that are not exclusive links to the destination, so C shouldn't send any information to B about A, as B is the only way to A.
|
||||||
|
*** MANET Routing
|
||||||
|
- Both Djikstra and Bellman-Ford were designed to operate in fairly stable networks.
|
||||||
|
- MANETs are usually quite unstable, as possibly all nodes are mobile and may be moving during communication.
|
||||||
|
- MANETs typically consist of resource-poor, energy constrained devices with limited bandwidth and high error rates.
|
||||||
|
- Also has missing infrastructure and high mobility
|
||||||
|
- According to Belding-Royer (who he??), the focus should be on the following properties
|
||||||
|
1) Minimal control overhead (due to limited energy and bandwidth)
|
||||||
|
2) Minimal processing overhead (Typically small processors)
|
||||||
|
3) Multihop routing capability (No infrastructure, nodes must act as routers)
|
||||||
|
4) Dynamic topology maintenance (High churn rates forces topology to be dynamic and be capable of easily adapting)
|
||||||
|
5) Loop prevention (Loops just take a lot of bandwidth)
|
||||||
|
- MANET routing protocols are typically either pro-active or re-active.
|
||||||
|
***** Proactive
|
||||||
|
- Every node maintains a routing table of routes to all other nodes in the network
|
||||||
|
- Routing tables are updated whenever a change occurs in the network
|
||||||
|
- When a node needs to send a message to another node, it has a route to that node in its routing table
|
||||||
|
- Two examples of proactive protocols
|
||||||
|
1) Destination-sequenced distance vector (DSDV)
|
||||||
|
2) Optimised link state routing (OSLR)
|
||||||
|
***** Reactive
|
||||||
|
- Called on-demand routing protocols
|
||||||
|
- Does not maintain routing tables at all times
|
||||||
|
- A route is discovered when it is needed, i.e. when the source has some data to send
|
||||||
|
- Two examples of reactive protocols
|
||||||
|
1) Ad-hoc on demand distance vector (AODV)
|
||||||
|
2) Dynamic source routing (DSR)
|
||||||
|
***** Combination of proactive and reactive
|
||||||
|
- Zone Routing Protocol (ZRP)
|
||||||
|
**** Local connectivity management
|
||||||
|
- MANET protocols have in common, that they need to have a mechanism that allows discovery of neighbours
|
||||||
|
- Neighbours are nodes within broadcast range, i.e. they can be reached within one hop
|
||||||
|
- Neighbours can be found by periodically broadcasting "Hello" messages. These won't be relayed. These messages contain information about the neighbours known by the sending node.
|
||||||
|
- When a hello message from x is received by y, y can check, if y is in the neighbour list of x. If y is there, the link must be bi-directional. Otherwise, it's likely uni-directional.
|
||||||
|
**** Destination-Sequenced Distance Vector
|
||||||
|
- Uses sequence numbers to avoid loops.
|
||||||
|
- Has message overhead which grows as O(n²), when a change occurs in the network.
|
||||||
|
***** Using sequence numbers
|
||||||
|
- Each node maintains a counter that represents its current sequence number. This counter starts at zero and is incremented by two whenever it is updated.
|
||||||
|
- A sequence number set by a node itself, will always be even.
|
||||||
|
- The number of a node is propagared through the network in the update messages that are sent to the neighbours.
|
||||||
|
- Whenever an update message is sent, the sender increments its number and prefixes this to the message.
|
||||||
|
- Whenever an update message is received, the receiver can get the number. This information is stored in the receiving nodes route table and is further propagated in the network in subsequent update messages sent, regarding routes to that destination.
|
||||||
|
- Like this, the sequence number set by the destination node is stamped on every route to that node.
|
||||||
|
- Update messages thus contain; a destination node, a cost of the route, a next-hop node and the latest known destination sequence number.
|
||||||
|
- On receiving an update message, these rules apply:
|
||||||
|
1) If the sequence number of the updated route is higher than what is currently stored, the route table is updated.
|
||||||
|
2) If the numbers are the same, the route with the lowest cost is chosen.
|
||||||
|
- If a link break is noticed, the noticer sets the cost to be inf to that node and increments the gone node's sequence number by one and sends out an update.
|
||||||
|
- Thus, the sequence number is odd, whenever a node discovers a link breakage.
|
||||||
|
- Because of this, any further updates from the disappeared node, will automatically supersede this number
|
||||||
|
- This makes DSDV loop free
|
||||||
|
- Sequence numbers are changed in the following ways
|
||||||
|
1) When a line breaks. The number is changed by a neighbouring node. Link breakage can't form a loop
|
||||||
|
2) When a node sends an update message. The node changes its own sequence number and broadcasts this. This information is passed on from the neighbours.
|
||||||
|
- Thus, the closer you are, the more recent sequence number you know.
|
||||||
|
- When picking routes, we trust the routers who knows the most recent sequence number, in addition to picking the shortest route.
|
||||||
|
***** Sending updates
|
||||||
|
- Two types of updates; full and incremental
|
||||||
|
- Full updates contain information about all routes known by the sender. These are sent infrequently.
|
||||||
|
- Incremental updates contain only changed routes. These are sent regularly.
|
||||||
|
- Decreases control bandwidth.
|
||||||
|
- Full updates are sent in some relatively large interval
|
||||||
|
- Incremental updates are sent frequently
|
||||||
|
- Full updates are allowed to use multiple network protocol data units, NPDUs (??????), whereas incremental can only use one. Too many incremental to fit in a single -> send full instead
|
||||||
|
- When an update to a route is received, different actions are taken, depending on the information:
|
||||||
|
1) If it's a new route, schedule for immediate update, send incremental update ASAP
|
||||||
|
2) If a route has improved, send in next incremental update
|
||||||
|
3) If sequence number has changed, but route hasn't, send in next incremental if space
|
||||||
|
***** Issue
|
||||||
|
- Suffers from routing fluctuations
|
||||||
|
- A node could repeatedly switch between a couple of routes
|
||||||
|
- Essentially, one route is slower, but for some reason the update comes from that first, while the other is quicker, but the number comes slower. You receive an update and update the route to be the slowest. Then you receive the slower update and have to to another update, as the new route is shorter.
|
||||||
|
- Fixed by introduction delay. If the cost to a destination changes this information is scheduled for advertisement at a time depending on the average settling time for that destination.
|
||||||
|
**** Optimised Link State Routing
|
||||||
|
- Designed to be effective in an environment with a dense population of mobile devices, which communicate often.
|
||||||
|
- Introduces multi point relay (MPR) sets. These are a subset of one-hop neighbours of a node, that is used for routing the messages of that node. These routers are called MPR selectors.
|
||||||
|
***** Multipoint relay set
|
||||||
|
- Selected independently by each node as a subset of its neighbours.
|
||||||
|
- Selected such that the set covers all nodes that are two hops away
|
||||||
|
- Doesn't have to be optimal
|
||||||
|
- Each node stores a list of both one-hop and two-hop neighbours. Collected from the hello messages which are broadcasted regardless. These should also contain neighbours. This means that all neighbours of the one-hop neighbours, must be the set of two-hop neighbours. We can then simply check if we know all.
|
||||||
|
***** Routing with MPR
|
||||||
|
- A topology control (TC) message is required to create a routing table for the entire network
|
||||||
|
- This is sent via the MPR and will eventually reach the entire network. It's not as much flooding as the standard LS algorithm.
|
||||||
|
**** Ad-hoc On-Demand Distance Vector
|
||||||
|
- Reactive
|
||||||
|
- Routes are acquired when they are needed
|
||||||
|
- Assumes symmetrical links
|
||||||
|
- Uses sequence numbers to avoid loops
|
||||||
|
***** Path Discovery
|
||||||
|
- When a node wishes to send something, a path discovery mechanism is triggered
|
||||||
|
- If node x wishes to send something to node y, but it doesn't know a route to y, a route request (RREQ) message is send to x's neighbours. The RREG contains:
|
||||||
|
1) Source address
|
||||||
|
2) Source seq no
|
||||||
|
3) Broadcast id - A unique id of the current RREQ
|
||||||
|
4) Destination addr
|
||||||
|
5) Destionation seq no
|
||||||
|
6) Hop count - The number of hops so far, incremented when RREQ is forwarded
|
||||||
|
- (source addr, broadcast id) uniquely identifies a RREQ. This can be used to check if RREG has been seen before.
|
||||||
|
- When RREQ is received, two actions can be taken
|
||||||
|
1) If a route to the destination is known and that path has a sequence number equal or greater than the destionation seq no in the RREQ, it responds to the RREQ by sending a RREP (route reply) back to the source.
|
||||||
|
2) If it doesn't have a recent route, it broadcasts the RREQ to neighbours with an increased hop count.
|
||||||
|
- When a RREQ is received, the address of the neighbour from whom this was received, is recorded. This allows for the generation of a reverse path, should the destination node be found.
|
||||||
|
- RREP contains source, destination addr, destionation seq no, the total number of hops from source to dest and a lifetime value for the route.
|
||||||
|
- If multiple RREPs are received by an intermediary node, only the first one is forwarded and the rest are forwarded if their destination sequence number is higher or they have a lower hop count, but the same dest seq no.
|
||||||
|
- When the RREP is send back to the source, the intermediary nodes record which node they received the RREP from, to generate a forward path to route data along.
|
||||||
|
***** Evaluation
|
||||||
|
- Tries to minimise control traffic flowing, by having nodes only maintain active routes.
|
||||||
|
- Loops prevented with sequence numbers
|
||||||
|
- No system wide broadcasts of entire routing tables
|
||||||
|
- Every route is only maintained, as long as it's used. It has a timeout and is discarded, if this timeout is reached.
|
||||||
|
- Path finding can be costly, as a long of RREG gets propagated through the network
|
||||||
|
- Expanding ring algorithm can help control the amount of messages going out, but if the receiver isn't close, this can be even more costly than the standard way
|
||||||
|
- Upon link failure; Upstream neighbour sends RREP with seq. no. +1 and hop count set to infinity to any active neighbours—that is neighbours that are using the route.
|
||||||
|
**** Dynamic Source Routing
|
||||||
|
- On-demand protocol
|
||||||
|
- DSR is a source routing protocol. This is main difference between DSR and AODV
|
||||||
|
- Source routing is a technique, where every message contains a header describing the entire path that the message must follow.
|
||||||
|
- When a message is received, the node checks if it's the destination node, if not, it forwards the message to the next node in the path.
|
||||||
|
- There is no need for intermediate nodes to keep any state about active routes, as was the case in the AODV protocol.
|
||||||
|
- DSR doesn't assume symmetrical links and can use uni-directional links, i.e. one route can be used from A to B and then a different route from B to A.
|
||||||
|
***** Path Discovery
|
||||||
|
- Discovery is similiar to AODV
|
||||||
|
- RREQ contains the source and destination address and a request id.
|
||||||
|
- Source address and request id defines the RREQ
|
||||||
|
- When an intermediate node receives a RREQ it does a few things.
|
||||||
|
1) If it has no route to the dest, it appends itself to the list of nodes in the RREQ and then forwards it to its neighbours
|
||||||
|
2) If it does have a route to the dest, it appends this route to the list of nodes and sends a RREP back to the source, containing this route.
|
||||||
|
- This system uses the same amount of messages, as AODV, and finds the same routes.
|
||||||
|
- When a node is ready to send RREP back to source, it can do one of 3 things:
|
||||||
|
1) If it already has a route to the source, it can send RREP back along this path
|
||||||
|
2) It can reverse the route in the RREP (i.e., the list the nodes append themselves to, when forwarding)
|
||||||
|
3) It can initiate a new RREQ to find a route to the source
|
||||||
|
- The second option assumes symmetrical links.
|
||||||
|
- The third approach can cause a loop, as the source and the dest host can endlessly look for each other
|
||||||
|
- Can be avoided by piggybacking the RREP on the second RREQ message. The receiver of this RREQ will be given a path to use when returning the reply.
|
||||||
|
***** Route cache
|
||||||
|
- There is no route table
|
||||||
|
- DSR use a route cache of currently known routes. The route cache of a node is in effect a tree rooted at the node
|
||||||
|
- This tree can contain multiple routes to a single destination
|
||||||
|
- This means it's most robust against broken links, as even though a link breaks, another can maybe be used
|
||||||
|
- Might take up O(n²) space
|
||||||
|
***** Promiscuous mode operation
|
||||||
|
- DSR takes advantage of the fact that wireless devices can overhear messages that aren't addressed to them.
|
||||||
|
- Since messages tend to be broadcasted, other nodes within the range of the broadcast, can also read the message
|
||||||
|
- Having nodes overhear messages that are not addressed to them, is called promiscuous mode operation.
|
||||||
|
- It's not required for DSR to work, but it improves the protocol.
|
||||||
|
- When two nodes on a path moves out of transmission range, some sort of acking mechanism must be used. This is usually done by using link-layer acks, but if such functionality isn't available, this must be done through other means.
|
||||||
|
- A passive ack is when a host, after sending a message to the next hop host in a path, overhears that the receiving host is transmitting the message again. This can be taken as a sign, that the host has in fact received the message and is now in the process of forwarding it towards the next hop.
|
||||||
|
- A host that overhears a message may add the route of the message to its route cache
|
||||||
|
- It might also be an error message, then the route cache can be corrected.
|
||||||
|
- Can also be used for route shortening, if A sends to B who sends to C, but C overhears the message to B, C can send an RREP to A and let A know the route can be shortened.
|
||||||
|
***** Evaluation
|
||||||
|
- Like AODV, DSR only uses active routes, i.e. routes timeout
|
||||||
|
- Control messages used are kept low by using same optimisations as AODV
|
||||||
|
- Storage overhead is O(n) - Route cache and information about recently received RREQ
|
||||||
|
- Loops are easily avoided in source routing, since nodes can just check if they're already a part of a path. If so, message is discarded.
|
||||||
|
**** Zone Routing Protocol
|
||||||
|
- Hybrid protocol
|
||||||
|
- In ZRP, each node defines a zone consisting of all of it's n-hop neighbours, where n may be varied.
|
||||||
|
- Within this zone, the node proactively maintains a routing table of routes to all other nodes in the zone. This is done using intrazone routing protocol, which is LS based.
|
||||||
|
- These zones can be used, when sending to nodes within the zone
|
||||||
|
- Outside the zone, a re-active interzone routing scheme is used.
|
||||||
|
- This uses a concept called bordercasting.
|
||||||
|
- The source node sends a route request (essentially an RREQ message) to all of the nodes on the border of its zone.
|
||||||
|
- These border nodes check if they can reach the dest directly. If not, they propagate the message to their border nodes.
|
||||||
|
***** Evaluation
|
||||||
|
- Less control traffic when doing route discovery, as messages are either sent to border nodes (skipping a lot of intermediary hops) or they're sent directly to someone within the zone.
|
||||||
|
- More control messages within limited range of the zones though.
|
||||||
|
- Storage complexity of O(n²) where n is the number of neighbours within the zone.
|
||||||
|
- Since LS is used, the running time is O(m + n log n), where m is edges connecting the n nodes in the zone.
|
||||||
|
- In dense scenarios, ZRP won't be feasible.
|
||||||
|
|
||||||
|
** Energy Efficient MANET Routing
|
||||||
|
- All mentioned protocols in chapter 2 try to minimise control traffic, which, albeit does save energy since transmitting fewer messages is nice, but this is done primarily to avoid wasting bandwidth.
|
||||||
|
*** Introduction to energy efficient routing
|
||||||
|
- Two main approaches
|
||||||
|
1) Power-save
|
||||||
|
2) power-control
|
||||||
|
- Power-save is concerned with sleep states. In a power-save protocol the mobile nodes utilise that their network interfaces can enter into a sleep state where less energy is consumed.
|
||||||
|
- Power-control utilises no sleep states. Instead the power used when transmitting data is varied; which also varies transmission range of nodes.
|
||||||
|
- Power-control can save some energy, but the real energy saver is in power-save, as the real waste in most MANETs is idle time.
|
||||||
|
- As such, power-save is the most important, but power-control can be used to complement it.
|
||||||
|
- Goal of the energy efficiency is important to define:
|
||||||
|
- One approach is to maximise overall lifetime of the entire network
|
||||||
|
- Stronger nodes that have a longer battery life, may be asked to do a lot of the heavy lifting.
|
||||||
|
- Another approach is to use minimum energy when routing, such that the route using the minimum amount of energy is taken.
|
||||||
|
- The physical position of nodes can be important when making routing decisions.
|
||||||
|
- Protocols tend to assume there is some positioning mechanism available, such as GPS.
|
||||||
|
- This is not assumed here.
|
||||||
|
- A third energy saving approach is load balancing. The protocol attempts to balance the load in such a way that it maximises overall lifetime. (This sounds a lot like having a few strong nodes do heavylifting)
|
||||||
|
*** The power-control approach
|
||||||
|
- Power-control protocols cut down on energy consumption by controlling the transmission power of the wireless interfaces.
|
||||||
|
- Turning down transmission power when sending to neighbours is nice. It consumes less energy for the sender, since the range is lowered, less nodes have to spend energy overhearing the message.
|
||||||
|
- There is a non-linear relation between transmission range and energy used, thus, more hops might in fact yield less energy spent.
|
||||||
|
- System called PARO uses this, as it allows more intermediary nodes, if this lowers the overall cost of the path.
|
||||||
|
*** Power-save approach
|
||||||
|
- Protocols that use the power-save approach cut down on energy consumption by utilising the sleep states of the network interfaces
|
||||||
|
- When a node sleeps, it can't participate in the network
|
||||||
|
- This means these protocols have to either
|
||||||
|
1) use retransmissions of messages to make sure that a message is received
|
||||||
|
2) make sure that all of the nodes do not sleep at the same time, and thus delegate the work of routing data to the nodes that are awake.
|
||||||
|
- Power-save protocols define ways in which nodes can take turns sleeping and being awake, so that none, or at least a very small percentage of the messages sent in the network are lost, due to nodes being in the sleep state.
|
||||||
|
- They are specifications of how it is possible to maximise the amount of time that nodes are sleeping, while still retaining the same connectivity and loss rates comparable to a network where no nodes are sleeping.
|
||||||
|
- IEEE 802.11 ad hoc power saving mode, part of the IEEE standard, uses sleep states.
|
||||||
|
- It uses the protocol on the link layer and is as such independent of which routing protocol is used on network layer.
|
||||||
|
- BECA/AFECA uses retransmissions
|
||||||
|
- Span specifices when nodes can sleep and delegates routing to the rest
|
||||||
|
**** IEEE
|
||||||
|
- Beacon interval within which each node can take a number of actions
|
||||||
|
- In the end of each beacon interval, the nodes compete for transmission of the next beacon, the one who first transmits, win.
|
||||||
|
- In the beginning of ea h bea on interval all nodes must be awake.
|
||||||
|
- It works in a few phases, where nodes can announce to receivers that they want to send stuff. After this phase, any node which wasn't contacted, can safely sleep.
|
||||||
|
**** BECA/AFECA
|
||||||
|
- The difference between BECA and AFECA is that AFECA takes node density into consideration when determining the period of time that a node may sleep.
|
||||||
|
- Both approaches are only power saving algorithms and not routing protocols. This means that they need to work together with some existing MANET routing protocol.
|
||||||
|
- It makes sense to choose an on-demand routing protocol for this purpose, as pro-active would keep the nodes alive.
|
||||||
|
***** Basic Energy-Conserving algorithm (BECA)
|
||||||
|
- Based on retransmissions
|
||||||
|
- Consists of timing information that defines the periods that nodes spend in the different states defined by the algorithm, and a specification of how many retransmissions are needed.
|
||||||
|
- BECA has three states
|
||||||
|
1) sleeping
|
||||||
|
2) listening
|
||||||
|
3) active
|
||||||
|
- Some rules to ensure no messages are lost
|
||||||
|
1) T_listen = T_retransmissions
|
||||||
|
2) T_sleep = k * T_retransmissions, for some k
|
||||||
|
3) Number_of_retrans >= k + 1
|
||||||
|
4) T_idle = T_retransmissions
|
||||||
|
- If A sends to B, but B sleeps, the message will be retrans R >= k + 1 times with interval T_restrans, until the message has been received.
|
||||||
|
- Since T_sleep is defined as k * T_retrans, at least one of the retrans will be received, even when B sleeps just before A transmits the message.
|
||||||
|
- Incurs higher latency, worst case k * T_retrans and on average (k * T_retrans) / 2. This latency is added for each hop.
|
||||||
|
- Thus, to keep this low, k must be somewhat small, which counteracts the energy saving.
|
||||||
|
- Thus, one needs to find a nice ratio.
|
||||||
|
- Apparently k = 1 is nice.
|
||||||
|
- A nice feature of BECA, which also applies to AFECA, is that in high traffic scenarios, where all nodes are on at all times, nodes are simply kept in the active state. In this way the power saving mechanism is disabled and the performance of the protocol is thus as good as the underlying protocol.
|
||||||
|
***** Adaptive Fidelity energy-conserving algorithm (AFECA)
|
||||||
|
- Same power save model as BECA, except instead of T_sleep, it has T_varia_sleep
|
||||||
|
- T_vs is varied according to amount of neighbours surrounding a node.
|
||||||
|
- This is estimated when in listening state, according to how many are overheard.
|
||||||
|
- Nodes are removed from the estimation after they timeout at T_gone time.
|
||||||
|
- T_vs is then defined as T_vs = Random(1, amount_of_neighbours) * T_sleep
|
||||||
|
- Sleep time of (N * T_sleep) / 2 on average
|
||||||
|
- 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
|
||||||
|
|
||||||
* Accessing and Developing WoT
|
* Accessing and Developing WoT
|
||||||
** Chapter 6
|
** Chapter 6
|
||||||
*** REST STUFF
|
*** REST STUFF
|
||||||
|
|
Loading…
Reference in New Issue
Block a user