NotegDue to the time constraints, only a subset of the slides will be discussed during the INFOCOM 2006 tutorial presentation本资料由-大学生创业|创业|创业网 减肥药排行榜|淘宝最好的减肥药|什么减肥药效果最好|减肥瘦身药|1 NotesgNames in brackets, as in [Xyz00], refer to a document in the list of referencesgThe handout may not be as readable as the original slides, since the slides contain colored text and figuresiNote that different colors in the colored slides may look identical in the black-and-white handout本资料由-大学生创业|创业|创业网 减肥药排行榜|淘宝最好的减肥药|什么减肥药效果最好|减肥瘦身药|2 Statutory WarningsgOnly most important features of various schemes are typically discussed, i.e, features I consider as being importantiOthers may disagreegMost schemes include many more details, and optimizationsiNot possible to cover all details in this tutorialgBe aware that some protocol specs have changed several times, and the slides may not reflect the most current specificationsgJargon used to discuss a scheme may occasionally differ from that used by the proposers3 CoveragegNot intended to be exhaustivegMany interesting papers not covered in the tutorial due to lack of time4 Tutorial OutlinegIntroductiongUnicast routinggMedium Access Control gPerformance of UDP and TCPgSelected security issuesgImplementation IssuesgStandards activitiesgOpen problems5 Mobile Ad Hoc Networks (MANET)Introduction and Generalities6 Mobile Ad Hoc NetworksgFormed by wireless hosts which may be mobilegWithout (necessarily) using a pre-existing infrastructuregRoutes between nodes may potentially contain multiple hops7 Mobile Ad Hoc NetworksgMay need to traverse multiple links to reach a destinationAB8 Mobile Ad Hoc Networks (MANET)gMobility causes route changesAB9 Why Ad Hoc Networks ?gEase of deploymentgSpeed of deploymentgDecreased dependence on infrastructure10 Many ApplicationsgPersonal area networkingicell phone, laptop, ear phone, wrist watchgMilitary environmentsisoldiers, tanks, planesgCivilian environmentsiMesh networksitaxi cab networkimeeting roomsisports stadiumsiboats, small aircraftgEmergency operationsisearch-and-rescueipolicing and fire fighting11 Many VariationsgFully Symmetric Environmentiall nodes have identical capabilities and responsibilitiesgAsymmetric Capabilitiesitransmission ranges and radios may differ ibattery life at different nodes may differiprocessing capacity may be different at different nodesispeed of movementgAsymmetric Responsibilitiesionly some nodes may route packets isome nodes may act as leaders of nearby nodes (e.g., cluster head)12 Many VariationsgTraffic characteristics may differ in different ad hoc networksibit rateitimeliness constraintsireliability requirementsiunicast / multicast / geocastihost-based addressing / content-based addressing / capability-based addressinggMay co-exist (and co-operate) with an infrastructure-based network13 Many VariationsgMobility patterns may be differentipeople sitting at an airport loungeiNew York taxi cabsikids playingimilitary movementsipersonal area networkgMobility characteristicsispeedipredictability•direction of movement•pattern of movementiuniformity (or lack thereof) of mobility characteristics among different nodes14 ChallengesgLimited wireless transmission rangegBroadcast nature of the wireless mediumiHidden terminal problem (see next slide)gPacket losses due to transmission errorsgMobility-induced route changesgMobility-induced packet lossesgBattery constraintsgPotentially frequent network partitionsgEase of snooping on wireless transmissions (security hazard)15 Hidden Terminal ProblemBCANodes A and C cannot hear each otherTransmissions by nodes A and C can collide at node BNodes A and C are hidden from each other16 Research on Mobile Ad Hoc NetworksVariations in capabilities & responsibilities XVariations in traffic characteristics, mobility models, etc. XPerformance criteria (e.g., optimize throughput, reduce energy consumption) + Increased research funding =Significant research activity17 The Holy GrailgA one-size-fits-all solutioniPerhaps using an adaptive/hybrid approach that can adapt to situation at handgDifficult problemgMany solutions proposed trying to address asub-space of the problem domain18 AssumptiongUnless stated otherwise, fully symmetric environment is assumed implicitlyiall nodes have identical capabilities and responsibilities19 Unicast RoutinginMobile Ad Hoc Networks20 Why is Routing in MANET different ?gHost mobilityilink failure/repair due to mobility may have different characteristics than those due to other causesgRate of link failure/repair may be high when nodes move fastgNew performance criteria may be usediroute stability despite mobilityienergy consumption21 Unicast Routing ProtocolsgMany protocols have been proposedgSome have been invented specifically for MANETgOthers are adapted from previously proposed protocols for wired networksgNo single protocol works well in all environmentsisome attempts made to develop adaptive protocols22 Routing ProtocolsgProactive protocolsiDetermine routes independent of traffic patterniTraditional link-state and distance-vector routing protocols are proactivegReactive protocolsiMaintain routes only if neededgHybrid protocols23 Trade-OffgLatency of route discoveryiProactive protocols may have lower latency since routes are maintained at all timesiReactive protocols may have higher latency because a route from X to Y will be found only when X attempts to send to YgOverhead of route discovery/maintenanceiReactive protocols may have lower overhead since routes are determined only if needediProactive protocols can (but not necessarily) result in higher overhead due to continuous route updatinggWhich approach achieves a better trade-off depends on the traffic and mobility patterns24 Overview of Unicast Routing Protocols25 Flooding for Data DeliverygSender S broadcasts data packet P to all its neighborsgEach node receiving P forwards P to its neighborsgSequence numbers used to avoid the possibility of forwarding the same packet more than oncegPacket P reaches destination D provided that D is reachable from sender SgNode D does not forward the packet26 Flooding for Data DeliveryBASEFHJDCGIKRepresents that connected nodes are within each other’s transmission rangeZYRepresents a node that has received packet PMNL27 Flooding for Data DeliveryBASEFHJDCGIKRepresents transmission of packet PRepresents a node that receives packet P forthe first timeZYBroadcast transmissionMNL28 Flooding for Data DeliveryBASEFHJDCGIK• Node H receives packet P from two neighbors: potential for collisionZYMNL29 Flooding for Data DeliveryBASEFHJDCGIK• Node C receives packet P from G and H, but does not forward it again, because node C has already forwarded packet P onceZYMNL30 Flooding for Data DeliveryBASEFHJDCGIKZYM• Nodes J and K both broadcast packet P to node D• Since nodes J and K are hidden from each other, their transmissions may collide => => Packet P may not be delivered to node D at all, despite the use of floodingNL31 Flooding for Data DeliveryBASEFHJDCGIKZY• Node D does not forward packet P, because node D is the intended destination of packet PMNL32 Flooding for Data DeliveryBASEFHJDCGIK• Flooding completed• Nodes unreachable from S do not receive packet P (e.g., node Z)• Nodes for which all paths from S go through the destination D also do not receive packet P (example: node N)ZYMNL33 Flooding for Data DeliveryBASEFHJDCGIK• Flooding may deliver packets to too many nodes (in the worst case, all nodes reachable from sender may receive the packet)ZYMNL34 Flooding for Data Delivery: AdvantagesgSimplicitygMay be more efficient than other protocols when rate of information transmission is low enough that the overhead of explicit route discovery/maintenance incurred by other protocols is relatively higherithis scenario may occur, for instance, when nodes transmit small data packets relatively infrequently, and many topology changes occur between consecutive packet transmissionsgPotentially higher reliability of data deliveryiBecause packets may be delivered to the destination on multiple paths35 Flooding for Data Delivery: DisadvantagesgPotentially, very high overheadiData packets may be delivered to too many nodes who do not need to receive themgPotentially lower reliability of data deliveryiFlooding uses broadcasting -- hard to implement reliable broadcast delivery without significantly increasing overhead–Broadcasting in IEEE 802.11 MAC is unreliableiIn our example, nodes J and K may transmit to node D simultaneously, resulting in loss of the packet –in this case, destination would not receive the packet at all 36 Flooding of Control PacketsgMany protocols perform (potentially limited) flooding of control packets, instead of data packetsgThe control packets are used to discover routesgDiscovered routes are subsequently used to send data packet(s)gOverhead of control packet flooding is amortized over data packets transmitted between consecutive control packet floods37 Dynamic Source Routing (DSR) [Johnson96]gWhen node S wants to send a packet to node D, but does not know a route to D, node S initiates a route discoverygSource node S floods Route Request (RREQ) gEach node appends own identifier when forwarding RREQ38 Route Discovery in DSRBASEFHJDCGIKZYRepresents a node that has received RREQ for D from SMNL39 Route Discovery in DSRBASEFHJDCGIKRepresents transmission of RREQZYBroadcast transmissionMNL[S][X,Y] Represents list of identifiers appended to RREQ40 Route Discovery in DSRBASEFHJDCGIK• Node H receives packet RREQ from two neighbors: potential for collisionZYMNL[S,E][S,C]41 Route Discovery in DSRBASEFHJDCGIK• Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ onceZYMNL[S,C,G][S,E,F]42 Route Discovery in DSRBASEFHJDCGIKZYM• Nodes J and K both broadcast RREQ to node D• Since nodes J and K are hidden from each other, their transmissions may collide NL[S,C,G,K][S,E,F,J]43 Route Discovery in DSRBASEFHJDCGIKZY• Node D does not forward RREQ, because node D is the intended target of the route discoveryMNL[S,E,F,J,M]44 Route Discovery in DSRgDestination D on receiving the first RREQ, sends a Route Reply (RREP)gRREP is sent on a route obtained by reversing the route appended to received RREQgRREP includes the route from S to D on which RREQ was received by node D45 Route Reply in DSRBASEFHJDCGIKZYMNLRREP [S,E,F,J,D]Represents RREP control message46 Route Reply in DSRgRoute Reply can be sent by reversing the route in Route Request (RREQ) only if links are guaranteed to be bi-directionaliTo ensure this, RREQ should be forwarded only if it received on a link that is known to be bi-directionalgIf unidirectional (asymmetric) links are allowed, then RREP may need a route discovery for S from node D iUnless node D already knows a route to node SiIf a route discovery is initiated by D for a route to S, then the Route Reply is piggybacked on the Route Request from D.gIf IEEE 802.11 MAC is used to send data, then links have to be bi-directional (since Ack is used)47 Dynamic Source Routing (DSR)gNode S on receiving RREP, caches the route included in the RREPgWhen node S sends a data packet to D, the entire route is included in the packet headerihence the name source routinggIntermediate nodes use the source route included in a packet to determine to whom a packet should be forwarded48 Data Delivery in DSRBASEFHJDCGIKZYMNLDATA [S,E,F,J,D]Packet header size grows with route length49 When to Perform a Route DiscoverygWhen node S wants to send data to node D, but does not know a valid route node D50 DSR Optimization: Route CachinggEach node caches a new route it learns by any meansgWhen node S finds route [S,E,F,J,D] to node D, node S also learns route [S,E,F] to node FgWhen node K receives Route Request [S,C,G] destined for node, node K learns route [K,G,C,S] to node SgWhen node F forwards Route Reply RREP [S,E,F,J,D], node F learns route [F,J,D] to node DgWhen node E forwards Data [S,E,F,J,D] it learns route [E,F,J,D] to node DgA node may also learn a route when it overhears Data packets51 Use of Route CachinggWhen node S learns that a route to node D is broken, it uses another route from its local cache, if such a route to D exists in its cache. Otherwise, node S initiates route discovery by sending a route requestgNode X on receiving a Route Request for some node D can send a Route Reply if node X knows a route to node DgUse of route cache ican speed up route discoveryican reduce propagation of route requests52 Use of Route CachingBASEFHJDCGIK[P,Q,R] Represents cached route at a node (DSR maintains the cached routes in a tree format)MNL[S,E,F,J,D][E,F,J,D][C,S][G,C,S][F,J,D],[F,E,S][J,F,E,S]Z53 Use of Route Caching:Can Speed up Route DiscoveryBASEFHJDCGIKZMNL[S,E,F,J,D][E,F,J,D][C,S][G,C,S][F,J,D],[F,E,S][J,F,E,S]RREQWhen node Z sends a route requestfor node C, node K sends back a routereply [Z,K,G,C] to node Z using a locallycached route[K,G,C,S]RREP54 Use of Route Caching:Can Reduce Propagation of Route RequestsBASEFHJDCGIKZYMNL[S,E,F,J,D][E,F,J,D][C,S][G,C,S][F,J,D],[F,E,S][J,F,E,S]RREQAssume that there is no link between D and Z.Route Reply (RREP) from node K limits flooding of RREQ.In general, the reduction may be less dramatic.[K,G,C,S]RREP55 Route Error (RERR)BASEFHJDCGIKZYMNLRERR [J-D]J sends a route error to S along route J-F-E-S when its attempt to forward the data packet S (with route SEFJD) on J-D failsNodes hearing RERR update their route cache to remove link J-D56 Route Caching: Beware!gStale caches can adversely affect performancegWith passage of time and host mobility, cached routes may become invalidgA sender host may try several stale routes (obtained from local cache, or replied from cache by other nodes), before finding a good routegAn illustration of the adverse impact on TCP will be discussed later in the tutorial [Holland99]57 Dynamic Source Routing: AdvantagesgRoutes maintained only between nodes who need to communicateireduces overhead of route maintenancegRoute caching can further reduce route discovery overheadgA single route discovery may yield many routes to the destination, due to intermediate nodes replying from local caches58 Dynamic Source Routing: DisadvantagesgPacket header size grows with route length due to source routinggFlood of route requests may potentially reach all nodes in the networkgCare must be taken to avoid collisions between route requests propagated by neighboring nodesiinsertion of random delays before forwarding RREQgIncreased contention if too many route replies come back due to nodes replying using their local cacheiRoute Reply Storm problemiReply storm may be eased by preventing a node from sending RREP if it hears another RREP with a shorter route59 Dynamic Source Routing: DisadvantagesgAn intermediate node may send Route Reply using a stale cached route, thus polluting other cachesgThis problem can be eased if some mechanism to purge (potentially) invalid cached routes is incorporated. gFor some proposals for cache invalidation, see [Hu00Mobicom]iStatic timeoutsiAdaptive timeouts based on link stability60 Flooding of Control PacketsgHow to reduce the scope of the route request flood ?iLAR [Ko98Mobicom]iQuery localization [Castaneda99Mobicom]gHow to reduce redundant broadcasts ?iThe Broadcast Storm Problem [Ni99Mobicom]61 Location-Aided Routing (LAR) [Ko98Mobicom]gExploits location information to limit scope of route request floodiLocation information may be obtained using GPSgExpected Zone is determined as a region that is expected to hold the current location of the destinationiExpected region determined based on potentially old location information, and knowledge of the destination’s speedgRoute requests limited to a Request Zone that contains the Expected Zone and location of the sender node62 Expected Zone in LARXYrX = last known location of node D, at time t0Y = location of node D at current time t1, unknown to node Sr = (t1 - t0) * estimate of D’s speedExpected Zone63 Request Zone in LARXYrSRequest ZoneNetwork SpaceBA64 LARgOnly nodes within the request zone forward route requestsiNode A does not forward RREQ, but node B does (see previous slide)gRequest zone explicitly specified in the route requestgEach node must know its physical location to determine whether it is within the request zone65 LARgOnly nodes within the request zone forward route requestsgIf route discovery using the smaller request zone fails to find a route, the sender initiates another route discovery (after a timeout) using a larger request zoneithe larger request zone may be the entire networkgRest of route discovery protocol similar to DSR66 LAR Variations: Adaptive Request ZonegEach node may modify the request zone included in the forwarded requestgModified request zone may be determined using more recent/accurate information, and may be smaller than the original request zoneSBRequest zone adapted by BRequest zone defined by sender S67 LAR Variations: Implicit Request ZonegIn the previous scheme, a route request explicitly specified a request zonegAlternative approach: A node X forwards a route request received from Y if node X is deemed to be closer to the expected zone as compared to YgThe motivation is to attempt to bring the route request physically closer to the destination node after each forwarding68 Location-Aided RoutinggThe basic proposal assumes that, initially, location information for node X becomes known to Y only during a route discoverygThis location information is used for a future route discoveryiEach route discovery yields more updated information which is used for the next discoveryVariationsgLocation information can also be piggybacked on any message from Y to XgY may also proactively distribute its location informationiSimilar to other protocols (e.g., DREAM, GLS)69 Location Aided Routing (LAR)gAdvantagesireduces the scope of route request floodireduces overhead of route discoverygDisadvantagesiNodes need to know their physical locationsiDoes not take into account possible existence of obstructions for radio transmissions70 DetourRouting Using Location Information71 Geographic Distance Routing (GEDIR) [Lin98]gLocation of the destination node is assumed knowngEach node knows location of its neighborsgEach node forwards a packet to its neighbor closest to the destinationgRoute taken from S to D shown belowSABDCFEobstructionHG72 Geographic Distance Routing (GEDIR) [Stojmenovic99]gThe algorithm terminates when same edge traversed twice consecutivelygAlgorithm fails to route from S to EiNode G is the neighbor of C who is closest from destination E, but C does not have a route to ESABDCFEobstructionHG73 Routing with Guaranteed Delivery [Bose99Dialm]gImproves on GEDIR [Lin98]gGuarantees delivery (using location information) provided that a path exists from source to destinationgRoutes around obstacles if necessarygA similar idea also appears in [Karp00Mobicom]74 Back toReducing Scope of the Route Request FloodEnd of Detour75 Query Localization [Castaneda99Mobicom]gLimits route request flood without using physical informationgRoute requests are propagated only along paths that are close to the previously known routegThe closeness property is defined without using physical location information76 Query LocalizationgPath locality heuristic: Look for a new path that contains at most k nodes that were not present in the previously known route gOld route is piggybacked on a Route RequestgRoute Request is forwarded only if the accumulated route in the Route Request contains at most k new nodes that were absent in the old routeithis limits propagation of the route request77 Query Localization: ExampleBEASDCGFInitial routefrom S to DBEASDCGFPermitted routeswith k = 2Node F does not forward the routerequest since it is not on any routefrom S to D that contains at most2 new nodesNode D moved78 Query LocalizationgAdvantages: iReduces overhead of route discovery without using physical location information iCan perform better in presence of obstructions by searching for new routes in the vicinity of old routesgDisadvantage:iMay yield routes longer than LAR(Shortest route may contain more than k new nodes)79 BDCABroadcast Storm Problem [Ni99Mobicom]gWhen node A broadcasts a route query, nodes B and C both receive itgB and C both forward to their neighborsgB and C transmit at about the same time since they are reacting to receipt of the same message from AgThis results in a high probability of collisions80 Broadcast Storm ProblemgRedundancy: A given node may receive the same route request from too many nodes, when one copy would have sufficedgNode D may receive from nodes B and C bothBDCA81 Solutions for Broadcast StormgProbabilistic scheme: On receiving a route request for the first time, a node will re-broadcast (forward) the request with probability pgAlso, re-broadcasts by different nodes should be staggered by using a collision avoidance technique (wait a random delay when channel is idle)ithis would reduce the probability that nodes B and C would forward a packet simultaneously in the previous example82 BDCAFESolutions for Broadcast StormsgCounter-Based Scheme: If node E hears more than k neighbors broadcasting a given route request, before it can itself forward it, then node E will not forward the requestgIntuition: k neighbors together have probably already forwarded the request to all of E’s neighbors83 EZ S(Y), then X ignores the routing information received from Y iIf S(X) = S(Y), and cost of going through Y is smaller than the route known to X, then X sets Y as the next hop to ZiIf S(X) < S(Y), then X sets Y as the next hop to Z, and S(X) is updated to equal S(Y)XYZ155 Hybrid Protocols156 Zone Routing Protocol (ZRP) [Haas98]Zone routing protocol combinesgProactive protocol: which pro-actively updates network state and maintains route regardless of whether any data traffic exists or notgReactive protocol: which only determines route to a destination if there is some data to be sent to the destination157 ZRPgAll nodes within hop distance at most d from a node X are said to be in the routing zone of node XgAll nodes at hop distance exactly d are said to be peripheral nodes of node X’s routing zone158 ZRPgIntra-zone routing: Pro-actively maintain state information for links within a short distance from any given nodeiRoutes to nodes within short distance are thus maintained proactively (using, say, link state or distance vector protocol)gInter-zone routing: Use a route discovery protocol for determining routes to far away nodes. Route discovery is similar to DSR with the exception that route requests are propagated via peripheral nodes.159 ZRP: Example withZone Radius = d = 2SCAEFBDS performs routediscovery for DDenotes route request160 ZRP: Example with d = 2SCAEFBDS performs routediscovery for DDenotes route replyE knows route from E to D, so route request need not beforwarded to D from E161 ZRP: Example with d = 2SCAEFBDS performs routediscovery for DDenotes route taken by Data162 Landmark Routing (LANMAR) for MANET with Group Mobility [Pei00Mobihoc]gA landmark node is elected for a group of nodes that are likely to move togethergA scope is defined such that each node would typically be within the scope of its landmark nodegEach node propagates link state information corresponding only to nodes within it scope and distance-vector information for all landmark nodesiCombination of link-state and distance-vectoriDistance-vector used for landmark nodes outside the scopeiNo state information for non-landmark nodes outside scope maintained163 LANMAR Routing to Nodes Within ScopegAssume that node C is within scope of node AgRouting from A to C: Node A can determine next hop to node C using the available link state informationABCFHGED164 LANMAR Routing to Nodes Outside ScopegRouting from node A to F, which is outside A’s scopegLet H be the landmark node for node FgNode A somehow knows that H is the landmark for CgNode A can determine next hop to node H using the available distance vector informationABCFHGED165 LANMAR Routing to Nodes Outside ScopegNode D is within scope of node FgNode D can determine next hop to node F using link state informationgThe packet for F may never reach the landmark node H, even though initially node A sends it towards HABCFHGED166 gLANMAR scheme uses node identifiers as landmarksgAnchored Geodesic Scheme [LeBoudec00] uses geographical regions as landmarks167 RoutinggProtocols discussed so far find/maintain a route provided it existsgSome protocols attempt to ensure that a route exists byiPower Control [Ramanathan00Infocom]iLimiting movement of hosts or forcing them to take detours [Reuben98thesis]168 Power ControlgProtocols discussed so far find a route, on a given network topologygSome researchers propose controlling network topology by transmission power control to yield network properties which may be desirable [Ramanathan00Infocom] iSuch approaches can significantly impact performance at several layers of protocol stackg[Wattwnhofer00Infocom] provides a distributed mechanism for power control which allows for local decisions, but guarantees global connectivityiEach node uses a power level that ensures that the node has at least one neighbor in each cone with angle 2p/3169 Some Variations170 Power-Aware Routing [Singh98Mobicom,Chang00Infocom]Define optimization criteria as a function of energyconsumption. Examples:gMinimize energy consumed per packetgMinimize time to network partition due to energy depletiongMaximize duration before a node fails due to energy depletion171 Power-Aware Routing [Singh98Mobicom]gAssign a weight to each linkgWeight of a link may be a function of energy consumed when transmitting a packet on that link, as well as the residual energy levelilow residual energy level may correspond to a high costgPrefer a route with the smallest aggregate weight172 Power-Aware RoutingPossible modification to DSR to make it power aware (for simplicity, assume no route caching):gRoute Requests aggregate the weights of all traversed linksgDestination responds with a Route Reply to a Route Request ifiit is the first RREQ with a given (“current”) sequence number, oriits weight is smaller than all other RREQs received with the current sequence number173 Preemptive Routing [Goff01MobiCom]gAdd some proactivity to reactive routing protocols such as DSR and AODVgRoute discovery initiated when it appears that an active route will break in the near futuregInitiating route discover before existing route breaks reduces discovery latency174 Performance of Unicast Routing in MANETgSeveral performance comparisons [Broch98Mobicom,Johansson99Mobicom,Das00Infocom,Das98ic3n]gWe will discuss performance issue later in the tutorial175 Address Auto-Configuration176 Address Auto-configurationgAuto-configuration important for autonomous operation of an ad hoc networkgIPv4 and IPv6 auto-configuration mechanisms have been proposed•Need to be adapted for ad hoc networks177 Auto-Configuration inAd Hoc NetworksgWorst case network delays may be unknown, or highly variablegPartitions may occur, and merge178 Duplicate Address Detectionin Ad Hoc NetworksgSeveral proposalsgOne example [Perkins]:iHost picks an address randomlyiHost performs route discovery for the chosen addressiIf a route reply is received, address duplication is detected179 Example: Initially Partitioned NetworkD’s packets for address a routed to A180 Merged NetworkgDuplicate address detection (DAD) important To avoid misrouting181 Strong DADgDetect duplicate addresses within t secondsgNot possible to guarantee strong DAD in presence of unbounded delaysiMay occur due to partitionsiEven when delays are bounded, bound may be difficult to calculate•Unknown network size182 DADgStrong DAD impossible with unbounded delaygHow to achieve DAD ?183 Design PrinciplegIf you cannot solve a problemChange the problem184 Weak DAD [Vaidya02MobiHoc]Packets from a given host to a given address should be routed to the same destination, despite duplication of the address185 Example: Initially Partitioned NetworkD’s packets for address a routed to A186 Merged Network:Acceptable Behavior with Weak DADPackets from Dto address astill routed tohost A187 Merged Network:Unacceptable behaviorPackets from Dto address arouted tohost K insteadof A188 Weak DAD: ImplementationgIntegrate duplicate address detection with route maintenanceSKIP189 Weak DAD with Link State RoutinggEach host has a unique (with high probability) keyiMay include MAC address, serial number, …iMay be large in sizegIn all routing-related packets (link state updates) IP addresses tagged by keysi (IP, key) pair190 Weak DAD with Link State RoutinggAddress duplication not always detectedgDuplication detected before misrouting can occurgWeak Reliable, but potentially delayed, DAD191 Link State Routing (LSR): Example192 Weak DAD with LSR193 Weak DAD with LSRHost X with key K_x joins and chooses IP_A (address duplication)X194 Weak DAD with LSRIf host D receives a link state update containing (IP_A, K_x), host D detects duplication of address IP_ATwo pairs with identical IP address but distinct keys imply duplication195 Just-in-Time DADgDuplication detected before routing tables could be mis-configured196 Higher Layer InteractiongHigher layers interaction may result in undesirable behavior197 Q discovers service Foo at address aExample198 Example: Networks mergeNode Aperformsservice discoveryfor Foo, andlearns from Qthat Foo isavailable ataddress a199 Example: Networks mergeNode A’s packets to aare delivered to MR provides serviceFoo not M200 Enhanced Weak DADgIf the status of host A above the network layer depends on state of host B(State A state B) then network layer of host A should be aware of (IP, key) pairs known to B201 Enhanced Weak DADgWorks despite upper layer interaction202 Weak DAD: Other IssuesgDuplicate MAC addresses within two hops of each other bad•Need a duplicate MAC address detection schemegNetwork layers performing unicasts using multicast/floodinggLimited-time address leasesgDAD with other routing protocolsiPossible. [Vaidya02Mobihoc] also discusses DSR.203 SummarygStrong DAD – Not always possiblegWeak DAD feasibleiCombines DAD with route maintenancegOverhead of weak DADiExpected to be low204 Capacity of Ad Hoc Networks205 Capacity of Fixed Ad Hoc Networks [Gupta00it]gn nodes in area A transmitting at W bits/sec using a fixed range (distance between a random pair of nodes is O(sqrt(n))gBit-distance product that can be transported by the network per second is Q ( W sqrt (A n) )gThroughput per nodeQ ( W / sqrt (n) )206 Capacity of Mobile Ad Hoc Networks [Grossglauser01Infocom]gAssume random motiongAny two nodes become neighbors once in a whilegEach node assumed sender for one session, and destination for another sessiongRelay packets through at most one other nodeiPacket go from S to D directly, when S and D are neighbors, or from S to a relay and the the relay to D, when each pair becomes neighbor respectivelygThroughput of each session is O(1)iIndependent of n207 Continues from last slide …gDelay in packet delivery can be large if O(1) throughput is to be achievediDelay incurred waiting for the destination to arrive close to a relay or the sendergTrade-off between delay and throughput208 Measured Capacity [Li01MobiCom]gConfirms intuitiongIn fixed networks, capacity is higher if average distance between source-destination pairs is small209 Measured Scaling Law[Gupta00]gMeasured in static networksgThroughput declines worse with n than theoretically predicted gExisting MAC protocols unable to exploit “parallelism” in channel access210 CapacitygHow to design MAC and routing protocols to approach theoretical capacity ?gOpen problem211 Medium Access Control Protocols212 Medium Access ControlgWireless channel is a shared mediumgNeed access control mechanism to avoid interferencegMAC protocol design has been an active area of research for many years [Chandra00survey]213 MAC: A Simple ClassificationWirelessMACCentralizedDistributedGuaranteedorcontrolledaccessRandomaccessThistutorial214 This tutorialgMostly focus on random access protocolsgNot a comprehensive overview of MAC protocolsgProvides discussion of some example protocols215 ABCHidden Terminal Problem [Tobagi75]gNode B can communicate with A and C bothgA and C cannot hear each othergWhen A transmits to B, C cannot detect the transmission using the carrier sense mechanismgIf C transmits, collision will occur at node B216 Busy Tone [Tobagi75,Haas98] gA receiver transmits busy tone when receiving datagAll nodes hearing busy tone keep silentgAvoids interference from hidden terminalsgRequires a separate channel for busy tone217 MACA Solution for Hidden Terminal Problem [Karn90]gWhen node A wants to send a packet to node B, node A first sends a Request-to-Send (RTS) to AgOn receiving RTS, node A responds by sending Clear-to-Send (CTS), provided node A is able to receive the packetgWhen a node (such as C) overhears a CTS, it keeps quiet for the duration of the transferiTransfer duration is included in RTS and CTS bothABC218 ReliabilitygWireless links are prone to errors. High packet loss rate detrimental to transport-layer performance.gMechanisms needed to reduce packet loss rate experienced by upper layers219 A Simple Solution to Improve ReliabilitygWhen node B receives a data packet from node A, node B sends an Acknowledgement (Ack). This approach adopted in many protocols [Bharghavan94,IEEE 802.11]gIf node A fails to receive an Ack, it will retransmit the packetABC220 IEEE 802.11 Wireless MACgDistributed and centralized MAC componentsiDistributed Coordination Function (DCF)iPoint Coordination Function (PCF)gDCF suitable for multi-hop ad hoc networkinggDCF is a Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) protocol221 IEEE 802.11 DCF gUses RTS-CTS exchange to avoid hidden terminal problemiAny node overhearing a CTS cannot transmit for the duration of the transfergUses ACK to achieve reliabilitygAny node receiving the RTS cannot transmit for the duration of the transferiTo prevent collision with ACK when it arrives at the senderiWhen B is sending data to C, node A will keep quiteABC222 Collision AvoidancegWith half-duplex radios, collision detection is not possiblegCSMA/CA: Wireless MAC protocols often use collision avoidance techniques, in conjunction with a (physical or virtual) carrier sense mechanismgCarrier sense: When a node wishes to transmit a packet, it first waits until the channel is idle.gCollision avoidance: Nodes hearing RTS or CTS stay silent for the duration of the corresponding transmission. Once channel becomes idle, the node waits for a randomly chosen duration before attempting to transmit.223 CFABEDRTSRTS = Request-to-SendIEEE 802.11Pretending a circular range224 CFABEDRTSRTS = Request-to-SendIEEE 802.11NAV = 10NAV = remaining duration to keep quiet225 CFABEDCTSCTS = Clear-to-SendIEEE 802.11226 CFABEDCTSCTS = Clear-to-SendIEEE 802.11NAV = 8227 CFABEDDATA•DATA packet follows CTS. Successful data reception acknowledged using ACK. IEEE 802.11228 IEEE 802.11CFABEDACK229 CFABEDACKIEEE 802.11Reserved area230 IEEE 802.11CFABEDDATATransmit “range”Interference“range”Carrier senserangeFA231 CSMA/CAgPhysical carrier sense, andgVirtual carrier sense using Network Allocation Vector (NAV)gNAV is updated based on overheard RTS/CTS/DATA/ACK packets, each of which specified duration of a pending transmissiongNodes stay silent when carrier sensed (physical/virtual)gBackoff intervals used to reduce collision probability232 Backoff Interval gWhen transmitting a packet, choose a backoff interval in the range [0,cw]icw is contention windowgCount down the backoff interval when medium is idleiCount-down is suspended if medium becomes busygWhen backoff interval reaches 0, transmit RTS233 DCF ExampledatawaitB1 = 5B2 = 15B1 = 25B2 = 20datawaitB1 and B2 are backoff intervalsat nodes 1 and 2cw = 31B2 = 10234 Backoff IntervalgThe time spent counting down backoff intervals is a part of MAC overheadgChoosing a large cw leads to large backoff intervals and can result in larger overheadgChoosing a small cw leads to a larger number of collisions (when two nodes count down to 0 simultaneously)235 gSince the number of nodes attempting to transmit simultaneously may change with time, some mechanism to manage contention is neededgIEEE 802.11 DCF: contention window cw is chosen dynamically depending on collision occurrence236 Binary Exponential Backoff in DCFgWhen a node fails to receive CTS in response to its RTS, it increases the contention windowicw is doubled (up to an upper bound)gWhen a node successfully completes a data transfer, it restores cw to Cwmingcw follows a sawtooth curve237 MILD Algorithm in MACAW [Bharghavan94]gWhen a node successfully completes a transfer, reduces cw by 1iIn 802.11 cw is restored to cwminiIn 802.11, cw reduces much faster than it increasesiMACAW: cw reduces slower than it increases Exponential Increase Linear DecreasegMACAW can avoid wild oscillations of cw when large number of nodes contend for the channel238 Alternative Contention Resolution Mechanism [Hiperlan]gElimination phaseiA node transmits a burst for a random number (geometrically distributed) of slotsiIf medium idle at the end of the burst, go to yield phase, else give up until next roundgYield phaseiStay silent for a random number (geometrical distributed) of slotsiIf medium still silent, transmit239 Random backoffData Transmission/ACKRTS/CTSContention Resolution OverheadgChannel contention resolved using backoffiNodes choose random backoff interval from [0, CW]iCount down for this interval before transmissiongBackoff and (optional) RTS/CTS handshake before transmission of data packet240 Inefficiency of IEEE 802.11gBackoff interval should be chosen appropriately for efficiencygBackoff interval with 802.11 far from optimum241 Random backoffData Transmission/ACKRTS/CTSUnproductiveObservationgBackoff and RTS/CTS handshake are unproductive:iDo not contribute to throughput242 ObservationgTerry Todd observed that if a protocol has a “bandwidth-independent” overhead it is possible to improve performance by moving the bandwidth-independent overhead to a narrowband channelgPipelining motivated by these observations243 Random backoffData Transmission/ACKRTS/CTSStage1Stage2Pipelining [Yang02techrep]gTwo stage pipeline:iRandom backoff and RTS/CTS handshakeiData transmission and ACKg“Total” pipelining: Resolve contention completely in stage 1244 Data Transmission/ACKRandom backoffRTS/CTSRandom backoffRTS/CTSRTS/CTSRandom backoffData Transmission/ACKHow to Pipeline ?gUse two channelsiControl Channel: Random backoff and RTS/CTS handshakeiData Channel: Data transmission and ACK245 Data Transmission/ACKRandom backoffRTS/CTSRandom backoffRTS/CTSRTS/CTSRandom backoffData Transmission/ACKControl ChannelData Channel PipelininggPipelining works well only if two stages are balanced!246 PipelininggLength of stage 1 depends on:iControl channel bandwidthiThe random backoff durationiThe number of collisions occurredgLength of stage 2 depends on:iData channel bandwidthiThe data packet size247 How much bandwidth does control channel require?gIf small, then iRTS/CTS takes very long time.iCollision detection is slowgIf large, then iThe portion of channel bandwidth used for productive data packet transmission is reducedTotal bandwidth is fixed!248 Difficulty with Total PipelininggThe optimum division of channel bandwidth varies with contention level and data packet sizegPerformance with inappropriate bandwidth division could be even worse than 802.11 DCF249 How to get around the issue of bandwidth division ?250 Partial PipelininggOnly partially resolve channel contention in stage 1gSince no need to completely resolve contention, the length of stage 1 can be elastic to match the length of stage 2251 Modified Two Stage PipelinegStage 1: Random backoff phase 1gStage 2: Random backoff phase 2, RTS/CTS handshake and Data/ACK transmissionBackoff phase 1Data/ACKStage1Stage2RTS/CTSBackoff phase 2252 Random backoff phase 1Random backoff phase 1Random backoff phase 1Data/ACKRTS/CTSBackoff phase 2Data/ACKRTS/CTSBackoff phase 2gStill use two channelsiNarrow Band Busy Tone Channel: •Random backoff phase 1iData Channel: Random backoff phase 2, RTS/CTS handshake and Data/ACK253 Random Backoff Phase 1gEach Station maintains a counter for random backoff phase 1gThe stations, which count to zero first, send a busy tone to claim win in stage 1iMultiple winners are possiblegOther stations know they lost on sensing a busy tone254 Gain over total pipelining?gNo packets transmitted on busy tone channelibandwidth can be smallithe difficulty of deciding optimum bandwidth division in “total pipelining” is avoidedgLength of stage 1 is elastic so the two stages can be kept balanced255 Benefits of Partial PipelinegOnly winners of stage 1 can contend channel in stage 2ireduces the data channel contentionireduces collision probability on the data channelStage 1Stage 2256 Sounds like HIPERLAN/1?Elimination StageData TransmissionYield StageHIPERLAN / 1 (no pipelining)Random backoff phase 1Random backoff phase 1Random backoff phase 1Data/ACKRTS/CTSBackoff phase 2Data/ACKRTS/CTSBackoff phase 2Partial Pipelining257 Benefits of Partial PipelinegBecause of pipelining, stages 1 and 2 proceedin parallel. Stage 1 costs little except for a narrow band busy tone channelRandom backoff phase 1Random backoff phase 1Random backoff phase 1Data/ACKRTS/CTSBackoff phase 2Data/ACKRTS/CTSBackoff phase 2Partial Pipelining258 Benefits of Partial PipelinegBy migrating most of the backoff to busy tone channel,bandwidth cost of random backoff is reducediCost of backoff = Channel bandwidth * backoff durationData Channel BandwidthBusy Tone Channel BandwidthBackoff DurationArea = cost of backoffUsing IEEE 802.11 DSSS, the backoff duration could be several milliseconds259 Results of Partial PipelininggImproved throughput and stability over 802.11 DCF802.11 DCFPartial Pipelining260 Fairness261 Fairness IssuegMany definitions of fairness plausiblegSimplest definition: All nodes should receive equal bandwidthABCDTwo flows262 Fairness IssuegAssume that initially, A and B both choose a backoff interval in range [0,31] but their RTSs collidegNodes A and B then choose from range [0,63]iNode A chooses 4 slots and B choose 60 slotsiAfter A transmits a packet, it next chooses from range [0,31]iIt is possible that A may transmit several packets before B transmits its first packetABCDTwo flows263 Fairness IssuegUnfairness occurs when one node has backed off much more than some other nodeABCDTwo flows264 MACAW Solution for FairnessgWhen a node transmits a packet, it appends the cw value to the packet, all nodes hearing that cw value use it for their future transmission attemptsgSince cw is an indication of the level of congestion in the vicinity of a specific receiver node, MACAW proposes maintaining cw independently for each receivergUsing per-receiver cw is particularly useful in multi-hop environments, since congestion level at different receivers can be very different265 Another MACAW ProposalgFor the scenario below, when node A sends an RTS to B, while node C is receiving from D, node B cannot reply with a CTS, since B knows that D is sending to CgWhen the transfer from C to D is complete, node B can send a Request-to-send-RTS to node A [Bharghavan94Sigcomm]iNode A may then immediately send RTS to node BABCD266 gThis approach, however, does not work in the scenario belowiNode B may not receive the RTS from A at all, due to interference with transmission from CABCD267 Weighted Fair Queueing [Keshav97book]gAssign a weight to each nodegBandwidth used by each node should be proportional to the weight assigned to the node268 Distributed Fair Scheduling (DFS) [Vaidya00Mobicom]gA fully distributed algorithm for achieving weighted fair queueinggChooses backoff intervals proportional to(packet size / weight)gDFS attempts to mimic the centralized Self-Clocked Fair Queueing algorithm [Golestani]gWorks well on a LAN269 Distributed Fair Scheduling (DFS)datawaitB1 = 15B2 = 5B1 = 15 (DFS actually picks a random value with mean 15)B2 = 5 (DFS picks a value with mean 5)Weight of node 1 = 1Weight of node 2 = 3Assume equalpacket sizeB1 = 10B2 = 5datawaitB1 = 5B2 = 5Collision !270 Impact of CollisionsgAfter collision resolution, either node 1 or node 2 may transmit a packetgThe two alternatives may have different fairness properties (since collision resolution can result in priority inversion)271 Distributed Fair Scheduling (DFS)datawaitB1 = 10B2 = 5B1 = 10B2 = 5datawaitB1 = 5B2 = 5Collision resolutiondatawaitdata272 Distributed Fair SchedulinggDFS uses randomization to reduce collisionsiAlleviates negative impact of synchronizationgDFS also uses a shifted contention window for choosing initial backoff intervaliReduces priority inversion (which leads to short-term unfairness)031031802.11DFS273 DFSgDue to large cw, DFS can potentially yield lower throughput than IEEE 802.11itrade-off between fairness and throughputgOn multi-hop network, properties of DFS still need to be characterizedgFairness in multi-hop case affected by hidden terminalsiMay need use of a copying technique, analogous to window copying in MACAW, to share some protocol state274 Fairness in Multi-Hop NetworksgSeveral definitions of fairness [Ozugur98,Vaidya99MSR,Luo00Mobicom, Nandagopal00Mobicom]gHidden terminals make it difficult to achieve a desired notion of fairness275 Estimation-Based Fair MAC [Bansou00MobiHoc]gAttempts to equalize throughput/weight ratio for all nodesgTwo parts of the algorithmiFair share estimationiWindow adjustmentgEach node estimates how much bandwidth (W) it is able to use, and the amount of bandwidth used by each station in its vicinityiEstimation based on overheard RTS, CTS, DATA packets276 Estimation-Based Fair MACgFair share estimation: Node estimates how much bandwidth (Wi) it is able to use, and the amount of bandwidth (Wo) used by by all other neighbors combinediEstimation based on overheard RTS, CTS, DATA packets277 Estimation-Based Fair MACgDefine:iTi = Wi / weight of iiTo = Wo / weight assigned to the group of neighbors of iiFairness index = Ti / TogWindow adjustment: iIf fairness index is too large, cw = cw * 2iElse if fairness index is too small, cw = cw / 2iElse no change to cw (contention window)SKIP278 Proportional Fair Contention Resolution (PFCR) [Nandagopal00Mobicom]gProportional fairness: Allocate bandwidth Ri to node i such that any other allocation Si has the following propertyiSi (Si-Ri) / Ri < 0 gLink access probability is dynamically changed depending on success/failure at transmitting a packetiOn success: Link access probability is increased by an additive factor iOn failure: Link access probability is decreased by a multiplicative factor (1-b) 279 Sender-Initiated ProtocolsgThe protocols discussed so far are sender-initiated protocolsgThe sender initiates a packet transfer to a receiver280 Receive-Initiated Mechanism [Talucci97,Garcia99]gIn most protocols, sender initiates a transfergAlternatively, a receiver may send aReady-To-Receive (RTR) message to a sender requesting it to being a packet transfergSender node on receiving the RTR transmits datagHow does a receiver determine when to poll a sender with RTR?iBased on history, and prediction of traffic from the sender281 Energy Conservation282 Energy ConservationgSince many mobile hosts are operated by batteries, MAC protocols which conserve energy are of interestgTwo approaches to reduce energy consumptioniPower save: Turn off wireless interface when desirableiPower control: Reduce transmit power283 Power Aware Multi-Access Protocol (PAMAS) [Singh98]gA node powers off its radio while a neighbor is transmitting to someone elseNode A sending to BNode C stays powered offCBA284 Power Aware Multi-Access Protocol (PAMAS)gWhat should node C do when it wakes up and finds that D is transmitting to someone elseiC does not know how long the transfer will lastNode A sending to BC stays powered offCBADENode D sending to EC wakes up andfinds medium busySKIP285 PAMASgPAMAS uses a control channel separate from the data channelgNode C on waking up performs a binary probe to determine the length of the longest remaining transferiC sends a probe packet with parameter LiAll nodes which will finish transfer in interval [L/2,L] respondiDepending on whether node C see silence, collision, or a unique response it takes varying actionsgNode C (using procedure above) determines the duration of time to go back to sleep286 Disadvantages of PAMASgUse of a separate control channelgNodes have to be able to receive on the control channel while they are transmitting on the data channeliAnd also transmit on data and control channels simultaneouslygA node (such as C) should be able to determine when probe responses from multiple senders collide287 Another Proposal in PAMASgTo avoid the probing, a node should switch off the interface for data channel, but not for the control channel (which carries RTS/CTS packets)gAdvantage: Each sleeping node always know how long to sleep by watching the control channelgDisadvantage: This may not be useful when hardware is shared for the control and data channelsiIt may not be possible turn off much hardware due to the sharing288 Power Save in IEEE 802.11 Ad Hoc ModegTime is divided into beacon intervalsgEach beacon interval begins with an ATIM windowiATIM = Beacon intervalATIMwindow289 Power Save in IEEE 802.11 Ad Hoc ModegIf host A has a packet to transmit to B, A must send an ATIM Request to B during an ATIM WindowgOn receipt of ATIM Request from A, B will reply by sending an ATIM Ack, and stay up during the rest of the beacon intervalgIf a host does not receive an ATIM Request during an ATIM window, and has no pending packets to transmit, it may sleep during rest of the beacon interval290 Power Save in IEEE 802.11 Ad Hoc ModeATIMReqATIMAckAckDataSleepNode ANode CNode B291 Power Save in IEEE 802.11 Ad Hoc ModegSize of ATIM window and beacon interval affects performance [Woesner98]gIf ATIM window is too large, reduction in energy consumption reducediEnergy consumed during ATIM windowgIf ATIM window is too small, not enough time to send ATIM request292 Power Save in IEEE 802.11 Ad Hoc ModegHow to choose ATIM window dynamically?iBased on observed load [Jung02infocom]gHow to synchronize hosts?iIf two hosts’ ATIM windows do not overlap in time, they cannot exchange ATIM requestsiCoordination requires that each host stay awake long enough (at least periodically) to discover out-of-sync neighbors [Tseng02infocom]ATIMATIM293 Impact on Upper LayersgIf each node uses the 802.11 power-save mechanism, each hop will require one beacon intervaliThis delay could be intolerablegAllow upper layers to dictate whether a node should enter the power save mode or not [Chen01mobicom]294 Power Save Using Wake-Up Channels295 MotivationgSleep mode power consumption << Idle power consumptionPower Characteristics for a Mica2 Mote Sensor296 Design AlternativesgSynchronous: Once a host enters sleep mode, it wakes up at a pre-determined time•Timer-basedgAsynchronous: A sleeping host can be woken up at any time by a neighborgHybrid: Synchronous + Asynchronous297 Using Wake-up Radio [Miller04WCNC]gAdd second, low-power radio to wakeup neighbors on-demandgLow-power wake-up can be achieved usingiSimpler hardware with a lower bit-rate and/or less decoding capability, oriA periodic duty cycle (e.g., as in STEM [UCLA]) using a “normal” radio–Latter approach used in the illustration here298 Actions of a Sleeping HostgPeriodically listen to a wake-up channel•Duty cycle affects energy consumptiongIf wake-up channel sensed busy:iTurn on data radioiReceive a “filter” packet on data radioiIf filter intended for another host, go back to sleep299 Actions of a Sender HostgTransmit a wake-up signal “long enough” if the intended receiver is expected to be sleepinggTransmit a filter packet specifying intended receivergTransmit data to the receiver300 Purely Asynchronous MechanismgIn a purely asynchronous approach, each packet burse is preceded by a “wake-up” signalgMight wake-up too many hosts near the transmitter – referred as “full” wakeup Energy cost301 Add a Synchronous ComponentgEach sleeping host will wake-up after a pre-defined interval of time (“timeout”)iReferred as “triggered” wakeupgIf a transmitter cannot wait until then, it may send a wake-up signaliSend wake-up signal if queue size exceeds threshold L or a delay boundgTimeout is computed based on recent traffic rate302 Timeout for Triggered WakeupsgIf too small, host may wake-up when there are no packets pending for itgIf too large, too many “full” wakeups303 Power Save Protocol [Miller04WCNC]304 Energy ConservationgPower savegPower control305 Power ControlPower control has two potential benefitgReduced interference & increased spatial reusegEnergy saving306 Power ControlgWhen C transmits to D at a high power level, B cannot receive A’s transmission due to interference from CBCDA307 Power ControlgIf C reduces transmit power, it can still communicate with D•Reduces energy consumption at node C•Allows B to receive A’s transmission (spatial reuse)BCDA308 Power ControlgReceived power level is proportional to 1/d , >= 2gIf power control is utilized, energy required to transmit to a host at distance d is proportional to d + constantgShorter hops typically preferred for energy consumption (depending on the constant) [Rodoplu99]iTransmit to C from A via B, instead of directly from A to CABC309 Power Control with 802.11gTransmit RTS/CTS/DATA/ACK at least power level needed to communicate with the receivedgA/B do not receive RTS/CTS from C/D. Also do not sense D’s data transmissiongB’s transmission to A at high power interferes with reception of ACK at CBCDA310 A Plausible SolutiongRTS/CTS at highest power, and DATA/ACK at smallest necessary power levelgA cannot sense C’s data transmission, and may transmit DATA to some other hostgThis DATA will interfere at CgThis situation unlikely if DATA transmitted at highest power leveliInterference range ~ sensing rangeBCDARTSDataInterference rangeAckData sensed311 gTransmitting RTS at the highest power level also reduces spatial reusegNodes receiving RTS/CTS have to defer transmissions312 CaveatgEnergy saving by power control is limited to savings in transmit energygOther energy costs may not change, and may represent a significant fraction of total energy consumption313 Power Controlled Multiple Access (PCMA) [Monks01infocom]gIf receiver node R can tolerate interference E, it sends a busy tone at power level C/E, where C is an appropriate constantgWhen some node X receives a busy-tone a power level Pr, it may transmit at power level Pt <= C/PrRSdataXbusy toneC/EYPt314 Power Controlled Multiple Access (PCMA) [Monks01infocom]gIf receiver node R can tolerate noise E, it sends a busy tone at power level C/E, where C is an appropriate constantgWhen some node X receives a busy-tone a power level Pr, it may transmit at power level Pt <= C/PrgExplanation:iGain of channel RX = gain of channel XR = giBusy tone signal level at X = Pr = g * C / EiNode X may transmit at level = Pt = C/Pr = E/giInterference received by R = Pt * g = E315 PCMAgAdvantageiAllows higher spatial reuse, as well as power saving using power controlgDisadvantages:iNeed a separate channel for the busy toneiSince multiple nodes may transmit the busy tones simultaneously, spatial reuse is less than optimal316 Small Addresses Save Energy [Schurgers01mobihoc]gIn sensor networks, packet sizes are small, and MAC addresses may be a substantial fraction of the packetgObservation: MAC addresses need only be unique within two hopsgFewer addresses are sufficient: Address size can be smaller. [Schurgers00mobihoc] uses Huffman coding to assign variable size encoding to the addressesgEnergy consumption reduced due to smaller addressesC0D3A2E1F2B1G0317 Adaptive Modulation318 Adaptive ModulationgChannel conditions are time-varyinggReceived signal-to-noise ratio changes with timeAB319 Adaptive ModulationgMulti-rate radios are capable of transmitting at several rates, using different modulation schemesgChoose modulation scheme as a function of channel conditionsDistanceThroughputModulation schemes providea trade-off betweenthroughput and range320 Adaptive ModulationgIf physical layer chooses the modulation scheme transparent to MACiMAC cannot know the time duration required for the transfergMust involve MAC protocol in deciding the modulation schemeiSome implementations use a sender-based scheme for this purpose [Kamerman97]iReceiver-based schemes can perform better321 Sender-Based “Autorate Fallback” [Kamerman97]gProbing mechanismsgSender decreases bit rate after X consecutive transmission attempts failgSender increases bit rate after Y consecutive transmission attempt succeed322 Autorate FallbackgAdvantageiCan be implemented at the sender, without making any changes to the 802.11 standard specificationgDisadvantageiProbing mechanism does not accurately detect channel stateiChannel state detected more accurately at the receiveriPerformance can suffer•Since the sender will periodically try to send at a rate higher than optimal•Also, when channel conditions improve, the rate is not increased immediately323 Receiver-Based Autorate MAC [Holland01mobicom]gSender sends RTS containing its best rate estimategReceiver chooses best rate for the conditions and sends it in the CTSgSender transmits DATA packet at new rategInformation in data packet header implicitly updates nodes that heard old rate324 Receiver-Based Autorate MAC ProtocolDCBACTS (1 Mbps)RTS (2 Mbps)Data (1 Mbps)NAV updated using ratespecified in the data packet325 Multiple Channels326 Multiple ChannelsgMultiple channels in ad hoc networks: typically defined FDMAgTDMA requires time synchronization among hosts in ad hoc networkiDifficultgMany MAC protocols have been proposed327 Multi-Channel MAC: A simple approachgDivide bandwidth into multiple channelsgChoose any one of the idle channelsgUse a single-channel protocol on the chosen channelifor instance, 802.11328 Multi-Channel MAC with Soft Reservation [Nasipuri00]gSimilar to the simple scheme, channel used recently for a successful transmission preferredgTends to “reserve” channels 329 Another ProtocolgUse one (control) channel for RTS/CTS and remaining (data) channels for DATA/ACKgEach host maintains NAV table, with one entry for each data channelgSender sends RTS to destination, specifying the channels that are free per sender’s tablegReceiver replies with CTS specifying a channel that it also thinks is freeiA channel is used only if both sender and receiver conclude that it is free330 Impact of Directional Antennason MAC and Routing331 Impact of Antennas on MACgWireless hosts traditionally use single-mode antennasgTypically, thesingle-mode = omni-directionalgRecently, antennas with multiple modes (often, but not necessarily, directional) have been developgWe will now focus on directional antennas with multiple modes332 IEEE 802.11gImplicitly assumes single mode antennasgTypically, omnidirectional antennas (though not necessarily)333 CFABEDRTSIEEE 802.11Reserved areaCTS334 CDXYOmni-Directional AntennasRed nodesCannotCommunicatepresently335 Directional AntennasCDXYNot possible using Omni336 QuestiongHow to exploit directional antennas in ad hoc networks ?iMedium access controliRouting337 Antenna ModelIn Omni Mode:gNodes receive signals with gain GogWhile idle a node stays in omni modeIn Directional Mode:gCapable of beamforming in specified directiongDirectional Gain Gd (Gd > Go)gDirectional mode has sidelobesSymmetry: Transmit gain = Receive gain338 Directional CommunicationReceived Power (Transmit power) *(Tx Gain) * (Rx Gain)Directional gain is higher339 Potential Benefits ofDirectional AntennasgIncrease “range”, keeping transmit power constantgReduce transmit power, keeping range comparable with omni modeiSeveral proposal focus on this benefitiAssume that range of omni-directional and directional transmission is equalDirectional transmissions at lower power340 CaveatsgOnly most important features of the protocols discussed heregAntenna characteristics assumed are often different in different papers341 Simple Tone Sense (STS) Protocol[Yum1992IEEE Trans. Comm.]342 STS ProtocolBased on busy tone signaling:gEach host is assigned a tone (sinusoidal wave at a certain frequency)gTone frequency unique in each host’s neighborhoodgWhen a host detects a packet destined to itself, it transmit a tonegIf a host receive a tone on directional antenna A,it assumes that some host in that direction is receiving a packetiCannot transmit using antenna A presentlyiOK to transmit using other antennas343 STS ProtocolgTone duration used to encode informationiDuration t1 implies transmitting node is busyiDuration t2 implies the transmitting node successfully received a transmission from another node344 ExampleSRBCADATATone t1Node A cannotInitiate atransmission.But B can sendto CBecause B doesnot receive t1345 STS ProtocolIssues:gAssigning tones to hostsgAssigning hosts to antennas: It is assumed that the directions/angles can be chosenidistribute neighbor hosts evenly among the antennasichoose antenna angles such that adjacent antennas have some minimum separation346 Busy Tone Directional MAC[Huang2002MILCOM]gExtends the busy tone (DBTMA) protocol originally proposed by omni-directional antennas [Deng98ICUPC]gThree channelsiData channeliTwo Busy Tone channels•Receive tone (BTr)•Transmit tone (BTt)347 DBTMAgSender:iSense BTr. If sensed busy, defer transmission.iIf BTr idle, transmit RTS to receivergReceiveriOn receiving RTS, sense BTt.iIf BTt idle, reply with a CTS, and transmit BTr until DATA is completely receivedgSenderiOn receiving CTS, transmit DATA and BTt both348 DBTMA + Directional AntennasgDBTMA reduces reduction in throughput caused by collisions by hidden terminalsgDirectional antennas can be used to transmit the busy tones directionallyiRTS/CTS, DATA, busy tones all may be sent directionallyiTrade-offs similar to directional versus omni-directional transmission of RTS/CTS349 Another Directional MAC protocol[Roychoudhury02mobicom]gDerived from IEEE 802.11 (similar to [Takai02mobihoc])gA node listens omni-directionally when idlegSender transmits Directional-RTS (DRTS) towards receivergRTS received in Omni mode (idle receiver in when idle)gReceiver sends Directional-CTS (DCTS)gDATA, ACK transmitted and received directionally350 CFABEDRTSRTS = Request-to-SendDirectional MACPretending a circular range for omniX351 CFABEDCTSCTS = Clear-to-SendDirectional MACX352 CFABEDDATA•DATA packet follows CTS. Successful data reception acknowledged using ACK. Directional MACX353 CFABEDACKDirectional MACX354 gNodes overhearing RTS or CTS set up directional NAV (DNAV) for that Direction of Arrival (DoA)XDYCCTSDirectional NAV (DNAV) [Roychoudhury02mobicom]Similar DNAV mechanism proposed in [Takai02mobihoc]355 gNodes overhearing RTS or CTS set up directional NAV (DNAV) for that Direction of Arrival (DoA)XYDirectional NAV (DNAV)DCDNAV356 Directional NAV (DNAV)ABCθDNAVDgNew transmission initiated only if direction of transmission does not overlap with DNAV, i.e., if (θ > 0)RTS357 DMAC ExampleB C A D EB and C communicateD and E cannot: D blocked with DNAV from CD and A communicate358 Issues with DMACgTwo types of Hidden Terminal ProblemsiDue to asymmetry in gain C ABDataRTSA’s RTS may interfere with C’s reception of DATAA is unaware of communication between B and C359 Issues with DMACNode A may now interfere at node C by transmitting in C’s direction CB D AgTwo types of Hidden Terminal ProblemsiDue to unheard RTS/CTS360 Issues with DMACRTSRTSRTSX does not know node A is busy. X keeps transmitting RTSs to node AABUsing omni antennas, X would be aware that A is busy, and defer its own transmissionXZY• DeafnessDATA361 Issues with DMACgUses DO links, but not DD links362 DMAC TradeoffsgBenefitsiBetter Network Connectivity iSpatial Reuse•Disadvantages–Hidden terminals–Deafness–No DD Links363 Using Training Sequences[Bellofiore2002IEEETrans.Ant.Prop]gTraining packets used for DoA determination, after RTS/CTS exchange omni-directionallyRTSCTSRXTRNTXTRNDATAACKSenderReceiver364 gPerformance depends on the TXTRN and RXTRN delaysgIf direction is known a priori, then these delays can potentially be avoidediBut mobility can change direction over time365 Another Variation[Nasipuri2000WCNC]gSimilar to 802.11, but adapted for directional antennasgAssumptions:iAntenna model: Several directional antennas which can all be used simultaneouslyiOmni-directional reception is possible (by using all directional antennas together)iDirection of arrival (DoA) can be determined when receiving omni-directionallyiRange of directional and omni transmissions are identical366 Protocol DescriptiongSender sends omni-directional RTSgReceiver sends omni-directional CTSiReceiver also records direction of sender by determining the antenna on which the RTS signal was received with highest power leveliSimilarly, the sender, on receiving CTS, records the direction of the receivergAll nodes overhearing RTS/CTS defer transmissionsgSender then sends DATA directionally to the receivergReceiver sends directional ACK367 DiscussiongProtocol takes advantage of reduction in interference due to directional transmission/reception of DATAgAll neighbors of sender/receiver defer transmission on receiving omni-directional RTS/CTS spatial reuse benefit not realized368 Enhancing DMACgAre improvements possible to make DMAC more effective ?gPossible improvements:iMake Use of DD Links [Roychoudhury02MobiCom]iOvercome deafness [Roychoudhury03techrep]369 Directional MAC: SummarygDirectional antennas need adaptation of the MAC protocolsgMAC protocols show improvement in aggregate throughput and delayiBut not alwaysgPerformance dependent on topology370 Routing with Directional Antennas371 Routing ProtocolsgMany routing protocols for ad hoc networks rely on broadcast messagesiFor instance, flood of route requests (RREQ)gUsing omni antennas for broadcast will not discover all possible linksgNeed to implement broadcast using directional transmissions372 Dynamic Source Routing [Johnson]gSender floods RREQ through the networkgNodes forward RREQs after appending their namesgDestination node receives RREQ and unicasts a RREP back to sender node, using the route in which RREQ traveled373 Route Discovery in DSRBASEFHJDCGIKZYRepresents a node that has received RREQ for D from SMNL374 Route Discovery in DSRBASEFHJDCGIKRepresents transmission of RREQZYBroadcast transmissionMNL[S][X,Y] Represents list of identifiers appended to RREQ375 Route Discovery in DSRBASEFHJDCGIKZYMNL[S,E][S,C]376 Route Discovery in DSRBASEFHJDCGIK• Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ onceZYMNL[S,C,G][S,E,F]377 Route Discovery in DSRBASEFHJDCGIKZYM• Nodes J and K both broadcast RREQ to node DNL[S,C,G,K][S,E,F,J]378 Route Reply in DSRBASEFHJDCGIKZYMNLRREP [S,E,F,J,D]Represents RREP control message379 DSR over Directional Antennas [Roychoudhury03PWC, Roychoudhury02UIUCTechrep]gRREQ broadcast by sweepingiTo use DD links380 Route Discovery in DSRBASEFHJDCGIKZYM• Nodes J and K both broadcast RREQ to node DNL[S,C,G,K][S,E,F,J]381 Larger Tx Range Fewer Hop RoutesFew Hop Routes Low Data Latency Small Beamwidth High Sweep DelayMore Sweeping High OverheadDirectional Routing TradeoffsBroadcast by sweeping382 IssuesgSub-optimal routes may be chosen if destination node misses shortest request, while beamformedgBroadcast storm: Using broadcasts, nodes receive multiple copies of same packet FJNJDKD misses request from KOptimize by having destination wait before replyingRREPRREQUse K antenna elements to forward broadcast packet383 Route Discovery in DSRFJD receives RREQ from J, and replies with RREPD misses RREQ from KNJRREPRREQDK384 Delayed RREP OptimizationgDue to sweeping – earliest RREQ need not have traversed shortest hop path.iRREQ packets sent to different neighbors at different points of timegIf destination replies to first arriving RREP, it might miss shorter-path RREQgOptimize by having DSR destination wait before replying with RREP385 Routing OverheadgUsing omni broadcast, nodes receive multiple copies of same packet - Redundant !!! •Broadcast Storm ProblemgUsing directional Antennas – can do better ?386 Use K antenna elements to forward broadcast packetRouting OverheadFootprint of Tx (number of control packets) (footprint of transmissions) No. Data Packets New measure for control Overhead =387 MobilitygLink lifetime increases using directional antennas.iHigher transmission range - link failures are less frequentgNodes moving out of beam coverage in order of packet-transmission-timeiLow probability388 gAntenna handoffiIf no response to RTS, MAC layer uses N adjacent antenna elements to transmit same packetiRoute error avoided if communication re-established [RoyChoudhury02UIUC Techrep]Mobility389 Other Approaches to Routingwith Directional Antennas[Nasipuri2000ICCCN]gModified version of DSRgTransmit Route Request in the last known direction of the receivergIf the source S perceives receiver R to have been in direction d, then all nodes forward the route request from S in direction d.390 Example 1BASEFHJDCGIKZYMNL391 Example 1BASEFHJDCGIKZYMNLRoute Reply392 Example 2BASEFHJDCGIKZYMNLD doesnot receiveRREQ393 Limited ForwardinggBenefit: Limits the forwarding of the Route RequestgDisadvantage: Effectively assumes that each node has a sense of orientation394 Routing with Directional Antennas: ConclusiongDirectional antennas can improve routing performancegBut suitable protocol adaptations necessary395 Directional Antennas: ConclusiongDirectional antennas can potentially benefitgBut also create difficulties in MAC and routing protocol design396 UDP onMobile Ad Hoc Networks397 User Datagram Protocol (UDP)gUDP provides unreliable deliverygStudies comparing different routing protocols for MANET typically measure UDP performancegSeveral performance metrics are often usediRouting overhead per data packetiPacket loss rateiPacket delivery delay398 UDP PerformancegSeveral relevant studies [Broch98Mobicom,Das9ic3n,Johansson99Mobicom,Das00Infocom,Jacquet00Inria]gResults comparing a specific pair of protocols do not always agree, but some general (and intuitive) conclusions can be drawniReactive protocols may yield lower routing overhead than proactive protocols when communication density is lowiReactive protocols tend to loose more packets (assuming than network layer drops packets if a route is not known)iProactive protocols perform better with high mobility and dense communication graph399 UDP PerformancegMany variables affect performance iTraffic characteristics•one-to-many, many-to-one, many-to-many•small bursts, large file transfers, real-time, non-real-timeiMobility characteristics•low/high rate of movement•do nodes tend to move in groupsiNode capabilities•transmission range (fixed, changeable)•battery constraintsiPerformance metrics•delay•throughput•latency•routing overheadiStatic or dynamic system characteristics (listed above)400 UDP PerformancegDifficult to identify a single scheme that will perform well in all environmentsgHoly grail: Routing protocol that dynamically adapts to all environments so as to optimize “performance”iPerformance metrics may differ in different environments401 TCP onMobile Ad Hoc Networks402 Overview ofTransmission Control Protocol / Internet Protocol(TCP/IP)403 Internet Protocol (IP)gPackets may be delivered out-of-ordergPackets may be lostgPackets may be duplicated 404 Transmission Control Protocol (TCP)gReliable ordered deliverygImplements congestion avoidance and controlgReliability achieved by means of retransmissions if necessarygEnd-to-end semanticsiAcknowledgements sent to TCP sender confirm delivery of data received by TCP receiveriAck for data sent only after data has reached receiver405 TCP BasicsgCumulative acknowledgementsgAn acknowledgement ack’s all contiguously received datagTCP assigns byte sequence numbersgFor simplicity, we will assign packet sequence numbersgAlso, we use slightly different syntax for acks than normal TCP syntaxiIn our notation, ack i acknowledges receipt of packets through packet i406 403937383533Cumulative AcknowledgementsgA new cumulative acknowledgement is generated only on receipt of a new in-sequence packet41403839353736343634idataacki407 Duplicate AcknowledgementsgA dupack is generated whenever an out-of-order segment arrives at the receiver403937383634424139403636Dupack(Above example assumes delayed acks)On receipt of 38408 Window Based Flow ControlgSliding window protocolgWindow size minimum ofireceiver’s advertised window - determined by available buffer space at the receivericongestion window - determined by the sender, based on feedback from the network23456789 10 1113112Sender’s windowAcks receivedNot transmitted409 Window Based Flow Control23456789 10 1113112Sender’s window23456789 10 1113112Sender’s windowAck 5410 Window Based Flow ControlgCongestion window size bounds the amount of data that can be sent per round-trip timegThroughput <= W / RTT411 Ideal Window SizegIdeal size = delay * bandwidthidelay-bandwidth product gWhat if window size < delay*bw ?iInefficiency (wasted bandwidth)gWhat if > delay*bw ?iQueuing at intermediate routers•increased RTT due to queuing delaysiPotentially, packet loss412 How does TCP detect a packet loss?gRetransmission timeout (RTO)gDuplicate acknowledgements413 Detecting Packet Loss Using Retransmission Timeout (RTO)gAt any time, TCP sender sets retransmission timer for only one packetgIf acknowledgement for the timed packet is not received before timer goes off, the packet is assumed to be lostgRTO dynamically calculated414 Retransmission Timeout (RTO) calculationgRTO = mean + 4 mean deviationiStandard deviation s : s = average of (sample – mean)iMean deviation d = average of |sample – mean|iMean deviation easier to calculate than standard deviationiMean deviation is more conservative: d >= s 22415 Exponential BackoffgDouble RTO on each timeoutPackettransmittedTime-out occursbefore ack received,packet retransmittedTimeout interval doubledT1T2 = 2 * T1416 Fast RetransmissiongTimeouts can take too longihow to initiate retransmission sooner?gFast retransmit417 Detecting Packet Loss Using Dupacks:Fast Retransmit Mechanism gDupacks may be generated due toipacket loss, oriout-of-order packet deliverygTCP sender assumes that a packet loss has occurred if it receives three dupacks consecutively12 1178910Receipt of packets 9, 10 and 11 will each generatea dupack from the receiver. The sender, on gettingthese dupacks, will retransmit packet 8.418 Congestion Avoidance and ControlgSlow Start: cwnd grows exponentially with time during slow startgWhen cwnd reaches slow-start threshold, congestion avoidance is performedgCongestion avoidance: cwnd increases linearly with time during congestion avoidanceiRate of increase could be lower if sender does not always have data to send419 Slow startCongestionavoidanceSlow start thresholdExample assumes that acks are not delayed420 Congestion ControlgOn detecting a packet loss, TCP sender assumes that network congestion has occurredgOn detecting packet loss, TCP sender drastically reduces the congestion windowgReducing congestion window reduces amount of data that can be sent per RTT421 Congestion Control -- TimeoutgOn a timeout, the congestion window is reduced to the initial value of 1 MSSgThe slow start threshold is set to half the window size before packet lossimore precisely, ssthresh = maximum of min(cwnd,receiver’s advertised window)/2 and 2 MSSgSlow start is initiated422 ssthresh = 8ssthresh = 10cwnd = 20After timeout423 Congestion Control - Fast retransmitgFast retransmit occurs when multiple (>= 3) dupacks come backgFast recovery follows fast retransmitgDifferent from timeout : slow start follows timeoutitimeout occurs when no more packets are getting acrossifast retransmit occurs when a packet is lost, but latter packets get throughiack clock is still there when fast retransmit occursino need to slow start424 Fast Recoverygssthresh = min(cwnd, receiver’s advertised window)/2 (at least 2 MSS)gretransmit the missing segment (fast retransmit)gcwnd = ssthresh + number of dupacksgwhen a new ack comes: cwnd = ssthrehienter congestion avoidanceCongestion window cut into half425 After fast retransmit and fast recovery window size isreduced in half.Receiver’s advertised windowAfter fast recovery426 TCP RenogSlow-startgCongestion avoidancegFast retransmitgFast recovery427 TCP PerformanceinMobile Ad Hoc Networks428 Performance of TCPSeveral factors affect TCP performance in MANET:gWireless transmission errorsgMulti-hop routes on shared wireless mediumiFor instance, adjacent hops typically cannot transmit simultaneouslygRoute failures due to mobility429 Random ErrorsgIf number of errors is small, they may be corrected by an error correcting codegExcessive bit errors result in a packet being discarded, possibly before it reaches the transport layer430 Random Errors May Cause Fast Retransmit403937383634Example assumes delayed ack - every other packet ack’d431 Random Errors May Cause Fast Retransmit414038393634Example assumes delayed ack - every other packet ack’d432 Random Errors May Cause Fast Retransmit4241394036Duplicate acks are not delayed36dupack433 Random Errors May Cause Fast Retransmit40363636Duplicate acks414342434 Random Errors May Cause Fast Retransmit4136363 duplicate acks triggerfast retransmit at sender42444336435 Random Errors May Cause Fast RetransmitgFast retransmit results iniretransmission of lost packetireduction in congestion windowgReducing congestion window in response to errors is unnecessarygReduction in congestion window reduces the throughput436 Sometimes Congestion Response May be Appropriate in Response to ErrorsgOn a CDMA channel, errors occur due to interference from other user, and due to noise [Karn99pilc]iInterference due to other users is an indication of congestion. If such interference causes transmission errors, it is appropriate to reduce congestion windowiIf noise causes errors, it is not appropriate to reduce windowgWhen a channel is in a bad state for a long duration, it might be better to let TCP backoff, so that it does not unnecessarily attempt retransmissions while the channel remains in the bad state [Padmanabhan99pilc]437 Impact of Random Errors [Vaidya99]Exponential error model2 Mbps wireless full duplex linkNo congestion losses438 Burst Errors May Cause TimeoutsgIf wireless link remains unavailable for extended duration, a window worth of data may be lostidriving through a tunnelipassing a truckgTimeout results in slow start gSlow start reduces congestion window to 1 MSS,reducing throughputgReduction in window in response to errors unnecessary439 Random Errors May Also Cause TimeoutgMultiple packet losses in a window can result in timeout when using TCP-Reno (and to a lesser extent when using SACK)440 Impact of Transmission ErrorsgTCP cannot distinguish between packet losses due to congestion and transmission errorsgUnnecessarily reduces congestion windowgThroughput suffers441 This TutorialgThis tutorial does not consider techniques to improve TCP performance in presence of transmission errorsgPlease refer to the Tutorial on TCP for Wireless and Mobile Hosts presented by Vaidya at MobiCom 1999, SeattleiThe tutorial slides are presently available from http://www.cs.tamu.edu/faculty/vaidya/ (follow the link to Seminars)g[Montenegro00-RFC2757] discusses related issues442 This TutorialgThis tutorial considers impact of multi-hop routes and route failures due to mobility443 Mobile Ad Hoc NetworksgMay need to traverse multiple links to reach a destination444 Mobile Ad Hoc NetworksgMobility causes route changes445 Throughput over Multi-Hop Wireless Paths [Gerla99]gConnections over multiple hops are at a disadvantage compared to shorter connections, because they have to contend for wireless access at each hop446 Impact of Multi-Hop Wireless Paths [Holland99]TCP Throughput using 2 Mbps 802.11 MAC447 Throughput Degradations withIncreasing Number of HopsgPacket transmission can occur on at most one hop among three consecutive hopsiIncreasing the number of hops from 1 to 2, 3 results in increased delay, and decreased throughputgIncreasing number of hops beyond 3 allows simultaneous transmissions on more than one link, however, degradation continues due to contention between TCP Data and Acks traveling in opposite directionsgWhen number of hops is large enough, the throughput stabilizes due to effective pipelining 448 Ideal Throughputgf(i) = fraction of time for which shortest path length between sender and destination is IgT(i) = Throughput when path length is IiFrom previous figuregIdeal throughput = S f(i) * T(i) 449 Impact of MobilityTCP ThroughputIdeal throughput (Kbps)Actual throughput2 m/s10 m/s450 Impact of MobilityIdeal throughputActual throughput20 m/s 30 m/s451 Throughput generally degrades with increasing speed …Speed (m/s)AverageThroughputOver 50 runsIdealActual452 But not always …Mobility pattern #Actualthroughput20 m/s30 m/s453 mobility causeslink breakage,resulting in routefailureTCP data and acksen route discardedWhy Does Throughput Degrade?TCP sender times out.Starts sending packets againRoute isrepairedNo throughputNo throughputdespite route repair454 mobility causeslink breakage,resulting in routefailureTCP data and acksen route discardedWhy Does Throughput Degrade?TCP sendertimes out.Backs off timer.Route isrepairedTCP sendertimes out.ResumessendingLarger route repair delaysespecially harmfulNo throughputNo throughputdespite route repair455 Why Does Throughput Improve?Low Speed ScenarioCBDACBDACBDA1.5 second route failureRoute from A to D is broken for ~1.5 second.When TCP sender times after 1 second, route still broken.TCP times out after another 2 seconds, and only then resumes.456 Why Does Throughput Improve?Higher (double) Speed ScenarioCBDACBDACBDA0.75 second route failureRoute from A to D is broken for ~ 0.75 second.When TCP sender times after 1 second, route is repaired.457 Why Does Throughput Improve?General PrinciplegThe previous two slides show a plausible cause for improved throughputgTCP timeout interval somewhat (not entirely) independent of speedgNetwork state at higher speed, when timeout occurs, may be more favorable than at lower speedgNetwork stateiLink/route statusiRoute cachesiCongestion458 How to Improve Throughput(Bring Closer to Ideal)gNetwork feedbackgInform TCP of route failure by explicit messagegLet TCP know when route is repairediProbingiExplicit notificationgReduces repeated TCP timeouts and backoff459 Performance ImprovementWithout networkfeedbackIdeal throughput 2 m/s speedWith feedbackActual throughput460 Performance ImprovementWithout networkfeedbackWith feedbackIdeal throughput 30 m/s speedActual throughput461 Performance with Explicit Notification[Holland99]462 IssuesNetwork FeedbackgNetwork knows best (why packets are lost)+ Network feedback beneficial-Need to modify transport & network layer to receive/send feedbackgNeed mechanisms for information exchange between layersg[Holland99] discusses alternatives for providing feedback (when routes break and repair)i[Chandran98] also presents a feedback scheme463 Impact of CachinggRoute caching has been suggested as a mechanism to reduce route discovery overhead [Broch98]gEach node may cache one or more routes to a given destinationgWhen a route from S to D is detected as broken, node S may:iUse another cached route from local cache, oriObtain a new route using cached route at another node464 To Cache or Not to CacheAverage speed (m/s)Actual throughput (as fraction of expected throughput)465 Why Performance Degrades With CachinggWhen a route is broken, route discovery returns a cached route from local cache or from a nearby nodegAfter a time-out, TCP sender transmits a packet on the new route.However, the cached route has also broken after it was cachedgAnother route discovery, and TCP time-out intervalgProcess repeats until a good route is foundtimeout dueto route failuretimeout, cachedroute is brokentimeout, second cachedroute also broken466 IssuesTo Cache or Not to CachegCaching can result in faster route “repair”gFaster does not necessarily mean correctgIf incorrect repairs occur often enough, caching performs poorlygNeed mechanisms for determining when cached routes are stale467 Caching and TCP performancegCaching can reduce overhead of route discovery even if cache accuracy is not very highgBut if cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple time-outs468 TCP PerformanceTwo factors result in degraded throughput in presence of mobility:gLoss of throughput that occurs while waiting for TCP sender to timeout (as seen earlier)iThis factor can be mitigated by using explicit notifications and better route caching mechanismsgPoor choice of congestion window and RTO values after a new route has been foundiHow to choose cwnd and RTO after a route change?469 Issues Window Size After Route RepairgSame as before route break: may be too optimisticgSame as startup: may be too conservativegBetter be conservative than overly optimisticiReset window to small value after route repairiLet TCP figure out the suitable window sizeiImpact low on paths with small delay-bw product470 IssuesRTO After Route RepairgSame as before route breakiIf new route long, this RTO may be too small, leading to timeoutsgSame as TCP start-up (6 second)iMay be too largeiMay result in slow response to next packet lossgAnother plausible approach: new RTO = function of old RTO, old route length, and new route lengthiExample: new RTO = old RTO * new route length / old route lengthiNot evaluated yetiPitfall: RTT is not just a function of route length471 Out-of-Order Packet DeliverygOut-of-order (OOO) delivery may occur due to:iRoute changesiLink layer retransmissions schemes that deliver OOOgSignificantly OOO delivery confuses TCP, triggering fast retransmitgPotential solutions:iDeterministically prefer one route over others, even if multiple routes are knowniReduce OOO delivery by re-ordering received packets•can result in unnecessary delay in presence of packet lossiTurn off fast retransmit•can result in poor performance in presence of congestion472 Impact of AcknowledgementsgTCP Acks (and link layer acks) share the wireless bandwidth with TCP data packetsgData and Acks travel in opposite directionsiIn addition to bandwidth usage, acks require additional receive-send turnarounds, which also incur time penaltyiTo reduce frequency of send-receive turnaround and contention between acks and data473 Impact of Acks: Mitigation [Balakrishnan97]gPiggybacking link layer acks with datagSending fewer TCP acks - ack every d-th packet (d may be chosen dynamically)•but need to use rate control at sender to reduce burstiness (for large d)gAck filtering - Gateway may drop an older ack in the queue, if a new ack arrivesireduces number of acks that need to be delivered to the sender474 Security Issues475 CaveatgMuch of security-related stuff is mostly beyond my expertisegSo coverage of this topic is very limited476 Security Issues in Mobile Ad Hoc NetworksgNot much work in this area as yetgMany of the security issues are same as those in traditional wired networks and cellular wirelessgWhat’s new ?477 What’s New ?gWireless medium is easy to snoop ongDue to ad hoc connectivity and mobility, it is hard to guarantee access to any particular node (for instance, to obtain a secret key)gEasier for trouble-makers to insert themselves into a mobile ad hoc network (as compared to a wired network)478 Resurrecting Duckling [Stajano99]gBattery exhaustion threat: A malicious node may interact with a mobile node often with the goal of draining the mobile node’s batterygAuthenticity: Who can a node talk to safely?iResurrecting duckling: Analogy based on a duckling and its mother. Apparently, a duckling assumes that the first object it hears is the motheriA mobile device will trust first device which sends a secret key479 Secure Routing [Zhou99]gAttackers may inject erroneous routing informationgBy doing so, an attacker may be able to divert network traffic, or make routing inefficientg[Zhou] suggests use of digital signatures to protect routing information and data bothgSuch schemes need a Certification Authority to manage the private-public keys480 Secure RoutinggEstablishing a Certification Authority (CA) difficult in a mobile ad hoc network, since the authority may not be reachable from all nodes at all timesg[Zhou] suggests distributing the CA function over multiple nodes481 MANET Authentication Architecture[Jacobs99ietf-id]gDigital signatures to authenticate a messagegKey distribution via certificatesgNeed access to a certification authorityg[Jacobs99ietf-id] specifies message formats to be used to carry signature, etc.482 Techniques for Intrusion-Resistant Ad Hoc Routing Algorithms (TIARA) [Ramanujan00Milcom]gFlow disruption attack: Intruder (or compromised) node T may delay/drop/corrupt all data passing through, but leave all routing traffic unmodifiedACBDTintruder483 Techniques for Intrusion-Resistant Ad Hoc Routing Algorithms (TIARA) [Ramanujan00Milcom]gResource Depletion Attack: Intruders may send data with the objective of congesting a network or depleting batteriesACBDTintruderUintruderBogus traffic484 Intrusion Detection [Zhang00Mobicom]gDetection of abnormal routing table updatesiUses “training” data to determine characteristics of normal routing table updates (such as rate of change of routing info)iEfficacy of this approach is not evaluated, and is debatablegSimilar abnormal behavior may be detected at other protocol layersiFor instance, at the MAC layer, normal behavior may be characterized for access patterns by various hostsiAbnormal behavior may indicate intrusiongSolutions proposed in [Zhang00Mobicom] are preliminary, not enough detail provided485 Preventing Traffic Analysis [Jiang00iaas,Jiang00tech]gEven with encryption, an eavesdropper may be able to identify the traffic pattern in the networkgTraffic patterns can give away information about the mode of operationiAttack versus retreatgTraffic analysis can be prevented by presenting “constant” traffic pattern independent of the underlying operational modeiMay need insertion of dummy traffic to achieve this486 Packet Purse Model [Byttayn00MobiHoc]gCost-based approach for motivating collaboration between mobile nodesgThe packet purse model assigns a cost to each packet transferiLink-level recipient of a packet pays the link-level sender for the serviceiVirtual money (“beans”) used for this purposegSecurity issues:iHow to ensure that some node does not sale the same packet to too many people to make money ?iHow to ensure that each receiver indeed has money to pay for service?487 MAC Layer Misbehavior488 Selfish Misbehavior to Improve PerformanceWireless channelAccess PointABMisbehaving nodes may violate MAC rules nNodes are required to follow Medium Access Control (MAC) rules489 Backoff ExamplegChoose backoff value B in range [0,CW] iCW is the Contention WindowgCount down backoff by 1 every idle slotwaitTransmitTransmitwaitB2=10B1=20B2=10B1=0 S1S2CW=31B1=15B2=25490 Data Transmission gReserve channel with RTS/CTS exchangeSender SReceiver RB=10DATAACKSBARRTSRTSCTSCTS491 Possible MisbehaviorgBackoff from biased distributioniExample: Always select a small backoff valueTransmitwaitB1 = 1B2 = 20TransmitwaitB2 = 19B1 = 1Misbehaving nodeWell-behaved node492 Goals [Kyasanur03dsn]gDiagnose node misbehavioriCatch misbehaving nodesgDiscourage misbehavioriPunish misbehaving nodes493 MAC Selfishness: Game-Theoretic ApproachgMacKenzie addresses selfish misbehavior in Aloha networksiNodes may use higher access probabilitiesgSolution uses game theoretic approachiAssumes there is some cost for transmittingiNodes independently adjust access prob. iUnder some assumptions network reaches a fair equilibrium494 MAC: Selfishnessg[Konorski01, Konorski02] discuss selfish misbehavior in 802.11 networksgGame theory used to analyze solutioniNodes use a black-burst to resolve contentioniWinner is not the largest burst, but node with burst within slots of largest burst495 Game theory - DiscussiongProtocols resilient to misbehavior can be developediDo not need explicit misbehavior detectiongSolutions assume perfect knowledgeiNo guarantees with imperfect informationgPerformance at equilibrium may be poor496 gUse payment schemes, charging per packetgMisbehaving node can achieve lower delay (e.g., by sending packet bursts) Average delay is less with same costAlternative Approach Per-packet payment schemes not sufficient (need to factor delay – harder)497 Another ApproachgReceivers detect sender misbehavioriAssume receivers are well-behaved (can be relaxed)nAccess Point is trusted. When AP transmits, it is well-behaved nWhen AP receives, it can monitor sender behaviorWireless channelAccess PointA498 IssuesgReceiver does not know exact backoff value chosen by senderiSender chooses random backoffiHard to distinguish between maliciously chosen small values and a legitimate random sequencegWireless channel introduces uncertaintiesiChannel status seen by sender and receiver may be different499 Potential Solution:Use long-term statisticsgObserve backoffs chosen by sender over multiple packetsgBackoff values not from expected distribution MisbehaviorSelecting right observation interval difficult500 A Simpler ApproachgRemove the non-determinism501 A Simpler ApproachgReceiver provides backoff values to senderiReceiver specified backoff for next packet in ACK for current packetgModification does not significantly change 802.11 behavioriBackoffs of different nodes still independentUncertainty of sender’s backoff eliminated502 Modifications to 802.11•R provides backoff B to S in ACK B selected from [0,CWmin]DATASender SReceiver RCTSACK(B)RTS•S uses B for backoffRTSB503 Protocol stepsStep 1: For each transmission:iDetect deviations: Decide if sender backed off for less than required number of slotsiPenalize deviations: Penalty is added, if the sender appears to have deviatedGoal: Identify and penalize suspected misbehavioriReacting to individual transmission makes it harder to adapt to the protocol504 Protocol stepsStep 2: Based on last W transmissions:iDiagnose misbehavior: Identify misbehaving nodesGoal: Identify misbehaving nodes with high probabilityiReduce impact of channel uncertaintiesiFilter out misbehaving nodes from well-behaved nodes505 Detecting deviationsgReceiver counts number of idle slots Bobsr Condition for detecting deviations: Bobsr < B (0 < <= 1)Sender SReceiver RACK(B)RTSBackoffBobsr506 Penalizing Misbehavior §When Bobsr < B, penalty P added §P proportional to B– Bobsr ACK(B+P)CTSDATA§ Total backoff assigned = B + PBobsrSender SReceiver RACK(B)RTSActual backoff < B507 Penalty Scheme issuesgMisbehaving sender has two optionsiIgnore assigned penalty Easier to detectiFollow assigned penalty No throughput gaingWith penalty, sender has to misbehave more for same throughput gain508 Diagnosing MisbehaviorgTotal deviation for last W packets usediDeviation per packet is B – BobsrgIf total deviation > THRESH then sender is designated as misbehavinggHigher layers / administrator can be informed of misbehavior509 MANETImplementation Issues510 Existing ImplementationsgSeveral implementations apparently exist (see IETF MANET web site)gOnly a few available publiclygMost implementations focus on unicast routing511 CMU Implementation [Maltz99]Physical devicesKernel spaceKernel spaceWaveLan-ICDPDUser spaceIPTCP/UDPDSR option processing (RREQ, RREP,…)Route cacheDSR Outputdsr_xmitSendbufferrexmitbufferRoute table512 CMU Implementation: Lessons LearnedgMulti-level priority queues helpful: Give higher priority to routing control packets, and lower for datagIf retransmission is implemented above the link layer, it must be adaptive to accommodate congestioniSince Wavelan-I MAC does not provide retransmissions, DSR performs retransmits itselfiDSR per-hop ack needs to contend for wireless mediumiTime to get the ack (RTT) is dependent on congestioniTCP-like RTT estimation and RTO used for triggering retransmits by DSR on each hopiThis is not very relevant when using IEEE 802.11 where the ack is sent immediately after data reception513 CMU Implementation: Lessons Learnedg“Wireless propagation is not what you would expect” [Maltz99]iStraight flat areas with line-of-sight connectivity had worst error ratesg“Bystanders will think you are nuts” [Maltz99]iIf you are planning experimental studies in the streets, it may be useful to let police and security guards know in advance what you are up to514 BBN Implementation [Ramanathan00Wcnc]gDensity and Asymmetric-Adaptive Wireless Network (DAWN)iQuote from [Ramanathan00Wcnc]: DAWN is a “subnet” or “link” level system from IP’s viewpoint and runs “below” IPDAWNProtocolsNokia MACUtilicom 2050 RadioNokia IP StackQos Based Forwarding=DAWN IP GatewayTopologycontrolElasticVirtualCircuitsScalableLink StateRouting515 DAWN FeaturesgTopology control by transmit power controliTo avoid topologies that are too sparse or too denseiTo extend battery lifegScalable link state routing: Link state updates with small TTL (time-to-live) sent more often, than those with greater TTLiAs a packet gets closer to the destination, more accurate info is used for next hop determinationgElastic Virtual Circuits (VC): iLabel switching through the DAWN nodes (label = VC id)iPath repaired transparent to the endpoints when hosts along the path move away516 Implementation Issues:Where to Implement Ad Hoc RoutinggLink layergNetwork layergApplication layer517 Implementation Issues:SecuritygHow can I trust you to forward my packets without tampering?iNeed to be able to detect tamperinggHow do I know you are what you claim to be ?iAuthentication issuesiHard to guarantee access to a certification authority518 Implementation IssuesgCan we make any guarantees on performance?iWhen using a non-licensed band, difficult to provide hard guarantees, since others may be using the same bandgMust use an licensed channel to attempt to make any guarantees519 Implementation IssuesgOnly some issues have been addresses in existing implementationsgSecurity issues often ignoredgAddress assignment issue also has not received sufficient attention520 Integrating MANET with the Internet [Broch99]gMobile IP + MANET routinggAt least one node in a MANET should act as a gateway to the rest of the worldgSuch nodes may be used as foreign agents for Mobile IPgIP packets would be delivered to the foreign agent of a MANET node using Mobile IP. Then, MANET routing will route the packet from the foreign agent to the mobile host.521 Related Standards Activities522 Internet Engineering Task Force (IETF)ActivitiesgIETF manet (Mobile Ad-hoc Networks) working groupihttp://www.ietf.org/html.charters/manet-charter.htmlgIETF mobileip (IP Routing for Wireless/Mobile Hosts) working group ihttp://www.ietf.org/html.charters/mobileip-charter.html523 Internet Engineering Task Force (IETF)ActivitiesgIETF pilc (Performance Implications of Link Characteristics) working groupihttp://www.ietf.org/html.charters/pilc-charter.htmlihttp://pilc.grc.nasa.goviRefer [RFC2757] for an overview of related work524 Related Standards ActivitiesgBlueToothigHomeRF [Lansford00ieee]ihttp://www.homerf.orggIEEE 802.11ihttp://grouper.ieee.org/groups/802/11/gHiperlan/2ihttp://www.etsi.org/technicalactiv/hiperlan2.htm525 Bluetooth[Haartsen98,Bhagawat00Tutorial]gFeatures: Cheaper, smaller, low power, ubiquitous, unlicensed frequency bandgSpec version 1.0B released December 1999 (1000+ pages)gPromoter group consisting of 9 iEricsson, IBM, Intel, Nokia, Toshiba, 3Com, Lucent, Microsoft, Motorolag1800+ adopters526 Bluetooth: Link TypesgDesigned to support multimedia applications that mix voice and datagSynchronous Connection-Oriented (SCO) linkiSymmetrical, circuit-switched, point-to-point connectionsiSuitable for voiceiTwo consecutive slots (forward and return slots) reserved at fixed intervalsgAsynchronous Connectionless (ACL) linkiSymmetrical or asymmetric, packet-switched, point-to-multipointiSuitable for bursty dataiMaster units use a polling scheme to control ACL connections527 Bluetooth: PiconetgA channel is characterized by a frequency-hopping patterngTwo or more terminals sharing a channel form a piconeti1 Mbps per PiconetgOne terminal in a piconet acts as a master and up to 7 slavesgOther terminals are slavesgPolling scheme: A slave may send in a slave-to-master slot when it has been addressed by its MAC address in the previous master-to-slave slot528 Inter-Piconet CommunicationgA slave can belong to two different piconets, but not at the same timegA slave can leave its current piconet (after informing its current master the duration of the leave) and join another piconetgA maser of one piconet can also join another piconet temporarily as a slave529 Bluetooth: ScatternetgSeveral piconets may exist in the same area (such that units in different piconets are in each other’s range)gEach piconet uses a different channel and gets 1 Mbps for the piconetiSince two independently chosen hopping patterns may select same hop simultaneously with non-zero probability, some collisions between piconets are possible, reducing effective throughputgA group of piconets is called a scatternet530 RoutinggAd hoc routing protocols needed to route between multiple piconetsgExisting protocols may need to be adapted for Bluetooth [Bhagwat99Momuc]iFor instance, not all nodes within transmission range of node X will hear node X•Only nodes which belong to node X’s current piconet can hear the transmission from XiFlooding-based schemes need to take this limitation into account531 Open IssuesinMobile Ad Hoc Networking532 Open ProblemsgIssues other than MAC and routing have received much less attention so farOther interesting problems:gImproving interaction between protocol layersgDistributed algorithms for MANETgApplications for MANET533 Related Research AreasgAlgorithms for dynamic networks (e.g., [Afek89])gSensor networks [DARPA-SensIT]iAd hoc network of sensorsiAddressing based on data (or function) instead of name•“send this packet to a temperature sensor”本资料由-大学生创业|创业|创业网 减肥药排行榜|淘宝最好的减肥药|什么减肥药效果最好|减肥瘦身药|534 Thank you !!For more information, send e-mail toNitin Vaidya atnhv@uiuc.edu© 2006 Nitin Vaidya本资料由-大学生创业|创业|创业网 减肥药排行榜|淘宝最好的减肥药|什么减肥药效果最好|减肥瘦身药|535 。
医疗卫生人才供需分析-详解洞察.docx
