Delay Tolerant Mobility Aware Routing/Mobility Dissemination Protocol for the Airborne Network

1. Delay Tolerant Mobility Aware Routing/MobilityDissemination Protocol for the Airborne Network Kevin Lee & Adam Piechowicz 10/10/2009

2. Problem Statement • An end-to-end path is not always guaranteed • Packets have to be delivered in a delay-tolerant fashion • How to use planned AN backbones’ trajectories to deliver packets to minimize: • Packet failure rate • Delay • Local buffer

3. Contributions • Provide best next forwarding hop in the delay tolerant network based on current network condition • Provide congestion avoidance and load balancing by local queuing awareness mechanism

4. MARP/MDP+DTN Design • Think of the topology as a time-varying graph • We can select the best next hop given a specified metric (minimum delay) • Use modified Dijkstra’s algorithm with time-varying edge costs • w(e(u,v), t) indicates the cost of using edge (u, v) after time time t • The cost is predominantly the time after t that (u, v) is up • Propagation delay negligible • Transmission rate not considered

5. Example 1 • Source node at 1 and each edge cost is 1

6. Example 2

7. Predecessor Computation • Take Node 3 from Example 2 • 2, 2 means: • It will take Node 1 to reach Node 3 with cost of 2 (the first 2) • The predecessor of Node 3 is Node 2 (the second 2) • One can then trace back to get the complete route traversal and the time at which the packet should be sent

8. Local Queuing Aware Scheduling • Network disconnectivity increases queuing delay • Queuing delay increases congestion • Route around congestion by considering neighbors’ queue size • w(e, L[u] + T) will incorporate: • The cost of sending packets already in the queue plus, • The cost of sending the last packet scheduled to use u to deliver to v

9. Importance of Encountering for Queuing Awareness • The more frequently a node encounters with another node, the more packets the node can offload to that node • Intuitively, the link between these two nodes provide lower delay to the destination • Two types of encountering: • Single • Multiple

10. Single Encountering • A node A single encounters another node B if node A meets node B only once in a period • Where time(1,e,L[u]+T) indicates the time Node u meets Node v at which time one packet in Node u’s queue is delivered since L[u] + T • P is the period of the time-varying graph • Qsize is the queue size at Node u

11. Single Queuing Example • Assume there are 2 messages in Node 2’s queue

12. Single Queuing Example (cont.) • w(e(2,3), 1) = 5 + 6 + 6 because it takes • 5 more seconds to dequeue the first packet, • 6 seconds to dequeue the second packet, • another 6 seconds to dequeue the last packet • By the eqn, w(e(2,3), 1) = 5 + 6 * 2 = 17 • Packets in Node 2’s queue will use the same edge in consideration, e.g., • w(e(2,3),1) considers first two packets going to Node 3 • w(e(2,4),1) considers first two packets go to Node 4

13. Multiple Encountering • A node A multiple encounters another node B if node A meets node B more than once in a period • Tx(e,t) is the # of times e is up during the remaining time t of one period

14. Multiple-Encounter Queuing Example • Assume there are 2 messages in Node 2’s queue

15. Multiple-Encounter Queuing Example (cont.) • w(e(2,3), 1) = 3 + 2 + 4 because it takes • 3 more seconds to dequeue the first packet, • 2 more seconds to dequeue the second packet, • 4 seconds to dequeue the last packet • Since Qsize (=3) > Tx (=2), eqn (2) is used: • w(e(2,3), 1) = (6 – 1) + 0 + 4 = 10

16. Handling Multiple-Traffic Flows • Contacts (the time-varying at any given point in time) is known • Local queuing is known; approximate global queuing by keeping track of messages along each routing path • Traffic demand is known, • It is a set of messages • Each message is a tuple (u,v,t,m), where u is the source of the msg, v is the destination, t is the time the msg is sent, m is size • Buffer constraints are given • THE ORACLE HAS COMPLETE KNOWLEDGE! – A linear programming exercise

17. Approximate Optimality • LP is computationally expensive! – Computation become too large for practical example • Use contacts and queuing oracle (EDAQ) instead • “EDAQ compares favorably, in terms of average delay, with the optimal solution.” • However, • Global knowledge may not be required for good performance in many cases • Implementing the queuing oracle, in particular, may not be worthwhile

18. Approximate Optimality (contd.) • Contact oracles (ED) might just be enough for our scenarios! • Lesson: TOO MUCH KNOWLEDGE MAY NOT ALWAYS BE GOOD!

19. Evaluation

20. MARP/MDP vs. MARP/MDP+DTN • Network Flow from GlobalHawk to AWACs 2 • Solid arrow shows the desired network flow • Dotted lines shows current available connections • 3 experimental variables • Radio range • Delay tolerance • Flow volume

21. Results • Delay tolerance represents largest improvement in packet delivery, 52% (col1 &2) • Fixed range: Low flow has higher delivery and lower latency (col 1 & 3) • Fixed flow: High radio range has higher delivery ratio and lower latency than low radio range

22. MARP/MDP+DTN vs. MARP/MDP+DTN+QC • Two separate rate flows from 1 and 2 to 5 • Transmission rates range from 2.048 Mbps to 1024 kbps

23. Results • When transmission rate is high, PDR for MARP/MDP+DTN is 0%

24. Packet Difference between Node 3 and 4 • Both flow forward to Node 3 heavily in MARP/MDP+DTN • MARP/MDP+DTN+QC is able to divert traffic and achieve load balancing

25. Latency • Delay extremely long in MARP/MDP+DTN • Result indicates the need for local queuing awareness

27. Conclusion & Future Work • MARP/MDP+DTN shows the benefit of delay tolerance • MARP/MDP+DTN+QC shows the benefit of local queuing awareness • Congestion scenario configuration to verify local queuing aware scheduling • Tune parameters/routing metrics of MARP/MDP+DTN+QC protocol in accordance with flight and link data obtained from real flight tests like Capstone II