RCRT: Rate-Controlled Reliable Transportfor Wireless Sensor NetworksJeongyeup PaekEmbedded Networks LaboratoryUniversity of Southern [email protected] GovindanEmbedded Networks LaboratoryUniversity of Southern [email protected] high-rate applications (imaging, structural moni-toring, acoustic localization) will need to transport large vol-umes of data concurrently from several sensors. These appli-cations are also loss-intolerant. A key requirement for suchapplications, then, is a protocol that reliably transport sensordata from many sources to one or more sinks without incur-ring congestion collapse. In this paper, we discuss RCRT,a rate-controlled reliable transport protocol suitable for con-strained sensor nodes. RCRT uses end-to-end explicit loss re-covery, but places all the congestion detection and rate adap-tation functionality in the sinks. This has two important ad-vantages: efficiency and flexibility. Because sinks make rateallocation decisions, they are able to achieve greater effi-ciency since they have a more comprehensive view of net-work behavior. For the same reason, it is possible to alterthe rate allocation decisions (for example, from one that en-sures that all nodes get the same rate, to one that ensuresthat nodes get rates in proportion to their demands), withoutmodifying sensor code at all. We evaluate RCRT extensivelyon a 40-node wireless sensor network testbed and show thatRCRT achieves more than twice the rate achieved by a re-cently proposed interference-aware distributed rate-controlprotocol, IFRC [23].Categories and Subject Descriptors:C.2.2 [Computer-Communication Networks]: NetworkProtocols—Wireless communicationGeneral Terms: Design, Experimentation, PerformanceKeywords: Sensor networks, Transport protocol, Reliable,Centralized, End-to-end1 IntroductionAs sensor network software and hardware matures, it is be-coming increasingly possible to conceive of a class of ap-plications that has received relatively little attention so far— applications requiring the transport of high-rate data.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SenSys’07, November 6–9, 2007, Sydney, Australia.Copyright 2007 ACM 1-59593-763-6/07/0011 ...$5.00.Sources for high-rate data include imagers, microphones,and accelerometers. These sensors in turn motivate severalinteresting applications in surveillance, precision agricul-ture, structural damage assessment, and military target track-ing.To support these emerging applications, we need to solvetwo problems. First, wireless sensors have limited radiobandwidth. A collection of sensors generating high-rate datacan easily overwhelm the network to the point of conges-tion collapse, where the network is unable to perform usefulwork because its capacity is exceeded. Second, applicationsthat use high-rate sensors of the kind described above areoften loss-intolerant. For example, source localization algo-rithms [2] use time difference of arrival between compara-ble samples at different nodes, and structural monitoring al-gorithms estimate structural mode shapes [5] by correlatingcomparable samples observed at different nodes. In eithercase, the loss of samples can adversely affect the accuracy ofthe algorithm.While many sensor network transport protocols have beenstudied in the literature, most of them solve one of the twoproblems identified above (Section 2): they either provide re-liable end-to-end delivery of data from every sensor to a sink,or discuss a congestion control mechanism without ensuringend-to-end reliable delivery.In this paper, we discuss the design and implementationof a transport protocol that ensures reliable delivery of sen-sor data from a collection of sensors to a base station, whileavoiding congestion collapse. However, we place two otherrequirements on the design of this transport protocol. First,unlike most existing proposals which, implicitly or explic-itly, support only a single stream of sensor data from eachnetwork node, we require the network to be able to supportmultiple concurrent streams from each sensor node. We fore-see that future sensor network deployments will be multi-user systems, with concurrently executing applications. Sec-ond, while much existing work has assumed a specific wayto allocate network capacity to all sensors (e.g., a fair alloca-tion), we require our solution to separate the capacity alloca-tion policy from the underlying transport mechanisms. It isunclear, yet, if there exists a single traffic allocation policythat would satisfy the needs of all sensor network applica-tions.Our solution, RCRT, has many different components,many of which are novel (Section 3). It uses relatively stan-dard mechanisms for end-to-end reliable delivery; the baseDistributed Congestion Control Centralized Congestion Control No Congestion ControlReliable Flush, STCP RCRT Wisden, Tenet, RMSTUnreliable IFRC, Fusion, CODA QCRA, ESRT Surge, CentRoute, RBCTable 1—Sensor Network Transport Protocols: A Taxonomystation (or sink) discovers missing packets and explicitly re-quests them from the sensors. However, its congestion con-trol functionality, in a significant departure from much of theprior work, is implemented in the sink. The sink has a com-prehensive view of the performance of the network, and ituses this perspective to control traffic allocation in a moreefficient way than would be possible with decentralized con-gestion control. RCRT employs a novel congestion detec-tion technique, in which the sink decides that the network iscongested if the time to repair a loss is significantly higherthan a round-trip time. Moreover, it de-couples rate adapta-tion from rate allocation; that is, the RCRT sink first decideshow much the total traffic needs to be reduced (or increased)in response to congestion (or lack thereof), then separatelydecides how to allocate the increase or decrease to differentsources. This decoupling allows a network administrator toassign different capacity allocation policies for different ap-plications.We have implemented RCRT’s sink-side functionality ona PC-class platform (our code