[Computer Communications and Networks] Guide to Wireless Sensor Networks || Congestion and Flow...

Chapter 8Congestion and Flow Control in WirelessSensor Networks

Vikram P. Munishwar, Sameer S. Tilak, and Nael B. Abu-Ghazaleh

Abstract Wireless sensor networks (WSNs) present a range of unique challengesto protocol designers due to their communication pattern, poor and unpredictableperformance of their low-power wireless radios, wireless interference, and resourceconstrains of individual sensor nodes. One of the challenges is how to addresscongestion control and reliable data delivery in such environments: the natureof WSN applications (data centric, prone to redundancy due to multiple sensorsreporting a single event) and infrastructure (sensor capabilities, and deploymentdensity and strategy) invite significantly different solutions from those present inconventional networks. In this chapter, we present a survey of existing congestioncontrol approaches and classify them based on various parameters such as mech-anisms used for congestion detection and control, support for application specificdesign, target data delivery model, and support for fairness and reliability. Since,WSN applications exhibit a wide variety of communication patterns, existing lit-erature has focused on three types of applications with regards to communicationamong sensors: one-to-one, one-to-many, and many-to-one. Reliability and conges-tion management approaches in the case of one-to-one (unicast) and one-to-many(multicast or broadcast) communication have been studied extensively in wiredas well as wireless ad hoc networks, providing significant experience to draw on.However, many-to-one communication pattern involves various opportunities (e.g.,loss-tolerance) as well as challenges (e.g., congestion management), thereby gainingmajor attention from the research community. Thus, the main focus of this chapter ison congestion and flow control approaches for many-to-one traffic pattern in WSNs.

V.P. Munishwar (�)Department of Computer Science, Watson School of Engineering and Applied Sciences,State University of New York, Binghamton, Binghamton, NY 13902, USAe-mail: [email protected]

S. Misra et al. (eds.), Guide to Wireless Sensor Networks, Computer Communications 205and Networks, DOI: 10.1007/978-1-84882-218-4 8,c� Springer-Verlag London Limited 2009

206 V.P. Munishwar et al.

8.1 Introduction

Wireless sensor nodes are generally characterized by their limited resources, includ-ing processing, storage, communication, and energy resources. The self-organizingand cooperative nature of sensor nodes makes it possible to deploy them in ad hocfashion in an inaccessible location to obtain required information about the targetarea. A wireless sensor network can be composed of multiple sensor nodes that self-organize to gather information, and relay this information to observers. An observercan either be a central node (base station) or a mobile node that moves around thenetwork and collects the data. In either case, observers are assumed to be resourcerich nodes having capabilities to store, process, and analyze the data collected fromsources and make the data available over a network, if desired. This makes sen-sor networks an attractive choice for a wide range of applications in areas such asmilitary, civil, mining, health, and monitoring for scientific as well as commercialpurposes.

WSNs have a number of unique characteristics that require protocols and systemsupport that significantly differs from those of traditional networks. Specifically,WSNs differ in the following ways:

1. They are data-centric: The observers are interested in timely and accurate gath-ering of the data. In contrast, traditional networks typically focus on communi-cation between different end-points on the network. There is redundancy amongthe information reported by physically colocated sensors. The performance of thenetwork is best measured in application specific terms, rather than in networkingterms such as throughput.

2. Unique traffic patterns: In WSNs, often data are funneled from a subset of sensorstoward an observer interested in collecting the data. Since, such communicationinvolves multiple senders and a single receiver, we term it as many-to-one trafficpattern.

These factors, combined with the nature of the wireless channel, and the empha-sis on energy efficiency, require new protocols and algorithms for WSNs that aresensitive to their unique characteristics.

In this chapter, we overview and classify protocols for congestion managementin WSNs [1]. Congestion is a classical problem in packet switched networks wherethe sources collectively exceed the network capacity at one or more intermediatenodes (routers), leading to packet drops [2]. If the offered load to the network is notcontrolled (via a congestion management protocol that typically limits the sourcerates), congestive collapse can arise. Because of the properties of WSNs overviewedin the previous paragraph, the impact of congestion is best measured in application-specific terms [1]. As such, new congestion management protocols that are awareof the nature of the application can lead to more effective solutions than classicalapproaches that rely only on networking measures.

Congestion control is essentially a resource allocation problem. A basic con-gestion control simply ensures that the source rates are regulated to avoid ormitigate congestion. Better approaches are also able to allocate the resources fairly –attempting to ensure that the competing sensor nodes at a congested node get equal

8 Congestion and Flow Control in Wireless Sensor Networks 207

shares of the bandwidth [3]. Similarly, handling cases, where sender(s) are sendingdata faster than a receiver can consume them, is called flow control. Finally, one ofthe important goals of congestion and flow control algorithms in WSNs is to providedesired level of reliability at the sink node, in an energy efficient manner, where reli-ability is nothing but a guarantee of successful delivery of data from source to sink.Again, the notion of reliability is best measured here in application-specific terms(e.g., data fidelity, or reliability in detecting an event).

In this chapter, we begin with presenting various congestion and flow controlalgorithms for WSNs, specifically designed for commonly observed data collection-based application, in which data are funneled from a subset of sensors towardan observer interested in collecting the data. Most of these algorithms focus onavoiding or mitigating congestion in WSNs; however, they use simple ARQ-basedprotocols to ensure overall reliability of the communication. Since an importantgoal of providing congestion and flow control in sensor networks is to minimizethe overall energy consumption in the network, it is equally important to focus onenergy-efficient reliability guaranteeing protocols for WSNs. Therefore, we alsodescribe some efforts specifically targeted toward providing energy-efficient reli-able data delivery in WSNs. Finally, we overview protocols that support congestioncontrol for applications involving different (less common) data delivery models forWSNs, and a MAC protocol that implicitly supports rate control in WSNs.

The remainder of the chapter is organized as follows: Sect. 8.2 explains conges-tion and flow control in detail followed by the description of why existing techniquesfor congestion management are not directly applicable in case of WSNs. In Sect. 8.3,we describe general challenges and design issues associated with developing energyefficient congestion and flow control mechanisms in WSNs. Section 8.4 gives theclassification approach that we have used to differentiate the congestion and flowcontrol protocols discussed in this chapter. Although, congestion control and relia-bility are two important features of transport protocols, we prefer to discuss them inseparate sections because majority of the existing protocols in WSNs focus mainlyon an individual feature, with little or no attention given to the other. In Sect. 8.5we focus on typical data collection-based application, and discuss some importantcontributions on congestion control, flow control, and fairness guarantee in sensornetworks. In Sect. 8.6, we discuss some of the existing approaches that focus mainlyon providing reliability guarantees in WSNs. In Sect. 8.7, we describe other relatedworks that either implicitly or explicitly contribute toward congestion and flow con-trol in WSNs. Finally, in Sect. 8.8, we compare some of the approaches discussedin the chapter, based on the classification scheme presented in Sect. 8.4, and giveconcluding remarks.

8.2 Background

In this section, we overview the problems of general congestion management andthen those of flow control in traditional networks. We then explain why congestionand flow control requirements are unique for WSNs, motivating the need for alter-native protocols and algorithms that are tailored for them.


8.2.1 Congestion Management

Congestion is caused by sources exceeding the link or buffer capacity at intermedi-ate nodes. In wired networks, the resource exceeded is the capacity of a given link(which is fixed for point to point links). In wireless networks, the capacity of a linkis determined by the number of active sources in interference range with each other.The MAC protocol is responsible for arbitrating the medium among the contendingsources. However, as a result, the effective capacity of a link can vary over time evenif the traffic going through a congested node does not vary over time.

Congestion control is carried out by either detecting early signs of oncomingcongestion and recovering before the onset of congestion (known as congestionavoidance) or detecting congestion and then recovering from it (known as conges-tion mitigation). Congestion management algorithms differ in how they accomplishcongestion detection and control (or avoidance). Detection may be carried out at thesources or at the intermediate nodes. In either case, control is carried out by reducingthe sending rate of the sources. We elaborate on these approaches in the following.

8.2.1.1 Congestion Detection

Congestion detection is a primitive and important step in any congestion control al-gorithm. In general, congestion can be detected either at an intermediate node or atthe sink (end-to-end). At an intermediate node, congestion or the possibility of con-gestion can be inferred based on various factors such as current queue occupancy,packet service time, or a combination of the present and the past channel loadingconditions. For instance, congestion detection based on queue occupancy is used inDECbit [4] and Random Early Detection (RED) [5] mechanisms. DECbit gives ex-plicit notification of congestion, while RED gives implicit congestion notification,either by piggybacking congestion state on a data packet to be transmitted or bydropping it. End-to-end congestion detection can consider factors such as timeouts,duplicate ACKs, inter-packet delay, etc. Transmission control protocol (TCP) [6]detects congestion based on duplicate ACKs or timeouts. Therefore, upon receivingthree duplicate ACKs, the fast recovery module of TCP considers that the conges-tion has occurred.

8.2.1.2 Congestion Control

Once congestion (or early sign of congestion) is detected, congestion control mech-anism needs to be initiated. Congestion control can be performed either in proactiveway, by avoiding the congestion collapse to occur, or in reactive way, by mitigatingthe congestion already occurred in the network. We briefly explain the two mecha-nisms now.


� Congestion avoidance: Congestion avoidance strategy involves detecting earlysigns of congestion in the network and initiating preventive measures to avoidcongestion collapse. For instance, TCP Vegas [7] tries to detect congestion whenit is in incipient stage by comparing the measured throughput rate with expectedthroughput rate at the sender. Depending on this difference, the source can de-termine whether the sending rate needs to be adjusted to make sure that the rightamount of extra data is present in the network. Other congestion avoidance mech-anisms include DECbit and RED, which detect and inform the early signs ofcongestion to the end node by monitoring the queue occupancy at an intermedi-ate node.

� Congestion mitigation: Once congestion arises and is detected, it is mitigated(recovered from) by having the sources reduce the overall offered load. In caseof wired networks and wireless ad hoc networks, data flow is end-to-end andnot collaborative (as in case of WSNs). Thus, for such networks, the assump-tion is that congestion occurs among competing sources, and therefore, ensuringfairness among the sources is an issue. This is especially true since congestioncontrol is carried out in a distributed way by different sources; that is, the sourcerate control is not coordinated. In WSNs, the competition for the resources isoften among multiple sources that respond to the same query; that is, all packetsare in service of the same flow and the notion of fairness must be replaced byapplication specific measures of data quality.

8.2.2 Flow Control

Flow control is a mechanism for ensuring that there is no rate-mismatch betweenone or more transmitter(s) and their receiver. In other words, flow control ensuresthat the overall transmission rate of the sender(s) never exceeds the reception rate ofthe receiver. There are two types of flow control mechanisms:

� Closed-loop flow control: In this technique, the receiver gives feedbacks directlyto the source. Depending on the feedback, source can adjust its transmission rateto handle the rate-mismatch.

� Open-loop flow control: In this technique, there is no feedback given by the re-ceiver to the source. On the other hand, it involves hop-by-hop feedbacks.

8.2.3 The Need for Congestion and Flow Control in WSNs

Before describing the congestion control problem in WSNs, we define the key-words that will be used throughout the chapter. Since, multiple sensors reportingtheir readings to the base station is a commonly observed scenario in WSNs, datafollows a tree-based routing topology with the base station (sink) as a root of thetree, as shown in Fig. 8.1. Here, node S represents the sink, while the other nodes


Fig. 8.1 Tree-based routingtopology

represent data generators and/or forwarders. In this chapter, we term the nodes thatare near the sources as upstream nodes while the nodes near the sink as downstreamnodes. Thus, if nodes F andG are the sources, then they represent a set of upstreamnodes for node C , whereas node A acts as a downstream node for node C . In addi-tion, we term the one-hop neighbor that is on the data forwarding path toward thesink as a parent node. Thus, for this topology, node A acts as a parent of nodes Cand D. Similarly, we term subtree of node A as a tree formed by all of its upstreamnodes .C;D; F;G/, with node A acting as a root of the tree.

The impact of congestion and the need for congestion avoidance mechanisms inWSN was identified by Tilak et al. [1]. Specifically, they study the effect of increas-ing the data reporting rate and the sensor density on the quality of the informationas viewed by the observer in a data funneling application. Although, higher den-sity of sensor nodes presents an opportunity for more accurate sensing, it becomesharmful to the performance of the overall network if congestion is not controlled;as sensor density increases, a higher load is placed on shared wireless channel andthe network is saturated faster. In addition to the need to make sure that the over-all reporting rates of sensors do not exceed the network capacity, it is important tomake sure that minimum application-specific accuracy requirements are met, and atthe same time the network is not expending energy on achieving excessive accuracythan the desired accuracy level. To support application’s requirement, following in-equality should be satisfied.

Capplication �

MXiD1

b.Si / � ˛Ctotal; (8.1)

where, Capplication is the required channel capacity to satisfy application’s need,Ctotal is the total channel capacity, ˛ is the fraction of the capacity dictated by theself interference that arises in multihop connections (˛ is typically around 0.25 [8]).PM

iD1 b.Si / is the total data in transit from M event-detecting sensors, where eachsensor, Si is transmitting at the bit rate of b.Si /, from time T to T C ı, where ı is


Fig. 8.2 Funneling effect oftraffic in WSNs

Sink

the average latency. The desired accuracy level required by the observer can be dif-ferent in case of different types of applications with different traffic flow paradigms.For instance, traffic generated by multiple nodes in response to a single event is gen-erally redundant and thus loss-tolerant. This decreases the level of accuracy requiredat the base station.

In a funneling WSN application, as shown in Fig. 8.2, it is helpful to differentiatebetween congestion that arises near the sink, vs. that arises near the sources.

� Congestion Near the Event-Sources: Detection of an event creates sudden burstof traffic from sensor nodes lying in the event region, leading to collisions andsignificant packet loss near the sources. This problem is especially prominent ifthe density of detecting nodes as well as the data generation rate is high, in whichcase the probability of having persistent hotspots near the sources increases dra-matically [9]. To handle this problem, hop-by-hop signaling indicating the needfor reducing the reporting rate (backpressure) has been proposed [3, 9].

� Congestion Near the Sink: Traffic generated at multiple source nodes travels inmultihop fashion toward the sink (base station). Especially in case of detectionof an event, data are generated at the source nodes almost at the same time.Such traffic, along the way to the base station, increases traffic-load in the regionnear to the base station due to the funnel-like communication pattern [10]. Thisincreased traffic load can result in node-level as well as link-level congestion nearthe sink node. Specifically, in a sparsely deployed network, sources generatingdata at higher rate can create transient hotspots near the sink [9].

Other forms of traffic such as one-to-one and one-to-many communication mayroutinely arise in WSNs. These communication patterns also pose congestion man-agement related challenges. For example, one-to-one communication may observepacket loss due to the hidden-terminal problem or interference due to concurrent-flows in the network, whereas one-to-many traffic flows (in case of flooding) exhibitcongestion-related issues away from the source node, since downstream nodes for-warding the data simultaneously can result in packet losses due to collisions, if any


measures to control the load are not taken. However, since such routing scenarios arenot unique to sensor networks, approaches to handle these challenges have alreadybeen discussed in the context of wired or wireless ad hoc networks.

8.3 Challenges and Design Space

In this section, we overview some of the challenges associated with building con-gestion and flow control support for WSNs. WSNs present some unique design levelissues due to the limited sensing, processing, storing and communicating capabil-ities of sensor nodes, different traffic patterns, and different deployment patterns.Thus, it is important to take into account various challenges associated with WSNs,before developing efficient congestion and flow control mechanisms. We now brieflydescribe challenges and design level issues in WSNs.

8.3.1 Resource Constraints

One of the major challenges presented by a wireless sensor network is the limitedbattery power, processing power, memory and storage capacity of sensor nodes.Radio communication is a costly operation in terms of energy consumption, whichplaces an emphasis on in-network processing to reduce the amount of data beingcommunicated, as well as effective networking protocols that reduce unnecessarypacket losses.

8.3.2 Traffic Patterns

Another difference between traditional networks and WSNs is the unique patterns ofcommunication that can occur in WSNs [11]. In most traditional networks, point-to-point, or unicast, communication dominates. However, in WSNs, many-to-onecommunication is most common, as data are sent from multiple sensors to an ob-server continuously or in response to a query or an event. Furthermore, one-to-manycommunication via optimized broadcast or geocast algorithms can occur as a queryis disseminated in the network, or information about an important event (or eventsummaries) are disseminated proactively in the network [12]. Periods of bursty ac-tivity can occur as an important event occurs, while at other times, the network canexhibit low activity. In applications that use storage, other complex patterns of com-munication can arise. These traffic patterns play an important role in how congestionis manifested, and the solutions for detecting and controlling it.


8.3.3 Network Architecture

Sensor network architecture can be broadly classified into flat and multi-tiered ar-chitectures. In a flat architecture, all sensor nodes are generally of the same typeand have similar responsibilities. Although, in such a topology, there is no over-head of topology construction, scalability is a major issue because even a smallchange needs to be propagated to the whole network. In case of multi-tired topol-ogy, resource constrained sensor nodes (motes) are present in the lower tire(s),whereas relatively resource rich nodes (Stargate-NetBridge) are present in the highertire(s) [13]. Such a mote and Stargate-NetBridge based architecture provides in-creased network capacity, due to the increased ability to perform computationallyintensive processing within the network itself. In addition, it also provides increasedmanageability and scalability.

8.3.4 Alternative Performance Metrics

Since WSNs are application driven networks, whose value is mainly in terms of thequality of sensing provided to the application, ideally congestion and flow controlmechanisms should target maintaining application level metrics of data quality. In ageneral scenario, sources react to the congestion in the network by limiting the datageneration rates, by scheduling packets or by dropping packets, thereby resulting inreduced data quality measured at the sink. Metrics such as coverage, data freshness,fidelity, and event detection reliability replace conventional network-centric metricsof throughput, delay, and overhead. Multiple events detected in a sensor networkcould be of different importance levels. Therefore, it is possible to provide mecha-nisms that give priority to the data with higher importance, when congestion arises.

8.3.5 Data Redundancy

Related to application level metrics, but also of broader applicability, is the observa-tion that typically an observation of interest will generally be detected by multiplesensor nodes that are in within sensing range of it. It is important to attempt toreduce this redundancy via data aggregation, or source rate control to reduce theamount of communication in the network [1]. However, should some redundancyremain, some loss of information may be acceptable if it does not compromise thedata quality.

8.4 Classification of Congestion and Flow Control Approaches

We differentiate the congestion control protocols along several axes that are de-scribed in this section.


8.4.1 Congestion Detection Mechanism

Congestion detection mechanisms can be classified into local congestion detectionand global congestion detection mechanisms. Local congestion detection typicallytakes place at intermediate nodes, where congestion detection can be carried outby monitoring local indicators of congestion such as queue occupancy or channelstate. On the other hand, global congestion detection is carried out at the sink (basestation) where end-to-end attributes such as inter-packet delays and the frequency ordistribution of losses can be used to infer congestion, especially how these attributesvary when the source rates are controlled.

8.4.2 Congestion Control Goals

Transport protocols employ a closed loop control process where they attempt tocontrol source transmissions to achieve an effective operating point. Some WSNprotocols that are based on traditional congestion control approaches consider net-work centric performance metrics such as end-to-end throughput or reliability. Weterm such approaches as network-centric congestion control approaches. Alterna-tively, the application-driven nature of WSNs invites other approaches, where theprotocol attempts to achieve application-specific metrics of performance, as ex-plained in Sect. 8.2.3. We term such approaches as application-specific approachesto congestion control.

8.4.3 Rate Control Mechanisms

Rate control mechanisms in WSNs can be broadly classified into centralized,source-control mechanism, and distributed, hop-by-hop backpressure mechanism.Source-control mechanism is carried out at the data collecting node (sink). Essen-tially, when congestion (or early sign of congestion) is detected, the sink instructsthe sources to adjust their reporting rates. Whereas, hop-by-hop backpressure mech-anism is carried out at intermediate nodes, in which the intermediate node instructsits upstream nodes to adjust their reporting rates based on its local congestion state.

8.4.4 Fairness and/or QoS

Congestion control represents the base requirement in terms of resource allocationin the presence of congestion. Specifically, congestion control is simply tasked withreducing the sending rates to avoid congestion. More refined resource control, whereadditional requirements about the resource allocation are maintained, is possible.This includes, for example, approaches that attempt to maintain fairness among the


contending flows when congestion arises. In the same vein, QoS approaches attemptto allocate the resources according to the flow importance or reservation levels. Weidentify protocols that provide some support for these capabilities.

8.4.5 Target Application Model

Most protocols focus on the many-to-one model of communication with data beingfunneled to the base-station. However, some protocols differ on their assumptionswithin this model, such as assuming high-rate flows, or multiple queries to multi-ple sinks, and others target different data delivery models, such as many-to-manycommunication of events, or one-to-many communication of queries.

8.4.6 Other Metrics

We also differentiate between protocols in terms of additional metrics. For example,some protocols require additional support (specialized MAC, or additional networkcapacity). Moreover, some protocols pay special attention to energy efficiency.

8.5 Congestion and Flow Control for Many-to-OneTraffic in WSNs

In this section, we overview WSN transport protocols that feature congestion con-trol and flow control support. Unlike traditional congestion management algorithmsfrom wired or wireless ad hoc networks, most of the existing protocols in WSNs fo-cus on applications involving many-to-one communication pattern with data beingfunneled from sensors toward a base station or a query generator. Thus, the ap-proaches discussed in this section mainly concentrate on many-to-one traffic patternin WSNs. We first describe network-centric protocols, followed by application-specific protocols, and finally an approach that supports both network-centric aswell as application-specific mechanisms.

8.5.1 Network-Centric Approaches

As described in the classification approach given in Sect. 8.4, network-centric con-gestion control approaches focus on traditional network centric performance metricssuch as end-to-end throughput or reliability. In this section, we describe such ap-proaches tailored toward WSNs.


8.5.1.1 CODA: Energy Efficient Congestion Detection and Avoidance

Congestion detection and avoidance in sensor networks (CODA) [9] differs fromclassical approaches in attempting to conserve energy and in its focus on both tran-sient and persistent hotspots and to regulate the individual sensor nodes generatinghigher data rates than others. As per the classification approach, CODA uses localcongestion detection mechanism and hop-by-hop backpressure as well as central-ized, source control as rate control mechanisms. More specifically, CODA consistsof three mechanisms, receiver-based congestion detection, open-loop hop-by-hopbackpressure, and closed-loop multi-source regulation. Receiver-based congestiondetection mechanism can be used at sink as well as at intermediate nodes, and itis based on explicit congestion detection mechanism such as queue occupancy andchannel state at the receiver. Once congestion is detected, if it is transient, the open-loop hop-by-hop backpressure technique is used to quickly mitigate it. However, ifthe congestion is persistent, rate control at the sources becomes necessary and theclosed-loop multi-source regulation mechanism is applied. Thus, these two controlmechanisms, when used in concert, complement each other. We now describe thethree mechanisms in more detail.

1. Receiver-based congestion detection: Buffer occupancy has been extensivelyused in traditional congestion detection algorithms as a measure of congestionlevel. In this paper, the authors demonstrate that buffer occupancy alone is not agood measure of congestion in wireless networks because of the shared natureof the channel. In CODA, receivers not only monitor buffer occupancy, but alsomeasure present and past channel utilization conditions to detect congestion. Atthe time of congestion, channel load generally increases at a much faster pacethan buffer occupancy. In other words, the number of packets received success-fully by a receiver is usually less than the number of packets transmitted by asender, because of interference on the path. Thus, dropped buffer occupancy atthe sender can give false information about the state of congestion in the net-work. However, continuous listening incurs high energy cost. Therefore, CODAuses a sampling scheme that activates local channel monitoring only under cer-tain conditions, for example only when the send buffer is not empty, in order tosave energy.

2. Open-loop hop-by-hop backpressure: When a receiver detects congestion, itsends backpressure signals toward the sources while the congestion state persists.The backpressure could propagate all the way to sources, or reach only interme-diate nodes depending on their local congestion state. Routing protocols can alsotake advantage of the backpressure information to guide routing decisions andselect better, non-congested paths for communication.

3. Closed-loop multisource regulation: CODA runs closed-loop congestion controlmechanism on the sink to regulate multiple sources, in the case of persistent con-gestion. Essentially, when the transmission rate of a source exceeds maximumtheoretical throughput .Smax/, the source informs the sink by setting a bit in ev-ery packet that it transmits to the sink, as long as the transmission rate remains


higher than Smax. In response, sink starts sending ACKs to the source until thesink detects congestion. When the sink detects congestion, it stops sending ACKsuntil the congestion is mitigated, to implicitly notify the sender to drop its rate.

8.5.1.2 Fusion: Awareness of Packet Priority

Although CODA supports congestion mitigation, it does not provide fairness guar-antees among sources. Fusion [3] addresses this problem and also supports priori-tized MAC – a mechanism to drain queues of congested nodes quickly. Similar toCODA, Fusion also uses hop-by-hop backpressure mechanism for rate control. Inaddition, Fusion uses local congestion detection approach, however unlike CODA,the designers of the protocol show experimentally that congestion detection basedon queue occupancy consistently outperforms that based on channel sampling. Wenow describe the approaches of Fusion in detail.

1. Hop-by-hop flow control: This mechanism is similar to that of CODA, with theexception that Fusion uses an implicit mechanism rather than the explicit messag-ing used by CODA. Specifically, nodes snoop on packets sent by their parent tocheck whether the congestion bit is set, in which case they throttle their transmis-sions, allowing the parent to come out of the congested state. This hop-by-hopbackpressure can reach source nodes if the congestion is persistent. However,completely stopping children from transmitting packets, upon detection of con-gestion at parent node, can block further backpressure propagation toward sourcenodes. To avoid this problem, each child is allowed to transmit one packet hav-ing the congestion bit set, thereby allowing its children to overhear about thecongestion.

2. Limiting source rates: This mechanism addresses an important problem, in whichpackets originated from distant sources get dropped near the sink due to con-gestion. To handle this problem, a passive snoop-based approach is used. Eachsensor listens to the traffic its parent forwards to determine total number of nodes,N , transmitting packets through the parent. When parent transmits N packets,each child takes one token. Each child is allowed to transmit as long as it has atleast one token and each transmission costs one token. This simple token-basedapproach allows each sensor to match its transmission rate with the rate of itsdescendants. For this scheme to work, it is assumed that all sensors offer sametraffic load, and routing tree is not significantly skewed.

3. Prioritized MAC: The CSMA MAC layer gives equal chances of transmissions toall sensor nodes. This is problematic especially in case of congestion scenarios,where a sensor node, serving as a parent to many source sensor nodes, tends todrop packets if its internal queues become full. Therefore, it becomes importantto give preference to an already congested parent over its children in accessingthe wireless medium. This problem is solved by using technique proposed by Aadand Castelluccia [14], in which the length of each sensor’s randomized backoffbecomes a function of its local congestion state. Therefore, backoff interval of a


congested sensor is set to one-fourth of the backoff interval of a non-congestedsensor, thereby increasing the chances of congested sensor in gaining access tothe wireless medium.In general, the hop-by-hop flow control mechanism can throttle the transmis-sions at any link in the network, whereas the rate limiting technique can providefairness to data generated by each source. In addition, the prioritized MAC alsoprovides fairness by prioritizing the in-transit traffic. Together, these strategiescomplement each other, thereby achieving high level of efficiency even after net-work reaches saturation.

8.5.1.3 Distributed Rate-Control with Fairness

Ee et al. [15] present another approach that addresses the need to support fairnessguarantees in addition to the congestion mitigation mechanism described in CODA.Similar to CODA, it uses local congestion detection mechanism, which is basedon monitoring queue occupancy. In addition, the rate control algorithm is based onhop-by-hop backpressure mechanism. To employ fairness, each node assigns fairtransmission rates to its upstream nodes. We now describe the basic rate-control andfairness mechanisms discussed in this work.

The basic congestion control mechanism is a closed-loop control algorithm, inwhich each node applies back pressure on its upstream nodes, when the node’squeue is full or about to become full. Similarly, when the queue becomes empty,the node disseminates a higher reporting rate to its upstream nodes. To avoid inter-ference incurred due to simultaneous transmissions of nodes at the same level, somejitter is introduced. The congestion control algorithm involves following steps:

1. Measure average packet transmission rate r: Assuming equal sized packets, thepacket transmission rate can be estimated as the inverse of the time required totransmit one packet. The packet transmission time, t , is measured from the timewhen the transport layer first sends the packet to the network layer to the timewhen network layer notifies the transport layer that the packet has been trans-mitted. The estimated packet transmission time is tracked using an exponentialmoving average of t .

2. Assign appropriate packet generation rate to upstream nodes: The average packettransmission rate is divided among all upstream nodes, n, to assign data packetgeneration rate as

rdata Dr

n: (8.2)

To calculate n, a simple bottom-up propagation approach is used, in whicheach node embeds its subtree size in a packet and sends it to the parent. Parentretrieves the subtree counts of all children, adds one to it (if parent itself is gen-erating data) and embeds the total count in the packet that it forwards furthertoward sink. When the queues are overflowing or about to overflow, the nodeassigns a lower packet generation rate to its upstream nodes.


3. Compare the rate rdata with the rate rdata;parent obtained from parent, and propa-gate smaller rate to the upstream nodes: rdata;parent can either be piggy-backed bythe parent in the packets it transmits or sent separately as a control message.

The fairness control mechanism uses either probabilistic selection or epoch-based proportional selection. In first, the child with a larger subtree size will gethigher probability of its queue getting selected than the other children. While insecond, within each epoch, the number of packets transmitted from each queue is aproduct of n and the number of nodes serviced by that queue.

8.5.1.4 IFRC: Interference-Aware Fair Rate Control

IFRC [16] differs from the previous approaches in that it presents an interferenceaware approach to congestion control. IFRC uses local congestion detection algo-rithm, which is based on monitoring queue occupancy, and it also supports fairnessin the network. Although, the work of Ee et al. [15] and IFRC focus on rate con-trol with fairness guarantee, IFRC differs from the former in that in IFRC, a nodecontrols the rates of all nodes, whose transmissions interfere with its transmissions,instead of controlling only its children. The main contributions of IFRC includeidentifying the set of all nodes that affect the rate at which the congested node istransmitting data (such flows may or may not be traversing through the congestednode), and designing a low-overhead yet efficient mechanism to share congestioninformation to the set of such nodes. We now overview IFRC in more detail.

IFRC assumes that the CSMA-based MAC protocol is used and the MAC layerprovides link-layer retransmissions to recover from packet losses. In addition, IFRCalso assumes that a link-quality based routing protocol is used and it builds a treestructure having base station as a root. Finally, each node is assumed to be gener-ating only one flow. IFRC considers that a node nj is a potential interferer of nodeni , if the flow originating at node nj uses a link that interferes with the traffic sentby node ni . Thus, for many-to-one traffic, a set of potential interferers of node niinclude neighbors of ni , neighbors of parent of ni , and subtrees of the parent as wellas neighbors of the parent. We now present three main phases of the IFRC design:

1. Congestion detection: IFRC uses exponentially weighted moving average ofqueue occupancy as a measure of congestion.

qavg D .1 � wq/ qavg C wqqinst (8.3)

IFRC detects oncoming congestion when the queue length crosses upperthreshold, U . Upon detection of congestion, IFRC halves its data generation rate,ri , then starts increasing it additively. Since, using a single upper threshold maystill keep the node in congested state, even after halving its rate, the authors pro-pose the use of multiple thresholds, U.k/, such that U.k/�U.k�1/ decreases ask starts increasing. This allows the node to continue cutting its rate aggressivelyuntil its queue starts to drain.


2. Congestion sharing: In IFRC, a node transmitting data piggybacks the rate andcongestion state of itself as well as its most congested child. This information isshared recursively in the network with the help of snooping. Thus, the IFRC’sgoal of assigning at least the most congested fair share rate to each flow can beachieved with the help of following rules:Rule 1: rate of a node should be less the rate of its parent.Rule 2: rate of a node should be less than the rate of its congested neighbor orthe congested child of the neighbor.

3. Rate adaptation: Rate adaptation in IFRC is based on additive increase mul-tiplicative decrease (AIMD) principle. At every inter-packet transmission time( 1

rate ) of node ni , the rate is increased by ırate , where ı represents intensity of

additive increase. Similarly, the rate is halved (multiplicative decrease), whencongestion is detected.

To avoid rate jumping from ratemin to ratemax in one step, we require ırate �

ratemin i.e.,ı D " rate2min; (8.4)

where " is a small positive number, whose value for small and sparse network isanalytically determined to be:

" <Fj

8U0

(8.5)

and for large network as

" <9U1

2s�2Fj

; (8.6)

where U0 and U1 are queue thresholds, s is the average depth of the tree, and Fj

is a function of topology and the network size.

8.5.1.5 RCRT: Congestion Control with End-to-End Reliability

The congestion control approaches discussed so far do not support reliable datatransport. Although 100% reliability is not a concern for some sensor network ap-plications, especially in which colocated sensors collect redundant information [1],there is a class of sensor network applications that requires 100% reliability. For in-stance, in structural monitoring applications, structural mode shape estimation canbe done by correlating readings taken from multiple sensors. The loss of samplescan result in inaccurate estimations. To address this problem, RCRT [17] supportsend-to-end reliability in addition to the rate control mechanism. RCRT focuses onapplications involving high-rate data communications requiring 100% reliability.RCRT uses global congestion detection mechanism at sink, which is based on thevariation in RTT between the sink and the source. In addition, RCRT’s rate controlmechanism is centralized, source-control-based approach. The rate control mecha-nism is implemented at the sink because the sink has a comprehensive view of the


state of the network, which makes it possible to use more efficient source rate allo-cation. In comparison with IFRC, RCRT supports multiple concurrent streams fromeach sensor node as well as different rate allocation policies for different flows basedon their demands. RCRT is shown to achieve more than twice the rate achieved byIFRC. We now explain different mechanisms supported by RCRT.

1. End-to-end reliability: RCRT supports 100% reliability using a standard end-to-end NACK-based feedback mechanism. Essentially, the sink maintains a listof missing packets per flow (here, flow represents the data transferred between asource and a sink), and sends a list of missing packets to each source for recovery.The sink also maintains out-of-order packets list per flow to support in-orderdelivery.

2. Congestion detection: RCRT uses an implicit congestion detection mechanismin which the sink assumes that the network is uncongested as long as the timetaken for loss-repairs is less than a certain threshold. More specifically, numberof RTTs required to recover a loss belonging to the flow from source i is:

Lnorm;i DLi

riRTTi

; (8.7)

where, Li is the length of source i ’s out-of-order packet list, and ri is therate assigned to source i . RCRT detects congestion if the exponentially weightedmoving average of Lnorm;i , denoted by Ci , is greater than an upper threshold U .Ideally, a loss should be repaired in approximately one RTT time (Ci D 1).Thus, when Ci > 2, the network is more likely congested. However, RCRT usesa more conservative value for the upper threshold (U D 4) because Ci increasessignificantly when the network moves from uncongested to congested state. Thelower threshold, L, is set to be 1.

3. Rate adaptation: RCRT uses an AIMD approach to control overall rate, R.t/which is nothing but

Pri .t/. When network is not congested, it increases R.t/

additively:R.t C 1/ D R.t/C A; (8.8)

whereA is a constant. Similarly, when network is congested, the rate is decreasedmultiplicatively:

R.t C 1/ DM.t/R.t/; (8.9)

where M.t/ is a time-dependent multiplicative decrease factor. RCRT usesconservative approach for determining when to decrease the rate; after rate ad-justment, sink waits for at least 2RTTi time to get the feedback of the rate change.In addition, RCRT uses a better way to determine value of M than just assum-ing it to be a constant as in M D 0:5 with TCP. Essentially, M.t/ is computedbased on the loss rate experienced by fi . If packet delivery ratio of fi is pi thenthe expected amount of traffic between source i and sink is ri .1�pi /

pi, including

the traffic for losses. Thus, when a flow in the network is congested, fi ’s rate isadjusted such that the total amount of traffic from source i is ri . However, when


a single flow is congested, RCRT conservatively adjusts the overall rate R.t/ bysetting M.t/ to be:

M.t/ Dpi .t/

2 � pi .t/: (8.10)

4. Rate allocation: RCRT allocates rates ri .t/ to each flow based on the rateallocation policy P . RCRT currently supports three rate allocation policies:demand-proportional or weighted rate assignment, demand-limited in whichoverall rate is equally divided among all sources provided that no source getsmore rate than it has demanded, and fair (equal) rate allocation policy.

8.5.2 Application-Specific Approaches

As described in Sect. 8.2.3, the reliability requirements in wireless sensor networksare application specific, and fundamentally different from network-centric reliabil-ity considerations present in typical transport protocols. WSNs involve applicationdriven protocols where success is defined relative to the network’s mission. Thus,in a typical data collection-based application, where events are detected by multi-ple colocated sensors and sent to the base station, the user is interested in reliablydetecting all events, rather than reliably receiving every packet (including thosewith redundant information). The inherent redundancy typically present in sensornetworks makes applications tolerant to some packet losses. Similarly, user is in-terested in knowing critical events as quickly as possible, when compared with theevents with least importance. In this section, we describe WSN protocols that takeinto account these application-specific requirements.

8.5.2.1 ESRT: Application Specific, Centralized Rate Control

The event-to-sink reliable transport (ESRT) [18] protocol focuses on the problem ofadjusting the reporting rates of sources to achieve required event reliability at thesink, with minimum resource utilization. According to the classification approach,ESRT uses local congestion detection mechanism. In addition, the rate controlmechanism of ESRT is centralized, source control based approach. Essentially,ESRT uses a closed-loop congestion control mechanism, in which processing isdone mainly at sink. ESRT assumes that sink nodes are powerful enough to reachall source nodes in the network by broadcast. The key idea in ESRT is that the sinkinstructs source nodes to adjust their reporting frequency based on the current reli-ability measure at the sink and the state of congestion in the network. On the onehand, when the reliability measure at the sink is lower than required, if there is nocongestion in the network then the sink instructs sources to increase their report-ing rate aggressively, whereas if there is congestion in the network, sink instructssources to reduce their reporting rate conservatively. On the other hand, if the reli-ability measure at sink is higher than required then sink instructs sources to reducetheir reporting rates to save energy.


ESRT tracks two parameters: (1) the reliability indicator, , computed by sink;and (2) the current state of congestion. The sink computes i for period i as follows

i Dri

Ri

; (8.11)

where ri is the observed event reliability and Ri is the desired event reliabilityat the sink. To inform the sink about current state of congestion, each sensor nodemonitors its queue size and sets the congestion bit in the packet going to sink if thenext chunk of source data is capable of causing buffer overflow at the node.

The actions in ESRT are based on the observation that increasing the data report-ing rate under congestion may actually reduce the data quality. Specifically, Tilaket al. [1] make the observation that under congestion, packets are dropped with-out discrimination between which packets got dropped and which got forwarded.This may lead to lower data quality than a case with lower reporting rate wherefewer packets are dropped and the sources receive better representation. Using theseparameters, the sink node categorizes the current network state into five differentstates, as shown in Fig. 8.3, where the states have the following interpretations

1. No Congestion, Low Reliability (NC, LR): Sources multiplicatively increase theirreporting rates to raise reliability.

2. No Congestion, High Reliability (NC, HR): Network is not congested, but ob-served reliability is higher than the desired reliability. Therefore, sink instructssource nodes to reduce the reporting rate cautiously, to always maintain the re-quired reliability but lower overhead.

f < fmax ;h < 1-e

f < fmax ;h < 1-e

f > fmax;h >= 1

f > fmax;h >= 1

f < fmax ;1-e <= h <= 1 + e

f < fmax ;1-e <= h <= 1 + e

f < fmax ;1-e <= h <= 1 + e

f < fmax ;1-e <= h <= 1 + e

f < fmax ;1-e <= h <= 1 + e

f <= fmax ;h > 1-e

f <= fmax ;h > 1-e

f <= fmax ;h > 1-e

f > fmax; h > 1

f > fmax ; h > 1

(NC,LR) (NC,HR)(C,LR)

(C,HR)

(OOR)

Fig. 8.3 ESRT protocol state model and transitions


3. Congestion, High Reliability (C, HR): Network is congested and reliability ishigher than desired reliability. Therefore, reduce the reporting rates multiplica-tively until congestion is resolved or reliability drops below the desired level.

4. Congestion, Low Reliability (C, LR): This is the worst possible state, in whichESRT exponentially reduces the reporting frequency to relieve the congestionand potentially improve reliability.

5. Optimal Operating Region (OOR): This is the optimal operating region wherethe reporting rate is just sufficient to meet the desired reliability. More precisely,1� " � i � 1C ", where " is a small error margin used to provide stability. Thegoal of ESRT is to always maintain the network state in OOR.

8.5.2.2 COMUT: Congestion Control Based on Importance of Data

In event-monitoring sensor networks, some events are of greater importance thanothers. Thus, event flows with different importance levels need different ways ofhandling to make sure that flows with greater importance will be delivered to thesink with higher fidelity and timeliness than the flows with lower importance.COMUT (congestion control for multi-class traffic) [19] takes into account thisimportant observation and provides a cluster-based congestion control mechanism.The congestion detection mechanism of COMUT is local, which is based on thenode’s current queue occupancy. In addition, the rate control mechanism of COMUTis a centralized, source-control based approach, which is run at the cluster-head(sentinel) level. Essentially, each node notifies its local congestion level to the sen-tinel. Sentinel exchanges the collective congestion level of its cluster along with thehighest importance level of the event-flow originated within its cluster with othersentinels present along the path toward the sink. This allows each sentinel to instructits members to adjust their data generating rate depending on the importance of theirdata and state of congestion on the path. Contributions of this work are twofold,we first present a self-organizing clustering mechanism that allows proactive mon-itoring of congestion at cluster level, followed by a decentralized mechanism formeasuring traffic intensity on intra as well as intercluster paths.

1. Cluster formation: COMUT uses a clustering-based approach for congestioncontrol to support scalability and regulation of packet transmission rates per clus-ter. Each cluster is governed by a cluster head, a.k.a. sentinel, which proactivelymonitors and predicts onset of congestion in localized scope. Sentinel is electedusing a random-timeout method with probabilistic announcement of being a sen-tinel. In other words, each sensor node waits for a random timeout. If it receives asentinel announcement message from other node in that time, it simply joins thecluster. In contrast, if it times out, it announces itself as a sentinel with probabil-ity Pn and sets a new, random timeout with probability .1�Pn/. Pn is a functionof n, where n is a count of number of instances when the sensor node has notelected itself as a sentinel after timeout. Thus, next timeout value is calculatedas:

PnC1 D .1 � Pn/.1 � e�˛n/C Pn; (8.12)


where alpha represents effective degree of increase of Pn with n. This is to makesure that with small number of iterative steps, each sensor node can either be-come a sentinel or a member of a cluster with neighboring node as a sentinel. Tofacilitate cluster formation, COMUT uses zone routing protocol (ZRP) [20].

2. Traffic intensity estimation and rate regulation: Each sensor monitors its localqueue load and reports load to the sentinel in fixed time intervals. Sentinel calcu-lates a collective estimate of load for the cluster by using the local readings fromeach cluster-member. These collective estimates are then communicated amongsentinels over the entire path from the set of source nodes to sink to obtain aggre-gate estimate of the traffic intensity, a.k.a. congestion level, for that path. Sentinelperiodically forwards the locally computed value of congestion level as well asthe level of highest important flow observed in its cluster to other sentinels onthe path toward source nodes. A threshold value can be calculated analytically,beyond which a cluster can be considered as congested. Thus, to save energy,congestion level can be forwarded only when it is above the threshold, insteadof forwarding it periodically. This information is useful in adjusting packet gen-eration rate at the source nodes. The proposed rate regulation policy is based onadditive increase and multiplicative decrease (AIMD) policy. However, to sup-port multiple classes of importance levels, the regulation policy is modified suchthat if the congestion level is above the threshold or if there exists a flow withhigher importance along the path to the sink then the generation rate is droppedto some minimum rate for the less important flows, where the value of minimumrate can be measured experimentally or via simulations, and can be set before thedeployment of sensors.During the initialization phase (at network setup time), flooding event flows tosentinels can waste energy and create congestion, before giving a chance to sen-tinels to estimate the congestion level and allow sources to initiate rate regulation.To solve this problem, COMUT uses slow start mechanism, which assigns anumber of Rate Regulation Epoch (RRE) intervals that a sensor should wait be-fore it increases its rate. Thus, in addition to handling early congestion scenarios,COMUT favors flows with higher importance by assigning them a smaller wait-ing interval.

8.5.3 Hybrid Approach

In this section, we present Siphon [21], which provides a hybrid approach thatsupports traditional network-centric as well as application-specific congestion con-trol mechanisms. Previously discussed congestion control schemes try to avoid ormitigate congestion either by limiting the data generation rates at sources, or bydropping packets, resulting in reduced overall application fidelity at sink. Thus, themain goal of Siphon is to maintain application fidelity measured at sink, even in caseof congestion collapse, where application fidelity can be as simple as events/secor complex (based on application specific metrics). Siphon uses local congestion


detection mechanism similar to CODA to support network-centric congestion con-trol initiated at node level, and global congestion detection mechanism to initiateapplication-specific congestion control at the base station. The main contribution ofSiphon lies in its novel congestion control mechanism, which is based on the useof additional network capacity. Essentially, a small number of multi-radio virtualsinks (VS) are randomly distributed across the sensor field, which take the traf-fic load off the already loaded sensors, on the onset of congestion, and move it tothe sink through their high capacity secondary radio network. Siphon uses stargatenodes as virtual sinks, which are equipped with a primary low-power mote radio,and a secondary long-range (e.g., IEEE 802.11) radio. Now we briefly describe thealgorithms for design level policies of Siphon.1. VS discovery and visibility scope control: Similar to the deployment of new ser-

vices, Siphon may be deployed in an incremental fashion. As a result, the sinkmight not be always equipped with a secondary radio, consequently reducing thechances of having secondary network rooted at sink. In addition, there is no guar-antee that VS will always be present near a congested node, making it imperativefor a congested node to discover for a nearby VS. To facilitate VS discovery,sink broadcasts VS-discovery packet embedding signature byte, which containsVS-TTL (hop-count) set to either l if sink is on the secondary network or NULLotherwise. Authors experimentally prove that an optimal value for l is 2. Whena VS receives VS-discovery message, it marks the forwarder of this packet as anext Siphon hop. If this packet is received from a secondary-radio, VS forwardsthe packet with signature byte embedded and VS-TTL set to l , over both the ra-dio links. Thus, non-VS nodes receiving control packets with signature byte andVS-TTL greater than zero, add the VS in their neighbor list along with the pathto the VS. Note that, if VS receives packet forwarded by a non-VS node thenVS does not announce its presence to its neighbors, as there exist no path to thesink over secondary radio channel. In other words, such an VS ends up forward-ing packets on the same path that would otherwise have been taken by originalpropagation funnels towards the sink, resulting in congestion near sink.

2. Congestion detection: Siphon uses mechanisms proposed in CODA [9] to detectlocal congestion level at a node. Thus, when congestion is detected, VS takes offthe traffic from the overloaded nodes and redirects it over the secondary networkto the sink. However, the important question is when to redirect traffic. If trafficis redirected as soon as there is a possibility of congestion, it diminishes thepossibility of aggregation, which can be better performed later in the funnel, andvice versa. Thus, to strike a balance, it is most beneficial to redirect traffic justbefore the possibility of congestion to occur in the funnel. Another approach fordetecting congestion in the network is a post-facto congestion detection, in whichsink initiates VS-based redirection depending on measured application fidelityand event data quality. Although, this approach is not good for detecting transientcongestion occurring deep in the network, it can detect congestion occurred closeto the sink. In addition, it obviates the need for running congestion detectionalgorithms on low-power motes. Further, it has an advantage of avoiding earlytraffic redirection when network-wide aggregation is used.


3. Traffic redirection: A sensor forwards a packet to neighbor VS if the packet hasredirection bit set. Siphon uses two approaches for setting the redirection bit: on-demand redirection, in which the redirection bit is set if congestion is detected,and always-on redirection, in which the redirection bit is always set. When VSreceives the packet, it forwards it to the next hop toward the sink, where nexthop could be either on the primary or the secondary-radio path. As a generalguideline for traffic redirection, the next hop on the redirected path should havelink estimation that is within 15% (lower-bound) of the link estimation of thenext hop on regular path.

4. Congestion in the secondary network: Siphon uses congestion detection schemefor secondary network as proposed by Murty et al. [22]. A VS does not advertiseits existence when it detects congestion on both primary and secondary networks.In such case, hop-by-hop backpressure mechanism proposed in CODA [9] isused. However, authors argue that there are less chances for VSs to become con-gested because they can communicate using two radios, on different channels, atthe same time.

8.6 Reliability Requirements in WSNs

Typically, the transport protocol is also tasked with maintaining end-to-end reliabil-ity. In this section, we discuss the transport protocols that focus mainly on reliabilityensuring issues in WSNs, with little or no attention given to the congestion controlissues.

As discussed in Sect. 8.2, an important class of traffic in sensor networks is many-to-one flows; these flows typically arise when multiple sensor nodes monitoring fora phenomenon jointly, report their readings to a base station for further processing.However, other classes of traffic also arise in WSN, including one-to-one and one-to-many communication. For instance, in a data-centric storage system (for exampleGHT [23]), sensed data at one sensor node needs to be stored at some other sensornode, depending on the key associated with the data. In such a scenario, there isone-to-one communication between the sensing node and the node responsible forits storage. In such applications, if there is little redundancy in the collected samples,end-to-end reliability ensuring mechanisms [24,25] are necessary. However, a stan-dard protocol such as TCP, which supports end-to-end reliability, may not be a goodchoice for sensor networks because the large header of TCP can be an overheadfor resource constrained sensor nodes. In addition, TCP assumes smart sender andsimple receiver, which does not fit into the sensor network model, where the senderneeds to be simple and the receiver (base station) can be complex. In addition, ifdata are redundant, then absolute reliability that is provided by TCP is wasteful, aslong as sufficient information is received by the base station to achieve the desiredmonitoring quality.

Similarly, when reprogramming the sensor nodes from the sink, a one-to-manydelay-tolerant communication pattern is observed. Reliability in such application


is particularly important because even a loss of a single packet out of the wholeprogram image can fail the purpose [26]. Queries in a sensor network often aregenerated from one node, but forwarded throughout the network (or some regionsof it); again, this is an one-to-many pattern. Finally, to handle applications that mayinclude all types of traffic flows, generic reliability guaranteeing mechanisms shouldbe used.

8.6.1 RMST: A Transport Layer Over Directed DiffusionRouting Protocol [27]

RMST [24] is a transport layer protocol, which aims to provide guaranteed deliveryand support for fragmentation/reassembly. To provide reliability, it uses a selectiveNACK-based protocol at either the receiving node or an intermediate node. Fast re-covery in response to a NACK is achieved by using the local caches of the nodesalong the path toward the source. If an intermediate node happens to have a copy ofthe packet required by the NACK, the retransmission request will be answered bythe intermediate node itself, thereby reducing the overhead of end-to-end retrans-missions.

8.6.2 RMBTS: Reliability for Block Data Transfers [25]

Reliability in WSNs is typically associated with the transfer of small amounts ofdata, such as low frequency sensor readings or event detections [28, 29]. However,there is a class of important applications in WSNs that requires bulk data trans-fer. For instance, in acoustic beamforming application, where raw data needs to betransferred to a centralized location, or applications involving a network of imagesensors, where nonredundant image data are transferred to the base station, a servicefor reliable bulk data communication is required.

To provide reliability, the option of using redundant messages can help if thebandwidth is available. However, this approach degrades the throughput signifi-cantly in case of mass data transfer. In contrast, additional cost of using controlmessages to provide reliability is acceptable in case of longer packet bursts. Forthis reason, RMBTS uses a reliable MAC (using RTS/CTS and acknowledgments).Since a reliable MAC can greatly reduce packet loss due to transmission errorsand collisions, a NACK-based end-to-end retransmission mechanism can be usedto recover the remaining lost packets. In addition, a link monitor service is used oneach node to collect statistics for the links connecting to the neighboring nodes bysending periodic ping messages and keeping track of the reply counts from eachneighbor. This information can then be used by the node to select a better parent inthe process of building a spanning tree having the base station as a root.


8.6.3 RBC: Reliability for Many-to-One, Bursty Traffic [30]

In this work, authors focus on bursty convergecast (many-to-one, bursty traffic) inwireless sensor networks, and show that the commonly used hop-by-hop packetrecovery mechanisms, such as synchronous explicit ACK (SEA) and stop-and-waitimplicit ACK (SWIA), do not result in performance improvement for this scenario.SEA, in which each packet’s reception is informed by an immediate explicit ACK,suffers from the problems of channel contention due to unscheduled retransmissionand ACK-losses, whereas SWIA, in which ACK is piggybacked on the packet thatis transmitted by the next hop (snooping based approach), suffers from the problemof increased loss probability of piggybacked ACKs due to the larger sizes of thepackets (resulting in unnecessary retransmissions), channel under-utilization due toin-order delivery constraint, and lack of retransmission scheduling.

To handle these problems, RBC uses window-less block acknowledgmentscheme, which alleviates the need of in-order delivery with the assumption that thedata packets are timestamped; at the same time, it reduces the ACK-loss probabilityby using block acknowledgments. To schedule retransmissions, RBC introducesdifferentiated contention control, which gives higher priority channel access to thepackets that have been transmitted less number of times. When multiple nodes havepackets of the same priority to transmit, preference is given to the node having morequeued packets. Finally, RBC also uses fine-grained timer management to deal withvarying ACK-delays resulting due to the changing network state and to expediteretransmissions of lost packets.

8.6.4 PSFQ: Reliability for One-to-Many Traffic Pattern [26]

PSFQ is a reliable transport protocol suitable for one-to-many routing. An importantapplication in the context of sensor networks is reprogramming the sensor nodesbased on application requirements. Reliability in such application is particularlyimportant because even a loss of a single packet out of the whole program imagecan fail the purpose. The key idea behind the design of PSFQ is that the sourcenode pumps data at slower pace, whereas receiver does the local recovery quicklyby fetching the lost segments from neighbors aggressively.

The PSFQ algorithm consists of three steps: (i) pump operation: before transmit-ting data, the source waits for a period of time uniformly distributed within somebounds tmin and tmax. Choosing an appropriate value of tmin is important becauseit determines the local recovery time at the receiver and allows it to reduce redun-dant broadcasts. (ii) fetch operation: Upon detection of a sequence number gap, thereceiver can initiate quick fetch operation by sending NACKs to the neighboringnodes. Intermediate nodes have local caching enabled to support quick recovery ofthe lost segments at receiver. (iii) report operation: it is necessary to inform thesource about successful transmission in order to collect statistics of dissemination


status as well as to allow sources to free up delivered segments. Reporting startsfrom the farthest target node, allowing the intermediate nodes to piggyback theirreports, thereby achieving aggregation along the way.

8.6.5 STCP: Reliability for Hybrid Traffic Pattern [31]

STCP is a transport layer protocol, which supports heterogeneous applications,such as continuous flow or event-driven applications, and provides reliability andcongestion control services for them. To provide reliability for continuous flow ap-plications, it takes advantage of the base station’s knowledge of the inter-arrivaltime between packets to implement NACK-based reliability. On the other hand, thebase station is unaware of the expected arrival time of the next packet for event-based applications, for which STCP uses ACK-based reliability. In addition, STCPalso supports handling different flows with different reliability requirements. Forinstance, the base station will not send NACKs for missing packets if the observedreliability is greater than the desired reliability value [1]. In case of data centric ap-plications, since the number of sources detecting an event can be very high, STCPdoes not provide acknowledgment-based reliability support, since acknowledgingeach source can deplete network resources and energy. In contrast, they assume thatthe data from multiple sources are loss-tolerant due to the inherent redundancy orcorrelation in the data.

STCP also supports congestion control, in which intermediate nodes probabilis-tically set a congestion bit depending on their current buffer occupancy; this is aform of explicit congestion notification (ECN). Thus, upon receiving packets withcongestion bit set, the sink informs the source(s) to take necessary measures, suchas reducing the data reporting rate, or choosing another, noncongested path.

8.7 Other Related Works

In this section, we describe other related efforts that contribute to congestion control.Specifically, we describe protocols to avoid congestion in networks having one-to-one and one-to-many data delivery models, followed by a MAC protocol thatsupports rate control for many-to-one traffic in WSNs.

8.7.1 One-to-One Protocols

In this section, we describe Flush [32] – a pipelining-based approach to conges-tion control for multihop one-to-one communication. According to the classificationscheme presented in Sect. 8.4, Flush is a network-centric approach to congestionavoidance and provides end-to-end reliability. In terms of target application model,


Flush is specially suited for bulk data transfer in WSNs. Similar to IFRC [16],Flush uses local congestion detection mechanism, which is based on the queue oc-cupancy. However, unlike IFRC, which focuses on determining a set of potentialinterferers, Flush specifically focuses on intrapath interference (or self-interference).Essentially, intrapath interference occurs when transmission of the same packet by asuccessor node interferes with the reception of the next packet from the predecessornode, whereas interpath interference occurs when two or more flows interfere witheach other. In addition, Flush proposes a novel rate control policy (based on sta-ble rate estimates), which results in increased overall efficiency in comparison withIFRC, because the AIMD policy of IFRC can be less efficient due to the typicalsaw-tooth pattern of AIMD. We now describe the mechanisms presented in Flush inmore detail.

Flush assumes that different flows do not interfere with each other, thereby ig-noring the need to focus on interpath interference. In addition, Flush also assumesthat: a node can snoop on the single-hop packets intended for other receivers, thelink layer can provide efficient single-hop acknowledgments, and there exist un-derlying best-effort routing and delivery mechanisms to support packet-forwardingtoward the data sink and from the data sink to the data sources, respectively. Whenthe sink sends a query to a specific source, requesting for a data object, Flush movesthrough four phases: In topology query phase, sink computes timeout at the sinkby measuring RTT with respect to the source. In data transfer phase, source sendsdata to the sink with maximum possible rate that will not cause congestion along thepath. The acknowledgment phase begins after the source finishes its data transfer,in which the sink requests for retransmissions by supplying NACKs. Finally, in theintegrity-check phase, i.e., upon receiving the whole data, the sink checks for theintegrity of the data and sends a fresh request if the integrity-check fails. We nowgive an overview of contributions of Flush to achieve two important goals, reliabledelivery and minimizing transfer time.

8.7.1.1 Reliability Protocol

During the data transfer from a source to a sink, some packets may be lost due toretransmission failures or queue overflows. When the sink believes that the sourcehas finished sending data, the sink sends NACKs to the source, where each NACKpacket contains at most three missing sequence numbers. Instead of sending a se-ries of NACK packets containing all missing sequence number, Flush simplifies thealgorithm by sending a single NACK packet every time, until all packets are suc-cessfully received by the sink.

8.7.1.2 Dynamic Rate Control Mechanism

Flush proposes a simple pipelining model for transferring data over a set of linearlyconnected nodes (from source to sink): when a node sends data to its successor, it


should wait until (i) its successor forwards the packet and (ii) all nodes along thepath, which can interfere with its successor, forward the packet. Thus, dynamic ratecontrol algorithm is governed by two rules:

– Rule1: A node should transmit only when its successor is interference-free (tosupport pipelining model)

– Rule2: A node’s sending rate should not be greater than the sending rate of itssuccessor (to prevent rate-mismatching)

Therefore, after transmitting one packet, the delay for node i to transmit nextpacket is

di D ıi C .ıi�1 C fi�1/; (8.13)

where ıi is a time taken by node i to send a packet, and fi�1 is a time taken byother nodes to send packets that can interfere with the successor node, .i � 1/. Tofacilitate this calculation, each data packet transmitted from node .i � 1/ includesıi�1 and fi�1, which can be obtained by node i by snooping. Node i uses thesevalues to determine the value of fi , which is nothing but the sum of the ı s of allsuccessors that the node i can hear. As the values ıi�1 and fi�1 can change overtime, Flush continually estimates and updates ıi and fi . To prevent rate mismatch,each node calculates its sending interval as:Di D max.di ;Di�1/. Again, each nodesimply includesDi in its data packet, so that the previous node can learn its value bysnooping. To handle congestion at a node, it advertises sending interval by doublingthe value of ıi , when its queue occupancy exceeds a specified threshold.

8.7.2 One-to-Many Protocols

One-to-many data delivery model can be typically observed in information/querydissemination applications. We briefly overview some of the protocols in thiscontext.

Broadcast or flooding is a common approach for transferring data in one-to-many fashion. However, this simple approach involves high energy consumptionof the network because of packet drops due to collisions at MAC layer and re-dundant transmissions to certain nodes through different paths (overlap problem).The former problem can be handled by using gossiping-based approaches [33],where the key idea is to forward the packet only to a randomly chosen neighbor,instead of all the neighbors. However, gossiping fails to handle the overlap problem.Thus, Heinzelman et al. [34] propose sensor protocols for information via negotia-tion (SPIN) protocols family, which solves the overlap problem in energy efficientmanner by having nodes negotiate with each other in order to transfer only usefulinformation.

Tilak et al. present a protocol for nonuniform information dissemination in sensornetworks [12], where the underlying assumption is that information about an eventis important to the nodes that are closer to the event. In other words, nodes that


are farther away from the event source can tolerate some loss of information aboutthat event, thus bringing nonuniformity in the information obtained by each node.To make sure that the network transfers only the enough amount of data that isrequired by the nodes, either deterministic or probabilistic approaches can be used.Essentially, the former approach applies filtering by forwarding only one packet outof n packets, where n is the protocol parameter such that 1

nrepresents the filtering

frequency. The later approach probabilistically determines whether to transmit thedata or not based on the value of a random number.

We also shed some light on another set of protocols, which have been proposedin the context of wireless ad hoc networks and mobile ad hoc networks (MANETs).In location based algorithm (LBA) [35], a node includes its location informationin the packet, so that the receiving node can decide whether its broadcast providessufficient coverage to be worth sending. In Ad Hoc Broadcast Protocol (ABHP)[36], nodes collect 2-hop neighbor information to explicitly select a set of 1-hopneighbors to rebroadcast the packet such that all 2-hop neighbors are covered.Similarly, in Scalable Broadcast Algorithm (SBA) [37], a node maintains 2-hopinformation to rebroadcast the packet only if this rebroadcast can cover additionalnodes that were not covered by the sender of the packet. For the environments withhigh transmission error rate, scheme such as Double Covered Broadcast (DCB) [38]can be used. In DCB, forward nodes are selected such that sender’s 2-hop neighborsand 1-hop forwarding neighbors are covered, whereas sender’s 1-hop nonforwardingneighbors are covered by at least two forwarding neighbors. Hypergossiping [39] isa protocol specifically designed for sparse MANETs, which are more susceptible tonetwork partitioning due to node movements. Hypergossiping tackles this problemby using gossiping algorithm inside partitions and performing broadcast repetitionon partition joins.

8.7.3 ARC: A MAC Protocol with Support for AdaptiveRate Control

ARC [40] is an energy efficient MAC protocol with an adaptive rate control mech-anism, aimed at providing channel access fairness for all the nodes in a WSN. ARCuses carrier sense multiple access (CSMA) but also attempts to reduce collisions byrandomizing synchronized traffic (e.g., traffic due to event detection). Specifically,ARC introduces random transmission delays and uses phase shifting in backoffintervals. Here, backoff interval is a time period for which a node waits after con-tention with the hope of getting access to the channel after the end of the interval.Of more interest to our topic, ARC uses a simple adaptive rate control scheme,which is based on additive increase and multiplicative decrease (AIMD) policy.The rate adaptation decisions are taken independently by each node, depending onwhether the parent node is able to successfully forward its packets. To achieve fair-ness with the self-generated as well as the route-through traffic, a node forwardingroute-through traffic of n children allocates the bandwidth for the packets generated


by itself as 1=.n C 1/. Thus, the adaptive rate control scheme coupled with themodified CSMA mechanism provides an effective and energy efficient solution thatsupports channel access fairness in WSNs.

8.8 Directions for Future Work

The survey presented in this chapter points to many interesting future research direc-tions. For example, it would be interesting to implement the congestion managementprotocols discussed in this chapter on a real testbed. This would allow one to eval-uate perfrormance of these protocols in a fair and consistent manner under a broadrange of real-world scenarios. For example, one can compare the protocols usingvarious metrics including robustness, energy-efficiency, etc. in real-world seetingswhere node failures, unfriendly nature of the physical environement are norms ratherthan exceptions. This will give researchers and end users insight into the behaviorsof these protocols and would enable them to select the one that meets their require-ments.

In addition, it will be useful to integrate congestion control mechanisms for dif-ferent data delivery models, and approaches to support fairness and reliability, toevaluate the efficiency of the nearly complete transport protocol for sensor networks.

8.9 Summary and Concluding Remarks

Data centric nature and many-to-one data delivery model of WSNs have attractedmany researchers to focus on congestion management related issues in WSNs. Inthis chapter, we have presented a survey of congestion and flow control approachesas well as mechanisms to ensure reliable data delivery in WSNs. A broad level com-parison of the congestion control and reliability protocols discussed in this chapteris given in the Table 8.1.

We also take a note of a similar work on surveying transport layer protocols forWSNs [41], which compares existing protocols for congestion control and reliabilitybased on different approaches used for congestion and loss detection, notification,and mitigation or recovery. In contrast, in this chapter, we present a survey of ex-isting protocols for congestion control, flow control, and reliability and comparethem based on various parameters such as mechanisms used for congestion de-tection and control, support for application specific design, target data deliverymodel, and support for fairness and reliability. In addition, we make this chaptermore comprehensive by including some of the important recent contributions in thisarea [16, 17, 32].


Tabl

e8.

1C

ompa

riso

nof

cong

estio

nco

ntro

land

relia

bilit

ypr

otoc

ols

Con

gest

ion

Rel

iabi

lity

Con

gest

ion

Con

gest

ion

Rat

eco

ntro

lFa

irne

ss/Q

oSTa

rget

cont

rol

guar

ante

ede

tect

ion

cont

rolg

oal

mec

hani

smsu

ppor

tap

plic

atio

nsu

ppor

tm

echa

nism

mod

el

CO

DA

Yes

No

Loc

alN

etw

ork-

cent

ric

Hop

-by-

hop

No

Man

y-to

-one

back

pres

sure

No

Fusi

onY

esN

oL

ocal

Net

wor

k-ce

ntri

cH

op-b

y-ho

pFa

irne

ssM

any-

to-o

neba

ckpr

essu

reE

eet

al.

Yes

No

Loc

alN

etw

ork-

cent

ric

Hop

-by-

hop

Fair

ness

Man

y-to

-one

back

pres

sure

IFR

CY

esN

oL

ocal

Net

wor

k-ce

ntri

cA

IMD

Fair

ness

Man

y-to

-one

RC

RT

Yes

Yes

Glo

bal

Net

wor

k-ce

ntri

cC

entr

aliz

ed,

No

Man

y-to

-one

sour

ce-c

ontr

olE

SRT

Yes

Yes

Loc

alA

pplic

atio

n-sp

ecifi

cC

entr

aliz

ed,

No

Man

y-to

-one

sour

ce-c

ontr

olC

OM

UT

Yes

No

Loc

alA

pplic

atio

n-sp

ecifi

cC

entr

aliz

ed,

Eve

nt-i

mpo

rtan

ceM

any-

to-o

neso

urce

-con

trol

base

dQ

oSSi

phon

Yes

No

NA

Hyb

rid

Usi

ngad

ditio

nal

Con

stan

trep

ortin

gra

teM

any-

to-o

nene

twor

kca

paci

tyR

MST

No

Yes

NA

NA

NA

No

One

-to-

one

RM

BT

SN

oY

esN

AN

AN

AN

oO

ne-t

o-on

eR

BC

No

Yes

NA

NA

NA

No

Man

y-to

-one

PSFQ

No

Yes

NA

NA

NA

No

One

-to-

Man

yST

CP

Yes

Yes

Loc

alN

etw

ork-

cent

ric

Cen

tral

ized

,N

oH

ybri

dso

urce

-con

trol

Flus

hY

esY

esL

ocal

Net

wor

k-ce

ntri

cD

ynam

icra

teco

ntro

lN

oO

ne-t

o-on

e


Questions

1. Why protocols for congestion control in WSNs need to be different than theprotocols in wired or wireless ad hoc networks?

2. How can transient and persistent hot spots occur in a WSN? What mechanismscan be used to handle them?

3. What are the different types of unfairness that can happen in a sensor network?Discuss at least one mechanism that handles each type of unfairness.

4. Why TCP is not directly suited as a transport layer protocol for sensor networks?5. What is a potential problem with ESRT, if different events should be given dif-

ferent transmission priorities? Why does ESRT reduce the overall throughput ofthe network?

6. Flush presents a pipelining based approach to congestion control, however itworks only for a one-to-one connection. How can the scheme be extended tomany-to-one communication with support for application level reliability?

7. Can we combine given approaches to create a protocol that supports reliabledata delivery for one-to-many and many-to-one traffic, without loss of overallthroughput?

8. Sink-oriented approaches are perfectly suitable for WSNs, since they have acomplete view of the network as well as knowledge of application specific re-quirements. Is the argument valid? Discuss your reason(s). If the argument isinvalid, can you suggest a possible approach to solve one of the problems?

9. In Siphon, the network is assumed to have a secondary network of a few re-source rich nodes. One possible solution is to put minimal functionality onlow-power sensor nodes: sensor nodes will sense the environment and reporttheir readings to nearby VS. The VS then transfers this data to the base stationover the secondary network. Discuss potential advantages and disadvantages ofthis approach.

10. COMUT supports rate allocation to sensor nodes based on the importance levelsof the events they are reporting. However, COMUT can not be directly usedto guarantee weighted fairness in the network. Discuss at least one additionalfactor that COMUT needs to consider to guarantee weighted fairness in thenetwork. Can you suggest a possible direction for the solution?

References

1. S. Tilak, N.B. Abu-Ghazaleh, and W. Heinzelman. Infrastructure tradeoffs for sensor networks.In WSNA ’02: Proceedings of the 1st ACM international workshop on Wireless sensor net-works and applications, ACM, New York, NY, USA, 2002. pages 49–58.

2. V. Jacobson. Congestion avoidance and control. In ACM SIGCOMM ’88, Stanford, CA,August 1988, pages 314–329.

3. B. Hull, K. Jamieson, and H. Balakrishnan. Mitigating congestion in wireless sensor networks.In SenSys ’04: Proceedings of the 2nd international conference on Embedded networked sensorsystems, ACM, New York, NY, USA, 2004. pages 134–147.


4. K.K. Ramakrishnan and R. Jain. Congestion avoidance in computer networks with a connec-tionless network layer: Part iv: A selective binary feedback scheme for general topologies,August 1987.

5. S. Floyd. Random early detection gateways for congestion avoidance. IEEE/ACM Transactionson Networking (TON), 1(4):397–413, 1993.

6. M. Allman, V. Paxson, and W. Stevens. Tcp congestion control, 1999.7. L.S. Brakmo, S.W. O’Malley, and L.L. Peterson. Tcp vegas: new techniques for congestion

detection and avoidance. SIGCOMM Comput. Commun. Rev., 24(4):24–35, 1994.8. J. Li, J. Jannotti, D.S.J. De Couto, D.R. Karger, and R. Morris. A scalable location service

for geographic ad hoc routing. In MobiCom ’00: Proceedings of the 6th annual internationalconference on Mobile computing and networking, New York, NY, USA, 2000. ACM, pages120–130.

9. C.-Y. Wan, S.B. Eisenman, and A.T. Campbell. Coda: Congestion detection and avoidance insensor networks. In SenSys ’03: Proceedings of the 1st international conference on Embeddednetworked sensor systems, New York, NY, USA, 2003. ACM, pages 266–279.

10. G.-S. Ahn, S.G. Hong, E. Miluzzo, A.T. Campbell, and F. Cuomo. Funneling-mac: A localized,sink-oriented mac for boosting fidelity in sensor networks. In SenSys ’06: Proceedings of the4th international conference on Embedded networked sensor systems, ACM, New York, NY,USA, 2006. pages 293–306.

11. S. Tilak, N.B. Abu-Ghazaleh, and W. Heinzelman. A taxonomy of wireless micro-sensor net-work models. SIGMOBILE Mob. Comput. Commun. Rev., 6(2):28–36, 2002.

12. S. Tilak, A. Murphy, and W. Heinzelman. Non-uniform information dissemination for sensornetworks. In ICNP ’03: Proceedings of the 11th IEEE International Conference on NetworkProtocols, IEEE Computer Society, Washington, DC, USA, 2003. page 295.

13. O. Gnawali, K.Y. Jang, J. Paek, M. Vieira, R. Govindan, B. Greenstein, A. Joki, D. Estrin, andE. Kohler. The tenet architecture for tiered sensor networks. Proceedings of the 4th interna-tional conference on Embedded networked sensor systems, 2006. pages 153–166.

14. I. Aad, C. Castelluccia, and R.A. INRIA. Differentiation mechanisms for IEEE 802.11. INFO-COM 2001. Twentieth Annual Joint Conference of the IEEE Computer and CommunicationsSocieties. Proceedings. IEEE, 1, 2001.

15. C.T. Ee and R. Bajcsy. Congestion control and fairness for many-to-one routing in sensornetworks. In SenSys ’04: Proceedings of the 2nd international conference on Embedded net-worked sensor systems, ACM, New York, NY, USA, 2004. pages 148–161.

16. S. Rangwala, R. Gummadi, R. Govindan, and K. Psounis. Interference-aware fair rate controlin wireless sensor networks. In SIGCOMM ’06: Proceedings of the 2006 conference on Appli-cations, technologies, architectures, and protocols for computer communications, ACM, NewYork, NY, USA, 2006. pages 63–74.

17. J. Paek and R. Govindan. Rcrt: Rate-controlled reliable transport for wireless sensor networks.In SenSys ’07: Proceedings of the 5th international conference on Embedded networked sensorsystems, ACM, New York, NY, USA, 2007. pages 305–319.

18. Y. Sankarasubramaniam, O. Akan, and I. Akyildiz. Esrt: Event-to-sink reliable transport inwireless sensor networks, 2003.

19. K. Karenos, V. Kalogeraki, and S.V. Krishnamurthy. Cluster-based congestion control for sup-porting multiple classes of traffic in sensor networks. In EmNets ’05: Proceedings of the 2ndIEEE workshop on Embedded Networked Sensors, Washington, DC, USA, 2005. IEEE Com-puter Society, pages 107–114.

20. Z.J. Haas, M.R. Pearlman, et al. The Zone Routing Protocol (ZRP) for Ad Hoc Networks.TERNET DRAFT-Mobile Ad hoc Networking (MANET) Working Group of the bternet Engi-neering Task Force (ETF), November, 1997.

21. C.-Y. Wan, S.B. Eisenman, A.T. Campbell, and J. Crowcroft. Siphon: Overload traffic manage-ment using multiradio virtual sinks in sensor networks. In SenSys ’05: Proceedings of the 3rdinternational conference on Embedded networked sensor systems, New York, NY, USA, 2005.ACM, pages 116–129.

22. D. Larson, T. Strategist, R. Murty, and E. Qi. An Adaptive Approach to Wireless NetworkPerformance Optimization. Technology, page 1, 2004.


23. S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan, and S. Shenker. Ght: A geo-graphic hash table for data-centric storage in sensornets, 2002.

24. F. Stann and J. Heidemann. Rmst: Reliable data transport in sensor networks. In Proceedingsof the First International Workshop on Sensor Net Protocols and Applications, Anchorage,Alaska, USA, 2003. pages 102–112.

25. P. Volgyesi, A. Nadas, and A. Ledeczi. Reliable multihop bulk transfer service for wirelesssensor networks. In ECBS ’06: Proceedings of the 13th Annual IEEE International Sympo-sium and Workshop on Engineering of Computer Based Systems (ECBS’06), IEEE ComputerSociety, Washington, DC, USA, 2006. pages 112–122.

26. C.-Y. Wan, A.T. Campbell, and L. Krishnamurthy. Psfq: A reliable transport protocol for wire-less sensor networks. In WSNA ’02: Proceedings of the 1st ACM international workshop onWireless sensor networks and applications, New York, NY, USA, 2002. ACM, pages 1–11.

27. C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed diffusion: A scalable and robustcommunication paradigm for sensor networks. In Mobile Computing and Networking, 2000.pages 56–67.

28. A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk, and J. Anderson. Wireless sensor networksfor habitat monitoring. Proceedings of the 1st ACM international workshop on Wireless sensornetworks and applications, 2002, pages 88–97.

29. G. Simon, M. Maroti,’ A. Ledeczi, G. Balogh, B. Kusy, A. Nadas, G. Pap, J. Sallai, andK. Frampton. Sensor network-based countersniper system. Proceedings of the 2nd interna-tional conference on Embedded networked sensor systems, 2004. pages 1–12.

30. H. Zhang, A. Arora, Y. Choi, and M.G. Gouda. Reliable bursty convergecast in wireless sensornetworks. Proceedings of the 6th ACM international symposium on Mobile ad hoc networkingand computing, 2005, pages 266–276.

31. Y.G. Iyer, S. Gandham, and S. Venkatesan. Stcp: A generic transport layer protocol for wirelesssensor networks. In Proceedings. 14th International Conference on Computer Communicationsand Networks (ICCCN), 2005. pages 449–454.

32. S. Kim, R. Fonseca, P. Dutta, A. Tavakoli, D. Culler, P. Levis, S. Shenker, and I. Stoica. Flush:A reliable bulk transport protocol for multihop wireless networks. In To appear in Proceedingsof the Fifth ACM Conference on Embedded Networked Sensor Systems (SenSys). ACM, 2007.

33. HEDETNIEMI-S. HEDETNIEMI, S. and A. LIESTMAN. A survey of gossiping and broad-casting in communication networks. In Networks 18, 1988.

34. W.R. Heinzelman, J. Kulik, and H. Balakrishnan. Adaptive protocols for information dissemi-nation in wireless sensor networks. In MobiCom ’99: Proceedings of the 5th annual ACM/IEEEinternational conference on Mobile computing and networking, ACM, New York, NY, USA,1999. pages 174–185.

35. S.-Y. Ni, Y.-C. Tseng, Y.-S. Chen, and J.-P. Sheu. The broadcast storm problem in a mobilead hoc network. In MobiCom ’99: Proceedings of the 5th annual ACM/IEEE internationalconference on Mobile computing and networking, New York, NY, USA, 1999. ACM, pages151–162.

36. W. Peng and X. Lu. Ahbp: An efficient broadcast protocol for mobile ad hoc networks.J. Comp. Sci. Tech., 16(2):114–125, 2001.

37. W. Peng and X.-C. Lu. On the reduction of broadcast redundancy in mobile ad hoc networks.In MobiHoc ’00: Proceedings of the 1st ACM international symposium on Mobile ad hocnetworking & computing, IEEE Press, Piscataway, NJ, USA, 2000. pages 129–130.

38. W. Lou and J. Wu. Double-covered broadcast (DCB): A simple reliable broadcast algorithm.In INFOCOM ’04. Twenty-third Annual Joint Conference of the IEEE Computer and Commu-nications Societies, 2004.

39. A. Khelil, P.J. Marron, C. Becker, and K. Rothermel. Hypergossiping: A generalized broadcaststrategy for mobile ad hoc networks. Ad Hoc Netw., 5(5):531–546, 2007.

40. A. Woo and D.E. Culler. A transmission control scheme for media access in sensor networks.In MobiCom ’01: Proceedings of the 7th annual international conference on Mobile computingand networking, ACM, New York, NY, USA, 2001. pages 221–235.

41. S. Floyd. A survey of transport protocols for wireless sensor networks, 2006.

Date post:	23-Dec-2016
Category:	Documents
Upload:	sudip
View:	216 times
Download:	0 times

[Computer Communications and Networks] Guide to Wireless Sensor Networks || Congestion and Flow...

Documents