<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="nlm-ta">Sensors</journal-id>
<journal-title>Sensors</journal-title>
<issn pub-type="epub">1424-8220</issn>
<publisher>
<publisher-name>Molecular Diversity Preservation International (MDPI)</publisher-name></publisher></journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3390/s91008083</article-id>
<article-id pub-id-type="publisher-id">sensors-09-08083</article-id>
<article-categories>
<subj-group>
<subject>Article</subject></subj-group></article-categories>
<title-group>
<article-title>Efficient Aggregation of Multiple Classes of Information in Wireless Sensor Networks</article-title></title-group>
<contrib-group>
<contrib contrib-type="author">
<name><surname>Qiu</surname><given-names>Xiaoling</given-names></name><xref ref-type="aff" rid="af1-sensors-09-08083"><sup>1</sup></xref><xref ref-type="corresp" rid="c1-sensors-09-08083"><sup>*</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Liu</surname><given-names>Haiping</given-names></name><xref ref-type="aff" rid="af1-sensors-09-08083"><sup>1</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Li</surname><given-names>Deshi</given-names></name><xref ref-type="aff" rid="af2-sensors-09-08083"><sup>2</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Yick</surname><given-names>Jennifer</given-names></name><xref ref-type="aff" rid="af3-sensors-09-08083"><sup>3</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Ghosal</surname><given-names>Dipak</given-names></name><xref ref-type="aff" rid="af1-sensors-09-08083"><sup>1</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Mukherjee</surname><given-names>Biswanath</given-names></name><xref ref-type="aff" rid="af1-sensors-09-08083"><sup>1</sup></xref></contrib></contrib-group>
<aff id="af1-sensors-09-08083">
<label>1</label> Department of Computer Science, University of California, Davis, CA, USA; E-Mails: <email>hpliu@ucdavis.edu</email> (H.P.L.); <email>mukherje@cs.ucdavis.edu</email> (B.M.)</aff>
<aff id="af2-sensors-09-08083">
<label>2</label> School of Electronic Information, Wuhan University, China; E-Mail: <email>dsli@whu.edu.cn</email></aff>
<aff id="af3-sensors-09-08083">
<label>3</label> Qualcomm Inc., San Diego, CA, USA; E-Mail: <email>jyick@qualcomm.com</email></aff>
<author-notes>
<corresp id="c1-sensors-09-08083">
<label>*</label>Author to whom correspondence should be addressed; E-Mail: <email>xqiu@ucdavis.edu</email>; Tel: +(530)-754-9251.</corresp></author-notes>
<pub-date pub-type="collection">
<year>2009</year></pub-date>
<pub-date pub-type="epub">
<day>14</day>
<month>10</month>
<year>2009</year></pub-date>
<volume>9</volume>
<issue>10</issue>
<fpage>8083</fpage>
<lpage>8108</lpage>
<history>
<date date-type="received">
<day>22</day>
<month>7</month>
<year>2009</year></date>
<date date-type="rev-recd">
<day>8</day>
<month>9</month>
<year>2009</year></date>
<date date-type="accepted">
<day>27</day>
<month>9</month>
<year>2009</year></date></history>
<permissions>
<copyright-statement>© 2009 by the authors; licensee Molecular Diversity Preservation International, Basel, Switzerland.</copyright-statement>
<copyright-year>2009</copyright-year>
<license>
<p>This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).</p></license></permissions>
<abstract>
<p>Congestion in a Wireless Sensor Network (WSN) can lead to buffer overflow, resource waste and delay or loss of critical information from the sensors. In this paper, we propose the Priority-based Coverage-aware Congestion Control (<italic>PCC</italic>) algorithm which is distributed, priority-distinct, and fair. <italic>PCC</italic> provides higher priority to packets with event information in which the sink is more interested. <italic>PCC</italic> employs a queue scheduler that can selectively drop any packet in the queue. <italic>PCC</italic> gives fair chance to all sensors to send packets to the sink, irrespective of their specific locations, and therefore enhances the coverage fidelity of the WSN. Based on a detailed simulation analysis, we show that <italic>PCC</italic> can efficiently relieve congestion and significantly improve the system performance based on multiple metrics such as event throughput and coverage fidelity. We generalize <italic>PCC</italic> to address data collection in a WSN in which the sensor nodes have multiple sensing devices and can generate multiple types of information. We propose a <italic>Pricing System</italic> that can under congestion effectively collect different types of data generated by the sensor nodes according to values that are placed on different information by the sink. Simulation analysis show that our <italic>Pricing System</italic> can achieve higher event throughput for packets with higher priority and achieve fairness among different categories. Moreover, given a fixed system capacity, our proposed <italic>Pricing System</italic> can collect more information of the type valued by the sink.</p></abstract>
<kwd-group>
<kwd>wireless sensor networks</kwd>
<kwd>congestion control</kwd>
<kwd>fairness</kwd>
<kwd>performance analysis</kwd></kwd-group></article-meta></front>
<body>
<sec sec-type="intro">
<label>1.</label>
<title>Introduction</title>
<p>In a Wireless Sensor Network (WSN), sensors cooperate to sense, collect, and report information about the environment to sinks. With the help of multihop wireless communication, a WSN can cover a large area without the infrastructure or a backbone wired network. However, congestion can exist inside a WSN due to the following inherent characteristics. First, in a multihop WSN, resources are limited. Typical sensors have limited battery power, memory, and computing capability. In addition, sensors also need to compete for shared resources inside the WSN, such as the shared wireless channel with neighboring nodes and common paths to sinks. Second, majority of the time, the topology of a WSN is not completely under control. As a result, a lot of traffic might contend for the same links or nodes that can become the bottlenecks of the whole network. This imbalance of network traffic due to the network topology can cause severe congestion in bottleneck nodes and/or links. Third, sensors that detect an important event usually increase the data generation rate to accurately alarm the sinks in time. For example, sensors used for monitoring temperature in a forest will generate a large number of alert packets in a short period of time when they detect fires. Fourth, some new applications, such as patient health monitoring [<xref ref-type="bibr" rid="b1-sensors-09-08083">1</xref>] and image sensing [<xref ref-type="bibr" rid="b2-sensors-09-08083">2</xref>], require high throughput and low delay, which can further aggravate the congestion inside a WSN. Therefore, congestion control is necessary and inevitable in the WSN. In the absence of congestion control, WSNs can suffer from packet loss due to buffer overflows and inefficient utilization of critical resources such as shared wireless channel capacity and sensor battery power.</p>
<p>Existing proposals to address congestion control in WSNs are either hop-by-hop data rate control or source rate limiting mechanisms. In this paper, we propose a Priority-based Coverage-aware Congestion Control (<italic>PCC</italic>) mechanism in Section 2.. <italic>PCC</italic> operates at the network and MAC layers. It is a distributed method that avoids aggregating network information in the sink and therefore does not require complicated and expensive communication among nodes [<xref ref-type="bibr" rid="b3-sensors-09-08083">3</xref>].</p>
<p>For advanced WSN applications, we expect to collect multiple categories of information from sensor nodes. For example, from an under-water sensor network, we may collect data about the temperature, the degree of ambient light, the pollution level, and other relevant parameters. The sink can request and store different monitored information from the sensors for each data collection cycle. It is much more efficient and economical than using separate overlapping sensor networks to gather different information. Currently, sensor nodes such as the Mote [<xref ref-type="bibr" rid="b4-sensors-09-08083">4</xref>] has the capability to gather all the information. The Mote can be equipped with different kinds of sensor interfaces in the circuit board; Arch Rock's EPIC Mote has integrated temperature, light and humidity sensors [<xref ref-type="bibr" rid="b5-sensors-09-08083">5</xref>]. However, multiple categories of information contend for the limited network resource to send data from sensors to the sink. Managing the sensors to cooperate and send multiple classes of data fairly and efficiently is a challenging problem, especially when the network is congested. The sensors could ignore the difference between data in the application-layer and send them to the sink with the same weight. However, different data have different value to the sink. For example, in the military application as in <xref ref-type="fig" rid="f1-sensors-09-08083">Figure 1</xref>, the sensor network can collect real-time battlefield information to identify an infantry, a tank, or a helicopter. However, different enemy units pose different level of hazard. The information about hostile helicopters and tanks are important and urgent since they may be more dangerous than infantries. On the other hand, it is also not advisable to assign very high priority to only one type of data. For example, although the data pertaining to hostile tanks are important, it is also important to collect some information regarding infantries. It may be disastrous to utilize all sensor network resources to locate hostile tanks at the cost of ignoring other enemy units.</p>
<p>Consequently, a WSN should be able to allocate network resource to a specific kind of data according to the “price” the sink places on the type of data. Hence, resource consumption depends on the following factors: (1) properties of the events, such as priority, location, and frequency; (2) properties of the sensor network, such as topology and link quality, and (3) other categories of events.</p>
<p>In Section 2., we provide a mechanism to estimate the success probability for transmitting a data packet from a sensor to the sink. The success probability is a good metric for resource consumption and includes both bandwidth and buffer. Based on the method in Section 2., we generalize our scheme to efficiently and fairly collect different categories of information when the WSN is congested. This is presented in Section 3.. The following are the key contributions of this paper:</p>
<list list-type="order">
<list-item>
<p>In a WSN, packets with information of the desired event (<italic>Event</italic> packets), such as fires in the forest, are more important and urgent than those without event information (<italic>Non-Event</italic> packets). (Note that <italic>Non-Event</italic> packets are inevitable since sensor nodes need to contact with the sink periodically to notify that they are alive.) Therefore, in <italic>PCC</italic> we distinguish them with different priority thereby providing different throughput and dropping probability.</p></list-item>
<list-item>
<p>When congestion occurs, packets from nodes far from the sink have a smaller chance to reach the destination than those from the nodes close to the sink [<xref ref-type="bibr" rid="b6-sensors-09-08083">6</xref>]. Without any control, the WSN can only collect the information from the nodes near the sinks. Therefore, in <italic>PCC</italic>, we assign packets an index to store the probability of a packet successfully reaching any node along its path to the sink. Then <italic>PCC</italic> can dynamically adjust its dropping probability during congestion, to guarantee fairness for all nodes and coverage fidelity of the whole network.</p></list-item>
<list-item>
<p>In a large WSN, wireless link quality changes according to multiple factors, such as obstacles between transmitter and receiver, multiple-path transmissions, and interference among neighbor links. In <italic>PCC</italic>, we consider the influence of link quality as an important parameter to indicate network resource utilization and the successful probability of transmissions.</p></list-item>
<list-item>
<p>We make use of cumulative survival probability of a packet reaching a node along its path to the sink and the priority of different event information to design a mechanism to efficiently and fairly collect different categories of information in a single WSN, called <italic>Pricing System</italic>.</p></list-item></list>
<p>The remainder of this paper is organized as follows. In Section 2., we present the details of the <italic>PCC</italic> mechanism, describe the design objectives, and present the simulation results. In Section 3., we propose a generalized pricing based scheme to efficiently collect multiple categories of information using one WSN. Related research is discussed in Section 4.. Finally, we conclude in Section 5..</p></sec>
<sec>
<label>2.</label>
<title>Priority-based Coverage-aware Congestion Control (PCC)</title>
<sec sec-type="methods">
<label>2.1.</label>
<title>System Model and Design Considerations</title>
<p>We design our congestion control mechanism based on the system model shown in <xref ref-type="fig" rid="f2-sensors-09-08083">Figure 2</xref>. We consider a WSN with <italic>N</italic> sensor nodes that act both as source nodes as well as routers to forward packets through a multihop network to the sink. Each sensor node has a fixed size buffer to store packets, which is shown for node <italic>C</italic> in <xref ref-type="fig" rid="f2-sensors-09-08083">Figure 2</xref>. The buffer of node <italic>C</italic> contains packets generated by itself and packets from other sensors, like packet <italic>P<sub>A</sub></italic> from node <italic>A</italic> and packet <italic>P<sub>B</sub></italic> from node <italic>B</italic>.</p>
<p>Under normal condition of the physical attribute monitored by the WSN, nodes generates <italic>Non-Event</italic> packets at a constant rate of <italic>r</italic> packets per second (pkts/sec) which are forwarded towards the sink. Upon sensing an event, sensor nodes generate <italic>Event</italic> packets at higher rate, <italic>k</italic> × <italic>r</italic> pkts/sec where <italic>k</italic> ≥ 1, to report the information to the sink. A one-bit field in the packet header is used to identify <italic>Event</italic> packets. The intermediate nodes can use this bit to route packets with different priority.</p>
<p>Based on the above system model, the goal is to find a novel mechanism to efficiently collect information generated by the nodes in the WSN. Before discussing the details of our approach, we first explain the objectives, the design challenges and the corresponding solutions to the challenges.</p>
<list list-type="order">
<list-item>
<p>High <italic>Event</italic> Packets Throughput: In a WSN with both <italic>Event</italic> and <italic>Non-Event</italic> packets, it is important to ensure that <italic>Event</italic> packet throughput is high. In addition, since <italic>Event</italic> packet generation rate is normally higher than that of <italic>Non-Event</italic> packets, congestion may occur when events are detected by different sensor nodes simultaneously. Therefore, our mechanism should first guarantee high <italic>Event</italic> packet throughput when nodes are congested, to make sure that emergency information, like fire in the forest, is reported to the sink correctly and in a timely manner. We set up two thresholds in the sensor node queue to drop <italic>Event</italic> and <italic>Non-Event</italic> packets to give the former higher priority. To the best of our knowledge, few papers differentiate <italic>Event</italic> and <italic>Non-Event</italic> packets in WSNs with the exception of Event-to-Sink Reliable Transport (ESRT) [<xref ref-type="bibr" rid="b7-sensors-09-08083">7</xref>]. Note that our work is different from ESRT, which is implemented in the transport layer and is an end-to-end congestion control method. <italic>PCC</italic>, on the other hand, is distributed and is based on network layer queue scheduling and MAC layer information feedback, as will be discussed in the following sections.</p></list-item>
<list-item>
<p>Coverage Fidelity: As we explained in Section 1., packet throughput from a specific sensor node drastically decreases when packets traverse multiple hops to the sink. Therefore, packets generated by nodes nearby the sink have much higher probability of reaching the sink than those generated by nodes far away from the sinks. This leads to a spatial bias in the information collected in a multihop WSN. However, it is crucial to achieve coverage fidelity in a WSN because each monitoring area is usually equally important or remote areas are even more important since they are more difficult to be monitored by direct methods. Unlike other proposed methods, we consider the fairness among different areas at the application layer. Our proposed mechanism ensures that the sink receives equal number of packets with the same priority from all the sensor nodes in the sensor network. In IFRC [<xref ref-type="bibr" rid="b8-sensors-09-08083">8</xref>], authors describe MAC layer fairness. However, MAC layer fairness does not ensure application layer fairness since the sink is biased to receive packets from nodes that are near it.</p></list-item>
<list-item>
<p>Flexible Queue Scheduler: Most queue schedulers drop packets from the tail rather than any position in the queue. But tail-dropping does not work well in our new scheme. For instance, if the queue in a sensor node is near fully occupied and dominated with <italic>Non-Event</italic> packets, when an <italic>Event</italic> packet arrives, it is better to drop <italic>Non-Event</italic> packets because <italic>Event</italic> packets are more important. To address <italic>Coverage Fidelity</italic>, we can consider the scenario in <xref ref-type="fig" rid="f3-sensors-09-08083">Figure 3</xref>, where node <italic>B</italic> is closer to node <italic>C</italic> than node <italic>A</italic>, and the sink is at the rightmost end. If node <italic>A</italic> generates packet <italic>P<sub>A</sub></italic> and node <italic>B</italic> generates packet <italic>P<sub>B</sub></italic> simultaneously, <italic>P<sub>B</sub></italic> will normally arrive at node <italic>C</italic> earlier. When <italic>P<sub>A</sub></italic> arrives at node <italic>C</italic> whose queue is highly utilized, <italic>P<sub>A</sub></italic> may be dropped while <italic>P<sub>B</sub></italic> remains in the queue. This results in unfairness to different sensors. To mitigate this our proposed method checks the status of all packets in the queue and selectively drops packets according to an optimization algorithm, which will be introduced in the next section. With the help of a list of pointers to packets in the queue, it is feasible to drop intermediate packets with much lower complexity than expected.</p></list-item>
<list-item>
<p>Resource Efficiency: Another important concern in a WSN is resource efficiency since sensor nodes usually have limited power and channel bandwidth [<xref ref-type="bibr" rid="b9-sensors-09-08083">9</xref>, <xref ref-type="bibr" rid="b10-sensors-09-08083">10</xref>]. In a WSN, packets from sensors far from the sink normally consume more network resource than those from nodes nearby the sink. In our proposed method, we give preference to maintain packets from remote nodes since those packets have consumed more network resource and have lower probability to reach the sink when the intermediate relaying node experiences severe congestion. Therefore, when the same information is collected from different sensors in the network, our mechanism can efficiently utilize network resources by reducing the average number of point-to-point transmissions.</p></list-item>
<list-item>
<p>MAC/PHY Link Quality: In a multihop WSN, the interference among neighboring links can severely reduce the transmission opportunities in MAC layer. In addition, in a WSN, wireless link qualities, such as noise and channel fading, are quite distinct according to locations, obstacles, etc. The link condition at MAC/PHY layer can also influence the success probabilities that packets reach the sink. In respect to resource efficiency, packets traveling through low quality links consume higher system resource since they require more re-transmission due to MAC collisions or more transmission time due to lower PHY layer transmission rate. Therefore, our mechanism will give packets traveling though poor quality links from remote nodes higher probability to reach the sink.</p></list-item></list></sec>
<sec sec-type="methods">
<label>2.2.</label>
<title>Protocol and Algorithm Design of PCC</title>
<p><italic>PCC</italic> is a distributed protocol. First, a distributed protocol is more robust to node or link failures than a centralized protocol. Second, a distributed protocol does not have to collect global information and distribute centrally determined control information, which may introduce large overheads that are not acceptable in a WSN. Third, the distributed algorithm is more scalable in large WSNs.</p>
<p>The protocol structure of <italic>PCC</italic> is shown in <xref ref-type="fig" rid="f4-sensors-09-08083">Figure 4</xref>. It operates both at the network and the MAC layers, which are shown in the left and the right branches, respectively. As in the left branch, when new packets arrive (from the application layer of the node or from other nodes as in <xref ref-type="fig" rid="f2-sensors-09-08083">Figure 2</xref>) into the network queue (Part <italic>1.1 in PCC</italic>), we selectively drop packets in the queue during congestion according to an optimization algorithm (Part <italic>1.2</italic> in <italic>PCC</italic>), introduced in the next subsection. Since our protocol is distributed, each packet <italic>i</italic> has an additional field in the header, <italic>P<sub>i</sub></italic>, to store the cumulative survival probability of the packet along the path. Therefore, at a sensor node when a packet chosen to be dropped, we need to update the <italic>P<sub>i</sub></italic> for all the remaining packets in the queue. Furthermore, as in the right branch of <xref ref-type="fig" rid="f4-sensors-09-08083">Figure 4</xref>, when the MAC layer is ready to transmit a packet (Part <italic>2.1</italic> in <italic>PCC</italic>), we need to update <italic>P<sub>i</sub></italic> of this packet with the probability that the packet will survive in the MAC/PHY link transmission from the node (Part <italic>2.2</italic> in <italic>PCC</italic>), and the packet is then send it to the next hop (Part <italic>2.3</italic> in <italic>PCC</italic>).</p>
<p>When a sensor node <italic>A</italic> generates a packet <italic>i</italic>, we initialize <italic>P<sub>i</sub></italic> = 1. Along the path from node <italic>A</italic> to the sink, all relaying nodes including <italic>A</italic> updates <italic>P<sub>i</sub></italic> based on the packet dropping probability in network layer and link layer transmission error and loss in the MAC/PHY layer. The cumulative survival probability of a packet reaching any node in the network is used to determine the dropping probability of the packet in the node.</p>
<sec>
<title>Queue Handler</title>
<p>As we explained in Section 2.1., <italic>PCC</italic> supports two priority classes of packets, <italic>Event</italic> and <italic>Non-Event</italic> packets. In any node in the network, suppose that the total buffer size is <italic>Q</italic> and in the queue there are <italic>N<sub>E</sub> Event</italic> packets and <italic>N<sub>N</sub> Non-Event</italic> packets with the total number of packets <italic>N</italic> = <italic>N<sub>E</sub></italic> + <italic>N<sub>N</sub></italic>. We set up two thresholds, <italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic> as shown in <xref ref-type="fig" rid="f2-sensors-09-08083">Figure 2</xref>, for handling different kinds of packets and apply the following logic.</p>
<list list-type="order">
<list-item>
<p>0 ≤ <italic>N</italic> ≤ <italic>Q<sub>min</sub></italic>: buffer all incoming packets.</p></list-item>
<list-item>
<p><italic>Q<sub>min</sub></italic> &lt; <italic>N</italic> &lt; <italic>Q<sub>max</sub></italic>: begin dropping <italic>Non-Event</italic> packets while keeping all <italic>Event</italic> packets. The dropping rate is selected such that the average number of <italic>Non-Event</italic> packets <italic>N<sub>N</sub></italic>̄ = <italic>F<sub>N</sub></italic>(<italic>N</italic>).</p></list-item>
<list-item>
<p><italic>Q<sub>max</sub></italic> ≤ <italic>N</italic> ≤ <italic>Q</italic>: drop all <italic>Non-Event</italic> packets and begin to drop some <italic>Event</italic> packets. The dropping rate is selected such that the average number of <italic>Event</italic> packets <italic>N<sub>E</sub></italic>̄ = <italic>F<sub>E</sub></italic>(<italic>N</italic>).</p></list-item></list>
<p>Function <italic>F<sub>N</sub></italic>(<italic>N</italic>) and <italic>F<sub>E</sub></italic>(<italic>N</italic>) will be discussed later on.</p>
<p>As we discussed in Section 2.1., the coverage fidelity and high <italic>Event</italic> packet throughput are important objectives. Therefore, we cannot randomly select packets in the queue to drop. In order to achieve coverage fidelity we need to give fair chance to all packets from different sensor nodes in the network to reach the sink. In other words, assuming that the accepting probability of a packet <italic>i</italic> is <italic>k<sub>i</sub></italic> (i.e., (1 − <italic>k<sub>i</sub></italic>) is the dropping probability), we would like to ensure that ∀<italic><sub>i</sub></italic>, <italic>j</italic>, <italic>P<sub>i</sub></italic> × <italic>k<sub>i</sub></italic> = <italic>P<sub>j</sub></italic> × <italic>k<sub>j</sub></italic>. In this case, we can guarantee that packets from different nodes have the same or similar probability to reach the sink. Therefore, our scheme is to find <italic>K<sub>E</sub></italic> = [<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, …, <italic>k<sub>NE</sub></italic>] and <italic>K<sub>N</sub></italic> = [<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, …, <italic>k<sub>NN</sub></italic>] under the following constraints:
<disp-formula id="FD1">
<label>(1)</label>
<mml:math id="mm1" display="block">
<mml:semantics id="sm1">
<mml:mrow>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>E</mml:mi></mml:msub></mml:mrow></mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>F</mml:mi>
<mml:mi>E</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD2">
<label>(2)</label>
<mml:math id="mm2" display="block">
<mml:semantics id="sm2">
<mml:mrow>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>j</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub></mml:mrow></mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>F</mml:mi>
<mml:mi>N</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD3">
<label>(3)</label>
<mml:math id="mm3" display="block">
<mml:semantics id="sm3">
<mml:mrow>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>E</mml:mi></mml:msub>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD4">
<label>(4)</label>
<mml:math id="mm4" display="block">
<mml:semantics id="sm4">
<mml:mrow>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>However, solving the above problem can result in conflicts. For example, consider three (Event) packets with <italic>P</italic><sub>1</sub> = 0.1, <italic>P</italic><sub>2</sub> = 0.25 and <italic>P</italic><sub>3</sub> = 0.5, and <italic>F<sub>E</sub></italic>(3) = 2. Solving the above problem yields <italic>K<sub>E</sub></italic> = [1.25,0.5,0.25]. Note that <italic>k<sub>i</sub></italic> is the accepting probability within [0, 1], so <italic>k</italic><sub>1</sub> is not an acceptable probability measure. In other words, it is impossible to strictly guarantee the constraints (3) and (4). To resolve this, we borrow another popular fairness metric, <italic>Jain's Fairness Index</italic>([<xref ref-type="bibr" rid="b11-sensors-09-08083">11</xref>]) 
<inline-formula>
<mml:math id="mm5">
<mml:semantics id="sm5">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>n</mml:mi>
<mml:mo>∗</mml:mo>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:msubsup>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
<mml:mn>2</mml:mn></mml:msubsup></mml:mrow></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></inline-formula>, to give a relatively fair opportunity to packets. The optimization problem for both <italic>Event</italic> and <italic>Non-Event</italic> packets can be stated as follows
<disp-formula id="FD5">
<label>(5)</label>
<mml:math id="mm6" display="block">
<mml:semantics id="sm6">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mtext>maximize</mml:mtext></mml:mrow>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mi>K</mml:mi>
<mml:mo>}</mml:mo></mml:mrow></mml:msub>
<mml:mfrac>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>P</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula>such that
<disp-formula id="FD6">
<label>(6)</label>
<mml:math id="mm7" display="block">
<mml:semantics id="sm7">
<mml:mrow>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>P</mml:mi></mml:msub></mml:mrow></mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mo>=</mml:mo>
<mml:mi>F</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD7">
<label>(7)</label>
<mml:math id="mm8" display="block">
<mml:semantics id="sm8">
<mml:mrow>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>P</mml:mi></mml:msub>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>∈</mml:mo>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>K</italic> is the decision variable and <italic>K</italic>, <italic>N<sub>P</sub></italic>, <italic>F</italic>(<italic>N</italic>) could be either <italic>K<sub>E</sub></italic>, <italic>N<sub>E</sub></italic>, <italic>F<sub>E</sub></italic>(<italic>N</italic>) or <italic>K<sub>N</sub></italic>, <italic>N<sub>N</sub></italic>, <italic>F<sub>N</sub></italic>(<italic>N</italic>) corresponding to <italic>Event</italic> and <italic>Non-Event</italic> packets, respectively.</p>
<p>It is difficult to implement the quadratic optimization problem in <xref ref-type="disp-formula" rid="FD5">Equation (5)</xref> with limited resources in the sensor nodes. Therefore, a simpler algorithm is required. Note that our initial objectives are <xref ref-type="disp-formula" rid="FD3">Equations (3)</xref> and <xref ref-type="disp-formula" rid="FD4">(4)</xref>, so for both <italic>Event</italic> and <italic>Non-Event</italic> packets, the objective can be restated as
<disp-formula id="FD8">
<label>(8)</label>
<mml:math id="mm9" display="block">
<mml:semantics id="sm9">
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mn>2</mml:mn></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mn>2</mml:mn></mml:msub>
<mml:mo>=</mml:mo>
<mml:mo>…</mml:mo>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>P</mml:mi></mml:msub></mml:mrow></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>P</mml:mi></mml:msub></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:mi>c</mml:mi></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD9">
<label>(9)</label>
<mml:math id="mm10" display="block">
<mml:semantics id="sm10">
<mml:mrow>
<mml:mo>⇒</mml:mo>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD10">
<label>(10)</label>
<mml:math id="mm11" display="block">
<mml:semantics id="sm11">
<mml:mrow>
<mml:mo>⇒</mml:mo>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mi>i</mml:mi></mml:munder>
<mml:mrow>
<mml:mfrac>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>=</mml:mo>
<mml:mi>F</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo>∵</mml:mo>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mi>i</mml:mi></mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mi>F</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD11">
<label>(11)</label>
<mml:math id="mm12" display="block">
<mml:semantics id="sm12">
<mml:mrow>
<mml:mo>⇒</mml:mo>
<mml:mi>c</mml:mi>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mi>F</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mo>∑</mml:mo>
<mml:mi>i</mml:mi></mml:msub>
<mml:mrow>
<mml:mfrac>
<mml:mn>1</mml:mn>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mfrac></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD12">
<label>(12)</label>
<mml:math id="mm13" display="block">
<mml:semantics id="sm13">
<mml:mrow>
<mml:mo>⇒</mml:mo>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mi>F</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mo>∑</mml:mo>
<mml:mi>i</mml:mi></mml:msub>
<mml:mrow>
<mml:mfrac>
<mml:mn>1</mml:mn>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>In this solution, if <italic>k<sub>i</sub></italic> &gt; 1 as discussed above, packet <italic>i</italic> should be kept in the queue, and therefore <italic>k<sub>i</sub></italic> ⇐ 1. However, this change influences the accepting probabilities of other packets, which need corresponding updates given <italic>k<sub>i</sub></italic> = 1. The details of how this done is shown in Algorithm 1, which finds the solution for objective in <xref ref-type="disp-formula" rid="FD5">Equation (5)</xref>.</p>
<p>In Algorithm 1, there are two loops inside the <italic>while</italic> statement, each of which has a complexity of <italic>O</italic>(<italic>N</italic>). The worst case for each execution of the <italic>while</italic> loop is that we separate one <italic>P<sub>i</sub></italic> from <italic>P</italic>⃗ in each iteration with complexity <italic>O</italic>(<italic>N</italic>). Therefore, overall computation complexity of Algorithm 1 is <italic>N</italic> × (2<italic>N</italic>) = 2<italic>N</italic><sup>2</sup> which is <italic>O</italic>(<italic>N</italic><sup>2</sup>).</p>
<p>The solution of this optimization problem, <italic>K<sub>E</sub></italic> and <italic>K<sub>N</sub></italic>, gives the accepting probability of each packet in the queue. This can be used by the node to drop packets when the node is congested while maintaining coverage fidelity by giving each packet a fair chance to remain in the queue. After the selection and dropping process, the <italic>P<sub>i</sub></italic> of each packet <italic>i</italic> is updated to <italic>P<sub>i</sub></italic> = <italic>P<sub>i</sub></italic> × <italic>k<sub>i</sub></italic> for all remaining packets since they experience dropping one more time (Part <italic>1.3</italic> in <italic>PCC</italic>).</p>
<p><italic>F<sub>E</sub></italic>(<italic>N</italic>) and <italic>F<sub>N</sub></italic>(<italic>N</italic>) are accepting functions for <italic>Event</italic> and <italic>Non-Event</italic> packets, respectively. In a tail-dropping scheme, when a new packet arrives, the accepting function is (<italic>N</italic> + 1) − <italic>f<sub>drop</sub></italic>(<italic>N</italic>) where <italic>f<sub>drop</sub></italic>(<italic>N</italic>) is the dropping probability of the new packet given <italic>N</italic> packets in the queue. In our system, since the queue handler could drop any number of packets, <italic>PCC</italic> can implement different kinds of <italic>F<sub>E</sub></italic>(<italic>N</italic>) and <italic>F<sub>N</sub></italic>(<italic>N</italic>) functions. Note that the basic purpose of <italic>F<sub>E</sub></italic>(<italic>N</italic>) and <italic>F<sub>N</sub></italic>(<italic>N</italic>) is to reduce the congestion as a result the dropping probability monotonically increases with the number of packets in the queue. In general, <italic>F<sub>N</sub></italic>(<italic>N</italic>) can be a linear, convex, or concave function within [<italic>Q<sub>min</sub></italic>, <italic>Q<sub>max</sub></italic>] through two fixed points, (<italic>Q<sub>min</sub></italic>, <italic>N<sub>N</sub></italic>) and (<italic>Q<sub>max</sub></italic>, 0) as shown in the left part of <xref ref-type="fig" rid="f5-sensors-09-08083">Figure 5</xref>. Clearly, with the convex function, packets are dropped very aggressively resulting in lower buffer utilization, while the concave function is more conservative and will result in higher buffer utilization. The linear function is between the convex and concave functions.</p>
<array>
<tbody>
<tr>
<td colspan="2" align="left" valign="top"><bold>Algorithm 1</bold> Optimization Algorithm</td></tr>
<tr>
<td colspan="2" align="left" valign="top">Input: <italic>P</italic>⃗, <italic>F</italic>(<italic>N</italic>)</td></tr>
<tr>
<td colspan="2" align="left" valign="top">Output: <italic>K</italic></td></tr>
<tr>
<td align="left" valign="top">1:</td>
<td align="left" valign="top">Initial <italic>K</italic> ⇐ [0]</td></tr>
<tr>
<td align="left" valign="top">2:</td>
<td align="left" valign="top"><bold>while</bold> TRUE <bold>do</bold></td></tr>
<tr>
<td align="left" valign="top">3:</td>
<td align="left" valign="top"> <bold>for</bold> <italic>i</italic> = 1 to <italic>N<sub>P</sub></italic> <bold>do</bold></td></tr>
<tr>
<td align="left" valign="top">4:</td>
<td align="left" valign="top">
<mml:math id="mm14">
<mml:semantics id="sm14">
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mi>F</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mo>∑</mml:mo>
<mml:mi>i</mml:mi></mml:msub>
<mml:mrow>
<mml:mfrac>
<mml:mn>1</mml:mn>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="left" valign="top">5:</td>
<td align="left" valign="top"> <bold>end for</bold></td></tr>
<tr>
<td align="left" valign="top">6:</td>
<td align="left" valign="top"> <italic>counter</italic> ⇐ 0</td></tr>
<tr>
<td align="left" valign="top">7:</td>
<td align="left" valign="top"> <bold>for</bold> <italic>i</italic> = 1 to <italic>N<sub>P</sub></italic> <bold>do</bold></td></tr>
<tr>
<td align="left" valign="top">8:</td>
<td align="left" valign="top">  <bold>if</bold> <italic>k<sub>i</sub></italic> &gt; 1 <bold>then</bold></td></tr>
<tr>
<td align="left" valign="top">9:</td>
<td align="left" valign="top">   <italic>k<sub>i</sub></italic> ⇐ 1</td></tr>
<tr>
<td align="left" valign="top">10:</td>
<td align="left" valign="top">   <italic>counter</italic> ⇐ <italic>counter</italic> + 1</td></tr>
<tr>
<td align="left" valign="top">11:</td>
<td align="left" valign="top">   <italic>P</italic>⃗ ⇐ <italic>P</italic>⃗<italic>\P<sub>i</sub></italic></td></tr>
<tr>
<td align="left" valign="top">12:</td>
<td align="left" valign="top">  <bold>end if</bold></td></tr>
<tr>
<td align="left" valign="top">13:</td>
<td align="left" valign="top"> <bold>end for</bold></td></tr>
<tr>
<td align="left" valign="top">14:</td>
<td align="left" valign="top"> <bold>if</bold> <italic>counter</italic> = 0 <bold>then</bold></td></tr>
<tr>
<td align="left" valign="top">15:</td>
<td align="left" valign="top">  <bold>return</bold> <italic>K</italic>;</td></tr>
<tr>
<td align="left" valign="top">16:</td>
<td align="left" valign="top"> <bold>else</bold></td></tr>
<tr>
<td align="left" valign="top">17:</td>
<td align="left" valign="top">  <italic>F</italic>(<italic>N</italic>) ⇐ <italic>F</italic>(<italic>N</italic>) − <italic>counter</italic></td></tr>
<tr>
<td align="left" valign="top">18:</td>
<td align="left" valign="top"> <bold>end if</bold></td></tr>
<tr>
<td align="left" valign="top">19:</td>
<td align="left" valign="top"><bold>end while</bold></td></tr></tbody></array>
<p>When <italic>N</italic> &gt; <italic>Q<sub>max</sub></italic>, we begin dropping <italic>Event</italic> packets. Furthermore, since we drop all <italic>Non-Event</italic> packets, <italic>N</italic> = <italic>N<sub>E</sub></italic>, which means the buffer is occupied only by <italic>Event</italic> packets. Since the buffer utilization ratio should monotonically increase with congestion, it implies <italic>F<sub>E</sub></italic>(<italic>N</italic>) ≤ <italic>F<sub>E</sub></italic>(<italic>N</italic> + 1). Additionally, since the dropping probability also needs to monotonically increase with <italic>N</italic> to relieve congestion, we can conclude that when there are <italic>N<sub>E</sub></italic> &gt; <italic>Q<sub>max</sub></italic> packets with a new incoming packet, we have <italic>N</italic> ≤ <italic>F<sub>E</sub></italic>(<italic>N</italic>) ≤ (<italic>N</italic> + 1). Consequently, we have <italic>F<sub>E</sub></italic>(<italic>N</italic>) = <italic>N</italic> + 1 − <italic>d<sub>E</sub></italic>(<italic>N</italic>), where <italic>d<sub>E</sub></italic>(<italic>N</italic>) is a non-decreasing function with the value bounded between [0,1]. While the above scheme looks similar to a tail-dropping scheme, it is important to point out that our mechanism is different from tail-dropping since we may drop a packet from any position in the queue. The only similarity is that the average number of remaining packets <italic>F<sub>E</sub></italic>(<italic>N</italic>) is similar to that in the tail-dropping scheme. The curve <italic>d<sub>E</sub></italic>(<italic>N</italic>) is shown in <xref ref-type="fig" rid="f5-sensors-09-08083">Figure 5</xref>, and it can also be a convex, linear or concave function. The convex function is conservative, the concave function is aggressive, and the linear function is in between since <italic>d<sub>E</sub></italic>(<italic>N</italic>) is the minus term.</p></sec>
<sec>
<title>Link Quality Measurement</title>
<p>As we discussed in Section 2.1., collisions in MAC layer and link failures in PHY layer influence the probability that a packet is successfully received by the sink. Therefore, when the MAC layer is ready to send the packets in the queue, we also need to update <italic>P<sub>i</sub></italic> to record the link quality information. A number of parameters can provide the link quality information, such as the number of interfering neighbors and Signal-to-Interference-and-Noise Ratio (<italic>SINR</italic>). However, due to limited resources in a WSN, we prefer to find an efficient parameter which can also be easily obtained through link measurement. In our system, we choose the ratio of the number of successful transmissions (<italic>M<sub>S</sub></italic>) to the total number of transmission attempts (<italic>M<sub>T</sub></italic>) as the metrics to indicate link quality. First, <italic>M<sub>T</sub></italic> and <italic>M<sub>S</sub></italic> represent the influence from both collisions in the MAC layer and transmission failures in the PHY. Second, each node can easily maintain this information by counting the transmissions in the MAC layer.</p>
<p>Note that wireless link quality in a WSN is usually time-variant. Therefore, recent measurement results are more important than those that are older; the new measurements can more accurately represent the current link quality. In other words, if we time 0 to <italic>t</italic> to be slotted into small intervals, 
<inline-formula>
<mml:math id="mm15">
<mml:semantics id="sm15">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>S</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mn>2</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>T</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mn>2</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></inline-formula> is more valuable than 
<inline-formula>
<mml:math id="mm16">
<mml:semantics id="sm16">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>S</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>T</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></inline-formula> as long as 0 ≤ <italic>t</italic><sub>1</sub> ≤ <italic>t</italic><sub>2</sub> ≤ <italic>t</italic>. On the other hand, we also do not want the instantaneous perturbation of link quality to destroy the accuracy of estimation of <italic>P<sub>i</sub></italic>, so we cannot simply abandon the information from 
<inline-formula>
<mml:math id="mm17">
<mml:semantics id="sm17">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>S</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>T</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></inline-formula> Therefore, we follow the basic idea of machine learning [<xref ref-type="bibr" rid="b12-sensors-09-08083">12</xref>]. In each time interval <italic>t<sub>j</sub></italic>, we independently collect the statistic information of 
<inline-formula>
<mml:math id="mm18">
<mml:semantics id="sm18">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>S</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>T</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></inline-formula> and the link quality in time interval <italic>t<sub>j</sub></italic>, denoted by <italic>L</italic>(<italic>t<sub>j</sub></italic>) to be given by
<disp-formula id="FD13">
<label>(13)</label>
<mml:math id="mm19" display="block">
<mml:semantics id="sm19">
<mml:mrow>
<mml:mi>L</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:mi>α</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>×</mml:mo>
<mml:mi>L</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi>j</mml:mi>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>+</mml:mo>
<mml:mi>α</mml:mi>
<mml:mo>×</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>S</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>M</mml:mi>
<mml:mi>T</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Then in Part <italic>2.2</italic> we update <italic>P<sub>i</sub></italic> = <italic>P<sub>i</sub></italic> × <italic>L</italic>(<italic>t<sub>j</sub></italic>) where <italic>t<sub>j</sub></italic>, is the current time. The parameter <italic>α</italic> will depend on the wireless network is and its value may be decided by the network administrator. If the link changes quickly, for example, as in an underwater WSN, <italic>α</italic> will be set close to 1 so as to incorporate more recent information. On the contrary, if the link is stable, <italic>α</italic> should be smaller so as to accept more history information to avoid instantaneous variation of the link.</p></sec>
<sec sec-type="discussion">
<title>Discussions</title>
<p>As we described in this section, different components in <italic>PCC</italic> realize the design considerations in Section 2.1.. First, the separate thresholds for <italic>Event</italic> and <italic>Non-Event</italic> packets in queue handler guarantee the high throughput of <italic>Event</italic> packets during congestion. Second, the optimization algorithm in <xref ref-type="disp-formula" rid="FD5">Equations (5)</xref>, <xref ref-type="disp-formula" rid="FD6">(6)</xref> and <xref ref-type="disp-formula" rid="FD7">(7)</xref> provides coverage fidelity of the whole network. Third, the proposed new queue dropping schemes, and corresponding packet admission probabilities <italic>K<sub>E</sub></italic> and <italic>K<sub>N</sub></italic> implements flexible queue scheduler. Finally, updating <italic>P<sub>i</sub></italic> by the probability of network dropping and MAC/PHY link failure efficiently utilize the network resource.</p></sec></sec>
<sec>
<label>2.3.</label>
<title>Evaluation and Comparison</title>
<p>In this section, we evaluate <italic>PCC</italic> and compare its performance with other existing solutions. Compared with the dynamic queue scheduling in <italic>PCC</italic>, most queue schedulers, such as <italic>FIFO</italic> or <italic>RED</italic> [<xref ref-type="bibr" rid="b13-sensors-09-08083">13</xref>] use tail-dropping. Since it is not our focus to compare different existing queue schedulers, we only show comparison results with <italic>FIFO</italic>. Note that the conclusions in this section still apply to other queue schedulers.</p>
<p>In the following simulations, we use standard IEEE 802.11 protocol for the MAC and physical layer. Ad hoc On-Demand Distance Vector (AODV) [<xref ref-type="bibr" rid="b14-sensors-09-08083">14</xref>] is used as routing protocol in network layer and User Datagram Protocol (UDP) and Constant Bit Rate (CBR) are used in the transport and application layers, respectively. For the results presented in the following subsections, the X-axis represents the rate at which the <italic>Non-Event</italic> packets are generated. Sensors with events generate <italic>Event</italic> packets at a higher rate, which is 1.5 times the basic rate. Note that in our simulations, all the sensor nodes that detect the <italic>Event</italic> generate at the same rate. However, this is not a requirement of our scheme. We compare the performance based on different metrics, such as throughput, packet delay and fairness. We consider random topologies with 24 sensors and one sink, where 12 sensors are <italic>Event</italic> nodes and the others are <italic>Non-Event</italic> nodes. The following results are the average of 25 simulation runs.</p>
<sec>
<title>Throughput and Delay</title>
<p>The throughput and end-to-end delay are shown in <xref ref-type="fig" rid="f6-sensors-09-08083">Figure 6</xref> and <xref ref-type="fig" rid="f7-sensors-09-08083">Figure 7</xref>, respectively. In <xref ref-type="fig" rid="f6-sensors-09-08083">Figure 6</xref>, since <italic>FIFO</italic> does not distinguish <italic>Event</italic> and <italic>Non-Event</italic> packets, the capacities of “Event FIFO” and “Non-Event FIFO” are roughly proportional to the traffic generation rate. However, when the traffic generation rate exceeds the bound, which degrades the wireless link quality by introducing more collision and larger contention window in MAC protocol, the overall capacity of <italic>FIFO</italic> decreases. <italic>PCC</italic> provides <italic>Event</italic> packets higher priority. Therefore, the throughput of “Event PCC” keeps increasing until it reaches the whole system capacity. On the other hand, more <italic>Non-Event</italic> packets are dropped during congestion, and therefore the capacity of “Non-Event PCC” decreases with the increase of the basic packet generation rate. As we explained before, with the constraint of the system capacity, sinks are more interested in the <italic>Event</italic> packets, so the results are consistent with our design objective.</p>
<p>In <xref ref-type="fig" rid="f7-sensors-09-08083">Figure 7</xref>, it is obvious that the end-to-end delay of <italic>Event</italic> or <italic>Non-Event</italic> packets in <italic>FIFO</italic> almost remains the same. Since <italic>PCC</italic> preferentially accepts <italic>Event</italic> packets, <italic>Event</italic> packets experience longer queue delay on average. However, during congestion, only a few <italic>Non-Event</italic> packets reach the sink (most are dropped in the intermediate nodes) and they experience low queueing delay. Therefore, the average delay of <italic>Non-Event</italic> packets in <italic>PCC</italic> is comparably low.</p></sec>
<sec>
<title>Coverage Fidelity</title>
<p>The most important improvement of <italic>PCC</italic> is that it provides fairness to all sensor irrespective of their location, and therefore offers coverage fidelity of the whole WSN. In <xref ref-type="fig" rid="f8-sensors-09-08083">Figure 8</xref>, we count the number of packets from different sensors and derive the Jain's Fairness Index (<italic>JFI</italic>). From the results, it is clearly observed that the fairness of <italic>FIFO</italic> decreases with the increase in the basic packet generation rate when the network is heavily congested and only the sensors very close to the sink are able to forward their packets to the sink. However, the <italic>JFI</italic> of <italic>Event</italic> packets in <italic>PCC</italic> is much higher since sensors give packets equal probability to go to the next hop. Since <italic>PCC</italic> drops <italic>Non-Event</italic> packets during congestion, only a few <italic>Non-Event</italic> of the packets can reach the destination. Therefore, the <italic>JFI</italic> of <italic>Non-Event</italic> packets does not improve.</p>
<p>To explicitly compare the performance of <italic>PCC</italic>, we use a chain topology, which contains three sensors and one sink. Node 1 is closest to the sink; node 3 is farthest from the sink and node 2 is in the middle. The distance between the nodes are the same. All sensors are either <italic>Event</italic> or <italic>Non-Event</italic> nodes. We count the number of packets received by the sink from the three sensors, and results are shown in <xref ref-type="table" rid="t1-sensors-09-08083">Table 1</xref>. We found that in <italic>FIFO</italic>, packets from remote nodes have a lower probability to reach the sink while in <italic>PCC</italic>, the network provides an equal chance to packets from all sensors. The fairness of both <italic>Event</italic> and <italic>Non-Event</italic> packets improve significantly with <italic>PCC</italic>.</p></sec>
<sec>
<title><italic>F<sub>E</sub></italic>(<italic>N</italic>) and <italic>F<sub>N</sub></italic>(<italic>N</italic>)</title>
<p>All the above results are based on the linear function for both <italic>F<sub>E</sub></italic>(<italic>N</italic>) and <italic>F<sub>N</sub></italic>(<italic>N</italic>). In this section, we compare the influence of different functions (e.g., convex, concave, direct line) on the performance of <italic>PCC</italic>. Since we collected the results when the network is congested and every sensor kept transmitting packets to the next hop, the throughput of the three functions are almost the same. The results of end-to-end delay and fairness are shown in <xref ref-type="fig" rid="f9-sensors-09-08083">Figure 9</xref> and <xref ref-type="fig" rid="f10-sensors-09-08083">Figure 10</xref>. In <xref ref-type="fig" rid="f9-sensors-09-08083">Figure 9</xref>, the delay of the concave curves (Note that “concave” refers to <italic>F<sub>E</sub></italic>(<italic>N</italic>), not <italic>d<sub>E</sub></italic>(<italic>N</italic>)) is largest since this scheme conservatively kept more packets in the buffer than the other two schemes; therefore packets have longer queue delay. However, if we employ the convex function, which aggressively drop more packets, the packet delay decreases since the average queue length of all nodes is the smallest among the three schemes.</p>
<p>Since <italic>PCC</italic> can selectively drop any packets in the queue, the more packets there are in the buffer, the more options <italic>PCC</italic> has, which means <italic>PCC</italic> can provide better fairness performance and hence higher coverage fidelity. The analysis is validated in <xref ref-type="fig" rid="f10-sensors-09-08083">Figure 10</xref> which shows that the performance of the concave function is the best among three schemes and that of the convex function is the worst.</p></sec>
<sec>
<title><italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic></title>
<p><italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic> are important parameters in <italic>PCC</italic> since they are the thresholds in the queue scheduler to determine when <italic>Event</italic> and <italic>Non-Event</italic> packets will be dropped. Similar to previous discussion, higher values of <italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic> are related to higher buffer utilization, so the average packet delay is larger due to longer queueing delay. Therefore, in this section we only show the fairness results of <italic>Non-Event</italic> packets, which are influenced by both <italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic>. In <xref ref-type="fig" rid="f11-sensors-09-08083">Figure 11</xref>, Q<italic><sub>min</sub></italic> and <italic>Q<sub>max</sub></italic> are normalized by the total buffer length. We find that when <italic>Q<sub>min</sub></italic> is increased with fixed <italic>Q<sub>max</sub></italic>, more <italic>Non-Event</italic> packets remain in the buffer without being selected by the queue scheduler. Consequently, the fairness is determined more by the wireless link quality and the lower fairness is due to the randomness. When <italic>Q<sub>max</sub></italic> is increased with a fixed <italic>Q<sub>min</sub></italic>, more <italic>Non-Event</italic> packets have the opportunity to remain in the buffer and the queue scheduler can implement the optimization algorithm to selectively drop packets. Consequently, the fairness index is higher. However, note that the influence of <italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic> is not obvious, or in other words, <italic>PCC</italic> is not very sensitive to the choice of the thresholds.</p></sec></sec></sec>
<sec>
<label>3.</label>
<title>A Generalized Approach for Multiple Event Types</title>
<p>In general, sensor nodes may have multiple sensing devices to monitor multiple attributes of the physical environment in which they are deployed. Each of these sensing devices will generate its own <italic>Event</italic> and <italic>Non-Event</italic> packets. Consequently, simply distinguishing <italic>Event</italic> and <italic>Non-Event</italic> packets may not be enough when the WSN is in a congested state. Different sensed data will have different value to the sink and it is important to ensure that more of the valuable data is collected by the sink when the network is congested. In this section, we extend <italic>PCC</italic> by introducing a <italic>Pricing System</italic> which modifies the packet dropping policy based on different priorities of different <italic>Event</italic> packets to achieve a specified balance between the aggregate “value” of the collected data and coverage fidelity. The key features of the proposed <italic>Pricing System</italic> are the following:</p>
<list list-type="bullet">
<list-item>
<p>The sink acts as the information consumer and sets a price that it is willing to pay for each different types of <italic>Event</italic> packets. Higher prices indicates the sink prefers the sensor network to collect this corresponding category of <italic>Event</italic> packet at the cost of more transmission resource. The ratio of different prices determines the balance between the priority and coverage. If all prices are equal, the <italic>Pricing system</italic> degrades to <italic>PCC</italic>. If one of the prices is ∞, the sink is willing to only accept the corresponding category of <italic>Event</italic> packets and consequently the wireless sensor network would block all other types of <italic>Event</italic> packets.</p></list-item>
<list-item>
<p>The sensors operate as the information providers and when congested selectively drop packets according to the value that the sink places on the information in each packet (determined by the price set by the sink). When the buffer utilization is high, the sensor tends to keep packets with the lower accumulated survival probability <italic>P<sub>i</sub></italic> and higher price. The detailed algorithm is introduced in Section 3.1..</p></list-item>
<list-item>
<p>The prices can dynamically vary according to the changes in the physical environment and the network condition. When the sink modifies the prices, the new prices are broadcast to the entire network and each sensor node uses the new prices to adjust the dropping policy during congestion.</p></list-item></list>
<p>The <italic>Pricing System</italic> gives more flexibility to the network administrators. It is easy to add or delete a category of information by adding a new price or setting the price to zero, as long as the hardware can sense the corresponding type of information. Adjusting the ranking of different types of <italic>Event</italic> packets can also be done through changing the prices of the data collected by the sensors. In addition, the prices configured by the network administrators is able to accurately control the dropping probabilities, and thus control the ratio of received packets in the sink. Based on the structure of <italic>PCC</italic>, we describe the algorithm for the <italic>Pricing System</italic> in Section 3.1. and evaluate the performance improvement in Section 3.2..</p>
<sec>
<label>3.1.</label>
<title>Protocol and Algorithm</title>
<p>The structure of the <italic>Pricing System</italic> is almost the same as <italic>PCC</italic> described in Section 2.1.. However, in order to support multiple types, it is necessary to modify the communication protocol and the dropping strategy as described below.</p>
<sec>
<title>Task 1</title>
<p>In the <italic>Pricing System</italic>, the sink needs to broadcast the updated prices to all sensors in the network. This functionality could be implemented on multiple layers, such as application, network or MAC layers. In order to avoid additional burden to the network, the <italic>Pricing System</italic> broadcasts the prices through the <italic>ACKs</italic> of the MAC layer so as not to introduce a new protocol. In wireless networks, <italic>ACKs</italic> in the MAC layer is inevitable due to the <italic>CSMA/CA</italic> protocol as the sender needs the confirmation of the transmission from the receivers. In the proposed approach, the sink could update the prices and notify the nodes within one hop when it receives their data frames. Later those sensors receiving the new prices could propagate the information to their neighbors. This process will eventually ensure that all sensors are aware of the new prices. This process does take some time to propagate the updated information to the whole network. However, note that the MAC layer transmissions occur frequently even without any data communication. For example, most routing protocols need to detect whether the next hop is still alive, which triggers periodic transmissions between two neighbors at the MAC layer.</p>
<p>In order to support the above approach, it is also necessary to modify the format of <italic>ACK</italic> frame. Suppose there are totally <italic>M</italic> types of packets, <italic>M</italic> − 1 types of <italic>Event</italic> packets and one type of <italic>Non-Event</italic> packet. In the payload of an <italic>ACK</italic>, <italic>M</italic> variables (2 bytes for each) present the prices of all categories; and one variable presents the <italic>time stamp</italic>, with which the nodes can compare the newly received prices with the stored ones. Therefore, the possible price range is 2<sup>16</sup> ≈ 64<italic>K</italic>; and the length of the time stamp is 64<italic>K</italic>, which could be utilized circularly if necessary.</p></sec>
<sec>
<title>Task 2</title>
<p>Unlike <italic>PCC</italic>, <italic>Pricing System</italic> supports multiple <italic>Event</italic> types. Therefore, in the header of each packet, we augment an additional part with <italic>n</italic> = <italic>log</italic><sub>2</sub><italic>M</italic> bits to label the type of the packet. When a sensor generates a packet, it sets the header with the category so that all nodes along the path to the sink are able to process this packet according to the dropping strategy introduced below.</p>
<p>The overall structure of the algorithm is similar to <xref ref-type="fig" rid="f4-sensors-09-08083">Figure 4</xref>, except that we replace the Part <italic>2.1</italic> with the following new dropping strategy. To support the multiple categories of events, we introduce a new notation <italic>R<sub>i</sub></italic>, which is the <italic>price</italic> of packet <italic>i. R<sub>i</sub></italic> can be any one of the <italic>M</italic> prices, ranging from 1 to 64<italic>K</italic>. With the definition of <italic>R<sub>i</sub></italic>, the Part <italic>2.1</italic> becomes
<list list-type="order">
<list-item>
<p>0 ≤ <italic>N</italic> ≤ <italic>Q<sub>min</sub></italic>: Keep all packets since the utilization of the buffer is low.</p></list-item>
<list-item>
<p><italic>Q<sub>min</sub></italic> ≤ <italic>N</italic> ≤ <italic>Q<sub>max</sub></italic>: Keep all types of <italic>Event</italic> packets and begin to drop <italic>Non-Event</italic> packets according to the function <italic>F<sub>N</sub></italic>(<italic>N</italic>) shown in left part of <xref ref-type="fig" rid="f5-sensors-09-08083">Figure 5</xref>. The optimization problems becomes
<disp-formula id="FD14">
<label>(14)</label>
<mml:math id="mm20" display="block">
<mml:semantics id="sm20">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mtext>maximize</mml:mtext></mml:mrow>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:msub>
<mml:mover accent="true">
<mml:mi>K</mml:mi>
<mml:mo>→</mml:mo></mml:mover>
<mml:mi>N</mml:mi></mml:msub>
<mml:mo>}</mml:mo></mml:mrow></mml:msub>
<mml:mfrac>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub></mml:mrow></mml:msub>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mi>R</mml:mi></mml:mfrac></mml:mrow></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub></mml:mrow></mml:msub>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mi>R</mml:mi></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula>such that
<disp-formula id="FD15">
<label>(15)</label>
<mml:math id="mm21" display="block">
<mml:semantics id="sm21">
<mml:mrow>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub></mml:mrow></mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>F</mml:mi>
<mml:mi>N</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD16">
<label>(16)</label>
<mml:math id="mm22" display="block">
<mml:semantics id="sm22">
<mml:mrow>
<mml:mo>∀</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>∈</mml:mo>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>R</italic> is the price of <italic>Non-Event</italic> packets, and <italic>K</italic>⃗<italic><sub>N</sub></italic> = [<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, …, <italic>k<sub>NN</sub></italic>] is the accepting probability, which is the decision variable. In the optimization algorithm, we would like the ratio of different type of price to be equal to the ratio of the cumulative survival probability of different types of packets as much as possible. The ideal case is when the Jain's Fairness Index equals 1, which is achieved when <italic>R</italic><sub>1</sub> : <italic>R</italic><sub>2</sub> : … : <italic>R<sub>M</sub></italic> = <italic>P</italic><sub>1</sub><italic>k</italic><sub>1</sub> : <italic>P<sub>2</sub>k<sub>2</sub></italic> : … : <italic>P<sub>M</sub>k<sub>M</sub></italic>. In other words, we ensure that <italic>Event</italic> packets for which the sink is willing to pay a higher price has higher accumulated survival probability (<italic>P<sub>i</sub>k<sub>i</sub></italic>) and the ratio of the cumulative survival probability follows the ratio of the prices. If two classes of packets traverse through similar network conditions, the ratio of throughput of these two types of packets should be similar to the ratio of the prices. Note that network condition includes both network link quality and the probability of being dropped in a node along the path to the sink. If the prices of two classes of packets are the same, we would like the probability of packets received at the sink to be the same. If all the prices are equal, the optimization problem becomes the same as Section 2.. Since all <italic>Non-Event</italic> packets have the same price and we selectively drop <italic>Non-Event</italic> packets, <xref ref-type="disp-formula" rid="FD14">Equation 14</xref> becomes
<disp-formula id="FD17">
<label>(17)</label>
<mml:math id="mm23" display="block">
<mml:semantics id="sm23">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mtext>maximize</mml:mtext></mml:mrow>
<mml:mrow>
<mml:mo>}</mml:mo>
<mml:msub>
<mml:mover accent="true">
<mml:mi>K</mml:mi>
<mml:mo>→</mml:mo></mml:mover>
<mml:mi>N</mml:mi></mml:msub>
<mml:mo>{</mml:mo></mml:mrow></mml:msub>
<mml:mfrac>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>N</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Note that if <italic>R</italic> = 0, then <italic>k<sub>i</sub></italic> = 0.</p></list-item>
<list-item>
<p><italic>Q<sub>max</sub></italic> ≤ <italic>N</italic> ≤ <italic>Q</italic>: After dropping all <italic>Non-Event</italic> packets, begin dropping <italic>Event</italic> packets since the buffer is highly utilized. The dropping strategy follows the optimization problem given by,
<disp-formula id="FD18">
<label>(18)</label>
<mml:math id="mm24" display="block">
<mml:semantics id="sm24">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mtext>maximize</mml:mtext></mml:mrow>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:msub>
<mml:mover accent="true">
<mml:mi>K</mml:mi>
<mml:mo>→</mml:mo></mml:mover>
<mml:mi>E</mml:mi></mml:msub>
<mml:mo>}</mml:mo></mml:mrow></mml:msub>
<mml:mfrac>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>E</mml:mi></mml:msub></mml:mrow></mml:msub>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:mfrac></mml:mrow></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>E</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>E</mml:mi></mml:msub></mml:mrow></mml:msub>
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>P</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo>×</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mn>2</mml:mn></mml:msup></mml:mrow></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula>such that
<disp-formula id="FD19">
<label>(19)</label>
<mml:math id="mm25" display="block">
<mml:semantics id="sm25">
<mml:mrow>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>j</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>E</mml:mi></mml:msub></mml:mrow></mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>j</mml:mi></mml:msub></mml:mrow>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>F</mml:mi>
<mml:mi>E</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD20">
<label>(20)</label>
<mml:math id="mm26" display="block">
<mml:semantics id="sm26">
<mml:mrow>
<mml:mo>∀</mml:mo>
<mml:mi>j</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mi>N</mml:mi>
<mml:mi>E</mml:mi></mml:msub>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>j</mml:mi></mml:msub>
<mml:mo>∈</mml:mo>
<mml:mo stretchy="false">[</mml:mo>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>R<sub>j</sub></italic> is the price of packet <italic>j</italic>, and <italic>K</italic>⃗<italic><sub>E</sub></italic> = [<italic>k</italic><sub>1</sub>, <italic>k</italic><sub>2</sub>, …, <italic>k<sub>NE</sub></italic>] is the accepting probability, which is the decision variable. The meaning of the optimization is the same as explained in last paragraph. <italic>F<sub>E</sub></italic>(<italic>N</italic>) = <italic>N</italic> + 1 − <italic>d<sub>E</sub></italic>(<italic>N</italic>) and the <italic>d<sub>E</sub></italic>(<italic>N</italic>) function are shown in the right part of <xref ref-type="fig" rid="f5-sensors-09-08083">Figure 5</xref>. Note that, if <italic>R<sub>j</sub></italic> = 0, then <italic>k<sub>j</sub></italic> = 0.</p></list-item></list></p>
<p>The algorithm is similar to Algorithm 1. The only difference is to set <italic>P<sub>i</sub>/R<sub>j</sub></italic> instead of <italic>P<sub>i</sub></italic>. Furthermore, the computation complexity is the same as <italic>PCC</italic>, which is <italic>O</italic>(<italic>N</italic><sup>2</sup>).</p></sec></sec>
<sec>
<label>3.2.</label>
<title>Simulations</title>
<p>In this section, we compare the performance of our <italic>Pricing System</italic> with FIFO. Note that the results shown here also apply to other tail dropping active queue management algorithm such as RED. We consider total throughput, throughput per class, fairness and “value” as the performance metrics for the performance comparison. In a multihop wireless network, 
<inline-formula>
<mml:math id="mm27">
<mml:semantics id="sm27">
<mml:mrow>
<mml:msubsup>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>N</mml:mi></mml:msubsup>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula> indicates the capacity of network, where <italic>N</italic> is the number of packets successfully received at the destination node, and <italic>h<sub>i</sub></italic> is the number of hops traversed by packet <italic>i</italic> from source to destination. The implicit assumption is that all packets are equally important. In this study, we consider a WSN with several classes of packets with different priorities. We use price <italic>R<sub>i</sub></italic> in our <italic>Pricing System</italic> to indicate the relative priority of packet <italic>i</italic>. Based on this, we define the new metric “value” as 
<inline-formula>
<mml:math id="mm28">
<mml:semantics id="sm28">
<mml:mrow>
<mml:msubsup>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>=</mml:mo>
<mml:mn>1</mml:mn></mml:mrow>
<mml:mi>N</mml:mi></mml:msubsup>
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi></mml:msub>
<mml:mo>∗</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>, where <italic>R<sub>i</sub></italic> is the price of packet <italic>i</italic> and <italic>h<sub>i</sub></italic> is the number of hops traversed by packet <italic>i</italic> from source to destination. The higher the “value”, the more information is collected from the WSN.</p>
<p>We evaluate the correctness and performance of our algorithm using a chain topology and a random topology. The chain topology is used as a base case to analyze and validate the results. In the simulations, IEEE 802.11 is used at the MAC/PHY layer, AODV is used as the routing protocol in the network layer, UDP is set as the transport layer protocol and CBR traffic source is used in the application layer.</p>
<p>The chain scenario consists of five nodes in a linear topology with equal distance between nodes. Node 1 is the sink and all packets generated by node 5 pass through nodes 4, 3, 2 to reach node 1. Node 5 generate <italic>Non-Event</italic> packets and three types of <italic>Event</italic> packets with price 2, 4, and 8 units, respectively. In order to explicitly evaluate the performance of our algorithm, we set <italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic> to 0 so that our optimization algorithm is always active during the simulation. Results are shown in <xref ref-type="fig" rid="f12-sensors-09-08083">Figure 12</xref> to <xref ref-type="fig" rid="f15-sensors-09-08083">Figure 15</xref>. The x-axis in all the figures is packet generation rate which is set to be the same for all the four (<italic>Non-Event</italic> and three <italic>Event</italic>) types of packets.</p>
<p>From <xref ref-type="fig" rid="f12-sensors-09-08083">Figure 12</xref> we can see that for FIFO which does not differentiate the packets, the throughput of different <italic>Event</italic> packets and <italic>Non-Event</italic> packets are almost the same. For our <italic>Pricing System</italic>, type 3 <italic>Event</italic> packets have the highest throughput since they have the highest price; type 1 <italic>Event</italic> packets have the lowest throughput since they have one fourth of type 1 price and one half of type 2 price. No <italic>Non-Event</italic> packets are received by the sink since they are all dropped. We set <italic>Q<sub>max</sub></italic> equal to 0 as to explicitly test our optimization algorithm, therefore, all <italic>Non-Event</italic> packets are dropped. We also find that the throughput of the type 1 <italic>Event</italic> in the Pricing System is less than that of FIFO. Since the total throughput of the network is fixed, the increased throughput of type 3 decrease the throughput of type 1. The total throughput is shown in <xref ref-type="fig" rid="f13-sensors-09-08083">Figure 13</xref>.</p>
<p>From <xref ref-type="fig" rid="f13-sensors-09-08083">Figure 13</xref>, we can see that the throughput increases with packet generation rate until the network capacity is reached at which point it saturates. We can also see that the total throughput of FIFO and our <italic>Pricing System</italic> has the same trend. However, the total throughput of our Pricing System is lower than that of FIFO because both <italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic> are 0. Consequently, the queue utilization is lower. But the total throughput should be almost the same for FIFO and Pricing System, which can be seen from our random topology simulation where <italic>Q<sub>min</sub></italic> = 1/3 * <italic>QueueSize</italic> and <italic>Q<sub>max</sub></italic> = 2/3 * <italic>QueueSize</italic>.</p>
<p>To validate the design of our Pricing System, <xref ref-type="fig" rid="f14-sensors-09-08083">Figure 14</xref> shows the the average <italic>P<sub>i</sub></italic> values of the received packets at the sink. Note that the <italic>P<sub>i</sub></italic> value in the sink means the successful transmission probability of packet to the sink. When the packet generation rate is small and there is sufficient network capacity, the successful transmission probability is higher. When the packet generation rate is high and the network becomes congested, the probability of successful transmission becomes smaller. The most important validation here is that when the network is highly congested, the ratio of average <italic>P<sub>i</sub></italic> values is almost the same as the ratio of price. For example, when the packet generation rate is 272 kbps, <italic>P</italic><sub>1</sub> = 0.1253, <italic>P</italic><sub>2</sub> = 0.2686, and <italic>P</italic><sub>3</sub> = 0.5176, which is in the same ratio as the price for the different types of packets namely, 2 : 4 : 8.</p>
<p><xref ref-type="fig" rid="f15-sensors-09-08083">Figure 15</xref> plots the “value” as a function of the packet generation rate. We see that the “value” of Pricing System is much better than FIFO when network is congested. When the traffic generation rate is low, the “value” is smaller than FIFO due to the low utilization of the queue buffer. It is not the case when <italic>Q<sub>min</sub></italic> = 1/3 * <italic>QueueSize</italic> and <italic>Q<sub>max</sub></italic> = 2/3 * <italic>QueueSize</italic>, which will be shown in the random topology simulation.</p>
<p><xref ref-type="fig" rid="f16-sensors-09-08083">Figure 16</xref> to <xref ref-type="fig" rid="f19-sensors-09-08083">Figure 19</xref> show the simulation results for random topologies; the results are average of 25 simulation experiments which corresponds to 25 different random topologies. Each random topology contains 25 nodes, including a sink. Eight of the nodes send <italic>Non-Event</italic> packets and 3 types of <italic>Event</italic> packets with the price 2 : 4 : 8. Other nodes do not generate packets but forward packets to the sink. The X-axis in the figures is the packet generation rate which is the same for each of the different types. In these simulations, we set <italic>Q<sub>min</sub></italic> = 1/3 * <italic>QueueSize</italic> and <italic>Q<sub>max</sub></italic> = 2/3 * <italic>QueueSize</italic> and the dropping functions are linear functions shown in <xref ref-type="fig" rid="f5-sensors-09-08083">Figure 5</xref>.</p>
<p><xref ref-type="fig" rid="f16-sensors-09-08083">Figure 16</xref> shows the throughput of different types of packets using FIFO and our <italic>Pricing System</italic>. First, the throughput of different types packets using FIFO are almost the same, since FIFO does not differentiate different type of packets. Second, when the network is not or lightly congested, FIFO and Pricing System has the similar throughput. But the throughput of <italic>Non-Event</italic> packets using <italic>Pricing System</italic> is smaller than that using FIFO, because the <italic>Pricing System</italic> begins to selectively drop some <italic>Non-Event</italic> packets so as to avoid congestion. Third, when network is highly congested, the throughput of type 3 and type 2 packets using Pricing System are much higher than those using FIFO. The <italic>Pricing System</italic> is able to guarantee higher probability of successful transmission of packets with higher priority when network is congested. Furthermore, the ratio of successful transmission of packets is consistent with the ratio of price decided by the network operator.</p>
<p><xref ref-type="fig" rid="f17-sensors-09-08083">Figure 17</xref> shows the total throughput of all types of packets using FIFO and our Pricing System. We can see that their throughputs are similar. In a wireless network, throughput increases as packet generation rate increasing. When the network is saturated, the total throughput decreases lightly because of the severe MAC layer contention. The FIFO line is more smooth since FIFO only drop packets when the buffer size is full. However, the pricing line has some randomness, since our <italic>Pricing System</italic> drop packet using the probability obtained from our optimization algorithm.</p>
<p>We show Jain's Fairness Index of different types of packets in <xref ref-type="fig" rid="f18-sensors-09-08083">Figure 18</xref>. Our optimization algorithm lets packets with the same price have the same probability of success to reach the sink. Our simulation results show that our <italic>Pricing System</italic> has higher fairness than FIFO. But the fairness of <italic>Non-Event</italic> packets using <italic>Pricing System</italic> has lower fairness than FIFO. This is because we drop all <italic>Non-Event</italic> packets when buffer size is bigger than <italic>Q<sub>max</sub></italic>.</p>
<p><xref ref-type="fig" rid="f19-sensors-09-08083">Figure 19</xref> shows the simulation results of our newly defined metric “value”. When network is not congested, the values of FIFO and <italic>Pricing System</italic> are almost the same. However, when the network is congested, the proposed <italic>Pricing System</italic> receives more packets with higher priority and has much higher value than FIFO.</p></sec></sec>
<sec>
<label>4.</label>
<title>Related Work</title>
<p>Prior works on congestion control mechanisms in WSNs are mainly embedded in the end-to-end controls, such as CODA [<xref ref-type="bibr" rid="b15-sensors-09-08083">15</xref>], ESRT [<xref ref-type="bibr" rid="b7-sensors-09-08083">7</xref>], STCP [<xref ref-type="bibr" rid="b16-sensors-09-08083">16</xref>], PORT [<xref ref-type="bibr" rid="b17-sensors-09-08083">17</xref>], SenTCP [<xref ref-type="bibr" rid="b18-sensors-09-08083">18</xref>] and [<xref ref-type="bibr" rid="b19-sensors-09-08083">19</xref>]. The underlying method in these papers is the use of end-to-end rate adjustment to fulfil congestion control. These protocols detect and prevent congestion by reducing the number of packet retransmissions and energy used. We briefly summarize the main contributions of these papers. Congestion Detection and Avoidance(CODA) is one of the early papers discussing congestion control in wireless sensor networks. CODA is a energy efficient scheme which comprises of three mechanisms: (1) receiver-based congestion detection, (2) open-loop hop-by-hop backpressure, and (3) closed-loop multi-source regulation. CODA is evaluated by two metrics proposed by the authors, namely, energy tax and fidelity penalty. Event-to-Sink Reliable Transport (ESRT) is based on the observation that sensor networks are event-based systems. ESRT protocol operation is determined by the network state in terms of congestion condition in the network and path reliability. Simulation analysis of ESRT shows that proposed transport protocol achieves desired reliability with minimum energy consumption. Sensor Transmission control Protocol (STCP) is a scalable and reliable transport layer protocol for sensor networks. STCP is central control protocol since most of the functionalities are implemented at the base station. Simulations show that STCP can increase network lifetime and achieve high reliability. Price-Oriented reliable Transport (PORT) protocol is proposed to obtain reliability and minimize energy consumption. Price refers to the communication cost between sources and the sink. PORT uses price information to achieve reliability. Minimization of energy consumption is achieved by two schemes, upstream information optimization of the sink and downstream optimal routing scheme locally implemented in sensor nodes. Simulations show the effectiveness of PORT for reducing energy consumption comparing to existing schemes. SenTCP is an open-loop hop-by-hop congestion control protocol for wireless sensor networks to improve system throughput, reduce packet dropping, and minimize energy consumption. The work in [<xref ref-type="bibr" rid="b19-sensors-09-08083">19</xref>] proposes a congestion control using the congestion degree calculated by the remaining buffer size and net flow.</p>
<p>Rate-Controlled Reliable Transport (RCRT) protocol proposed in [<xref ref-type="bibr" rid="b20-sensors-09-08083">20</xref>] ensures efficient and flexible rate control like previous protocols. However, RCRT has the improvement that combine reliable transmission and congestion control together. Congestion detection and rate adaptation functionality are performed by the sink. The author also evaluated RCRT on a 40-node wireless sensor network testbed and show that it achieves better performance compared with IFRC [<xref ref-type="bibr" rid="b8-sensors-09-08083">8</xref>].</p>
<p>The studies reported in [<xref ref-type="bibr" rid="b21-sensors-09-08083">21</xref>–<xref ref-type="bibr" rid="b24-sensors-09-08083">24</xref>] address the congestion problem using routing protocols. In [<xref ref-type="bibr" rid="b21-sensors-09-08083">21</xref>], congestion control is achieved by dividing the monitoring areas into several subareas and adjust the local and forwarding traffic based on the transmission parameter. In [<xref ref-type="bibr" rid="b22-sensors-09-08083">22</xref>], an interference-minimized multipath routing protocol is proposed for load balancing and a congestion control scheme to reduce the loading rate of the source. The main idea of [<xref ref-type="bibr" rid="b23-sensors-09-08083">23</xref>] is to find a less congested node to forward packets to when congestion occurs. In [<xref ref-type="bibr" rid="b24-sensors-09-08083">24</xref>] a routing protocol is proposed for congestion control in WSNs by selecting a route which use Network Allocation Vector (NAV)[<xref ref-type="bibr" rid="b25-sensors-09-08083">25</xref>] information to determine the channel status. Our optimization algorithm is orthogonal with these protocols since they work in different layers.</p>
<p>Other research based on priority fairness are [<xref ref-type="bibr" rid="b26-sensors-09-08083">26</xref>], IFRC [<xref ref-type="bibr" rid="b8-sensors-09-08083">8</xref>], Fusion [<xref ref-type="bibr" rid="b27-sensors-09-08083">27</xref>], and [<xref ref-type="bibr" rid="b28-sensors-09-08083">28</xref>–<xref ref-type="bibr" rid="b30-sensors-09-08083">30</xref>]. The study reported in [<xref ref-type="bibr" rid="b26-sensors-09-08083">26</xref>] gives a design of a distributed, scalable congestion elimination mechanism in the transport layer, which ensures fair delivery of packets to the sink when using either a probabilistic selection or a epoch-based proportional selection. Interference-Aware Fair Rate Control (IFRC) discusses a mechanism for each node to detect the contending flows locally and fairly by adapting its own transmission rate and using a congestion sharing mechanism. It can achieve MAC layer fairness, but not application layer fairness. Application layer fairness is more important to users. Fusion combines three mechanisms that span to different layers. They are hop-by-hop flow control, rate limiting source traffic, and a prioritized MAC protocol. Hop-by-hop flow control is used for congestion detection and mitigation. Rate limiting is used to prevent unfairness toward sources which are far from the sink. A prioritized MAC scheme is designed for congested nodes to have higher priority to access the channel as to quickly drain out their buffer. The works reported in [<xref ref-type="bibr" rid="b28-sensors-09-08083">28</xref>–<xref ref-type="bibr" rid="b30-sensors-09-08083">30</xref>] share a similar idea and use node priority index to reflect the importance of each node for priority-based congestion control. These papers neglect the details of MAC protocols and assume they provide even access opportunities for each node, which neglect the important characteristic of time-varying wireless links in WSNs. Finally, the priority index design is based on node priority, not priority of different classes of information.</p>
<p>To the best of our knowledge, there is only one paper that discusses congestion control for heterogeneous traffic [<xref ref-type="bibr" rid="b31-sensors-09-08083">31</xref>]. But the protocol did not consider the wireless link characteristic, fairness and coverage fidelity. Our scheme, however, can efficiently collect different categories of information based on their relative priorities and also consider the affect of wireless links to achieve fairness.</p></sec>
<sec sec-type="conclusion">
<label>5.</label>
<title>Conclusion</title>
<p>In this paper, we have proposed a new scheme <italic>PCC</italic> to address congestion problem in a WSN and then we extend <italic>PCC</italic> to efficiently collect multiple categories of information in an advanced WSN. In <italic>PCC</italic>, we assign different priorities to <italic>Event</italic> and <italic>Non-Event</italic> packets, which have different values in a WSN. We propose an optimization algorithm to provide fair opportunity to sensors irrespective of their locations. We present a novel queue scheduler, which can drop any packets in the queue, supplies much more flexibility to information collection during congestion. Finally, also carefully involve the factor of different wireless link qualities and utilize the statistic information to adjust the dropping decision. In <italic>PCC</italic>, sensors only need to collect local information about the queue in the network layer and link quality in MAC layer, which is scalable and practical for large WSNs. Our analysis and simulation show that <italic>PCC</italic> can achieve high <italic>Event</italic> throughput and much better fairness and hence higher coverage fidelity. We also discussed the influence of some of the parameters on <italic>PCC</italic>, such as admission function and two thresholds for <italic>Event</italic> and <italic>Non-Event</italic> packets.</p>
<p>In the <italic>Pricing System</italic>, we propose an optimization algorithm for the queue scheduler. The <italic>Pricing System</italic> is simple and efficient to distribute network resources to different <italic>Event</italic> packet according to the decision of the network operator. The <italic>Pricing System</italic> is carried out when the network is congested. Following the design, we can control congestion and fully utilize the WSN. Our simulations show that higher throughput can be achieved for packets with higher price, and fairness can be guaranteed within one category.</p></sec></body>
<back>
<ack>
<p>The authors would like to thank the reviewers for their detailed comments that have helped improve the quality of the paper. This research was funded in parts by NSF Grant 0551654, China National High Technology Plan grant 2007AA01Z225 and NSF China 60972044.</p></ack>
<ref-list>
<title>References and Notes</title>
<ref id="b1-sensors-09-08083"><label>1.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Paek</surname><given-names>J.</given-names></name><name><surname>Chintalapudi</surname><given-names>K.</given-names></name><name><surname>Govindan</surname><given-names>R.</given-names></name><name><surname>Caffrey</surname><given-names>J.</given-names></name><name><surname>Masri</surname><given-names>S.</given-names></name></person-group><article-title>A Wireless Sensor Network for Structural Health Monitoring: Performance and experience</article-title><conf-name>Proceedings of the 2nd IEEE Workshop on Embedded Networked Sensors</conf-name><conf-loc>Washington, DC, USA</conf-loc><year>2005</year></citation></ref>
<ref id="b2-sensors-09-08083"><label>2.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Rahimi</surname><given-names>M.</given-names></name><name><surname>Baer</surname><given-names>R.</given-names></name><name><surname>Warrior</surname><given-names>J.</given-names></name><name><surname>Estrin</surname><given-names>D.</given-names></name><name><surname>Srivastava</surname><given-names>M.B.</given-names></name></person-group><article-title>In Situ Image Sensing and Interpretation in Wireless Sensor Networks</article-title><conf-name>Proceedings of the 3rd ACM Conference on Embedded Networked Sensor Systems (SenSys)</conf-name><conf-loc>San Diego, CA, USA</conf-loc><year>2005</year></citation></ref>
<ref id="b3-sensors-09-08083"><label>3.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Qiu</surname><given-names>X.</given-names></name><name><surname>Ghosal</surname><given-names>D.</given-names></name><name><surname>Mukherjee</surname><given-names>B.</given-names></name><name><surname>Yick</surname><given-names>J.</given-names></name><name><surname>Li</surname><given-names>D.</given-names></name></person-group><article-title>Priority-Based Coverage-Aware Congestion Control for Multihop Sensor Networks</article-title><conf-name>Proceedings of the 28th International Conference on Distributed Computing Systems Workshops</conf-name><conf-loc>Beijing, China</conf-loc><year>2008</year></citation></ref>
<ref id="b4-sensors-09-08083"><label>4.</label><citation citation-type="web"><article-title>Wikipedia</article-title><comment><ext-link xlink:href="http://en.wikipedia.org/wiki/Motes" ext-link-type="uri">http://en.wikipedia.org/wiki/Motes</ext-link> (accessed in May, 2009)</comment></citation></ref>
<ref id="b5-sensors-09-08083"><label>5.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Dutta</surname><given-names>P.</given-names></name><name><surname>Taneja</surname><given-names>J.</given-names></name><name><surname>Jeong</surname><given-names>J.</given-names></name><name><surname>Jiang</surname><given-names>X.</given-names></name><name><surname>Culler</surname><given-names>D.</given-names></name></person-group><article-title>A Building Block Approach to Sensornet Systems</article-title><conf-name>Proceedings of the Sixth ACM Conference on Embedded Networked Sensor Systems (SenSys)</conf-name><conf-loc>Raleigh, NC, USA</conf-loc><year>2008</year></citation></ref>
<ref id="b6-sensors-09-08083"><label>6.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Cheng</surname><given-names>X.</given-names></name><name><surname>Mohapatra</surname><given-names>P.</given-names></name><name><surname>Lee</surname><given-names>S.</given-names></name><name><surname>Banerjee</surname><given-names>S.</given-names></name></person-group><article-title>Performance Evaluation of Video Streaming in Multihop Wireless Mesh Networks</article-title><conf-name>Proceedings of the 18th International Workshop on Network and Operating Systems Support for Digital Audio and Video, Braunschweig</conf-name><conf-loc>Braunschweig, Germany</conf-loc><year>2008</year></citation></ref>
<ref id="b7-sensors-09-08083"><label>7.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Sankarasubramaniam</surname><given-names>Y.</given-names></name><name><surname>Akan</surname><given-names>O.B.</given-names></name><name><surname>Akyilidiz</surname><given-names>I.F.</given-names></name></person-group><article-title>ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks</article-title><conf-name>Proceedings of the 4th ACM International Symposium on Mobile Ad hoc Networking &amp; Computing (MobiHoc)</conf-name><conf-loc>New York, NY, USA</conf-loc><year>2003</year></citation></ref>
<ref id="b8-sensors-09-08083"><label>8.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Rangwala</surname><given-names>S.</given-names></name><name><surname>Gummadi</surname><given-names>R.</given-names></name><name><surname>Govindan</surname><given-names>R.</given-names></name><name><surname>Psounis</surname><given-names>K.</given-names></name></person-group><article-title>Interference-Aware Fair Rate Control in Wireless Sensor Networks</article-title><conf-name>Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications</conf-name><conf-loc>Pisa, Italy</conf-loc><year>2006</year></citation></ref>
<ref id="b9-sensors-09-08083"><label>9.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Akyildiz</surname><given-names>I.F.</given-names></name><name><surname>Su</surname><given-names>W.</given-names></name><name><surname>Sankarasubramaniam</surname><given-names>Y.</given-names></name><name><surname>Cayirci</surname><given-names>E.</given-names></name></person-group><article-title>A Survey on Sensor Networks</article-title><source>IEEE Commun. Mag.</source><year>2002</year><volume>8</volume><fpage>142</fpage><lpage>114</lpage></citation></ref>
<ref id="b10-sensors-09-08083"><label>10.</label><citation citation-type="thesis"><person-group person-group-type="author"><name><surname>Yick</surname><given-names>J.</given-names></name></person-group><article-title>Advanced Services in Wireless Sensor Networks</article-title><source>Ph.D Thesis</source><publisher-name>University of California</publisher-name><publisher-loc>Davis, CA, USA</publisher-loc><year>2006</year></citation></ref>
<ref id="b11-sensors-09-08083"><label>11.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Jain</surname><given-names>R.</given-names></name></person-group><source>The Art of computer systems Performance Analysis</source><edition>1st ed.</edition><publisher-name>Wiley</publisher-name><publisher-loc>New York, NY, USA</publisher-loc><year>1991</year></citation></ref>
<ref id="b12-sensors-09-08083"><label>12.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Mitchell</surname><given-names>M.T.</given-names></name></person-group><source>Machine Learning</source><edition>1st ed.</edition><publisher-name>McGraw Hill</publisher-name><publisher-loc>New York, NY, USA</publisher-loc><year>1997</year></citation></ref>
<ref id="b13-sensors-09-08083"><label>13.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Floyd</surname><given-names>S.</given-names></name><name><surname>Jacobson</surname><given-names>V.</given-names></name></person-group><article-title>Random Early Detection Gateways for Congestion Avoidance</article-title><source>IEEE ACM Trans. Netw.</source><year>1993</year><volume>1</volume><fpage>397</fpage><lpage>413</lpage><pub-id pub-id-type="doi">10.1109/90.251892</pub-id></citation></ref>
<ref id="b14-sensors-09-08083"><label>14.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Perkins</surname><given-names>C.</given-names></name><name><surname>Royer</surname><given-names>E.</given-names></name></person-group><article-title>Ad-hoc On-Demand Distance Vector Routing</article-title><conf-name>Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications</conf-name><conf-loc>New Orleans, LA, USA</conf-loc><year>1999</year></citation></ref>
<ref id="b15-sensors-09-08083"><label>15.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Wan</surname><given-names>C.-Y.</given-names></name><name><surname>Eisenman</surname><given-names>S.B.</given-names></name><name><surname>Campbell</surname><given-names>A.T.</given-names></name></person-group><article-title>CODA: Congestion Detection and Avoidance in Sensor Networks</article-title><conf-name>Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys)</conf-name><conf-loc>Los Angeles, CA, USA</conf-loc><year>2003</year></citation></ref>
<ref id="b16-sensors-09-08083"><label>16.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Iyer</surname><given-names>Y.G.</given-names></name><name><surname>Gandham</surname><given-names>S.</given-names></name><name><surname>Venkatesan</surname><given-names>S.</given-names></name></person-group><article-title>STCP: A Generic Transport Layer Protocol for Wireless Sensor Networks</article-title><conf-name>Proceedings of 14th International Conference on Computer Communication and Networks (ICCCN)</conf-name><conf-loc>San Diego, USA</conf-loc><year>2005</year></citation></ref>
<ref id="b17-sensors-09-08083"><label>17.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Zhou</surname><given-names>Y.</given-names></name><name><surname>Lyu</surname><given-names>M.R.</given-names></name></person-group><article-title>PORT: A Price-Oriented Reliable Transport Protocol for Wireless Sensor Networks</article-title><conf-name>Proceedings of IEEE Symposium on Software Reliability Engineering (ISSRE)</conf-name><conf-loc>Chicago, IL, USA</conf-loc><year>2005</year></citation></ref>
<ref id="b18-sensors-09-08083"><label>18.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Wang</surname><given-names>C.</given-names></name><name><surname>Sohraby</surname><given-names>K.</given-names></name><name><surname>Li</surname><given-names>B.</given-names></name></person-group><article-title>SenTCP: A Hop-by-Hop Congestion Control Protocol for Wireless Sensor Networks</article-title><conf-name>Proceedings of IEEE INFOCOM</conf-name><conf-loc>Miami, FL, USA</conf-loc><year>2005</year></citation></ref>
<ref id="b19-sensors-09-08083"><label>19.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Sheu</surname><given-names>J.-P.</given-names></name><name><surname>Hu</surname><given-names>W.-K.</given-names></name></person-group><article-title>Hybrid Congestion Control Protocol in Wireless Sensor Networks</article-title><conf-name>Proceedings of IEEE Vehicular Technology Conference (VTC)</conf-name><conf-loc>Marina Bay, Singapore</conf-loc><year>2008</year></citation></ref>
<ref id="b20-sensors-09-08083"><label>20.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Paek</surname><given-names>J.</given-names></name><name><surname>Govindan</surname><given-names>R.</given-names></name></person-group><article-title>RCRT: Rate-Controlled Reliable Transport for Wireless Sensor Networks</article-title><conf-name>Proceedings of the 5th ACM Conference on Embedded Networked Sensor Systems (SenSys)</conf-name><conf-loc>Sydney, Australia</conf-loc><year>2007</year></citation></ref>
<ref id="b21-sensors-09-08083"><label>21.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Liu</surname><given-names>Y.</given-names></name><name><surname>Liu</surname><given-names>Y.</given-names></name><name><surname>Pu</surname><given-names>J.</given-names></name><name><surname>Xiong</surname><given-names>Z.</given-names></name></person-group><article-title>A Robust Routing Algorithm with Fair Congestion Control in Wireless Sensor Network</article-title><conf-name>Proceedings of 17th International Conference on Computer Communications and Networks (ICCCN)</conf-name><conf-loc>St. Thomas, U.S. Virgin Islands, USA</conf-loc><year>2008</year></citation></ref>
<ref id="b22-sensors-09-08083"><label>22.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Teo</surname><given-names>J.-Y.</given-names></name><name><surname>Ha</surname><given-names>Y.</given-names></name><name><surname>Tham</surname><given-names>C.-K.</given-names></name></person-group><article-title>Interference-Minimized Multipath Routing with Congestion Control in Wireless Sensor Network for High-Rate Streaming</article-title><source>IEEE Trans. Mobile Comput.</source><year>2008</year><volume>7</volume><fpage>1124</fpage><lpage>1137</lpage><pub-id pub-id-type="doi">10.1109/TMC.2008.24</pub-id></citation></ref>
<ref id="b23-sensors-09-08083"><label>23.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Chen</surname><given-names>J.</given-names></name><name><surname>Zhou</surname><given-names>M.</given-names></name><name><surname>Li</surname><given-names>D.</given-names></name><name><surname>Sun</surname><given-names>T.</given-names></name></person-group><article-title>A Priority Based Dynamic Adaptive Routing Protocol for Wireless Sensor Networks</article-title><conf-name>Proceedings the Workshop on Intelligent Networks and Intelligent Systems</conf-name><conf-loc>Beijing, China</conf-loc><year>2008</year></citation></ref>
<ref id="b24-sensors-09-08083"><label>24.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Hsu</surname><given-names>Y.-P.</given-names></name><name><surname>Feng</surname><given-names>K.-T.</given-names></name></person-group><article-title>Cross-layer Routing for Congestion Control in Wireless Sensor Networks</article-title><conf-name>Proceedings of 2008 IEEE Radio and Wireless Symposium</conf-name><conf-loc>Orlando, FL, USA</conf-loc><year>2008</year></citation></ref>
<ref id="b25-sensors-09-08083"><label>25.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Society</surname><given-names>I.C.</given-names></name></person-group><source>IEEE Standard 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.</source><publisher-name>IEEE</publisher-name><publisher-loc>Piscataway, NJ, USA</publisher-loc><year>1997</year></citation></ref>
<ref id="b26-sensors-09-08083"><label>26.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Ee</surname><given-names>C.T.</given-names></name><name><surname>Bajcsy</surname><given-names>R.</given-names></name></person-group><article-title>Congestion Control and Fairness for Many-to-One Routing in Sensor Networks</article-title><conf-name>Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems (SenSys)</conf-name><conf-loc>Baltimore, MD, USA</conf-loc><year>2004</year></citation></ref>
<ref id="b27-sensors-09-08083"><label>27.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Hull</surname><given-names>B.</given-names></name><name><surname>Jamieson</surname><given-names>K.</given-names></name><name><surname>Balakrishnan</surname><given-names>H.</given-names></name></person-group><article-title>Mitigating Congestion in Wireless Sensor Networks</article-title><conf-name>Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems (SenSys)</conf-name><conf-loc>Baltimore, MD, USA</conf-loc><year>2004</year></citation></ref>
<ref id="b28-sensors-09-08083"><label>28.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Wang</surname><given-names>C.</given-names></name><name><surname>Sohraby</surname><given-names>K.</given-names></name><name><surname>Lawrence</surname><given-names>V.</given-names></name><name><surname>Li</surname><given-names>B.</given-names></name><name><surname>Hu</surname><given-names>Y.</given-names></name></person-group><article-title>Priority-based Congestion Control in Wireless Sensor Networks</article-title><conf-name>Proceedings of IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing</conf-name><conf-loc>Washington, DC, USA</conf-loc><year>2006</year></citation></ref>
<ref id="b29-sensors-09-08083"><label>29.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Li</surname><given-names>Z.</given-names></name><name><surname>Liu</surname><given-names>P.X.</given-names></name></person-group><article-title>Priority-based Congestion Control in Multi-path and Multi-hop Wireless Sensor Networks</article-title><conf-name>Proceedings of IEEE Conference on Robotics and Biomimetics</conf-name><conf-loc>Sanya, China</conf-loc><year>2007</year></citation></ref>
<ref id="b30-sensors-09-08083"><label>30.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Yaghmaee</surname><given-names>M.H.</given-names></name><name><surname>Adjeroh</surname><given-names>D.</given-names></name></person-group><article-title>A New Priority based Congestion Control Protocol for Wireless Multimedia Sensor Networks</article-title><conf-name>Proceedings of International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM)</conf-name><conf-loc>Washington, DC, USA</conf-loc><year>2008</year></citation></ref>
<ref id="b31-sensors-09-08083"><label>31.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Monowar</surname><given-names>M.M.</given-names></name><name><surname>Rahman</surname><given-names>M.O.</given-names></name><name><surname>Hong</surname><given-names>C.S.</given-names></name></person-group><article-title>Multipath Congestion Control for Heterogeneous Traffic in Wireless Sensor Network</article-title><conf-name>Proceedings of 10th International Conference on Advanced Communication Technology (ICACT)</conf-name><conf-loc>Gangwon-Do, Korea</conf-loc><year>2008</year></citation></ref></ref-list>
<sec sec-type="display-objects">
<title>Figures and Table</title>
<fig id="f1-sensors-09-08083" position="float">
<label>Figure 1.</label>
<caption>
<p>Collection of multiple classes of information in a WSN.</p></caption>
<graphic xlink:href="sensors-09-08083f1.gif"/></fig>
<fig id="f2-sensors-09-08083" position="float">
<label>Figure 2.</label>
<caption>
<p>The overall system model.</p></caption>
<graphic xlink:href="sensors-09-08083f2.gif"/></fig>
<fig id="f3-sensors-09-08083" position="float">
<label>Figure 3.</label>
<caption>
<p>Queue scheduler that allows dropping intermediate packets.</p></caption>
<graphic xlink:href="sensors-09-08083f3.gif"/></fig>
<fig id="f4-sensors-09-08083" position="float">
<label>Figure 4.</label>
<caption>
<p>A block diagram illustrating the overall structure of <italic>PCC</italic>.</p></caption>
<graphic xlink:href="sensors-09-08083f4.gif"/></fig>
<fig id="f5-sensors-09-08083" position="float">
<label>Figure 5.</label>
<caption>
<p>Candidate <italic>F<sub>N</sub></italic>(<italic>N</italic>) and <italic>d<sub>E</sub></italic>(<italic>N</italic>) functions.</p></caption>
<graphic xlink:href="sensors-09-08083f5.gif"/></fig>
<fig id="f6-sensors-09-08083" position="float">
<label>Figure 6.</label>
<caption>
<p>System throughput.</p></caption>
<graphic xlink:href="sensors-09-08083f6.gif"/></fig>
<fig id="f7-sensors-09-08083" position="float">
<label>Figure 7.</label>
<caption>
<p>Avgerage end-to-end delay.</p></caption>
<graphic xlink:href="sensors-09-08083f7.gif"/></fig>
<fig id="f8-sensors-09-08083" position="float">
<label>Figure 8.</label>
<caption>
<p>Jain's fairness of the different schemes.</p></caption>
<graphic xlink:href="sensors-09-08083f8.gif"/></fig>
<fig id="f9-sensors-09-08083" position="float">
<label>Figure 9.</label>
<caption>
<p>End-to-end delay for the three different functions for implementing <italic>F<sub>E</sub></italic>(<italic>N</italic>)</p></caption>
<graphic xlink:href="sensors-09-08083f9.gif"/></fig>
<fig id="f10-sensors-09-08083" position="float">
<label>Figure 10.</label>
<caption>
<p>Fairness for the three different functions for implementing <italic>F<sub>E</sub></italic>(<italic>N</italic>).</p></caption>
<graphic xlink:href="sensors-09-08083f10.gif"/></fig>
<fig id="f11-sensors-09-08083" position="float">
<label>Figure 11.</label>
<caption>
<p>Influence of <italic>Q<sub>min</sub></italic> and <italic>Q<sub>max</sub></italic>.</p></caption>
<graphic xlink:href="sensors-09-08083f11.gif"/></fig>
<fig id="f12-sensors-09-08083" position="float">
<label>Figure 12.</label>
<caption>
<p>Throughput of multiple types of packets for chain topology.</p></caption>
<graphic xlink:href="sensors-09-08083f12.gif"/></fig>
<fig id="f13-sensors-09-08083" position="float">
<label>Figure 13.</label>
<caption>
<p>Aggregate system throughput for chain topology.</p></caption>
<graphic xlink:href="sensors-09-08083f13.gif"/></fig>
<fig id="f14-sensors-09-08083" position="float">
<label>Figure 14.</label>
<caption>
<p>Pi values of different types of <italic>Event</italic> packets for chain topology.</p></caption>
<graphic xlink:href="sensors-09-08083f14.gif"/></fig>
<fig id="f15-sensors-09-08083" position="float">
<label>Figure 15.</label>
<caption>
<p>Comparison of value for chain topology.</p></caption>
<graphic xlink:href="sensors-09-08083f15.gif"/></fig>
<fig id="f16-sensors-09-08083" position="float">
<label>Figure 16.</label>
<caption>
<p>Throughput of different <italic>Event</italic> types for random topology.</p></caption>
<graphic xlink:href="sensors-09-08083f16.gif"/></fig>
<fig id="f17-sensors-09-08083" position="float">
<label>Figure 17.</label>
<caption>
<p>Aggregate system throughput for random topology.</p></caption>
<graphic xlink:href="sensors-09-08083f17.gif"/></fig>
<fig id="f18-sensors-09-08083" position="float">
<label>Figure 18.</label>
<caption>
<p>Fairness of different classes of <italic>Event</italic> packets for random topology.</p></caption>
<graphic xlink:href="sensors-09-08083f18.gif"/></fig>
<fig id="f19-sensors-09-08083" position="float">
<label>Figure 19.</label>
<caption>
<p>Comparison of value for random topology.</p></caption>
<graphic xlink:href="sensors-09-08083f19.gif"/></fig>
<table-wrap id="t1-sensors-09-08083" position="float">
<label>Table 1.</label>
<caption>
<p>Packets successfully received from different sensors in a chain topology.</p></caption>
<table frame="box" rules="all">
<thead>
<tr>
<th align="center" valign="top"/>
<th align="center" valign="top">Node 1</th>
<th align="center" valign="top">Node 2</th>
<th align="center" valign="top">Node 3</th>
<th align="center" valign="top">Jain's Fairness Index</th></tr></thead>
<tbody>
<tr>
<td align="center" valign="top"><italic>Event PCC</italic></td>
<td align="center" valign="top">139</td>
<td align="center" valign="top">130</td>
<td align="center" valign="top">135</td>
<td align="center" valign="top">0.99925</td></tr>
<tr>
<td align="center" valign="top"><italic>Event FIFO</italic></td>
<td align="center" valign="top">297</td>
<td align="center" valign="top">77</td>
<td align="center" valign="top">20</td>
<td align="center" valign="top">0.54735</td></tr>
<tr>
<td align="center" valign="top"><italic>Non-Event PCC</italic></td>
<td align="center" valign="top">149</td>
<td align="center" valign="top">125</td>
<td align="center" valign="top">124</td>
<td align="center" valign="top">0.99247</td></tr>
<tr>
<td align="center" valign="top"><italic>Non-Event FIFO</italic></td>
<td align="center" valign="top">292</td>
<td align="center" valign="top">60</td>
<td align="center" valign="top">23</td>
<td align="center" valign="top">0.52437</td></tr></tbody></table></table-wrap></sec></back></article>
