5375d22dc77fcd16586a592d09d6ced8.ppt
- Количество слайдов: 34
Opportunistic Routing in Multi-hop Wireless Networks* A. Zubow Sanjit Biswas and Robert Morris, SIGCOMM 2005, pdos. csail. mit. edu/papers/roofnet: exor-sigcomm 05/roofnet_exor-sigcomm 05. pdf
Traditional wireless routing • Abstraction – wireless radio looks like a link – wireless network looks like a graph • Routing protocol computes shortest paths on graph – Routing protocols: AODV, DSR, TORA, DSDV, OLSR – Link metrics: hop count, ETX, ETT, WCETT packet A packet B src dst 2 C
Radios aren’t wires A 3 4 56 56 1 2 3 45 6 B src dst C • Every packet is broadcast • Reception is probabilistic 3
Basic Idea • In wireless networks, – use of channel diversity => better performance – e. g. , time diversity, spatial diversity, frequency diversity • Probabilistic reception of a single broadcast at different receivers provides such a form of diversity. 4
Key idea • Delayed binding of next hop – Node broadcasts packet – No next hop specified • Due to probabilistic reception, different receiver nodes may/may not receive packet • Receiver “closest” to destination becomes the next hop, i. e. , it will forward the packet towards destination. 5
Key idea packet A packet B src dst C 6
Why this might work … src N 1 N 2 N 3 N 4 N 5 dst 75% 50% 25% • • Assumes probability falls off gradually with distance Best traditional route over 50% hops: 3(1/0. 5) = 6 tx Throughput 1/# transmissions Ex. OR exploits lucky long receptions: 4 transmissions 7
Why this might work … N 1 5% 2 src N 2 25% N 3 25 10 0% 100% dst % 00 1 % N 4 • Assume independent losses • Traditional routing: 1/0. 25 + 1 = 5 tx • Ex. OR: 1/(1 – 0. 25)4) + 1 = 2. 5 transmissions 8
Challenges in protocol design • Agreement protocol: nodes must agree on the subset of them that received the packet • Scheduling protocol: to minimize collisions between different nodes by avoiding simultaneous transmission • Efficiency in forwarding: node “closest” to destination that receives packet should become forwarder • Only nodes that are really useful should participate 9
Ex. OR batching tx: 12 tx: 100 src ` rx: 85 57 N 2 tx: 34 N 4 rx: 40 0 tx: 0 rx: 22 0 dst 99 rx: 88 N 1 tx: 31 N 3 53 rx: 23 tx: 23 • Send batches of packets for efficiency • Node closest to the dst sends first – Other nodes listen, send remaining packets in turn • Repeat schedule until dst has whole batch 10
Protocol Design: Outline • Source sends packets in batches • Source includes a priority list of forwarders, ordered by “distance” to destination in every packet header. • Scheduling: Lower priority nodes wait for higher priority nodes before transmitting. • A “batch map” is used for agreement: indicates the highest priority node that has received each packet – included in the packet header – updated from higher priority nodes back towards lower priority nodes – provides an acknowledgement 11
Protocol Design • Layer 2. 5 solution • Batching: Batch. Sz Batch. ID Pkt. Num • Scheduling: Frag. Num Frag. Sz • Agreement: Batch Map 12
Priority ordering of forwarders N 2 N 4 src dst N 1 N 3 • Goal: nodes “closest” to the destination send first • Sort by (modified) ETX metric to dst – Nodes periodically flood ETX “link state” measurements – Path ETX is weighted shortest path (Dijkstra’s algorithm) • Source sorts and includes list in Ex. OR header 13
Digression: ETX primer • Measurement of link ETX metric: – Measure forward probability of loss pf using periodic HELLO packets – Then, ETX = 1/pf • If the link is i. i. d Bernoulli with loss probability pf, then ETX = expected number of retransmissions for success. • Path ETX = sum of link ETX along path • Can be computed using Djikstra or Bellman Ford 14
Digression: ETX primer 15
Batch-map: Reliable summaries tx: {2, 4, 10. . . 97, 98} summary: {1, 2, 6, . . . 97, 98, 99} N 2 N 4 src dst N 1 N 3 tx: {1, 6, 7. . . 91, 96, 99} summary: {1, 6, 7. . . 91, 96, 99} • • Repeat summaries in every data packet in a batch map Cumulative: what all previous nodes rx’d This is a gossip mechanism for summaries Propagate batch map back from destination to sender 16
Scheduling Goal: only one node sends at a time Src sends entire batch Dst sends 10 empty packets with batch maps Then highest priority node starts transmitting whatever it has received • Other nodes: on receiving pkt, update batch map and • • – estimate sending rate of current sender – use Frag. Sz and Frag. Num to estimate sender’s time to completion • Assume (in absence of information) that each higher priority node transmits at least 5 packets • Schedule repeats after lowest priority node transmits. 17
Scheduling 18
Some more protocol details … • Towards the end of a batch, – overhead of scheduling and agreement spread out over fewer packets – Send last 10% of packets of a batch using traditional routing • Too many forwarders = high overhead – Source runs a Ex. OR simulation at the beginning and only chooses those nodes which transmitted over 10% of packets 19
Using Ex. OR with TCP Client PC Node Proxy Web Server TCP Gateway Ex. OR Batches (not TCP) Web Proxy Ex. OR • Batching requires more packets than typical TCP window 20
Evaluation Details 1 kilometer 21
Evaluation Details § Click router user-space § § implementation Directly tx and rx raw Ethernet frames: libpcap like interface IEEE 802. 11 b, Intersil Prism 2. 5 chipset, 200 m. W transmit power, pseudo-IBSS Traditional Routing 802. 11 unicast with linklevel retransmissions Hop-by-hop batching UDP, sending as MAC allows 22 • • • 65 Node pairs 1. 0 MByte file transfer 1 Mbps 802. 11 bit rate 1 KByte packets Link loss measurements used to compute ETX metric offline Ex. OR 802. 11 broadcasts 100 packet batch size
25 Highest throughput pairs 3 Traditional Hops 2. 3 x Throughput (Kbits/sec) More opportunities for making progress 1000 800 2 Traditional Hops 1. 7 x Ex. OR Traditional Routing 600 400 200 0 Node Pair 23 1 Traditional Hop 1. 14 x Batch maps ACKs are more robust and efficient
Throughput (Kbits/sec) 25 Lowest throughput pairs 1000 800 Ex. OR Traditional Routing 4 Traditional Hops 3. 3 x 600 400 200 0 Node Pair Longer Routes Ex. OR can use longer asymmetric links 24
Throughput improves by 200%!! 25
Packets that fall short help! 26
Packets that travel further help! 27
Ex. OR moves packets farther Fraction of Transmissions 58% of Traditional Routing transmissions 0. 6 Ex. OR Traditional Routing 0. 2 25% of Ex. OR transmissions 0. 1 0 0 100 200 300 400 500 600 700 800 900 Distance (meters) • Ex. OR average: 422 meters/transmission • Traditional Routing average: 205 meters/tx 28 1000
Discussion • Late binding of next hop is similar to selection diversity – RTS to multiple potential receivers – Decide “best one” after receiving CTS • Another example of diversity use is “opportunistic scheduling” – Different users have different channels – Send to the user with the best channel – Cellular downlink scheduling, OAR 29
Discussion • Implicit design assumptions: – Carrier sense is good enough – RTS/CTS handshake does not buy us much more – Spatial reuse gain is negligible • scheduling protocol ensures only one node to transmit at a time • All of these assumptions are satisfied when – mesh networks are small and don’t have too many high hop-count paths 30
Discussion • Scheduling in Ex. OR ensures that – higher priority nodes transmit earlier than lower priority nodes – prevents collisions between transmissions of the same flow • No inter-flow collision avoidance is done – I don’t think there are easy ways to handle the scheduling problem in this case 31
Discussion • Scheduling may lead to – collisions – priority inversion 32
Discussion • For long routes, unicast comparison is unfair – hop by hop unicast transmissions does not do any spatial reuse – In IEEE 802. 11 settings, there will be some throughput boost due to spatial reuse • No multiple flow evaluations are carried out. 33
Conclusion • Ex. OR uses a form of selection diversity to bind the next hop only after receiving the current packet • Radio is not a wire: treat it as a broadcast medium instead • Ex. OR gives 2 x throughput improvement • Ex. OR implemented on Roofnet 34
5375d22dc77fcd16586a592d09d6ced8.ppt