13.07.2015 Views

Mobility-Assisted Data Delivery in Wireless Network

Mobility-Assisted Data Delivery in Wireless Network

Mobility-Assisted Data Delivery in Wireless Network

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Message Ferry<strong>in</strong>g and Other ShortStories:<strong>Mobility</strong>-<strong>Assisted</strong> <strong>Data</strong> <strong>Delivery</strong> <strong>in</strong> <strong>Wireless</strong><strong>Network</strong>sMostafa H. AmmarCollege of Comput<strong>in</strong>gGeorgia Institute of TechnologyAtlanta, GAMessage Ferry Project Group Members: Ellen Zegura, Wenrui Zhao,Hyewon Jun, Jeonghwa Yang, Yang Chen, Shashi Merugu, V<strong>in</strong>cent Borrel, Ahmed Mansy,Jon Olson, Mukarram B<strong>in</strong> Tariq, Meng GuoU. Mass Collaborators: Brian Lev<strong>in</strong>e, Mark CornerFund<strong>in</strong>g: NSF, DARPA, Cisco


The “Traditional” MANET <strong>Wireless</strong>ParadigmThe <strong>Network</strong> is “Connected” There exists a (possibly multi-hop) pathfrom any source to any dest<strong>in</strong>ation The path exists for a long-enough period oftime to allow mean<strong>in</strong>gful communication If the path is disrupted it can be repaired<strong>in</strong> short order


A Brief History of <strong>Wireless</strong> Nets <strong>Wireless</strong> networks are as old as the Internet itself DARPA PRnet Initial motivation for some protocol functions (e.g., IP-layerfragmentation) PRnet -> SURANet -> Mobile Ad-hoc Net (MANET) Latest MANET wave co<strong>in</strong>cided with 802.11 activities Most wireless today is base-station oriented (not mobile, norad-hoc) My conclusion: attempt to emulate wired net modelfor MANET has led to failure to achieve widedeployment


The Rise of Intermittently-Connected <strong>Network</strong>s


Intermittently-Connected<strong>Wireless</strong> <strong>Network</strong>sDisconnected By Necessity By Design (e.g. for power considerations)Mobile With enough mobility to allow for someconnectivity over time <strong>Data</strong> paths may not exist at any one po<strong>in</strong>t<strong>in</strong> time but do exist over time


<strong>Mobility</strong>-<strong>Assisted</strong> <strong>Data</strong> <strong>Delivery</strong>:A New Communication Paradigm<strong>Mobility</strong> used for connectivityNew Forward<strong>in</strong>g ParadigmStoreCarry for a whileforwardSpecial nodes: Transport entities that arenot sources or dest<strong>in</strong>ations


Also Known AsDelay-Tolerant <strong>Network</strong>sDisruption-Tolerant <strong>Network</strong>sSparse <strong>Network</strong>sOpportunistic <strong>Network</strong>s


<strong>Data</strong> ApplicationsNicely suitable for Message-Switch<strong>in</strong>gDelay tolerance … but can work atmultiple time scale


Epidemic Rout<strong>in</strong>g Vahdat and Becker Utilize physical motion of devices totransport data Store-carry-forward paradigm Nodes buffer and carry data when disconnected Nodes exchange data when met data is replicated throughout the network Robust to disconnections Scalability and resource usage problems


Epidemic Rout<strong>in</strong>g


Epidemic Rout<strong>in</strong>g


Epidemic Rout<strong>in</strong>g


Epidemic Rout<strong>in</strong>gmessage isdelivered


The Trouble with ERPotentially high-failure rateMessage duplication consumes nodalresourcesSome mobility patterns can causedisconnectionCan be improved with contactprobability <strong>in</strong>formation - Lev<strong>in</strong>e et al


Other “Orig<strong>in</strong>al” SystemsZebraNet and SWIM<strong>Data</strong> MULE and Smart-TagsVehicle-to-Vehicle CommunicationMessage Ferry<strong>in</strong>gDakNet


SWIM


Vehicles on Highways <strong>Network</strong>sDest<strong>in</strong>ationSource


Vehicles on Highways <strong>Network</strong>sDest<strong>in</strong>ationSource


Vehicles on Highways <strong>Network</strong>sDest<strong>in</strong>ationSource


Roadside-to-Roadside Relay<strong>in</strong>g


DakNet(Pentland, Fletcher, and Hasson)


Message Ferry<strong>in</strong>g (MF) @ GTZhao and AmmarExploit non-randomness <strong>in</strong> devicemovement to deliver data A set of nodes called ferries responsiblefor carry<strong>in</strong>g data for all nodes <strong>in</strong> thenetwork Store-carry-forward paradigm toaccommodate disconnectionsFerries act as a mov<strong>in</strong>g communication<strong>in</strong>frastructure for the network


Message Ferry<strong>in</strong>g System(cont.)MFSMSMFMDD


Putt<strong>in</strong>g It All Together Common Features: Intermittent Connectivity Store, carry and forward Other dimensions where they may differ Special Nodes? Source/Dest<strong>in</strong>ation Mobile? Potential for controll<strong>in</strong>g mobility for datatransport purposes? <strong>Data</strong> Communication Pattern


More on Message Ferry<strong>in</strong>g


MF Variations Ferry <strong>Mobility</strong> Task-oriented, e.g., bus movement Messag<strong>in</strong>g-oriented, e.g., robot movement Regular Node <strong>Mobility</strong> Stationary Mobile: task-oriented or messag<strong>in</strong>g-oriented Number of ferries and level of coord<strong>in</strong>ation Level of regular node coord<strong>in</strong>ation Ferry designation Switch<strong>in</strong>g roles as ferry or regular node


Target EnvironmentsNeeded for networks where Sparse network with no node contacts Not enough node contactsAlso usable <strong>in</strong> other networks


A Taste of Message Ferry<strong>in</strong>g Ferry Route Design Problem S<strong>in</strong>gle Ferry Multiple FerriesMF with Mobile NodesMF <strong>in</strong> MANETs!!


A Taste of Message Ferry<strong>in</strong>g Ferry Route Design Problem S<strong>in</strong>gle Ferry Multiple FerriesMF with Mobile NodesMF <strong>in</strong> MANETs!!


Stationary NodesFerry Route Design


Route Design - Stationary Nodes Ferry route problem Given node locations and expected trafficbetween nodes, f<strong>in</strong>d ferry route such thatferry visits all nodes, meets trafficrequirements and m<strong>in</strong>imizes averagemessage delay Solution A generalization of Travel<strong>in</strong>g SalesmanProblem


Numerical ResultsExperiment sett<strong>in</strong>gs n nodes <strong>in</strong> 4km x 4km area A s<strong>in</strong>gle ferry mov<strong>in</strong>g at speed 20m/sNode distributions Random uniform node distribution (UN) Random clustered node distribution (CN)Traffic models Uniform traffic Non-uniform traffic


Impact of <strong>Network</strong> Size MF provides reasonable performance For 40 nodes, each node can send at 10Kbps with1070s delay.


A Taste Message Ferry<strong>in</strong>g Ferry Route Design Problem S<strong>in</strong>gle Ferry Multiple FerriesMF with Mobile NodesMF <strong>in</strong> MANETs!!


Multiple Ferry Route DesignWhy multiple ferries? <strong>Data</strong> transport capacity Fault toleranceMultiple ferries <strong>in</strong>troduce new problems Which ferry serves which node? Interaction between ferries Tradeoff between number of ferries andperformance improvement


Multiple Ferry Route DesignProblem <strong>Network</strong>s with n stationary nodes and mferries Ferries move at a constant speed and followperiodic routes Bandwidth requirements are known e.g., node A sends to node B at 10kbps Problem: f<strong>in</strong>d optimal ferry routes suchthat bandwidth requirements are met andaverage delay is m<strong>in</strong>imized NP-hard problem


Algorithms S<strong>in</strong>gle Route Algorithm (SIRA) All ferries follow the same route No <strong>in</strong>teraction between ferries Multiple Route Algorithm (MURA) Ferries can follow different routes No <strong>in</strong>teraction between ferries Node Relay<strong>in</strong>g Algorithm (NRA) Nodes relay data between ferries Ferry Relay<strong>in</strong>g Algorithm (FRA) <strong>Data</strong> exchange between ferries


Algorithms S<strong>in</strong>gle Route Algorithm (SIRA) All ferries follow the same route No <strong>in</strong>teraction between ferries Multiple Route Algorithm (MURA) Ferries can follow different routes No <strong>in</strong>teraction between ferries Node Relay<strong>in</strong>g Algorithm (NRA) Nodes relay data between ferries Ferry Relay<strong>in</strong>g Algorithm (FRA) <strong>Data</strong> exchange between ferries


Algorithms S<strong>in</strong>gle Route Algorithm (SIRA) All ferries follow the same route No <strong>in</strong>teraction between ferries Multiple Route Algorithm (MURA) Ferries can follow different routes No <strong>in</strong>teraction between ferries Node Relay<strong>in</strong>g Algorithm (NRA) Nodes relay data between ferries Ferry Relay<strong>in</strong>g Algorithm (FRA) <strong>Data</strong> exchange between ferries


Algorithms S<strong>in</strong>gle Route Algorithm (SIRA) All ferries follow the same route No <strong>in</strong>teraction between ferries Multiple Route Algorithm (MURA) Ferries can follow different routes No <strong>in</strong>teraction between ferries Node Relay<strong>in</strong>g Algorithm (NRA) Nodes relay data between ferries Ferry Relay<strong>in</strong>g Algorithm (FRA) <strong>Data</strong> exchange between ferries


Simulation ResultsSett<strong>in</strong>gs 5km x 5km area, 40 nodes, ferry speed:10m/s Radio range: 100m, data rate: 10mbps Nodes send to random dest<strong>in</strong>ationsComparison of algorithms All algorithms achieve similar delay whennumber of ferries is small or traffic load ishigh MURA performs best


Impact of Number of Ferries100101bw=10Kbpsbw=56Kbpsbw=100Kbpsbw=200Kbpsbw=320KbpsMessage <strong>Delivery</strong> Delay (hour)0.10 2 4 6 8 10 12 14 16Number of Ferries The use of more ferries reduces message delayand improves total transport capacity Scalability can be achieved by add<strong>in</strong>g more ferries


A Taste Message Ferry<strong>in</strong>g Ferry Route Design Problem S<strong>in</strong>gle Ferry Multiple FerriesMF with Mobile NodesMF <strong>in</strong> MANETs!!


MF for <strong>Network</strong>s with MobileNodesNodes are mobile and limited <strong>in</strong>resources, e.g., buffer, energyS<strong>in</strong>gle ferry is used Not limited <strong>in</strong> buffer or energy<strong>Data</strong> communication <strong>in</strong> messages Application layer data unit Message timeout


Four Approaches Non-Proactive ( = Messag<strong>in</strong>g-Specific)mobility Ferry<strong>in</strong>g without Epidemic Rout<strong>in</strong>g Ferry<strong>in</strong>g with Epidemic Rout<strong>in</strong>g Proactive Rout<strong>in</strong>g Schemes Node-Initiated MF Nodes move to meet ferry Ferry-Initiated MF Ferry moves to meet nodes


Four Approaches Non-Proactive ( = Messag<strong>in</strong>g-Specific)mobility Ferry<strong>in</strong>g without Epidemic Rout<strong>in</strong>g Ferry<strong>in</strong>g with Epidemic Rout<strong>in</strong>g Proactive Rout<strong>in</strong>g Schemes Node-Initiated MF Nodes move to meet ferry Ferry-Initiated MF Ferry moves to meet nodes


Node-Initiated Message Ferry<strong>in</strong>gMeettheIf no, keepOKwork<strong>in</strong>gferry?Work<strong>in</strong>g


Node-Initiated Message Ferry<strong>in</strong>gGo to Ferry


Node-Initiated Message Ferry<strong>in</strong>gSend/RecvGo to Work


Node-Initiated Message Ferry<strong>in</strong>gGo to Work


Node Trajectory Control Whether node should move to meet the ferry Goal: m<strong>in</strong>imize message drops and reduceproactive movement Go to ferry if Work-time percentage > threshold and Estimated message drop percentage > threshold


SimulationsNs simulations us<strong>in</strong>g 802.11 MAC anddefault energy model40 nodes <strong>in</strong> 5km x 5km area25 random (source, dest<strong>in</strong>ation) pairsNode mobility random-waypo<strong>in</strong>t with max speed 5m/sMessage timeout: 8000 secS<strong>in</strong>gle ferry with speed 15m/s Rectangle ferry route


Performance MetricsMessage delivery rateMessage DelayNumber of delivered messages per unitenergy Only count transmission energy <strong>in</strong> regularnodes


Message <strong>Delivery</strong> Rate10.90.80.70.60.5Message delivery rateFIMFNIMFF w/ERER0.40.30.20.10Epidemic Rout<strong>in</strong>gEpidemic Rout<strong>in</strong>g (w/ ferry)NIMFFIMF-NNFIMF-TA100 200 300 400 500 600 700 800Node buffer size (messages)


4000350030002500Message DelayMessage delay (sec)FIMFNIMFF w/ERER2000150010005000Epidemic Rout<strong>in</strong>gEpidemic Rout<strong>in</strong>g (w/ ferry)NIMFFIMF-NNFIMF-TA100 200 300 400 500 600 700 800Node buffer size (messages)


A Taste Message Ferry<strong>in</strong>g Ferry Route Design Problem S<strong>in</strong>gle Ferry Multiple FerriesMF with Mobile NodesMF <strong>in</strong> MANETs!!


MF as a Power-ManagementDevice <strong>in</strong> MANETsIntroduc<strong>in</strong>g a MF <strong>in</strong> a well-connectedMANET can help organize powermanagementactivitiesNodes can sleep when MF is out ofrange.Can this improve on delay/powertradeoff


Power Management <strong>in</strong> MFFerry location <strong>in</strong> terms of the radio range of anodeFerry OutInOutNodeSearch Contact Dormant The network model <strong>in</strong> MF A s<strong>in</strong>gle ferry and multiple nodes Location and time: known by each node, e.g., us<strong>in</strong>gGPS70


Sleep<strong>in</strong>g Time EstimationHow long to sleep <strong>in</strong> the dormant mode?Based on the predicted location of theferryMovement scenariosFerryNodeStationary nodes Mobile nodesStrictly scheduled 1 3Loosely scheduled 2 471


Performance Evaluation Ns-2 simulation with 802.11 MAC protocol 50 nodes <strong>in</strong> 2000m x 500m and a ferry Capacity of node buffer: 700 messages Dynamic source rout<strong>in</strong>g (DSR) with asynchronous wake-up mechanism DSR-x: wake-up <strong>in</strong>terval of x seconds DSR:CAM: cont<strong>in</strong>uous aware mechanism How to sleep (i.e., disabl<strong>in</strong>g or turn<strong>in</strong>g off):decided based on the expected sleep time75


Impact of Traffic Load onStationary Nodes DSR with large wake-up <strong>in</strong>tervals and MF:Low energy consumption and high delivery delay76


A Fundamental QuestionWhat is the relationship of MF netswith MANETs and with other DTNs?


Understand<strong>in</strong>g the<strong>Wireless</strong> and Mobile<strong>Network</strong> Space[CHANTS 07]


Background Different Types of <strong>Wireless</strong> and Mobile(WAM) <strong>Network</strong>s MANETS -> MANET Rout<strong>in</strong>g (AODV,DSR,…) DTNs (opportunistic,…) -> DTN rout<strong>in</strong>g (flood<strong>in</strong>g,MaxProp, Prophet, …) Sparse, Disconnected Nets -> Message Ferries,<strong>Data</strong> Mules, Throwboxes, …Questions: What’s the relationship among these classes? How can one tell to which of these classes aparticular network belongs?


Some Term<strong>in</strong>ologyA Space Path: A multi-hop path whereall the l<strong>in</strong>ks are active at the same timeA Space/Time Path: A multi-hop paththat exists over timeNOTE: S path is a special case of S/Tpath


Space/Space-Time Paths


The <strong>Wireless</strong> and Mobile (WAM) Space(my panel presentation at WDTN 2005)HighSpace/Time PathsHybrid Environments“<strong>Mobility</strong>”LowSpace PathsNo (Space/Time)PathsHighNode DensityLow


Mapp<strong>in</strong>g Rout<strong>in</strong>g Solutions to SpaceHighSpace/Time PathsNoPathSolu’nsHybrid Environments“<strong>Mobility</strong>”LowSpace PathsSpace-Path SolutionsNo (Space/Time)PathsS/T Path SolutionsHighNode DensityLow


Classify<strong>in</strong>g WAMsGoal:Provide a framework for WAMclassification that provides guidanceabout the deployment of rout<strong>in</strong>gapproachesStart<strong>in</strong>g po<strong>in</strong>t: Theory of Evolv<strong>in</strong>gGraphs


Evolv<strong>in</strong>g Graph (EG)**A. Ferreira. Build<strong>in</strong>g a reference comb<strong>in</strong>atorial model forMANETS. IEEE <strong>Network</strong>, 18(5):24–29, Set 2004. Is a graph with edges that turn “on”and “off” over timeMade up of a sequence of subgraphsTwo variations: of EGs F<strong>in</strong>ite-Duration Inf<strong>in</strong>ite Duration (our def<strong>in</strong>ition)Journey = Space-Time Path: M<strong>in</strong>-hop, foremost, shortest


WAMs as Evolv<strong>in</strong>g Graphs


Our Classification –The idealized versionFor Inf<strong>in</strong>ite-duration graphsIdeal Space-Path <strong>Network</strong>s (SPNs):An <strong>in</strong>f<strong>in</strong>ite evolv<strong>in</strong>g graph where allsubgraphs are connectedIdeal Unassisted DTNs (U-DTN):For all t and for all (i, j) there is ajourney from i to j after tIdeal Assistance-needed DTN (A-DTN):Everyth<strong>in</strong>g else


SPNs, U-DTNs, A-DTNs


Mapp<strong>in</strong>g Rout<strong>in</strong>g Families WAMClassesMANET ROUTINGDTN ROUTINGSPARSE NET ROUTING


An “Practical” ClassificationIntuition: Boundary between classes isnot “crisp”.Additional Considerations: F<strong>in</strong>ite-duration EGs Practical rout<strong>in</strong>g considerations, e.g., ittakes time for a MANET rout<strong>in</strong>g protocolto discover routes.Many ways to do this – See CHANTS07for one approach


Classify<strong>in</strong>g <strong>Network</strong>s From<strong>Network</strong> TracesGoal<strong>Network</strong> and ProtocolParameters: η, δ, γ<strong>Mobility</strong> Model orTrace<strong>Network</strong> Classifier<strong>Network</strong>Classification


<strong>Network</strong> ClassificationObjective: Percentage of time spent <strong>in</strong>each network class.X% SPN, Y% U-DTN, Z% A-DTN Informally: SPN: <strong>Network</strong> connected for long enoughperiod and with high l<strong>in</strong>k resilience U-DTN: Long enough <strong>in</strong> U-DTN class andpath-less time is < γ A-DTN otherwise


Illustrative ExamplesRWP and RW mobility models2km x 2km, 250m radio range, 3hrsPedestrian (avg 1.5m/s) and vehicular(15m/s) speedsGoal: to illustrate classificationoutcome from our approach


Effect of SpeedRWP – Pedestrian SpeedRWP – Vehicular Speed


Jo<strong>in</strong>t Density/Speed: RWP


Rema<strong>in</strong><strong>in</strong>g IssuesTransformations between classesPartial classification (e.g., per S-D pair)More on practical parametricclassification – direct analysis ofrout<strong>in</strong>gExperience us<strong>in</strong>g classification


Conclud<strong>in</strong>g Remarks FINALLY! A realistic mobile wireless networkparadigm With<strong>in</strong> this new paradigm: Everyth<strong>in</strong>g looks familiar but this is a trulydifferent environment Techniques developed have wide applicability Fertile Ground for both network<strong>in</strong>g problems andnovel application paradigmsEssential to understand entire WAMspace


Conclud<strong>in</strong>g Remarks<strong>Mobility</strong> can be your friendNow the rest of the ICEBERG is visible MANETs are just a special caseSo many networks so little time Can be solved by unified treatment ofentire WAM space


Questions?

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!