Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mobile Computing – A Distributed Systems Perspective Prof. Nalini Venkatasubramanian Department of Computer Science University of California, Irvine.

Similar presentations


Presentation on theme: "Mobile Computing – A Distributed Systems Perspective Prof. Nalini Venkatasubramanian Department of Computer Science University of California, Irvine."— Presentation transcript:

1 Mobile Computing – A Distributed Systems Perspective Prof. Nalini Venkatasubramanian Department of Computer Science University of California, Irvine

2 Outline zThe Future: Mobile and Pervasive Computing zAn Applications View zA Content View zMultimedia Content zQoS Basics and End-to-end support zA Systems View xDevice, Operating System xNetworks, Middleware xApplication, Content xA Cross-Layer Approach to Systems Support zSupporting Cross Cutting Concerns (Security, Reliability, Heterogeneous Interoperability)

3 Pervasive Computing and Communication zProliferation of devices ySystem support for multitude of smart (mobile) devices that attach and detach from a distribution infrastructure produce a large volume of information at a high rate limited by communication and power constraints zRequire a customizable global networking backbone. xThat can handle heterogeneous needs of applications Quality of Service (QoS), security, reliability xThat can make effective use of the underlying infrastructure zIntelligent Middleware is key to supporting application needs in a highly dynamic environment

4 Distributed Mobile Applications

5 In the last 5 years….. zNew devices w/ new capabilities yData capture, storage, presentation zNew apps ySocial networking,…. yMultimedia applications, gaming, data capturing, download/upload/streaming yInformation seek/notification zNew network infrastructures yDTN, WiMax, UWB,… zNew computational infrastructure yCloud computing, grids… New problems and challenges…

6 Introduction GSM or CDMA BS BS Cell Phone PDA Laptop WLAN Access Point ad hoc network Users Networks Applications Mobile Devices Mobile Ecosystem

7 Technology Incentive zGrowth in computational capacity xMM workstations with audio/video processing capability xDramatic increase in CPU processing power xDedicated compression engines for audio, video etc. zRise in storage capacity xLarge capacity disks (several gigabytes) xIncrease in storage bandwidth,e.g. disk array technology zSurge in available network bandwidth xhigh speed fiber optic networks - gigabit networks xfast packet switching technology

8 Enabler: Mobile Communication Networks zCellular - GSM (Europe+), TDMA & CDMA (US) xFM: 1.2-9.6 Kbps; Digital: 9.6-14.4 Kbps (ISDN-like services) zPublic Packet Radio - Proprietary x19.2 Kbps (raw), 9.6 Kbps (effective) zPrivate and Share Mobile Radio zWireless LAN - wireless LAN bridge (IEEE 802.11) xRadio or Infrared frequencies: 1.2 Kbps-15 Mbps zPaging Networks – typically one-way communication xlow receiving power consumption zSatellites – wide-area coverage (GEOS, MEOS, LEOS) xLEOS: 2.4 Kbps (uplink), 4.8Kbps (downlink)

9 Mobile Network Architecture

10 Wireless network characteristics zVariant Connectivity yLow bandwidth and reliability zFrequent disconnections predictable or sudden zAsymmetric Communication yBroadcast medium zMonetarily expensive yCharges per connection or per message/packet  Connectivity is weak, intermittent and expensive

11 Device Characteristics zBattery Power restrictions yTransmit/receive, disk spinning, display, CPUs, memory consume power zResource constraints yMobile computers are resource poor yReduce program size yComputation and communication load cannot be distributed equally zSmall screen sizes

12 Mobility Characteristics zLocation changes location management - cost to locate is added to communication zHeterogeneity in services ybandwidth restrictions and variability zDynamic replication of data data and services follow users zQuerying data - location-based responses zSecurity and authentication  System configuration is no longer static

13 Challenges Challenges Global Context Network Context Need high degree of “network awareness” and “customizability”  congestion rates, mobility patterns etc.  QoS driven resource provisioning  Heterogeneous networks Device Context  Heterogeneous devices  Limited battery lifetime  Size/weight limitations  Computation/Communication constraints Application Context Application Context  Increasing QoS., security, reliability demands  Soft Real Time Constraints  Support for traditional media (text, images) and continuous media (audio/video)  Synchronization (e.g. lip sync., floor control) System support for multitude of components  Attach and detach from a distributed infrastructure  Deal with large vol. of information at a high rate  Changing global system state

14 Mobile Multimedia – Rich Media applications on mobile devices xChallenges Soft Real time Requirements High demands on CPU / Network Loss in performance directly affects user perception xOpportunities Predictable regular behavior allows for interesting optimizations and adaptations Wide Area Network Wireless Network Low-power mobile device Access point MEDIA SERVER Video request Video stream OBJECTIVE : Stream rich multimedia content at highest possible quality (user experience) over wired and wireless networks

15 Multimedia Information Systems: Challenges zSheer volume of data xNeed to manage huge volumes of data zTiming requirements xamong components of data computation and communication. xMust work internally with given timing constraints - real-time performance is required. zIntegration requirements xneed to process traditional media (text, images) as well as continuous media (audio/video). xMedia are not always independent of each other - synchronization among the media may be required.

16 High Data Volume of Multimedia Information

17 Quality of Service in MM Applications zQoS: A Design Parameter for MM yMinor violations of performance requirements yGenerally used to express constraints on Timing, availability, reliability,security, resource utilization User NetworkMM devices System Application (Network QoS) (Device QoS) (System QoS) (Application QoS) (Perceptual QoS) (Operating and Communication System)

18 QoS Classes zQoS Service Classes determine xreliability of offered QoS xutilization of resources yGuaranteed Service Class xQoS guarantees are provided based on deterministic and statistical QoS parameter values. yPredictive Service Class xQoS parameter values are estimated and based on the past behavior of the service yBest-effort Service Class xNo guarantees or only partial guarantees provided xNo QoS parameters are specified or some minimal bounds are given.

19 Supporting continuous media: Approaches yAdmission control xProvide different service classes yFast storage and retrieval of Multimedia content xOptimized organization (placement) of multimedia files on disk xSpecial disk scheduling algorithms yEfficient Memory Management xSufficient buffers to avoid jitter x Intelligent Caching

20 End-to-end QoS for Wired Applications zUsually achieved through QoS Brokers yCoordinates interactions between multiple sessions with QoS needs zTypical Functions of a QoS broker yResource Provisioning xDeal adaptively with incoming requests xAllocate server, network and client resources yPredictive and Adaptive Data Placement xRe(configure) data to service requests more efficiently zMust maintain resource allocation invariants

21 Supporting QoS in Mobile Applications zNew challenges yConstantly changing system conditions xNetwork connectivity, user mobility yDevice constraints xEnergy, CPU, display, bandwidth zThis needs yProvisioning, re-provisioning based on local conditions of wireless network yData Placement based on current and projected data access patterns zCross-layer awareness required yResource provisioning algorithms utilize current system resource availability information to ensure that applications meet their QoS requirements

22 QoS-based resource provisioning zProvisioning Network and Server Resources Effectively xState information enables decision making for resource provisioning - e.g. Routing, Scheduling and Placement xMaintaining accurate and current system information is important yExisting Approaches xIn network : QoS Based Routing xAt Server : Server Load Balancing yFuture Middleware will support CPSS (Combined Path and Server Scheduling) s1 s2 s3 O O s1 s2 s3 CD

23 Data Placement in Mobile Environments S 3 v 6 v 5 v 3 v 4 S 2 v 5 v 6 v 1 v 2 S 1 v 1 v 2 v 3 v 4 S 2 v 5 v 6 v 1 v 2 S 1 v 1 v 2 v 3 v 4 Initial placement After replication degree enforcement S 3 v 1 v 2 v 3 v 4 zDesign replication and intelligent data placement mechanisms that yEnsure effective resource management yEnsure QoS for admitted clients zDesign caching mechanisms yPartition data/processing between mobile clients and infrastructure yAllows disconnected operation yEfficient power management

24 Need for a Cross Layer Approach zInformation exchange needed yTo provide information good enough for resource provisioning tasks such as admission control, load balancing etc. xNeed an information collection mechanism that is : is aware of multiple levels of imprecision in data is aware of quality requirements of applications makes optimum use of the system (network and server) resources zSample Parameters yNetwork link status, Data server capacity (Remote disk bandwidth, Processor capacity), device constraints (battery power, memory limitations)

25 Case Study: Power Management zPower Optimization in battery operated mobile devices is a crucial research challenge zDevices operate in dynamic distributed environments zPower Management strategies need to be aware of global system state and exploit it. NETWORK CARD DISPLAY CPU Display NIC CPU Misc.

26 Existing Work in Power Optimization Architecture (cpu, memory) Soderquist (ACM Multimedia 97) Azevedo (AWIA 2001) Hughes, Adve (MICRO 01, ICSA 01) Brooks (ISCA 2000), Choi (ISLPED 02) Leback (ASPLOS 2000), Microsoft’s ACPI Flinn (ICDSP 2001), Yau (ICME 2002) Krintz, Wolski (ISLPED 2004) Noble (SOSP 97, MCSA 1999) Li (CASES 2002), Othman (1998) Abeni (RTSS 98) Rudenko ( ACM SAC 99), Satyanarayan (2001) Power Optimization has been extensively researched Network Interface Card Chandra (MMCN 04,02, USENIX 2002, ICPP 04) Shenoy (ACM MM 2002) Feeney, Nilson ( Infocom 2001) Katz (IEICE 97) Operating System DVS, DPM, Driver Interfaces, system calls Ellis, Vahdat (IEEE pervasive 05, Usenix 03, ASPLOS 02) Hao, Nahrstedt (ICMCS 99, HPDC 99, Globecom 01) Yuan (MMCN 03,04, SOSP 03, ACM MM 04), Rajkumar (03), Anand (Mobicom 03, Mobisys 04) DVS (Shin, Gupta, Weiser, Srivastava, Govil et. al.) DPM (Douglis, Hembold, Delaluz, Kumpf et. al.) User/Application Quality of Service Application/user feedback

27 Limitations of Current Approaches zLimited co-ordination between the different system layers Address concerns at one or two system levels Make assumptions about adaptations at other system levels (lack awareness) zDevice Centric Cannot exploit global system knowledge (e.g. congestion, mobility, location) Reactive Adaptations zLack of generalized framework Server Wired Network Proxy Wireless Network Client Illustration Client congestion What if new applications are started or residual battery energy changes?

28 Power-aware middleware A power-cognizant distributed middleware framework can o dynamically adapt to global changes o co-ordinate techniques at different system levels o maximize the utility (application QoS, power savings) of a low-power device. o study and evaluate cross layer adaptation techniques for performance vs. quality vs. power tradeoffs for mobile handheld devices. Wide Area Network Wireless Network Low-power mobile device proxy Use a Proxy-Based Architecture Execute Remote Tasks Caching Compression State MonitorTraffic Shaping CompositingTranscoding server Use proxy to dynamically adapt to global changes Coordinate techniques on device

29 Power-Aware Adaptive Middleware Architecture (cpu, memory) Network Operating SystemMiddleware Distributed Adaptation Cross-Layer Adaptation Appl. specific Adaptation DYNAMO SYSTEM Mohapatra et. al (ICN 05, ITCC 05, ACM Middleware 04, DATE 04, ICDCS 03, MWCN 03, ACM MM 03, RTAS/RTSS Workshops 03, Estimedia 03, CIPC 03, ICDCS 01) Distributed Adaptation Cross-Layer Adaptation Power-Aware API User/Application Quality of Service Application/user feedback

30 Cross-Layer Approach device Architecture Operating System Distributed Middleware User/Application LOCAL CROSS LAYER ADAPTATION 1. Expose “state” information to other layers 2.Design strategies at each layer to dynamically adapt to changes at other layers Proxy network Middleware GLOBAL (End-to-End) PROXY BASED ADAPTATION 1.Design end-to-end adaptations that can exploit global state (network noise, mobility patterns, device state etc.) 2. Use control information to notify mobile device of adaptations 3. Adapt strategies on device

31 Energy-Sensitive Video Transcoding for Mobile devices ► We conducted a survey to subjectively assess human perception of video quality on handhelds. ► Hard to programmatically identify video quality parameters ► We identified 8 perceptible video quality levels that produced noticeable difference in power consumption (Compaq iPaq 3600) 5.38 W3.88 WQSIF, 20fps,100kbpsQ8 (Terrible) 5.5 W3.95 WQSIF, 20fps, 150KbpsQ7 (Bad) 5.63 W4.06 WHSIF, 24fps, 150KbpsQ6(Poor) 5.73 W4.15 WHSIF, 24fps, 200KbpsQ5 (Fair) 5.81 W4.24 WHSIF, 24fps, 350KbpsQ4 (Good) 5.86 W4.31 WSIF, 25fps, 350KbpsQ3 (Very Good) 5.99 W4.37 WSIF, 25fps, 450KbpsQ2 (Excellent) 6.07 W4.42 WSIF, 30fps, 650KbpsQ1 (Like original) Avg. Power (Linux) Avg. Power (Windows CE) Video transformation parameters QUALITY VIDEO TRANSCODING PARAMETERS Quality/Power Matrix for COMPAQ IPAQ 3600 ( Grand Theft Auto Action Video Sequence)

32 Energy-Sensitive Video Transcoding: Visual Comparison Parameters varying: frame size, bit-rate, frame rate Profile power for each quality Optimize system for each quality Quality 1 (like original) Avg. Power : 6.24 W Quality 4 (good) Avg. Power : 5.81 W Quality 7 (bad) Avg. Power : 5.41 W

33 Energy-Aware Video Transcoding Residual Energy (E RES ) User defined Quality (Q threshold ) Proxy Mobile Device Q STREAM = Max(Q i ) such that P STREAM * T < E RES Q STREAM > Q THRESHOLD Q STREAM = Video streamed by proxy Q threshold = Threshold quality level acceptable to the user P STREAM = Avg. Power consumption for video playback E RES = Residual Energy of device T = Time of playback Video Stream (Q STREAM )

34 Energy-Aware Application Adaptation CPUNIC Linux OS Dynamo Middleware DISPLAY NIC CPU Mobile Device Dynamo Middleware Proxy Wireless Network Wireless Network QoS Monitor Application User Profile Negotiation Communication E-Q profileTranscoder

35 Network Card Optimization zWireless NIC cards can operate in various power modes yAvg. power consumption in sleep mode (0.184 W) whereas idle/receive modes consume (1.34/1.435 W) respectively.  NIC can be transitioned to sleep mode (high energy savings)  Packets can get lost (quality drop) zAdaptation yProxy buffers video and sends it in bursts to the device yControl info added - when device should wake up  Allows for long sleep intervals of the network card on device yLimitations  Large bursts can result in high packet loss rates  Access point and mobile device buffering limitations

36 Adaptation at Proxy Residual Energy, Quality threshold + Noise (S L ), Buffer capacity ( B f ), Decode rate (F d ) Proxy Mobile Device Video Stream (Q STREAM ) # of frames, buffer size, quality Q STREAM = Max(Q i ) such that P STREAM * T < E RES Q STREAM > Q THRESHOLD Set local buffer size based on noise level (empirical) Fix quality level (Q i ) to be streamed (Q STREAM... Q THRESHOLD ) Let N = number of transcoded frames in local buffer Burst Size (I) = N / F d Send next burst after I seconds.

37 Adaptation at Mobile Device Proxy Mobile Device Video Stream (Q STREAM ) # of frames (N), buffer size, quality, σ Burst Size (I) = N / F d Worst case transmission delay of burst (D) = σ x T AP Therefore total sleep time (δ) for NIC at the device δ = I – D + γ. D EtoE total number of packets at the Access Point P saved ≥ δ x (P IDLE - P SLEEP ) Switch network card to “sleep” mode for δ seconds after receiving video

38 Network Card Adaptation in Dynamo CPUNIC Linux OS Dynamo Middleware DISPLAY NIC CPU Mobile Device Dynamo Middleware Proxy Wireless Network Wireless Network QoS Monitor Application User Profile Negotiation Communication NIC adaptation Network Transmission E-Q profileTranscoder

39 Network Energy Savings NIC CPU Backlight 399 Frames Energy Savings – 50% - 75% (over no optimization) Frames Lost – < 5% 1738 Frames Energy Savings – 35% - 57% (over no optimization) Frames Lost – < 12% 2924 Frames Energy Savings – 25% - 45% (over no optimization) Frames Lost – < 10%

40 Backlight Compensation zAdaptation 1) Enhance luminance of video frames at proxy 2) Dim backlight on the device to compensate luminance enhancement zProblems yTechnique to achieve the suitable (optimal) backlight dimming factor yReduce flicker induced by frequent backlight switching

41 Backlight Adaptation Backlight Level Quality (PSNR) Power Savings Fair 149 30.17 41.8% Good 162 34.28 36.7% Excellent 205 42.31 27.3% Backlight Level Power Savings Fair 80 44.8% Good 125 39.7% Excellent 186 30.3% Backlight Level Power Savings Fair 172 34.8% Good 162 27.7% Excellent 205 21.4%

42 Backlight Adaptation in Dynamo Residual Energy, Quality threshold + Noise (S L ), Buffer capacity ( B f ), Decode rate (F d ) Proxy Mobile Device Video Stream (Q STREAM ) # of frames, buffer size, quality + Backlight Setting Stream luminance compensated video Use backlight quantization table to set backlight

43 Backlight Adaptation using Dynamo CPUNIC Linux OS Dynamo Middleware DISPLAY NIC CPU Mobile Device Dynamo Middleware Proxy Wireless Network Wireless Network QoS Monitor Application User Profile Negotiation Communication NIC adaptor Network Transmission E-Q profileTranscoder Backlight adaptor B/L Scaling NIC CPU Backlight

44 Architecture/CPU Adaptation zDVS idea: trade off processor speed for power zMPEG frame decoding – good candidate yFrame decoding takes less than the frame delay yDecoding time – depends on frame type: I, P, B IBBBBPP MPEG Stream 0time Voltage FdFd D with DVS no DVS

45 CPU Adaptation using Dynamo Residual Energy, Quality threshold + Noise (S L ), Buffer capacity ( B f ), Decode rate (F d ) Proxy Mobile Device Video Stream (Q STREAM ) # of frames, buffer size, quality Backlight Setting + Profiled WCET, BCET, Avg. Execution time Middleware communicates execution characteristics to scheduler Scheduler can now dynamically re- compute slowdown parameters for the new video quality Determine video quality Use a rule base of profiled data to send execution parameters to the mobile device

46 Linux OS CPU Adaptation scheduler Dynamo Middleware DISPLAY NIC CPU Mobile Device Dynamo Middleware Proxy Wireless Network Wireless Network QoS Monitor Application User Profile Negotiation Communication NIC adaptor Network Transmission Backlight adaptation CPU adaptation Rule Base E-Q profile B/L Scaling Transcoder

47 Overall Energy Savings Network (37.7%) Display (26.9%) CPU (27.2%) Other (8.2%) Other (8.2%) Network (15.09%) NIC Savings (22.64%) Display (14.8%) Display Savings (12.1%) CPU (13.6%) CPU Savings (13.6%) Energy Distribution (Before Optimization) Energy Distribution (After Optimization) Note: These are avg. energy savings Total energy savings ~ 48% (for a medium action video clip called Foreman) After Cross-Layer Optimizations Avg. Battery lifetime of the mobile device increases by approximately 2 times its original lifetime under similar load (i.e. battery power consumption). Implications for a commercial PDA

48 Secure Mobile Multimedia – Energy Implications  Mobile multimedia applications are vulnerable to security attacks in wireless networks  Significant computation for video encryption is expected on battery-operated mobiles Insecure network Symmetric Encryption Technique Video Encoder Secure Video Encoder Attacks Symmetric Decryption Technique Video Decoder Secure Video Decoder Encoding without Encryption Encoding with Encryption (Selective) Encoding with Encryption (Naïve) 0 10 20 30 40 50 60 70 80 90 FOREMAN.qcifNEWS.qcif Video Clips Measured Energy (Joules) Negligible Energy Overhead Experimental Study Battery -Operated Devices ▶ Evaluate symmetric video encryption schemes w.r.t. energy Problem and Motivation

49 Reliable Mobile Multimedia – Energy Implications Problem and Motivation  Video streams over a wireless network Data loss  Error control Channel coding : FEC, Retransmission Source coding: Error-resilient coding Energy efficiency Fast recovery Flexibility Experimental Study  Probability Based Partial intra-coding  trade-offs among error resiliency, encoding efficiency, energy consumption  Most energy consuming operation  Avoiding ME can improve energy profile at the cost of encoding efficiency  High impact on image quality  Making ME algorithm robust against packet loss can improve error resiliency Idea: ME (Motion Estimation) is.. Multiplexing, Packetizing & Channel Encoding MEDCTQVLC Video Encoder Raw Video Lossy Network

50 Mobile Grid/Cloud Computing

51 Dealing with mobility zProxy must be close to device for effectiveness zIdea – use a network of proxies and identify how to use the proxy network for multiple moving devices… zWhere to obtain proxies xFixed backbone infrastructure (Akamai) –Could be effective, but proprietary xGrid infrastructure (MAPGRID) –Open access, but intermittently available xCloud infrastructure (Charisma) –Open access, limited ability to tailor use of proprietary backbone resources

52 Observations (I) – Proxy-based Techniques zNetwork proxies support for mobile applications, e.g.: yProxy caching: x[Hadjiefthymiades WWW01], [Xu TKDE04],[Wang TM 07], etc. yProxy-based content transcoding: x[Shenoy, MMCN03] [Change EUROMICRO Journal 07], etc. yOffloading tasks: x[Kejariwal, Trans VLSI 06], [Mohapatra, ACM 2003],[ Li, NOSSDAV 2003], etc. ► Grid/Cloud infrastructure support for implementing proxy-based solutions, e.g: using grid machines as proxies for mobile applications [Phan MobiCom 02] ► Online Server or third party Storage ► e.g. iPhone 3G MobileMe keeps all user information in the “cloud”  “

53 Observations (II) - Context Awareness and Predictability zImportance of Context information, e.g. yEnabling mobile applications: xLocation-based services yAchieving service flexibility and adaptability: xLayered video transcoding [Shanableh Transaction of Multimedia 05], etc. yImproving system performance: xMobility-aware data allocation (increasing cache hit ratio) [Peng ICPP00], etc. zPredictability and Patterns of Context xExploited for improving handoff performance, reducing task failure rate and dynamic resource allocation, etc xMobility prediction [Song, IEEE Transaction on Mobile Computing 06] xMobility models [ MCNett SIGMOBILE review 05] [Hong MSWiM99] xCharacterizing resource availability in desktop grids [Kondo FGCS 07]

54 MAPGrid: A New Paradigm Grid Enabled Mobile Applications VS 3 VS 2 VS 1 Broker

55 Research Challenges zResource Discovery yApplication aspect xEnsure user QoS satisfaction ySystem View xDefine an “optimal” grid resource allocation User mobility resource heterogeneity Grid intermittent availability xAdapt to changing context User mobility, device energy, and proxy availability ► Data Placement  Application aspect ► Guarantee data availability ► Improve information retrieval efficiency with user mobility  System View ► Address both short term on-demand caching and long term data placement ► Make caching or data replication at finer granularity ► Balance availability efficiency tradeoff

56 MapGrid zUses (idle) grid computing resources as the intermediate node cache proxy for mobile applications. zResources on grid (storage and computation) are intermittently available. zMapGrid uses the interval tree data structure for storing the information about available resources on grid. zMobility pattern has been used to optimal data replication policy in MapGrid. 56

57 MobileClientMobileClient BrokerBroker Mobile Client Monitoring Monitoring DirectoryServiceDirectoryService RequestSchedulerRequestScheduler ResourceReservationResourceReservation PlacementManagementPlacementManagement TertiaryStorageTertiaryStorage Volunteer Servers(Grids) Volunteer Servers(Grids) GridMonitoringGridMonitoring MapGrid Middleware Service Architecture Req Info Moving_Profile Req Req* Req# Req@ Data 1. Resource Discovery 2. Schedule Planning 1. Resource Discovery 2. Schedule Planning Reports changes in grid resources Reports changes in grid resources Admission Control Contains information about available resources on Grid and Clients Contains information about available resources on Grid and Clients Replace the data to grid resources Replace the data to grid resources Mobility Pattern detection 57

58 MapGrid zRequest: R(VID, itinerary) where VID is the video and itinerary is mobility information. zGrid Loading Factor: z Grid Factor: If grid j is available at time t equal 1 else 0. If grid j is available at time t equal 1 else 0. Distance of grid J from request R. Distance of grid J from request R. 58

59 Grid Resource Discovery for Mobile Services Partition Service Period All chunks have VS assignments? Proxy (VS) Selection Y N apply mobility or location information choose the number of chunks (partition) decide the size of each chunk choose available VSs choose lighter loaded VSs choose “closer” VSs Satisfy different QoS reqirements on service response time, service continuity… Rescheduling if dynamic changes happen R: R: Rescheduling when device has no enough residual energy for the current QoS level Rescheduling when grid node fails

60 Grid Resource Discovery for Mobile Services Partition Service Period All chunks have VSassignments? Volunteer Server Allocation Y N Problem: ► Determine number of partitions and size of each partition Machine learning approach using mobility info Rescheduling if dynamic changes happen

61 Grid Resource Discovery for Mobile Services Partition Service Period All chunks have VSassignments? Volunteer Server Allocation Y N Rescheduling if dynamic changes happen Optimizing grid resource selection ► Factors: Load, location, availability, capacity ► Achieve system-wide load balancing ► Maximize the number of accepted services Graph theoretic approach

62 Grid Service Discovery (Multimedia Application) P2: Deterministic data placement T2: Random VS availability Collections of services support by Collections of services support by grid significantly increases request acceptance and Completion ratios

63 MAPGrid Prototype Client Volunteer Servers Broker Globus Toolkit The Volunteer Server can join and disjoin the grid dynamically. Failure detection for both client and VSs using Globus life time management control. Data Information Services Life time control GridFTP JMF (Java Media Framework) JADE Http Client can specify QoS requirements via friendly GUI

64 Mobile Cloud Computing

65 What is Cloud Computing zCloud computing is a model for enabling convenient, on- demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). zIt can be rapidly provisioned and released with minimal management effort. zIt provides high level abstraction of computation and storage model. xOn-Demand Self Service, xHeterogeneous Access, xResource Pooling.

66 Essential Characteristics zOn-Demand Self Service: yA consumer can unilaterally provision computing capabilities, automatically without requiring human interaction with each service’s provider. zHeterogeneous Access: yCapabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms. 66

67 zResource Pooling: yThe provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model. yDifferent physical and virtual resources dynamically assigned and reassigned according to consumer demand. zMeasured Service: yCloud systems automatically control and optimize resources used by leveraging a metering capability at some level of abstraction appropriate to the type of service. yIt will provide an analyzable and predictable computing platform. 67 Essential Characteristics (cont.)

68 Service Models zCloud Software as a Service (SaaS): yThe capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. yThe applications are accessible from various client devices such as a web browser (e.g., web-based email). yThe consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage,… yExamples: Caspio, Google Apps, Salesforce, Nivio, Learn.com. 68

69 zCloud Platform as a Service (PaaS): yThe capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. yThe consumer does not manage or control the underlying cloud infrastructure. y Consumer has control over the deployed applications and possibly application hosting environment configurations. yExamples: Windows Azure, Google App. 69 Service Models (cont.)

70 zCloud Infrastructure as a Service (IaaS): yThe capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources. y The consumer is able to deploy and run arbitrary software, which can include operating systems and applications. yThe consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls). yExamples: Amazon EC2, GoGrid, iland, Rackspace Cloud Servers, ReliaCloud. 70 Service Models (cont.)

71 Service Model at a glance: Picture From http://en.wikipedia.org/wiki/File:Cloud_Computing_Stack.svg 71 Service Models (cont.)

72 Deployment Models zPrivate Cloud: yThe cloud is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise. zCommunity Cloud: yThe cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns. yIt may be managed by the organizations or a third party and may exist on premise or off premise. zPublic Cloud: yThe cloud infrastructure is made available to the general public or a large industry group and it is owned by an organization selling cloud services. zHybrid cloud: yThe cloud infrastructure is a composition of two or more clouds (private, community, or public). 72

73 Service Model at a glance: Picture From http://en.wikipedia.org/wiki/File:Cloud_computing_types.svg 73 Deployment Models (cont.)

74 Evolution of Computing Environment: [Satyanarayanan_2001] : Toward Pervasive Computing environment 74 CloudComputingPromises Towards Pervasive Computing

75 Cloudlet zIt has been shown that a one hop connection from mobile device to internet is not efficient. zHumans are sensitive to the current delay in clouds ylatency is unlikely to improve significantly ysecurity and firewall it is unlikely that latency improves (although increase in bandwidth). zCloudlet yBetween mobile devices and cloud pools (Infrastructure). micro edition of cloud zA cloudlet (micro edition of cloud)only contains soft states such as cache copies of data or code. 75

76 Cloudlets are as the infrastructure for mobile cloud computing. From: [Satyanarayanan_2009] 76 The prototype based on this systems is implemented in CMU and called Kimberley [Satyanarayanan_2009]. Cloudlet (cont.)

77 77 Dynamic Task Reconfiguration zHow can we support dynamic task/service reconfiguration to achieve energy gains (i.e. migrate computationally expensive tasks from the device to the proxy and use the results locally) Approach: Identify “energy intensive” components that can be dynamically migrated to a proxy ► What to reconfigure?  computation/communication characteristics of tasks (use Profiling)  Current residual power of the device ► When to reconfigure?  Identify set of policies that dictate how often or under what conditions reconfigurations should be initiated

78 78 Dynamo: Dynamic Task Reconfiguration ► Cast the distribution problem as a “Source Parametric Flow Network”. ► Use Current residual energy at device to make the flow graph “source parametric” How to maintain an optimized component distribution under dynamic device power conditions? Problem Solution

79 79 Source Parametric Flow Graph DP device proxy RdRd RpRp Runtime on Device Runtime on Proxy M1M1 M2M2 MnMn A1A1 A i = Energy cost of executing task M i at the proxy. infinite ApAp A2A2 AnAn B1B1 B i = Energy cost of executing task M i at the device. BdBd infinite B2B2 BnBn X1X1 YnYn If M i is executing on the Device, then X i = communication costs in energy terms If M i is executing on the Proxy, then Y i = communication costs in energy terms XnXn Y1Y1 Y2Y2 X2X2

80 80 High Level Algorithm ► The minimum cut of the graph determines which components can be moved to the proxy. ► Can be solved using a modified FIFO Pre-Flow push algorithm. ► Complexity = O(n 3 ) FOR (each reconfiguration interval) DO BEGIN o update list of components/residual energy on device o generate network flow graph o determine component partitioning (min cut) o IF (new partition) o reconfigure components between device and proxy END

81 AlfredO Platform (ETH Zurich) zSaaS distribution model for physical services (MW 2008, 2009) zMobile Phones as universal interfaces to cloud applications zSupports partition and distribution of modularized applications zin a client-server setup yOSGI-based (Open Services Gateway Initiative) yFocus on presentation and logic modules 81 Virtual ticket machine Turn the phone into an interface for the ticket machine Home 3D Planner

82 AlfredO architecture and applications (MW 2009) Component Based Architecture Supports optimal task migration between server and mobile client [Middleware 2009]. Generate an application graph and determine a cut (tasks done on server side and remaining will be done on mobile side) to meet the required optimization issues. Premise: Modularized application and Model of resource consumption and dependencies among application modules Goal: Partition the application between phone and server based on different criteria (bandwidth, memory )

83 83 S1S1 S1S1 S2S2 S2S2 S3S3 S3S3 S4S4 S4S4 S5S5 S5S5 S7S7 S7S7 S6S6 S6S6 S8S8 S8S8 S1S1 S1S1 S2S2 S2S2 S3S3 S3S3 S4S4 S4S4 S5S5 S5S5 S7S7 S7S7 S6S6 S6S6 S8S8 S8S8 Mobile Cut S1S1 S1S1 S2S2 S2S2 S3S3 S3S3 S4S4 S4S4 S5S5 S5S5 S7S7 S7S7 S6S6 S6S6 S8S8 S8S8 Original Plan AlfredO

84 AlfredO (MW 2009)

85 zJust like ISPs cloud computing could be considered in different Tiers. zThe backbone Cloud which usually large organization such as Google, Yahoo, Microsoft support them. zThe second tier is edge Cloud which is near end user. Tier 2-Cloud (Edge Cloud) Tier 1-Cloud (Backbone Clouds,. Amazon EC2, Azure,… ) CHARISMA: Tiered Clouds

86 Mobile Client Middleware(Broker) Cloudlet and Cloud Pool Cloud Service Registry and Discovery Admission Control Admission Control Mobile Profile Monitoring Qos Monitoring, Service Discovery Scheduler Mobile Client Mobile Client Cloudlet Pools Cloudlet Pools Mobile Profile Analyzer Qos Analyzer Cloud Pools Cloud Pools Qos Monitoring Qos Monitoring

87 87 Functionalities Middleware Blocks Accepts or rejects mobile client requests according to the resources available and mobile profile (it could be power- aware, resource –aware and…. Policies, Maybe Game Theory could be used for optimal admission policy). Admission Control Monitors mobile profile.Mobile Profile Monitoring Analyzes mobile profile specially power level, location pattern,… for optimal scheduling. Mobile Profile Analyzer It schedules the accepted requests and design a plan according to the negotiations done with Cloudlets (Schedule Queue). Scheduler It discovers cloudlets (maybe based on ontology and semantics) in the area (like UDDI), its Qos during service from mobile client. It also registers its services and middleware business on UDDI for accessing mobile clients. Qos Monitoring, Service Discovery (Cloud and Cloudlets) It is analyzing the Cloudlets services and make a list of suitable cloudlets and policy of admission. Qos Analyzer FunctionalitiesMobile Client Block Reports the Middleware about the Qos of the cloudlets.Qos Monitoring

88 Barcode Reader: Sample Application zSimple barcode reader service has been implemented. zIn this scenario the user takes a picture of the barcode for getting some information about the object, for example the cheapest price location. zThe picture is sent to cloudlet for processing. zThe cloudlet extracts the information and queries Amazon or other clouds for price and returns back to the user 88

89 CloudCloudlet 89

90 Cloud(Amazon) Cloudlet Cloud(Yahoo) Yahoo Cloud (Flicker) as a Cache. 90

91 91 http://www.youtube.com/watch?v=fQywFeN1wdM

92 Cloud computing zRemote access to distributed and shared cluster resources yPotentially owned by someone else (e.g. Amazon, Google, …) x Users rent a small fraction of vast resource pools Advertised service-level-agreements (SLAs) Resources are opaque and isolated xOffer high availability, fault tolerance, and extreme scale yRelies on OS, network, and storage virtualization/isolation SLAs Web Services Virtualization

93 Ad Hoc Future: Interoperable Networking Heterogeneous access technologies available End devices equipped with multiple radio interfaces Applications are run over the most efficient access networks 802.11b 802.11a Bluetooth GPRS UMTS Wi-Fi Cellular...... Reliable Secure QoS over multiple access networks

94 Always Best Connected: Solution Components access discovery access selection AAA support mobility management content adaptation profile handling what accesses are currently available? what are their bandwidth and delay? what access to choose; what is “best”? user/network-based solution one or multiple accesses in parallel session continuity, session transfer support for real-time services authentication, authorization, accounting accesses, services...  single logon applications adapting to access & device personal profiles for ABC access selection & content adaptation

95 Access Selection: Benefits zContinual connectivity yUninterrupted Internet access even when some of the access networks are unavailable zHigh throughput/QoS yConnect via the access network with highest data rate and/or shortest delay zBroader bandwidth yAggregate the bandwidth offered by multiple access networks zEnergy Conservation yDifferent power consumption properties of access networks provide chances for better energy efficiency. zEnhanced Security yTransmitting sensitive data on multiple access networks potentially provides higher security.

96 Access Selection: Research Challenges zNon-predetermined traffic flows start/terminate at discrete time points. zAccess networks’ bandwidth and delay might fluctuate. How to select appropriate access networks for application traffic flows? zQoS requirements zEnergy consumption zUser/application specified access preferences DynamicityMultiple Constraints

97 Groupware apps zMultiparty collaborations zSeguti zReliability + Security

98 Summary zNew Generation of Pervasive and Mobile Computing Applications with diverse content yNeed significant enhancements in system and software support zDistributed mobile middleware can significantly improve performance of next generation mobile applications. yOpen interfaces will yield much more optimized solutions for distributed mobile devices. The use of cross-layer design architectures is inevitable for future mobile systems, if we are to realize cumulative benefits of independent research at each system layer.

99 Admission Control yMultimedia clients can be tolerant or intolerant xIntolerant clients - deterministic service guarantees xTolerant clients - can tolerate brief distortions in playback continuity. yGuaranteed Services provide QoS guarantees xDeterministic Admission Control xStatistical Admission Control xPredictive Admission Control yBest effort services do not provide guarantees

100 Multimedia Storage Requirements zReal-time Storage and Retrieval xRecording CM recording devices generate continuous stream of media quanta that must be stored in realtime. xPlayback - Reverse operation of recording Media Quanta must be presented using the same timing sequence with which they were captured. zHigh Data Transfer Rate and Large Storage Space xHDTV quality - 81Mbytes/sec xNTSC quality - 27Mbytes/sec

101 Buffering Strategies in Client Server Systems yIn client-server systems (e.g. VOD) xflow of information is from server to client xIn any application, preset movement of media streams as application progresses with execution xThere is always a window available to plan movement of further bits At any point in execution, the number of bits in transit equals the buffer size at the client plus the bits equivalent of the channel, in between the client and server. xBuffer management strategies balance the bits in transit (buffer size and bits in channel) can be fixed (non-adaptive) or dynamic (adaptive)

102 Increasing Server Capacity zBatching yGroup clients requesting the same video object that arrive within a short duration of time or use adaptive piggybacking zCaching yInterval Caching xExploits sequential nature of MM access xCache only interval between temporally spaced clients xOrder the intervals based on increasing space, smaller interval implies smaller time to reaccess. yFrequency Caching x80-20 rule for video accesses xCache most frequently accessed video objects xLarge buffer required xNot dynamic - based on past history, future estimates

103 Wireless Networking 103 Networks for Mobile Computing zMobile Internet yMobile IP (MIP) xIntroduction (goals, architecture, protocol, examples) xMIP messages, encapsulations xMIP issues: triangular routing, reverse tunneling, MobileIPv6 yMicro-mobility Protocols xCellular IP xHMIP xMobileNAT ySummary z Mobile Ad Hoc Networks yIntroduction: difference from Wireless Sensor Networks (WSNs) yRouting Protocols xWRP xAODV xDSR xImprovements: interference levels topology control/management ySummary

104 Wireless Networking 104 Motivation for Mobile IP zInternet routing ybased on IP destination address and network prefix ychange of physical subnet implies that the mobile node should xchange its IP address to have a topologically correct address zChallenges – 1) find the MS, 2) avoid disconnection yDNS? Updates take to long time yPer-host routing? Too many entries in the RT. zSolution: yMobile IP is an open standard, defined by the Internet Engineering Task Force (IETF) RFC 2002, that allows users to keep the same IP address, stay connected, and maintain ongoing applications while roaming between IP networks yNetwork supported Mobile IP (tunneling in IPv4) yHost supported Mobile IPv6 ( Routing extension header)

105 Wireless Networking 105 Requirements to Mobile IP (RFC 3344) zTransparency yMobile keeps its IP address when changing subnets yCommunication continues after interruption of link possible zCompatibility yno changes to current end-systems and routers required - tunneling yno changes to fixed systems – HA-FA tunneling zSecurity yauthentication of all registration messages – MIP messages zEfficiency and scalability yonly a few additional messages to the mobile system required (connection typically via a low bandwidth radio link) – MIP messaging yGlobal support of a large number of mobile systems in the whole Internet – HA for MN

106 Wireless Networking 106 Architectural Components 1.End system elements yMobile Node (MN) yCorrespondent Node (CN): communication partner 2.Network elements yHome Agent (HA): System in the home network of the MN, typically a router xRegisters the location of the MN, tunnels IP datagrams to the COA yForeign Agent (FA): the default router for MN xForwards the tunneled datagrams to the MN xCan be collocated with MN yCare-of Address (COA): address of the current tunnel end-point for the MN xCan be associated with the MN or FA.

107 Wireless Networking 107 Mobile IP Protocol zAgent Advertisement using ICMP yHA and FA periodically send advertisement messages into their physical subnets in ICMP messages yMN listens to these messages and detects, if it is in the home or a foreign network (standard case for home network) yMN reads a COA from the FA advertisement messages yMN may send out router (agent) solicitation. zRegistering the COA using UDP ybinding for the mobile node – tuple (home address, COA, registration lifetime, authentication) ybinding update sent by MN to HA for remote redirect. zTraffic forwarding using Tunneling yHA advertises the IP address of the MN (as for fixed systems) via proxy ARP yrouters adjust their entries, these are stable for a longer time (HA responsible for a MN over a longer period of time) ypackets to the MN are sent to the HA, which tunnels to the COA. yindependent of changes in COA/FA

108 Wireless Networking 108 Example network mobile end-system Internet router end-system FA HA MN home network foreign network (physical home network for the MN) (current physical network for the MN) CN

109 Wireless Networking 109 Data transfer to the mobile system Internet sender FA HA MN home network foreign network receiver 1 2 3 1. Sender sends to the IP address of MN, HA intercepts packet (via proxy ARP) 2. HA tunnels packet to COA, here FA, by encapsulation 3. FA forwards the packet to the MN CN

110 Wireless Networking 110 Data transfer from the mobile system Internet receiver FA HA MN home network foreign network sender 1 1. Sender sends to the IP address of the receiver as usual, FA works as default router CN

111 Wireless Networking 111 Agenda zMobile Internet yMobile IP (MIP) xIntroduction (goals, architecture, protocol, examples) xMIP messages, encapsulations xMIP operations: triangular routing, reverse tunneling, MobileIPv6 yMicro-mobility Protocols xCellular IP xHMIP xMobileNAT ySummary z Mobile Ad Hoc Networks yIntroduction: difference from Wireless Sensor Networks (WSNs) yRouting Protocols xWRP xAODV xDSR xImprovements: interference levels topology control/management ySummary

112 Wireless Networking 112 Mobile Ad-hoc Networks (MANET) zAd-hoc network: yA collection of wireless mobile hosts forming a temporary network without the aid of any established infrastructure or centralized administration. zSignificant differences to existing wired networks: yWireless ySelf-starting yNo administrator yCannot assume, that every computer is within communication range of every other computer yPossibly quite dynamic topology of interconnections zTraffic types: unicast/multicast/anycast/geocast

113 Wireless Networking 113 Routing in MANET zRouting assumptions for unicast traffic yFlat topology assumption xProactive: DSDV, TORA, WRP xReactive: AODV, DSR, STAR yHierarchical topology assumption xClustering: CBRP, PATM yGeographic assumption xLocation aided routing: LAR, GeoCast

114 Wireless Networking 114 Classification of Routing Protocols for MANETS Unicast-Routing Protocol for MANET (Topology-based) Table-Driven/ Proactive Hybrid On-Demand /Reactive Clusterbased/ Hierarchical Distance Vector Link- State ZRP DSR AODV TORA LANMAR CEDAR DSDV OLSR TBRPF FSR STAR MANET: Mobile Ad hoc Network (IETF working group)

115 Wireless Networking 115 Desired Properties of Ad Hoc Routing Protocols zDistributed zBandwidth efficient yReduce control traffic/overhead zBattery efficient zFast route convergence zCorrect: loop free yReduce overhead zUnidirectional Link Support

116 Wireless Networking 116 Performance Metrics of Ad Hoc Routing Protocols zMaximize yend-to-end throughput ydelivery ratio yload balancing (congestion) zMinimize yend-to-end delay ypacket loss yshortest path/minimum hop (route length) yoverhead (bandwidth) yenergy consumption

117 Wireless Networking 117 Mobile Ad hoc Networks (MANET) vs. Sensor Networks MANETSensorNet applicationsmeeting, grp collaborationsmart building, habitat monitoring comm.address-centric comm.data centric comm. topologypeer-to-peersensors  base & peer-to-peer trafficrandomperiodic, synchronous platformlaptops, PDAsmotes: more resource constrained scale10’s>1000: larger scale and more redundancy mobilityslow (meeting) ~ fast (cars): focus on mobility slow (habitat) ~ fast: less focus on mobility so far similarityNo infrastructure, multi-hop, wireless networks

118 Wireless Networking 118 Address Centric Routing (AC) Temperature Reading (source 2) Temperature Reading (source 1) Give Me The Average Temperature? ( sink ) source 1 source 2 B Z

119 Wireless Networking 119 Data Centric Routing (DC) Temperature Reading (source 2) Temperature Reading (source 1) Give Me The Average Temperature? ( sink ) source 1 source 2 source 1 & 2 B Z

120 Wireless Networking 120 Distance-Vector routing zEach node maintains a routing table containing ylist of all available destinations ynumber distance to each each destination ynext hop to reach a destination zThe succession of next hops leads to a destination zEach node periodically broadcasts its current estimate of the shortest distance to each available destination to all of its neighbors zTypical representative: Distributed Bellman-Ford (DBF)

121 Wireless Networking 121 AODV (Ad Hoc On-Demand Distance Vector) zAODV is based on the DSDV (Destination-Sequenced Distance Vector) algorithm yDistance vector ySequence numbers controlled by the destination. zCreation of routes on a demand basis – traffic reactive zNodes that are not on a selected path do not maintain routing information or participate in routing table exchanges! zGoal: Minimize broadcast overhead and transmission latency

122 Wireless Networking 122 Route Requests from S to D in AODV B A S E F H J D C G I K Z Y Represents a node that has received RREQ for D from S M N L

123 Wireless Networking 123 Route Requests from S to D in AODV B A S E F H J D C G I K Represents transmission of RREQ Z Y Broadcast transmission M N L

124 Wireless Networking 124 Route Requests from S to D in AODV B A S E F H J D C G I K Represents links on Reverse Path Z Y M N L

125 Wireless Networking 125 Reverse Path Setup from S to D in AODV B A S E F H J D C G I K Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ once Z Y M N L

126 Wireless Networking 126 Reverse Path Setup from S to D in AODV B A S E F H J D C G I K Z Y M N L

127 Wireless Networking 127 Reverse Path Setup in AODV B A S E F H J D C G I K Z Y Node D does not forward RREQ, because node D is the intended target of the RREQ M N L

128 Wireless Networking 128 Route Reply from D to S in AODV B A S E F H J D C G I K Z Y Represents links on path taken by RREP M N L

129 Wireless Networking 129 Route Reply in AODV zIntermediate node may also send a Route Reply (RREP) provided that it knows a more recent path than the one previously known to sender S yTo determine whether the path known to an intermediate node is more recent, destination sequence numbers are used zThe likelihood that an intermediate node will send a RREP not as high as DSR yAn intermediate node which knows a route, but with a smaller sequence number, cannot send Route Reply

130 Wireless Networking 130 Forward Path Setup in AODV B A S E F H J D C G I K Z Y M N L Forward links are setup when RREP travels along the reverse path Represents a link on the forward path

131 Wireless Networking 131 Data Delivery in AODV B A S E F H J D C G I K Z Y M N L Routing table entries used to forward data packet. Route is not included in packet header. DATA

132 Wireless Networking 132 AODV Key Advantages z“ Partial” routing tables are constructed reactively yEntries are updated only when a node sends to another unreachable node yNo periodic updates yNode not on active paths maintain no routing entries  Reduce packet overhead zRouting table yNo source routing needed  reduce bit overhead y“Route caching”  reduce establishment latency ySequence number  loop freedom zPush link failure to relevant nodes  Reduce establishment latency

133 Wireless Networking 133 Dynamic Source Routing (DSR) [Johnson96] zWhen node S wants to send a packet to node D, but does not know a route to D, node S initiates a route discovery using Route Request (RREQ) zEach node appends own identifier when forwarding RREQ

134 Wireless Networking 134 Route Discovery in DSR B A S E F H J D C G I K Z Y Represents a node that has received RREQ for D from S M N L

135 Wireless Networking 135 Route Discovery in DSR B A S E F H J D C G I K Represents transmission of RREQ Z Y Broadcast transmission M N L [S] [X,Y] Represents list of identifiers appended to RREQ

136 Wireless Networking 136 Route Discovery in DSR B A S E F H J D C G I K Node H receives packet RREQ from two neighbors: potential for collision Z Y M N L [S,E] [S,C]

137 Wireless Networking 137 Route Discovery in DSR B A S E F H J D C G I K Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ once Z Y M N L [S,C,G] [S,E,F]

138 Wireless Networking 138 Route Discovery in DSR B A S E F H J D C G I K Z Y M Nodes J and K both broadcast RREQ to node D Caveat: Since nodes J and K are hidden from each other, their transmissions may collide N L [S,C,G,K] [S,E,F,J]

139 Wireless Networking 139 Route Discovery in DSR zDestination D on receiving the first RREQ, sends a Route Reply (RREP) yRREP is sent on a route obtained by reversing the route appended to received RREQ yRREP includes the route from S to D on which RREQ was received by node D

140 Wireless Networking 140 Route Reply in DSR B A S E F H J D C G I K Z Y M N L RREP [S,E,F,J,D] Represents RREP control message

141 Wireless Networking 141 Dynamic Source Routing (DSR) zNode S on receiving RREP, caches the route included in the RREP zWhen node S sends a data packet to D, the entire route is included in the packet header yhence the name source routing zIntermediate nodes use the source route included in a packet to determine to whom a packet should be forwarded

142 Wireless Networking 142 Data Delivery in DSR B A S E F H J D C G I K Z Y M N L DATA [S,E,F,J,D] Packet header size grows with route length

143 Wireless Networking 143 DSR Optimization: Route Caching zEach node caches a new route it learns by any means yThrough Route Request (RREQ) xWhen node K receives RREQ [S,C,G] destined for node D, node K learns route [K,G,C,S] to node S yThrough Route Reply (RREP) xWhen node S finds RREP [S,E,F,J,D] to node D, node S also learns route [S,E,F] to node F xWhen node F forwards RREP [S,E,F,J,D], node F learns route [F,J,D] to node D yThrough DATA packet’s source routes xWhen node E forwards Data [S,E,F,J,D] it learns route [E,F,J,D] to node D xA node may also learn a route when it overhears Data zProblem: Stale caches may increase overheads

144 Wireless Networking 144 Dynamic Source Routing: Advantages zRoutes maintained only between nodes who need to communicate yreduces overhead of route table maintenance zRouting cache can further reduce route discovery overhead zA single route discovery may yield many routes to the destination, due to intermediate nodes replying from local caches

145 Wireless Networking 145 Dynamic Source Routing: Disadvantages zPacket header size grows with route length due to source routing zFlooding of route requests may potentially reach all nodes in the network zStale caches will lead to increased overhead zCommon problems for both AODV and DSR yPotential collisions between route requests propagated by neighboring nodes - insertion of random delays before forwarding RREQ yIncreased contention if too many route replies come back due to nodes replying using their local cache - Route Reply Storm problem


Download ppt "Mobile Computing – A Distributed Systems Perspective Prof. Nalini Venkatasubramanian Department of Computer Science University of California, Irvine."

Similar presentations


Ads by Google