General Principles of Intellectual Property: Concepts of Intellectual Proper...
2010-04-24-DTN-based Delivery of Word-of-Mouth Information with Priority and Deadline
1. DTN-based Delivery of Word-of-Mouth Information with Priority and Deadline Yasuhiro Ishimaru, Weihua Sun, Keiichi Yasumoto, Minoru Ito 2010/4/26 1 ICMU2010@Seattle Nara Institute of Science and Technology, Japan
2.
3. By Delay Tolerant NetworkTarget spot: data exist Source spot: sending request Request Request Data is transferred by persons with computing devices Reply Receiving spot: receiving reply 2010/4/26 2 ICMU2010@Seattle
4. Limitation in DTN environments Data amount that can be transferred through DTN is limited User may not receive all reply data User wants to receive Reply data by deadline(e.g.,event info, time sale info) More important datawhen sending multiple requests Requirements for data sharing in DTN 2010/4/26 3 ICMU2010@Seattle We need a differentiation mechanism that transfers more important/deadline-sensitive data prior to others
5. Background Related Work Proposed Method Experiment Conclusion Outline 2010/4/26 4 ICMU2010@Seattle
6.
7. Small server with storage & communication functions Deployed at multiple different spots Increase opportunities for mobile nodes to exchange data Increase data delivery ratio Throwbox[7] With Throwbox Without Throwbox 2010/4/26 6 ICMU2010@Seattle
8.
9. Background Related Work Proposed Method Experiment Conclusion Outline 2010/4/26 8 ICMU2010@Seattle
10. Maximize overall user satisfactionin congested DTN environments Deploy InfoBoxes into target area to increase communication opportunities By scheduling at InfoBox Save DTN resource discard data that are likely to miss deadline Increase user satisfaction transfer the data with higher cost-performance prior to others Goal and Basic Ideas 2010/4/26 9 ICMU2010@Seattle Goal Basic ideas Similar to Throwbox InfoBox
11. Sharing word-of-mouth information in rural sightseeing area Put InfoBox at each sightseeing spot Users (tourists) retrieve word-of-mouth info via InfoBox Target Environment Todaiji temple Target area Nara Park Nara Station Kasuga Shrine Ukimido Temple User InfoBox 2010/4/26 10 ICMU2010@Seattle
12. User enjoys favorite tour by visiting spots and staying there Sends requests and receives reply data through InfoBox Request contains: destination spot, receiving spot, importance score User gets satisfaction if it receives reply data at receiving spot Service Model Todaiji Nara Park Rep:20 Req:20 Nara St. Example request: DestSpot: Nara Park RecSpot: KasugaShrineImportance Score: 20 KasugaShrine Ukimido Satisfaction:20 2010/4/26 11 ICMU2010@Seattle
13. Equipped with mobile terminals (cell phones) Capable of Bluetooth communication Active Behavior Moving between spots and staying at a spot Sending request to InfoBox Passive Behavior Receiving reply data from InfoBox Relaying data between InfoBoxes (receive, carry, re-send) Assumption for User 2010/4/26 12 ICMU2010@Seattle InfoBox
14. Small battery-driven PC equipped with: Sufficient CPU power and storage Bluetooth communication capability Deployed near gate to each spot CANNOT communicate with other InfoBox Schedules send/receive actions with user terminals Knows user’s moving probability between spots Assumption for InfoBox Sightseeing spot gate InfoBox 50% 70% InfoBox C 50% InfoBoxA 80% 20% 30% InfoBox B 13 ICMU2010@Seattle
15. Communication model Bluetooth-based communication Radio range: circle with radius R (e.g., 10m) No packet loss due to collision Max. Available Bandwidth: BW (e.g., 1Mbps) Queue-based communication InfoBox has a queue for storing and sending data Congestion: receive-data amounts > send-able-amounts Assumption for Communication between InfoBox and User A 2010/4/26 14 ICMU2010@Seattle Congestion Receiving Sending Queue B C D
16. InfoBox schedules send/receive actions by applying the following techniques to each data in its queue Delivery time estimation for the data Decision of appropriate number of replicas for the data Cost-performance estimation for the data These techniques achieve data delivery with high overall user satisfaction Proposed Scheduling Algorithm 2010/4/26 15 ICMU2010@Seattle
17. Sending a data which CANNOTarrive by deadline wastes resource, and disturbs other data’s delivery Why estimate delivery time? Replication time = 10 min Delivery time = 20 min Replicationtime = 10 min By using delivery time estimation, we can discard data seems to miss deadline Arrival Delivery time = 20 min Arrival DL: 10 min 30min 30min DL: 40 min 40min 30min DL: 10 min DL: 40 min 50min 40min DL: 40 min InfoBox DL: 80 min 60min 50min DL: 40 min DL: 80 min Number of delivered data: 2 Number of delivered data: 3 2010/4/26 16 ICMU2010@Seattle
18. Delivery time estimationfor each data Target Spot Receiving Spot Source Spot staying time ε traveling time γ Reply delivery timeβ Request delivery time α ReceivingDeadline = γ+ε Delivery Time = α+β ≦ Receiving Deadline Data which can not satisfy the constraint will be discarded 2010/4/26 17 ICMU2010@Seattle
19.
20. Based on user’s moving probabilityWhy estimate number of data replicas? Data Data Target InfoBox Replica Replica Source InfoBox 30% Replica Replica Replica Replica 70% 2010/4/26 18 ICMU2010@Seattle
21. Decide appropriate number of replicas Route in time for Deadline System Parameter: Required delivery ratio δ Required ratio that data is delivered from Source to Target Based on users moving probability, to achieve δ Ex. δ = 0.9, p1=0.3, p2=0.7 Target p1(30%) Route expires of Deadline Source p2(70%) n(=7) is the appropriate number of replicas 2010/4/26 19 ICMU2010@Seattle
22.
23. Multi HopECP =(50 x 90%) / (100 x 3) =0.15 (points/KB) 2010/4/26 20 ICMU2010@Seattle
24. InfoBox sorts data in descending order of ECP Replicates data to users with calculated no. of replicas Data scheduling by proposed method A A ECP=0.8 Replica=3 B ECP=0.7 Replica=4 C ECP=0.5 Replica=4 A Sending Queue A Other Spots 2010/4/26 21 ICMU2010@Seattle
25. Background Related Work Proposed Method Experiment Conclusion Outline 2010/4/26 22 ICMU2010@Seattle
26. We developed own simulator in Java Simulation Configuration Simulation parameters User mobility model 2010/4/26 23 ICMU2010@Seattle
27. Total Satisfaction Overall importance scores associate with data that were delivered within deadline. A larger value means a better performance We confirmed total satisfaction by adjusting required delivery ratio δ Comparison queuing methods Ⅰ. FIFO : First in first out Ⅱ. Satisfaction: Sorted by satisfaction point Ⅲ. Deadline : Sorted by deadline Metric 2010/4/26 24 ICMU2010@Seattle
31. Conclusion Proposed a method to maximize overall user satisfaction for data delivery in congested DTN environments Confirmed good effect of the proposed method by comparing with 3 conventional methods Future Work Compare with Epidemic method, etc. Find some mechanisms to reduce network load when congestion occurs Conclusion 2010/4/26 26 ICMU2010@Seattle
34. Delivery time estimationfor each data ε γ β Reply delivery time Target Spot Receiving Spot Source Spot RS staying time User traveling time How to estimate deadline User traveling time (γ) is from posting request at Source Spot until he/she arrives at Receiving Spot RS staying time (ε) is staying time when user is at Receiving Spot The total time of γ and ε is Deadline How to estimate data delivery time Request delivery time α is the delivery time from a request was posted at Source Spot until it was carried to Target Spot Reply delivery timeβ is the traveling time until user arrives at RS α Request delivery time Deadline = γ+ε Deadline ≧ α+β 2010/4/26 29 ICMU2010@Seattle
![Users want to share data even in area where communication infrastructure is not available. (Ex. disaster area, rural area, etc) Target application data retrieval by specifying target spot and receiving spot Data Retrieval in DTN Environments ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)