<?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/s91209666</article-id>
<article-id pub-id-type="publisher-id">sensors-09-09666</article-id>
<article-categories>
<subj-group>
<subject>Article</subject></subj-group></article-categories>
<title-group>
<article-title>Data Centric Sensor Stream Reduction for Real-Time Applications in Wireless Sensor Networks</article-title></title-group>
<contrib-group>
<contrib contrib-type="author">
<name><surname>Aquino</surname><given-names>Andre Luiz Lins</given-names></name><xref ref-type="aff" rid="af1-sensors-09-09666"><sup>1</sup></xref><xref ref-type="corresp" rid="c1-sensors-09-09666"><sup>*</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Nakamura</surname><given-names>Eduardo Freire</given-names></name><xref ref-type="aff" rid="af2-sensors-09-09666"><sup>2</sup></xref></contrib></contrib-group>
<aff id="af1-sensors-09-09666">
<label>1</label> Computer Science Department, Federal University of Ouro Preto, Ouro Preto, MG, Brazil</aff>
<aff id="af2-sensors-09-09666">
<label>2</label> FUCAPI - Analysis, Research and Technological Innovation Center, Manaus, AM, Brazil; E-Mail: <email>eduardo.nakamura@fucapi.br</email></aff>
<author-notes>
<corresp id="c1-sensors-09-09666">
<label>*</label>Author to whom correspondence should be addressed; E-Mail: <email>alla@iceb.ufop.br</email>; Tel: +55-3559-1692.</corresp></author-notes>
<pub-date pub-type="collection">
<year>2009</year></pub-date>
<pub-date pub-type="epub">
<day>2</day>
<month>12</month>
<year>2009</year></pub-date>
<volume>9</volume>
<issue>12</issue>
<fpage>9666</fpage>
<lpage>9688</lpage>
<history>
<date date-type="received">
<day>13</day>
<month>10</month>
<year>2009</year></date>
<date date-type="rev-recd">
<day>9</day>
<month>11</month>
<year>2009</year></date>
<date date-type="accepted">
<day>13</day>
<month>11</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>This work presents a data-centric strategy to meet deadlines in soft real-time applications in wireless sensor networks. This strategy considers three main aspects: (i) The design of real-time application to obtain the minimum deadlines; (ii) An analytic model to estimate the ideal sample size used by data-reduction algorithms; and (iii) Two data-centric stream-based sampling algorithms to perform data reduction whenever necessary. Simulation results show that our data-centric strategies meet deadlines without loosing data representativeness.</p></abstract>
<kwd-group>
<kwd>sensor-stream reduction algorithms</kwd>
<kwd>wireless sensor network</kwd>
<kwd>data-centric routing algorithm</kwd></kwd-group></article-meta></front>
<body>
<sec sec-type="intro">
<label>1.</label>
<title>Introduction</title>
<p>Despite their potential application, wireless sensor networks (WSNs) [<xref ref-type="bibr" rid="b1-sensors-09-09666">1</xref>-<xref ref-type="bibr" rid="b3-sensors-09-09666">3</xref>] have severe resource restrictions, such as low computational power, reduced bandwidth, and limited energy sources. Some applications are characterized by their emergency to deliver the data (real-time applications), <italic>i.e.</italic>, the data gathering has tight deadlines. Examples of these applications include: surveillance systems, biometric sensing, and intrusion detection. These applications have soft real-time characteristics, <italic>i.e.</italic>, environment is not controllable, applications usually use probabilistic models to process data, and communication does not have acknowledgment.</p>
<p>By considering the real-time applications in WSNs, we can identify some related work. In general, current contributions consider architectures and mathematical models for general applications [<xref ref-type="bibr" rid="b4-sensors-09-09666">4</xref>–<xref ref-type="bibr" rid="b6-sensors-09-09666">6</xref>]. Aquino <italic>et al.</italic> [<xref ref-type="bibr" rid="b7-sensors-09-09666">7</xref>] propose and evaluate a design strategy to determine minimum deadlines used by a specific stream reduction algorithm in general WSNs applications. However, routing and application-level solutions for specific real-time scenarios have been recently proposed [<xref ref-type="bibr" rid="b8-sensors-09-09666">8</xref>–<xref ref-type="bibr" rid="b10-sensors-09-09666">10</xref>].</p>
<p>In WSNs applications, physical variables, such as temperature and luminosity, can be monitored continuously along the network operation. The data set representing these physical variables can be referred to as <italic>data-stream</italic> [<xref ref-type="bibr" rid="b11-sensors-09-09666">11</xref>]—or <italic>sensor-stream</italic>, considering the WSNs context. As a consequence of this continuous monitoring, we might have high delays in such a way that real-time deadlines are not met. This motivation led us to propose a strategy to control the amount of data gathered by the network and its associated delay.</p>
<p>Before introducing our data-centric strategy, allow us to comment on data-stream related work. The data-stream contributions usually focus either in improving stream algorithms [<xref ref-type="bibr" rid="b12-sensors-09-09666">12</xref>–<xref ref-type="bibr" rid="b15-sensors-09-09666">15</xref>] or in applying the data-stream techniques to specific scenarios [<xref ref-type="bibr" rid="b16-sensors-09-09666">16</xref>–<xref ref-type="bibr" rid="b20-sensors-09-09666">20</xref>]. However, regarding data-stream solutions used in WSNs, we can identify a few researches that consider WSNs as distributed databases in which some functions (e.g., maximum, minimum and average) can be computed in a distributed fashion [<xref ref-type="bibr" rid="b21-sensors-09-09666">21</xref>–<xref ref-type="bibr" rid="b25-sensors-09-09666">25</xref>].</p>
<p>Considering real-time requirements and sensor-stream characteristics, we propose a data-centric strategy capable of reducing the data during data routing. In this case, the routing elements consider some application aspects, such as data type and deadline information. Our strategy considers: (1) a project design of real-time application to obtain the minimum deadlines; (2) an analytic model to estimate the ideal sample size used by the reduction algorithms; (3) and two stream-based sampling algorithms to perform data reduction when necessary during the routing task.</p>
<p>To validate our data-centric strategy, we use specific scenarios in which application deadlines cannot be met without data reduction. In our simulation, we use a naive tree routing based on shortest-path tree in a flat network. Application information is fed to relay nodes during build and rebuild tree phases. To identify the stream item delay, we consider that the clocks of the nodes are exactly synchronized. Thus, the time synchronization problem in WSNs [<xref ref-type="bibr" rid="b26-sensors-09-09666">26</xref>] is not considered here. However, data quality is evaluated to show the associated data reduction impact. Simulation results show that our data-centric strategies meet deadlines without loosing data representativeness.</p>
<p>Regarding data reduction strategies for WSNs, current researches use data fusion, aggregation, compression or correlation techniques [<xref ref-type="bibr" rid="b3-sensors-09-09666">3</xref>] to help save energy and reduce the packet delay [<xref ref-type="bibr" rid="b27-sensors-09-09666">27</xref>–<xref ref-type="bibr" rid="b29-sensors-09-09666">29</xref>]. The closer approach to sample stream reduction is the adaptive sampling, <italic>i.e.</italic>, the sampling strategy modifies following the phenomenons variations. The objective of this approach is to improve accuracy, identify correlation and eliminate redundancy [<xref ref-type="bibr" rid="b30-sensors-09-09666">30</xref>–<xref ref-type="bibr" rid="b32-sensors-09-09666">32</xref>]. However, there are some works that consider samples of different sources keeping the representativeness without overwriting the data, which can be applied to an uniform random or deterministic sample [<xref ref-type="bibr" rid="b16-sensors-09-09666">16</xref>, <xref ref-type="bibr" rid="b33-sensors-09-09666">33</xref>–<xref ref-type="bibr" rid="b35-sensors-09-09666">35</xref>]. It is important to highlight that our work considers the reduction of only one source, <italic>i.e.</italic>, our sampling is performed in each data set separately.</p>
<p>Our contribution can be highlighted through the analytical model, project design, different sample stream algorithm, and evaluation considering three more realistic real-time scenarios. The general contributions of our strategy are the following:
<list list-type="bullet">
<list-item>
<p><bold>Data-stream:</bold> In this work, we use sensor-stream algorithms as an in-network solution, and we improve the network performance by reducing the packet delay in real-time applications.</p></list-item>
<list-item>
<p><bold>Data reduction:</bold> Regarding data reduction, we show that we can meet real-time application deadlines when we use sensor-stream techniques during the routing task. This in-network approach represents a new contribution.</p></list-item>
<list-item>
<p><bold>Real-time:</bold> We present a analytical model to estimate the ideal amount of data-reduction, and we apply the stream-based solution in realistic real-time scenarios. To the best of our knowledge this is the first work that tries to quantify the reduction intensity based on real-time deadlines.</p></list-item></list></p>
<p>This work is organized as follows. Section 2. presents the data-centric real-time reduction problem. Section 3. shows how to design real-time sensor network applications by using stream-based data reduction. Section 4. discusses a formal formulation that is used to determine the ideal sample size. Section 5. describes the sampling stream reduction algorithms. Simulation results are presented in Section 6., and Section 7. presents our conclusions and outlook.</p></sec>
<sec>
<label>2.</label>
<title>Problem Statement</title>
<p>The problem we address in this work is the sensor-stream reduction algorithms as a data-centric mechanism to meet deadlines in real-time applications. We consider the data-stream sampling technique to perform data reduction [<xref ref-type="bibr" rid="b36-sensors-09-09666">36</xref>]. Since we use a sensor-stream algorithm for data reduction, the scope, and the problem itself can be defined as follows.</p>
<p>Let us consider a WSN monitoring physical or environmental conditions, such as temperature, sound, vibration, pressure, motion or pollutants, at different locations. Such a system is represented by the diagram [<xref ref-type="bibr" rid="b37-sensors-09-09666">37</xref>]:</p>
<p>
<graphic xlink:href="sensors-09-09666u1.gif"/></p>
<p>This diagram illustrates the following behavior:
<list list-type="bullet">
<list-item>
<p>The ideal behavior denoted by <italic>N</italic> → <bold>V</bold>* → <italic>D</italic>, where <italic>N</italic> denotes the environment and the process to be measured, <bold><italic>P</italic></bold> is the phenomenon of interest, with <bold>V*</bold> their space-temporal domain. If complete and uncorrupted observation was possible, we could devise a set of ideal rules <bold><italic>R*</italic></bold> leading to ideal decisions <bold><italic>D*</italic></bold>.</p></list-item>
<list-item>
<p>The sensed behavior is denoted by <italic>N</italic> <bold>→ V* → V →</bold> <italic>D</italic>. In this case, we have a set of <bold><italic>s</italic></bold> sensors <bold><italic>S=</italic>(<italic>S</italic></bold><italic><sub>l</sub></italic><bold>,<italic>…,S</italic></bold><italic><sub>s</sub></italic>), each one providing measurements of the phenomenon and producing a report in the domain <bold><italic>V</italic></bold><italic><sub>i</sub></italic>, with <bold>1 ≤ <italic>i ≤ s</italic></bold>; all possible domain sets are denoted <bold><italic>V=</italic>(<italic>V</italic></bold><italic><sub>U</sub></italic><bold><italic>…, V</italic></bold><italic><sub>s</sub></italic>). Using such information, we can conceive the set of rules <italic>R</italic> leading to the set of decisions <italic>D</italic>. We consider <bold>V</bold> to be a sensor-stream, due to its “time series” characteristics.</p></list-item>
<list-item>
<p>The reduced behavior is denoted by <italic>N</italic> <bold>→ V* → V → V →</bold> <italic>D</italic>′. Dealing with <bold>V</bold> may be too expensive in terms of, for instance, power, bandwidth, computer resources usage, and, specially, time delivery to meet the deadline requirements. Since the level of redundancy is not negligible in most situations, we can reduce this information volume. Sensor-stream reduction techniques are denoted by <bold>Ψ</bold>, and they transform the complete domain <bold>V</bold> into the smaller one <bold>V</bold>. New rules that use <bold>V</bold> are denoted by <italic>R′</italic>, and they lead to the set of decisions <italic>D</italic>′.</p></list-item></list></p>
<p>Based on these behaviors, the problem addressed in this work can be stated as follows:</p>
<sec>
<title>Problem definition</title>
<p><italic>Given a sensor-stream behavior, how can we use a data-centric data reduction algorithm (<bold>Ψ</bold>) to meet application deadlines? Moreover, what is the impact over the decisions <bold>D</bold>, when we use the <bold>Ψ</bold> reduction over <bold>V</bold> generated by <italic>S</italic>?</italic></p>
<p>To address the data-centric reduction problem in real-time applications, we consider the following assumptions:
<list list-type="bullet">
<list-item>
<p><bold>WSN topology:</bold> The set of sensors <bold><italic>S =</italic> (<italic>S</italic></bold><italic><sub>1</sub></italic><bold>,<italic>…, S</italic></bold><italic><sub>n</sub></italic>) is distributed in a squared area <bold><italic>A = L × L</italic></bold>. There is only one sink node located at (0, 0) on the left bottom corner. The density is kept constant and all nodes have the same hardware configuration.</p></list-item>
<list-item>
<p><bold>Routing protocol:</bold> The network communication is based on a multihop shortest-path tree [<xref ref-type="bibr" rid="b38-sensors-09-09666">38</xref>] as the routing protocol. To evaluate only the data-centric stream reduction performance, the tree is built just once before the traffic starts and the network is kept static. The build tree process is depict in <xref ref-type="fig" rid="f1-sensors-09-09666">Figure 1</xref>. First in (a), the sink node sends a flooding message requesting to build tree. After this, in (b), the nodes sets your father node considering the first message received in flooding process (it is considered that the first packet received represents the shortest path to sink). Finally, in (c), we have the complete tree mounted.</p></list-item>
<list-item>
<p><bold>Sensor-stream item: V</bold><italic><sub>i</sub></italic> values are generated by one specific sensor located at (<italic>L,L</italic>) on the right top corner (the opposite side of sink node), for convention we use <bold>V</bold> to represent the stream generated. For each stream, we process one stream item <bold>V = {V<sub>1</sub>,<italic>…</italic>, V</bold><italic><sub>n</sub></italic><bold>{</bold> where the amount of data stored before the data sent is <bold>| V| =</bold> <italic>N</italic>. The generation is continuous at regular intervals (periods) of time. We consider gaussian data (<italic>μ</italic> <bold>=</bold> 0.5 and <bold><italic>σ =</italic></bold> 0.1) sent in bursts.</p></list-item>
<list-item>
<p><bold>Quality of a sample:</bold> To assess the impact of data reduction on data quality, based on decision <italic>D</italic>, we consider two rules: <italic>R<sub>dst</sub></italic> and <italic>R<sub>val</sub></italic>. The rule <italic>R<sub>dst</sub></italic> aims at identifying whether <bold>V</bold> and <bold>V′</bold> data distributions are similar. To compute this distribution similarity (T), we use the Kolmogorov-Smirnov test [<xref ref-type="bibr" rid="b39-sensors-09-09666">39</xref>]. The rule <italic>R<sub>val</sub></italic> evaluates the discrepancy among the values in sampled streams, <italic>i.e.</italic>, if they still represent the original stream. To quantify this discrepancy (<bold>Φ</bold>), we compute the absolute value of the largest distance between the average value of the original data, and the lower or higher confidence interval values (95%) of the sampled data:
<disp-formula id="FD1">
<mml:math id="mm1" display="block">
<mml:semantics id="sm1">
<mml:mrow>
<mml:mo mathvariant="bold">Φ</mml:mo>
<mml:mo>=</mml:mo>
<mml:mo>max</mml:mo>
<mml:mo stretchy="false">{</mml:mo>
<mml:mo stretchy="false">|</mml:mo>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">low</mml:mi></mml:mrow></mml:msub>
<mml:mo>−</mml:mo>
<mml:mi>a</mml:mi>
<mml:mi>υ</mml:mi>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mi>g</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:mo>,</mml:mo>
<mml:mo stretchy="false">|</mml:mo>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">hig</mml:mi></mml:mrow></mml:msub>
<mml:mo>−</mml:mo>
<mml:mi>a</mml:mi>
<mml:mi>υ</mml:mi>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mi>g</mml:mi></mml:msub>
<mml:mo stretchy="false">|</mml:mo>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>in which the pair (<italic>v<sub>low</sub></italic>; <italic>v<sub>hig</sub></italic>) is the confidence interval for the sampled data and <italic>avg<sub>g</sub></italic> is the average (mean value) of original data [<xref ref-type="bibr" rid="b36-sensors-09-09666">36</xref>]. These rules help us to identify the scenarios where our sampling algorithm is better than simple random sampling strategy.</p></list-item></list></p>
<p>These assumptions are considered in the whole paper. For instance, the routing algorithm is shortest path tree, the stream item is the set V = {Vi,…, V<italic><sub>n</sub></italic>{, and so on. In the next three sections, we answer the questions addressed in <italic>Problem definition</italic> by presenting the reduction design in real-time applications, the analytic model that estimate the ideal sample size |<bold>V</bold>′|, and the data-centric reduction algorithms.</p></sec>
<sec sec-type="methods">
<label>3.</label>
<title>Data-Centric Reduction Design in Real-Time WSNs Applications</title>
<p>The first task of our data-centric strategy considers the design of real-time application. The objectives of this design are the: characterization of the stream flow while it passes by each sensor node; identification of the software components required by real-time applications by each sensor node; and identification of the required hardware resources by each sensor node. These aspects are illustrated in <xref ref-type="fig" rid="f2-sensors-09-09666">Figure 2</xref>, which shows the data-centric design in real-time WSNs applications, this design represents the sensor node view.</p>
<p>Basically, we have three steps to characterize the stream flow in each node: received data, data classification, and data processing. Considering the received data, <bold>V</bold> can be generated by the application or received from other nodes. In both cases, <bold>V</bold> is delivered to the routing layer. <italic>Application parameters</italic>, used to help the reduction phase, are also received whenever the routing tree is rebuilt. Once a sensor node receives <bold>V</bold>, we need to classify its type (classification step). In our case, the types considered are the <italic>sensing</italic> received from the application and the <italic>infrastructure</italic> received from other nodes. This classification is important because the routing layer behavior will be different for each one. When the node receives the <italic>application parameters</italic>, the <italic>real-time information</italic> database must be updated with new information. Such information include, for example, application deadlines, hops towards the sink, and time towards the sink. In the processing step, <italic>real-time requirements</italic> are verified. These requirements are used to decide the more suitable reduction strategy (<italic>stream solution choice</italic>), it is important highlight that this requirements are dynamically updated when the stream is received, <italic>i.e.</italic>, the relay node has only the local information. This occurs because the reduction may lead to different outputs with different “data qualities”. In our case, in this step, we determine <bold>| V′|</bold> according to the deadline requirements. The sample size determination and the reduction algorithm will be presented latter on. Finally, in the data out step, <bold>V</bold>, which may be reduced, is routed towards the sink.</p>
<p>In <xref ref-type="fig" rid="f2-sensors-09-09666">Figure 2</xref>, we can identify the software components required in real-time applications: a classification component to identify the type of <bold>|V|</bold>; an application-parameter component to process and store real-time application parameters; an oracle component to verify when the current stream item requires reduction; a stream size estimation component to compute <bold>|V′|</bold>, when necessary; a reduction component to perform the reduction; and a data out component to set the new parameters aggregated toV′.</p>
<p>Finally, the hardware resources necessary must be identified considering the <bold>|V|</bold> supported and the reduction algorithm complexity. <bold>|V|</bold> and <bold>|V′|</bold> are used to estimate the memory and bandwidth necessary to conceive the real-time WSN solution. In addition, the complexity of the reduction algorithm is important to determine the computational power necessary to apply the reduction strategy. These aspects are important to conceive a successful data-centric reduction for real-time applications.</p></sec>
<sec>
<label>4.</label>
<title>What Is the Ideal Sample Size?</title>
<p>The second task of our data-centric strategy considers the <bold>|V′|</bold> estimation. The objectives of this estimation is to allow relay nodes to perform the reduction in a data-centric way, <italic>i.e.</italic>, the routing layer uses application information to meet real-time requirements by applying <bold>Ψ</bold> to reduce <bold>|V|</bold>.</p>
<p>In the <italic>stream solution choice</italic> of processing step (<xref ref-type="fig" rid="f2-sensors-09-09666">Figure 2</xref>) we determine <bold>|V′|</bold> necessary to meet the deadline specified in <italic>real-time requirements</italic>. In this case, to determine <bold>|V′|</bold>, every sensor node has a maximum packet size (<bold><italic>ps</italic></bold>) permitted. In our case, we consider <bold><italic>p</italic></bold><italic><sub>s</sub></italic> <bold>=</bold> 20 items. However, every relay node knows its hop and time distances (considering only one packet) to the sink node, <italic>h<sub>dst</sub></italic> and <italic>t<sub>dst</sub></italic> respectively. This information is fed during the tree building phase, and stored in <italic>real-time information</italic> database.</p>
<p>In some cases, <bold>V</bold> needs to be fragmented in <bold>V =</bold> {<bold>V<sup>1</sup><italic>…</italic> V′</bold>{, where <italic>n<sub>f</sub></italic> is the number of fragments. All <bold>V</bold><italic><sup>j</sup></italic> (0 <italic>&lt; j ≤ n<sub>f</sub></italic>) encapsulate the application deadline (<italic>d<sub>a</sub></italic>), number of fragments (<italic>n<sub>f</sub></italic>), instant the fragment was generated (<italic>t<sub>gen</sub></italic>), and its number of hops (<italic>h<sub>src</sub></italic>). Thus, the relay node has all information about the stream item when it receives only one fragment.</p>
<p>Every relay node computes the new local deadline (<italic>d<sub>l</sub></italic>), as depicted at the following:</p>
<p>
<graphic xlink:href="sensors-09-09666u2.gif"/></p>
<p>This deadline accounts the route between the relay and the sink node, and it is defined as
<disp-formula id="FD2">
<mml:math id="mm2" display="block">
<mml:semantics id="sm2">
<mml:mrow>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>a</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula>where <italic>t<sub>src</sub></italic> is the estimated time to deliver <bold>V</bold><italic><sup>j</sup></italic> from the source node to the current relay node,
<disp-formula id="FD3">
<mml:math id="mm3" display="block">
<mml:semantics id="sm3">
<mml:mrow>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">now</mml:mi></mml:mrow></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">gen</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Let us consider <italic>t<sub>src</sub></italic> be the time of the V<sup>1</sup> to travel from source at relay node. Then, <bold>V</bold><sup>2</sup> will arrive in <italic>t<sub>src</sub>/h<sub>src</sub></italic> units of time (e.g., seconds), <italic>i.e.</italic>, estimated time for the last hop as depicted at the following:</p>
<p>
<graphic xlink:href="sensors-09-09666u3.gif"/></p>
<p>This consideration is necessary, because the information in the relay node is only about <italic>t<sub>src</sub></italic>, therefore, the complete stream cames from the last relay node rather than directly from source. Thus, the estimated time receive <bold>V</bold> is
<disp-formula id="FD4">
<label>(1)</label>
<mml:math id="mm4" display="block">
<mml:semantics id="sm4">
<mml:mrow>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">rec</mml:mi></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>n</mml:mi>
<mml:mi>f</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>/</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>In a similar way, let us consider <italic>t<sub>dst</sub></italic> the time of the <bold>V</bold><sup>1</sup> to travel from relay node at sink. Then, <bold>V</bold><sup>2</sup> will arrive in <italic>t<sub>dst</sub>/h<sub>dst</sub></italic> units of time (e.g., seconds), <italic>i.e.</italic>, estimated time for the last hop as depicted at the following:</p>
<p>
<graphic xlink:href="sensors-09-09666u4.gif"/></p>
<p>Thus, the estimated time to deliver <bold>V</bold> is
<disp-formula id="FD5">
<label>(2)</label>
<mml:math id="mm5" display="block">
<mml:semantics id="sm5">
<mml:mrow>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">del</mml:mi></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>n</mml:mi>
<mml:mi>f</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo>/</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>The first term of the sum is considered in <italic>t<sub>del</sub></italic> equation because <bold>V</bold><sup>1</sup> has not arrived yet. Remember that <italic>t<sub>dst</sub></italic> and <italic>h<sub>dst</sub></italic> are calculated when the tree is built. It is important highlighted that the transmissions between nodes in a WSN does not work like a pipeline. In our scenarios each sensor node has only one radio and it can either receive or send data, but not do both at the same time. So, the <italic>t<sub>rec</sub></italic> and <italic>t<sub>del</sub></italic> are estimated in each relay node separately.</p>
<p>Thus, |<bold>V</bold>′| is determined and used only if the <italic>gap &gt;</italic> 0, <italic>i.e.</italic>, there is time to deliver the complete stream or part of it. <italic>gap</italic> is defined as
<disp-formula id="FD6">
<label>(3)</label>
<mml:math id="mm6" display="block">
<mml:semantics id="sm6">
<mml:mrow>
<mml:mi mathvariant="italic">gap</mml:mi>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mi mathvariant="italic">delay</mml:mi></mml:mrow></mml:semantics></mml:math></disp-formula>where the stream <italic>delay</italic> at the sink node is
<disp-formula id="FD7">
<label>(4)</label>
<mml:math id="mm7" display="block">
<mml:semantics id="sm7">
<mml:mrow>
<mml:mi mathvariant="italic">dealy</mml:mi>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">rec</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">del</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>The delay can be depicted as the following:</p>
<p>
<graphic xlink:href="sensors-09-09666u5.gif"/></p>
<p>Thus, to compute |V′|, used to meet the application deadline, we consider the inequality
<disp-formula id="FD8">
<label>(5)</label>
<mml:math id="mm8" display="block">
<mml:semantics id="sm8">
<mml:mrow>
<mml:mi mathvariant="italic">gap</mml:mi>
<mml:mo>&gt;</mml:mo>
<mml:mn>0</mml:mn></mml:mrow></mml:semantics></mml:math></disp-formula>from (3) and (4) we have
<disp-formula id="FD9">
<mml:math id="mm9" display="block">
<mml:semantics id="sm9">
<mml:mrow>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mi mathvariant="italic">delay</mml:mi>
<mml:mo>&gt;</mml:mo>
<mml:mn>0</mml:mn></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD10">
<mml:math id="mm10" display="block">
<mml:semantics id="sm10">
<mml:mrow>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">rec</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">del</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>&gt;</mml:mo>
<mml:mn>0</mml:mn></mml:mrow></mml:semantics></mml:math></disp-formula>0 using (1) and (2) we have
<disp-formula id="FD11">
<mml:math id="mm11" display="block">
<mml:semantics id="sm11">
<mml:mrow>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>n</mml:mi>
<mml:mi>f</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>/</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>n</mml:mi>
<mml:mi>f</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo>/</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>&gt;</mml:mo>
<mml:mn>0</mml:mn></mml:mrow></mml:semantics></mml:math></disp-formula>so that
<disp-formula id="FD12">
<mml:math id="mm12" display="block">
<mml:semantics id="sm12">
<mml:mrow>
<mml:msub>
<mml:mi>n</mml:mi>
<mml:mi>f</mml:mi></mml:msub>
<mml:mo>&lt;</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula>considering that <italic>n<sub>f</sub> =</italic> ⌈|V<italic>′|/p<sub>s</sub></italic>⌉, we have
<disp-formula id="FD13">
<mml:math id="mm13" display="block">
<mml:semantics id="sm13">
<mml:mrow>
<mml:mo stretchy="false">|</mml:mo>
<mml:mrow>
<mml:mtext>V</mml:mtext>
<mml:mo>′</mml:mo>
<mml:mo stretchy="false">|</mml:mo>
<mml:mo>&lt;</mml:mo></mml:mrow>
<mml:msub>
<mml:mi>p</mml:mi>
<mml:mi>s</mml:mi></mml:msub>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></disp-formula>finally to reach the inequality we have
<disp-formula id="FD14">
<label>(6)</label>
<mml:math id="mm14" display="block">
<mml:semantics id="sm14">
<mml:mrow>
<mml:mo stretchy="false">|</mml:mo>
<mml:mrow>
<mml:mtext>V</mml:mtext>
<mml:mo>′</mml:mo>
<mml:mo stretchy="false">|</mml:mo>
<mml:mo>=</mml:mo></mml:mrow>
<mml:msub>
<mml:mi>p</mml:mi>
<mml:mi>s</mml:mi></mml:msub>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Meanwhile, considering the |<bold>V</bold>′| presented by Aquino <italic>et al.</italic> [<xref ref-type="bibr" rid="b40-sensors-09-09666">40</xref>], the sample size is estimated based on
<disp-formula id="FD15">
<label>(7)</label>
<mml:math id="mm15" display="block">
<mml:semantics id="sm15">
<mml:mrow>
<mml:mrow>
<mml:mo stretchy="false">|</mml:mo>
<mml:mtext>V</mml:mtext>
<mml:mo>′</mml:mo>
<mml:mo stretchy="false">|</mml:mo>
<mml:mo>=</mml:mo></mml:mrow>
<mml:msub>
<mml:mi>p</mml:mi>
<mml:mi>s</mml:mi></mml:msub>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>a</mml:mi></mml:msub>
<mml:mo>/</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>In order to identify both formulations, in simulation study (Section 6.), we will use the terms <italic>complex formulation</italic> and <italic>simplified formulation</italic> to represent <xref ref-type="disp-formula" rid="FD14">Equations 6</xref> and <xref ref-type="disp-formula" rid="FD15">7</xref>, respectively However, in both cases when the <italic>gap ≤</italic> 0 we consider |<bold>V′</bold>| = <italic>ps</italic> or the received is simple forwarded to preserve the data quality, because this <italic>gap</italic> means that the deadline was lost and the minor and more quickly data that can be delivered have to <italic>p<sub>s</sub></italic> size.</p></sec>
<sec>
<label>5.</label>
<title>Sensor-Stream Reduction</title>
<p>Finally, the third aspect of our data-centric strategy considers the sensor-stream reduction algorithm (<bold>Ψ</bold>). The objective of this reduction is to try to meet deadlines from real-time applications while keeping data fidelity (accuracy). The proposed sensor-stream reduction is motivated by the problem stated in Section 2. and evaluated in processing phase of project design described in Section 3.</p>
<p>The in-network (data-centric) reduction algorithm is integrated into a shortest-path routing tree. In this case, the routing tree is built, based on application requirements, from the sink (root) to the sources nodes by using a flooding strategy. In this flooding, <italic>h<sub>dst</sub></italic> and <italic>t<sub>dst</sub></italic> values are delivered to every sensor node. Once the routing tree is built, the source node can send <bold>V</bold> towards the sink. At this moment, relay nodes receive {V<sup>1</sup><italic>…</italic> V<italic><sup>nf</sup></italic>{ in some packets (fragments) and forward them to another relay node until the sink is reached.</p>
<p>In this forward process, when a relay node receives <bold>V</bold><sup>1</sup>, it checks the stream reduction criterion, in our case if <italic>gap &gt;</italic> 0 (<xref ref-type="disp-formula" rid="FD8">Equation 5</xref>). If the criterion is satisfied <bold>V</bold><sup>1</sup> is stored and the node waits to receive and store {<bold>V<sup>2</sup></bold><italic><sup>…</sup></italic> <bold>V</bold><italic><sup>nf</sup></italic>{. Otherwise, all fragments are forwarded. It is important highlighted that this forwarding is in routing layer, considering the sensor radio, certainly, the fragments are queued until the sender radio turns able. Based on the <italic>real-time information, |</italic><bold>V</bold>′| is computed through <xref ref-type="disp-formula" rid="FD14">Equation 6</xref>. When all fragments arrive, the <bold>Ψ</bold> reduction is enabled. This forwarding process is shown in Algorithm 1.</p>
<array>
<tbody>
<tr>
<td align="left" valign="top" colspan="2"><bold>Algorithm 1:</bold> Pseudo-code of reduction decision.</td></tr>
<tr>
<td align="left" valign="top"/>
<td colspan="2" align="left" valign="top"><bold>Data:</bold> V<italic><sup>j</sup></italic> – fragment stream received</td></tr>
<tr>
<td align="left" valign="top">1</td>
<td colspan="2" align="left" valign="top"><bold>begin</bold></td></tr>
<tr>
<td align="left" valign="top">2</td>
<td colspan="2" align="left" valign="top"> “Get from V<italic><sup>j</sup></italic> the fragments information”</td></tr>
<tr>
<td align="left" valign="top">3</td>
<td colspan="2" align="left" valign="top"> <bold>if</bold> <italic>j</italic> = 1 <bold>then</bold></td></tr>
<tr>
<td align="left" valign="top">4</td>
<td colspan="2" align="left" valign="top">  “<italic>gap</italic> is computed through <xref ref-type="disp-formula" rid="FD5">equations (2</xref>–<xref ref-type="disp-formula" rid="FD7">4)</xref>”</td></tr>
<tr>
<td align="left" valign="top">5</td>
<td colspan="2" align="left" valign="top">  <bold>if</bold> <italic>gap &gt;</italic> 0 <bold>then</bold></td></tr>
<tr>
<td align="left" valign="top">6</td>
<td colspan="2" align="left" valign="top">   “Enable <bold>V</bold> storage”</td></tr>
<tr>
<td align="left" valign="top"><sub>7</sub></td>
<td colspan="2" align="left" valign="top">   
<mml:math id="mm16">
<mml:semantics id="sm16">
<mml:mrow>
<mml:mo stretchy="false">|</mml:mo>
<mml:mrow>
<mml:mtext>V</mml:mtext>
<mml:mo>′</mml:mo>
<mml:mo stretchy="false">|</mml:mo>
<mml:mo>=</mml:mo></mml:mrow>
<mml:msub>
<mml:mi>p</mml:mi>
<mml:mi>s</mml:mi></mml:msub>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">src</mml:mi></mml:mrow></mml:msub>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">dst</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow>
<mml:mo>−</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">{</mml:mo>
<mml:mrow>
<mml:mtext>Equation</mml:mtext>
<mml:mspace width="0.2em"/>
<mml:mn>6</mml:mn>
<mml:mo stretchy="false">}</mml:mo></mml:mrow></mml:mrow></mml:semantics></mml:math></td></tr>
<tr>
<td align="left" valign="top">8</td>
<td align="left" valign="top">  <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">9</td>
<td align="left" valign="top"> <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">10</td>
<td align="left" valign="top"> <bold>if</bold> <italic>Storage is enabled</italic> <bold>then</bold></td></tr>
<tr>
<td align="left" valign="top">11</td>
<td align="left" valign="top">  “Store <bold>V</bold><italic><sup>j</sup></italic>”</td></tr>
<tr>
<td align="left" valign="top">12</td>
<td align="left" valign="top">  <bold>if</bold> <italic>j</italic> = <italic>n<sub>f</sub></italic> then</td></tr>
<tr>
<td align="left" valign="top">13</td>
<td align="left" valign="top">   <bold>V</bold> <italic>←</italic> “Compute <bold>Ψ</bold> on <bold>V</bold> with | <bold>V′</bold>| size”</td></tr>
<tr>
<td align="left" valign="top">14</td>
<td align="left" valign="top">   “Send<bold>V</bold>”</td></tr>
<tr>
<td align="left" valign="top">15</td>
<td align="left" valign="top">  <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">16</td>
<td align="left" valign="top"> <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">17</td>
<td align="left" valign="top"> <bold>else</bold></td></tr>
<tr>
<td align="left" valign="top">18</td>
<td align="left" valign="top">  “Forward <bold>V</bold><italic><sup>j</sup></italic>”</td></tr>
<tr>
<td align="left" valign="top">19</td>
<td align="left" valign="top"> <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">20</td>
<td align="left" valign="top"><bold>end</bold></td></tr></tbody></array>
<p>When the reduction is able, a histogram of <bold>V</bold> is built (line 13 of Algorithm 1). We consider a simple histogram, all elements sensed are between [0; 1] and we have 10 equals histogram classes. To obtain such a sample, we choose the central elements of each histogram class, respecting the sample size | V′| and the class frequencies of the histogram. Thus, the resulting sample will be represented by the same histogram. Meanwhile, considering the sensor-stream reduction algorithm presented by Aquino <italic>et al</italic> [<xref ref-type="bibr" rid="b40-sensors-09-09666">40</xref>], the sample elements are randomly chosen in each histogram class instead of considering the central elements. The reduction algorithms, used here, and their operations are depicted in <xref ref-type="fig" rid="f3-sensors-09-09666">Figure 3</xref>. The random sampling (a), we have a “stream in <bold>V</bold>” with 100 elements, |<bold>V</bold>′| → 50% of <bold>V</bold> is randomly chosen (this choice is performed in each histogram class), and then a “stream out <bold>V</bold>′” is generated with | <bold>V</bold>′| = 50. The central sampling (b), we have again a “stream in <bold>V</bold>” with 100 elements, | <bold>V′</bold>| → 50% of <bold>V</bold> is choice considering the central histogram classes elements, and then a “stream out <bold>V</bold>′” is generated with |<bold>V</bold>′| = 50.</p>
<p>In order to identify both algorithms, in simulation study (Section 6.), we use <bold>Ψ</bold><sub>central</sub> and <bold>Ψ</bold><sub>random</sub> to represent the central and random elements choice, respectively. The <bold>Ψ</bold><sub>central</sub> sample reduction process is present in Algorithm 2.</p>
<p>Analyzing the Algorithm 2 we have:</p>
<sec>
<title>Line 2</title>
<p>Executes in <italic>O</italic>(|<bold>V</bold>| log |<bold>V</bold>|);</p></sec>
<sec>
<title>Lines 11-15</title>
<p>Define the inner loop that determines the number of elements at each histogram class of the resulting sample, considering <italic>H<sub>cn</sub></italic> as the number of histogram class and <italic>n'<sub>coli</sub></italic> as the columns in sampled histograms, where 0 <italic>&lt; i &lt; H<sub>cn</sub></italic>. The 
<inline-formula>
<mml:math id="mm17">
<mml:semantics id="sm17">
<mml:mrow>
<mml:msubsup>
<mml:mo>∑</mml:mo>
<mml:mi>i</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>H</mml:mi>
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mi>n</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:msubsup>
<mml:mrow>
<mml:msub>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mo>′</mml:mo></mml:msup>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mtext mathvariant="italic">col</mml:mtext></mml:mrow>
<mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:msup>
<mml:mi>V</mml:mi>
<mml:mo>′</mml:mo></mml:msup>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>, we have that this inner loop executes in <italic>O</italic>(|<bold>V</bold>′|) steps.</p></sec>
<sec>
<title>Lines 7-20</title>
<p>Define the outer loop in which the input data is read and the sample elements are chosen. Because the inner loop is executed only when condition in line 8 is satisfied, the overall complexity of the outer loop is <italic>O</italic>(|<bold>V</bold>|) + <italic>O</italic>(|<bold>V</bold>′|) = <italic>O</italic>(|<bold>V</bold>| + |<bold>V</bold>′|), since we have an interleaved execution. Let <italic>n<sub>col</sub></italic> be the columns in original histograms, where 0 <italic>&lt; i &lt; H<sub>cn</sub></italic>. Basically, before evaluating the condition of Line 8, <italic>n<sub>coli</sub></italic> is accounted and |<bold>V</bold><italic>|/H<sub>cn</sub></italic> interactions are executed. Whenever this condition is satisfied, <italic>n'<sub>coli.</sub></italic> is built and |V<italic>′|/H<sub>cn</sub></italic> interactions are executed (Lines 11-15). In order to build the complete histogram, we must cover all classes (<italic>H<sub>cn</sub></italic>), then we have <italic>H<sub>cn</sub></italic> (|V| + |V′|)<italic>/H<sub>cn</sub></italic>=|<bold>V</bold>| + |<bold>V</bold>′|.</p></sec>
<sec>
<title>Line 21</title>
<p>Re-sorts the sample in <italic>O</italic>(|<bold>V′</bold>| log |<bold>V′</bold>|).</p>
<p>Thus, the overall complexity is</p>
<p><italic>O</italic>(|<bold>V</bold>| log |<bold>V</bold>|) + <italic>O</italic>(|<bold>V</bold>| + |<bold>V</bold>′|) + <italic>O</italic>(|<bold>V</bold>′| log |<bold>V</bold>′|) = <italic>O</italic>(|<bold>V</bold>| log |<bold>V</bold>|)</p>
<p>since |<bold>V</bold>′<italic>| ≤ |</italic><bold>V</bold>|. The sorting step is necessary, because, in our case, to build the histogram, we need the elements to be sorted, so that we always get the correct elements of <bold>V′</bold>. The space complexity is <italic>O</italic>(|<bold>V</bold>| + |<bold>V</bold>′|) = <italic>O</italic>(|<bold>V</bold>|) because we store the original sensor-stream and the resulting sample. Since every source node sends its sample stream towards the sink, the communication complexity is <italic>O</italic>(| <bold>V</bold>′<italic>| D</italic>), where <italic>D</italic> is the largest route (in hops) in the network.</p>
<array>
<tbody>
<tr>
<td align="left" valign="top" colspan="2">Algorithm 2: Pseudo-code of <bold>Ψ</bold><sub>central</sub> sampling reduction.</td></tr>
<tr>
<td align="left" valign="top"/>
<td align="left" valign="top"><bold>Data:</bold> V – original sensor-stream</td></tr>
<tr>
<td align="left" valign="top"/>
<td align="left" valign="top"><bold>Data:</bold> |V′| - resulting sample size</td></tr>
<tr>
<td align="left" valign="top"/>
<td align="left" valign="top"><bold>Result:</bold> V - resulting sample set</td></tr>
<tr>
<td align="left" valign="top">1</td>
<td align="left" valign="top"><bold>begin</bold></td></tr>
<tr>
<td align="left" valign="top">2</td>
<td align="left" valign="top"> <italic>Sort</italic>(<bold>V</bold>)</td></tr>
<tr>
<td align="left" valign="top">3</td>
<td align="left" valign="top"> <italic>wid ←</italic> “Histogram's class width”</td></tr>
<tr>
<td align="left" valign="top">4</td>
<td align="left" valign="top"> <italic>fst←0</italic> {first index of histogram class}</td></tr>
<tr>
<td align="left" valign="top">5</td>
<td align="left" valign="top"> <italic>n<sub>col</sub> ←</italic> 0 {number of elements per columns in V}</td></tr>
<tr>
<td align="left" valign="top">6</td>
<td align="left" valign="top"> <italic>w←0</italic></td></tr>
<tr>
<td align="left" valign="top"><italic>7</italic></td>
<td align="left" valign="top"> <bold>for</bold> <italic>k←</italic>0 <italic>to|</italic><bold>V</bold>|-1do</td></tr>
<tr>
<td align="left" valign="top">8</td>
<td align="left" valign="top">  <bold>if V</bold>[k] <italic>&gt;</italic> <bold>V</bold> [<italic>fst</italic>]<italic>+wid or k = |</italic><bold>V</bold>|- 1 <bold>then</bold></td></tr>
<tr>
<td align="left" valign="top"><italic>9</italic></td>
<td align="left" valign="top">   <italic>n'<sub>col</sub></italic> ← ⌈n'<sub>col</sub> | <bold>V</bold>′<italic>|/|</italic><bold>V</bold>| ⌉{number of elements per columns in V′}</td></tr>
<tr>
<td align="left" valign="top">10</td>
<td align="left" valign="top">   <italic>index ←f st</italic>+⌈(<italic>n<sub>col</sub>-n'<sub>col</sub></italic>)<italic>/2</italic>⌉</td></tr>
<tr>
<td align="left" valign="top">11</td>
<td align="left" valign="top">   <bold>for</bold> <italic>l←</italic>0 <italic>to n'<sub>col</sub></italic> <bold>do</bold></td></tr>
<tr>
<td align="left" valign="top">12</td>
<td align="left" valign="top">    <bold>V</bold><italic>′</italic>[<italic>w</italic>] <italic>←</italic> <bold>V</bold>[<italic>index</italic>]</td></tr>
<tr>
<td align="left" valign="top">13</td>
<td align="left" valign="top">    <italic>w ← w</italic> + 1</td></tr>
<tr>
<td align="left" valign="top">14</td>
<td align="left" valign="top">    <italic>index ← nextIndex</italic></td></tr>
<tr>
<td align="left" valign="top">15</td>
<td align="left" valign="top">   <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">16</td>
<td align="left" valign="top">   <italic>n<sub>col</sub> ←</italic> 0</td></tr>
<tr>
<td align="left" valign="top">17</td>
<td align="left" valign="top">   <italic>fst ← k</italic></td></tr>
<tr>
<td align="left" valign="top">18</td>
<td align="left" valign="top">  <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">19</td>
<td align="left" valign="top">  <italic>n<sub>col</sub> ← n<sub>col</sub></italic> + 1</td></tr>
<tr>
<td align="left" valign="top">20</td>
<td align="left" valign="top"> <bold>end</bold></td></tr>
<tr>
<td align="left" valign="top">21</td>
<td align="left" valign="top"> <italic>Sort</italic>(<bold>V′</bold>) {according to the original order}</td></tr>
<tr>
<td align="left" valign="top">22</td>
<td align="left" valign="top"><bold>end</bold></td></tr></tbody></array></sec></sec>
<sec>
<label>6.</label>
<title>Simulation</title>
<p>This section presents the simulation study of our data-centric strategy in specific scenarios. We perform our evaluation by using the NS-2 (Network Simulator 2), version 2.33 <underline>(</underline><ext-link xlink:href="http://nsnam.isi.edu/nsnam/index.php/Main_Page" ext-link-type="uri">http://nsnam.isi.edu/nsnam/index.php/Main_Page</ext-link>). Each simulated scenario was executed with 33 random topologies. At the end, for each scenario we plot mean values with 95% (symmetric asymptotic) confidence intervals.</p>
<p>To identify assess the network behavior, we variate the number of nodes and the stream size (| <bold>V</bold>|). The evaluated parameters are the delay and error in data quality, specified by two statistical tests. The default parameters used in simulations are presented in <xref ref-type="table" rid="t1-sensors-09-09666">Table 1</xref>.</p>
<p>To evaluate the delay in real-time scenarios, it is important to determine the minimum deadline (<italic>d<sub>mm</sub></italic>) for each number of nodes and |<bold>V</bold>| being considered. To do this, we consider different network sizes (128, 256, 512, and 1024), the |<bold>V</bold>| = {256, 512,1024, 2048{, and only one data source generating <bold>V</bold>. In our case, the <italic>d<sub>min</sub></italic>values is determined by measuring the time between the first data packet sent by the source and the last packet received by the sink, <italic>i.e.</italic>, the time for <bold>V</bold> to be entirely received by the sink. <xref ref-type="fig" rid="f4-sensors-09-09666">Figure 4</xref> illustrates <italic>d<sub>min</sub></italic>values for all scenarios being considered.</p>
<p>It is important to highlight that if either application has a deadline smaller than the one shown in <xref ref-type="fig" rid="f4-sensors-09-09666">Figure 4</xref> or the network is not in perfect conditions, then all data cannot be transmitted unless some reduction is performed. However, despite all nodes (sources) know the real time requirements of the packets they generate, they cannot infer the necessary data reduction locally because the network has some global restriction not perceived for them.</p>
<p>In the problem scope defined in Section 2., we discuss the impact of the solutions regarding the data quality, which is considered as our decision <italic>D</italic>. To assess the impact of data reduction on data quality, based on decision <italic>D</italic>, we consider the rules <italic>R<sub>dst</sub></italic> and <italic>R<sub>val</sub></italic> defined before. These rules are represented by T and <bold>Φ</bold> errors, respectively.</p>
<p>It is possible to apply these rules, because we consider the reduction of only one source, <italic>i.e.</italic>, our sampling is performed in each data set separately. For example, considering a simple network of nodes connected as a tree as <italic>Sink-Node<sub>A</sub>-Node<sub>B</sub></italic>. After in network data reduction we give equal opportunity to the data points <italic>of Node<sub>A</sub></italic> and <italic>Node<sub>B</sub></italic> separately. So, clearly the data gathered in the sink will represent the original data of the network, where neither data nodes will be over-represented.</p>
<p>The deadlines for the real-time scenarios, that we consider, are 50% of the minimum deadlines with(out) concurrent traffic; minimum deadlines with delay caused by relay nodes in each packet transmitted with(out) concurrent traffic. These study are discussed in the next subsections. For all scenarios, we evaluate the simplified and complex formulations, both using <bold>Ψ</bold><sub>central</sub> or <bold>Ψ</bold><sub>random</sub>. We use a Monte Carlo simulation [<xref ref-type="bibr" rid="b41-sensors-09-09666">41</xref>] considering a complete mapping between the number of nodes and the stream size, only unusual results will be presented. However, the y-axis scale is not kept constant in all figures. The reason is that such a re-scale allow us to make better analysis.</p>
<sec>
<label>6.1.</label>
<title>Half of Deadlines without Concurrent Traffic</title>
<p>The first scenario considers half of minimum deadlines (<italic>d<sub>a</sub> = d<sub>min</sub>/2</italic>) without concurrent traffic in this case, the application cannot send <bold>V</bold> and meet <italic>d<sub>a</sub></italic>. In this case, <bold>V</bold> is reduced by using our data-centric strategy. In Monte Carlo simulation, we change the number of nodes (128, 256, 512, and 1024) and |<bold>V</bold>| (256, 512, 1024, and 2048). <xref ref-type="fig" rid="f5-sensors-09-09666">Figure 5</xref> shows the delay results varying the number of nodes with |<bold>V</bold>| = 2048.</p>
<p>In this case, the <italic>d<sub>a</sub></italic> cannot be met in many cases. However, without the our data-centric reduction strategy these delays would be even larger. When the number of nodes is 512 and 1024, the simplified formulation presents a smaller delay compared with the complex formulation, and the deadline is met.</p>
<p>The reason is that, in the simplified formulation, the reduction is harder and less data is forwarded. When the number of nodes is 1024, the simplified formulation delivers 19% of data, while the complex formulation delivers 25%. This indicates that, considering only the deadline achievement, the simplified formulation is more appropriate. However, the reduction ratio is greater.</p>
<p>Regarding the data error evaluation. <xref ref-type="fig" rid="f6-sensors-09-09666">Figures 6</xref> and <xref ref-type="fig" rid="f7-sensors-09-09666">7</xref> show the error evaluation for different numbers of nodes with |<bold>V</bold>| = 256. <xref ref-type="fig" rid="f6-sensors-09-09666">Figure 6</xref> shows that in all cases we have T <italic>≤</italic> 40%. <bold>Ψ</bold><sub>random</sub>, in both formulations, has a smaller ϒ-error because the random choice improves data dispersion, and the simplified formulation has a smaller ϒ-error.</p>
<p><xref ref-type="fig" rid="f7-sensors-09-09666">Figure 7</xref> shows that in all cases we have <bold>Φ</bold> ≈ 5%. Ψ<sub>central</sub>, in both formulation, has a smaller <bold>Φ</bold>-error because the central elements choice improves the average test. Again, the simplified formulation has a smaller <bold>Φ</bold>-error The error evaluation indicates that the simplified formulation is more appropriate in this specific scenario. Considering the evaluated algorithms, <bold>Ψ</bold><sub>random</sub> may be used when <italic>R<sub>dst</sub></italic> is the rule priority, otherwise, <bold>Ψ</bold><sub>central</sub> should be used.</p>
<p>The partial conclusion, considering this critical real-time scenarios, is that the simplified formulation is more appropriate, because the deadlines are usually met while keeping data representativeness. Considering the sampling algorithm, <bold>Ψ</bold><sub>random</sub> or <bold>Ψ</bold><sub>central</sub> can be used when data application decisions are related, <italic>R<sub>dst</sub></italic> or <italic>R<sub>val</sub></italic>, respectively.</p></sec>
<sec>
<label>6.2.</label>
<title>Delay Caused by Relay Nodes without Concurrent Traffic</title>
<p>The second scenario, considers <italic>d<sub>a</sub> = d<sub>min</sub></italic> and all relay nodes delaying the stream fragments (<bold>V</bold><sup>j</sup>)per <italic>d<sub>a</sub>/</italic>10000 or 0.01% of the <italic>d<sub>a</sub></italic>. In this scenario, the application cannot send <bold>V</bold>, because the relay nodes eventually can be executing another task, consequently, the deadline <italic>d<sub>a</sub></italic> cannot be met. We change the number of nodes (128, 256, 512, and 1024) and |<bold>V</bold>| (256, 512, 1024, and 2048). The objective of this scenarios is to identify the appropriate strategy when relay nodes have other high priority tasks.</p>
<p><xref ref-type="fig" rid="f8-sensors-09-09666">Figure 8</xref> shows the delay results when we change the number of nodes with | <bold>V</bold>| = 2048. In contrast to prior scenario, <italic>d<sub>a</sub></italic> is always met. The complex formulation, in a more realistic scenario, presents a better time usage, <italic>i.e.</italic>, the delay is closer to deadline values. This occurs because the <bold>Ψ</bold>-reduction estimation in sample case [<xref ref-type="disp-formula" rid="FD15">Equation 7</xref>] is related to <italic>d<sub>a</sub>, i.e.</italic>, if <italic>d<sub>a</sub> &gt; d<sub>min</sub></italic> reduction cannot be efficient, when we consider other delay aspects like concurrent traffic. Another important observation is that more data is received in the complex formulation strategy. When the number of nodes is 1024, nearly 20% of data are deliver, in the complex formulation, against 18%, in the simplified one. This fact indicates that, considering only the deadline achievement, the complex formulation is more appropriate to more realistic scenarios.</p>
<p><xref ref-type="fig" rid="f9-sensors-09-09666">Figures 9</xref> and <xref ref-type="fig" rid="f10-sensors-09-09666">10</xref> show the error evaluation when we vary the number of nodes and keep | V| = 256. Similar to previous scenario, the results (<xref ref-type="fig" rid="f9-sensors-09-09666">Figure 9</xref>) show that in all cases we have T ≤ 40%. <bold>Ψ</bold><sub>random</sub>, in both formulation, has a smaller ϒ-error, because the random choice improves data dispersion. However, the simplified formulation has a smaller ϒ-error. In <xref ref-type="fig" rid="f10-sensors-09-09666">Figure 10</xref>, we always have <bold>Φ</bold> ≈ 5%. Again, <bold>Ψ</bold><sub>central</sub>, in both formulation, has a smaller <bold>Φ</bold>-error ecause the central elements choice improves the average test. Although, the simplified formulation has a smaller <bold>Φ</bold>-error with 128, 256 and 512 nodes, the complex formulation presents a better performance for 1024 nodes.</p>
<p>Error evaluations suggest that the simplified formulation is more appropriate for small networks and the complex formulation is more scalable. In general, <bold>Ψ</bold><sub>random</sub> is preferable when the <italic>R<sub>dst</sub></italic> has higher priority compared to the <italic>R<sub>val</sub></italic>, otherwise, <bold>Ψ</bold><sub>central</sub> should be chosen. However, the complex formulation is more appropriate when we have large scale networks. The partial conclusion, considering more realistic real-time scenarios, is that the complex formulation is more appropriate, because the deadlines are met in all cases and the data representativeness is kept.</p></sec>
<sec>
<label>6.3.</label>
<title>Half of Deadlines with Concurrent Traffic</title>
<p>This scenario considers 50% of minimum deadlines (<italic>d<sub>a</sub></italic> = <italic>d<sub>min</sub>/</italic>2) with concurrent traffic. We use a 128-node network (we do not consider more nodes due to NS limitations), and vary the percentage of nodes generating data traffic (16%, 20%, 25%, and 33% of 128 nodes) and |V| (256, 512, 1024, and 2048). The objective of this scenario is to identify the best strategy in critical applications when the network traffic gradually increases.</p>
<p>In <xref ref-type="fig" rid="f11-sensors-09-09666">Figure 11</xref>, <italic>d<sub>a</sub></italic> is met only by complex formulation. The reason is that the Ψ-reduction, in complex formulation, is gradually performed during the data routing, and fewer data is delivered. Particularly, when the percentage of nodes generating data is 33%, nearly 6.5% of data is delivered by the complex formulation, while 10% is delivered by the simplified formulation. Thus, considering the deadline achievement, the complex formulation is more appropriate in this scenario.</p>
<p><xref ref-type="fig" rid="f12-sensors-09-09666">Figures 12</xref> and <xref ref-type="fig" rid="f13-sensors-09-09666">13</xref> show the error evaluation considering a 128-node network, varying the percentage of nodes that generate data traffic, and keeping |<bold>V</bold>| = 256. As we can see in <xref ref-type="fig" rid="f12-sensors-09-09666">Figure 12</xref>, results show that in all cases we have T ≤ 30%. In both formulations, <bold>Ψ</bold><sub>random</sub> has a smaller ϒ-error. However, in the complex formulation, <bold>Ψ</bold><sub>central</sub> presents a smaller ϒ-error when we have fewer data traffic (16% and 20%). The reason is that the complex formulation executes fewer consecutive <bold>Ψ</bold>-reductions. <xref ref-type="fig" rid="f13-sensors-09-09666">Figure 13</xref> shows that, in all cases, we have <bold>Φ</bold> ≈ 20%, note the increase in terror, compared to previous scenarios (<bold>Φ</bold> ≈ 5%). The reason is that in both formulations there more consecutive <bold>Ψ</bold>-reductions affecting data quality. Therefore, considering the confidence interval, both <bold>Ψ</bold>-reductions have the same behavior. Again, when the percentage of nodes generating data is high, the simplified formulation has a smaller <bold>Φ</bold>-error.</p>
<p>The data error evaluation suggests that the simplified formulation is slightly better than the complex one. However, the partial conclusion, considering this critical and realistic real-time scenario, is that the complex formulation is more appropriate, because deadlines are met and data representativeness is kept. Considering the sampling algorithms, the behavior is kept in both <bold>Ψ</bold>-reduction strategies.</p></sec>
<sec>
<label>6.4.</label>
<title>Delay Caused by Relay Nodes with Concurrent Traffic</title>
<p>The last scenario considers <italic>d<sub>a</sub></italic> = <italic>d<sub>min</sub></italic>, concurrent traffic, and all relay nodes delay the stream fragments at 0.01% of the <italic>d<sub>a</sub></italic>. Again, we use a 128-node network and vary the percentage of nodes generating traffic (16%, 20%, 25%, and 33% of 128 nodes) and |<bold>V</bold>| (256, 512, 1024, and 2048). The</p>
<p>objective of this scenario is to identify the best strategy when the relay nodes have extra tasks with high priority and the network has a traffic that gradually increases.</p>
<p><xref ref-type="fig" rid="f14-sensors-09-09666">Figure 14</xref> shows the delay results in a 128-node network varying the percentage of nodes generating traffic and |V| = 2048. The <italic>d<sub>a</sub></italic> is met in most cases. The complex formulation presents a more scalable behavior considering the percentage of nodes generating data. This occurs because the <bold>Ψ</bold>-reduction estimation [<xref ref-type="disp-formula" rid="FD15">Equation 7</xref>] is related to <italic>d<sub>a</sub></italic>, <italic>i.e.</italic>, if <italic>d<sub>a</sub> ≥ d<sub>min</sub></italic> the <bold>Ψ</bold>-reduction cannot be efficient, when we consider other delay aspects, like concurrent traffic.</p>
<p><xref ref-type="fig" rid="f15-sensors-09-09666">Figures 15</xref> and <xref ref-type="fig" rid="f16-sensors-09-09666">16</xref> show the error evaluations considering a network with 128-nodes, varying the percentage of nodes generating traffic and |<bold>V</bold>| = 256. Simplified and complex formulation are presented by using <bold>Ψ</bold><sub>central</sub> and <bold>Ψ</bold><sub>random</sub>. <xref ref-type="fig" rid="f15-sensors-09-09666">Figure 15</xref> shows that in all cases we have T <italic>≤</italic> 40%. The <bold>Ψ</bold>*<sub>central</sub>, in complex formulation, has a smaller ϒ-error. The reason is that the complex formulation performs the maximum Ψ-reduction sooner (<bold>*<sub>central</sub></bold> is executed once or twice). This result shows that because fewer successive <bold>*</bold>-reductions are performed, more representativeness is kept in the reduced data, <italic>i.e.</italic>, data degradation is mitigated.</p>
<p><xref ref-type="fig" rid="f16-sensors-09-09666">Figure 16</xref> shows that, in general, we have <bold>Φ</bold> <italic>≤</italic> 30%. The complex formulation with <bold>Ψ</bold><sub>central</sub> presents <bold>Φ</bold> <italic>≈</italic> 5%. The reason is that the <bold>Ψ</bold><sub>central</sub> has a smaller <bold>Φ</bold>-error because the central elements choice improves the average test and the complex formulation performs the maximum <bold>Ψ</bold>-reduction early.</p>
<p>The errors evaluation suggest that the complex formulation is more appropriate with the <bold>Ψ</bold><sub>central</sub> strategy. The partial conclusion, considering this scenario, is that the complex formulation is actually more appropriate, because the deadlines are met in all cases while keeping data representativeness. Considering the sampling algorithm, the <bold>Ψ</bold><sub>central</sub> strategy with complex formulation is always indicated.</p></sec></sec>
<sec sec-type="conclusions">
<label>7.</label>
<title>Conclusions</title>
<p>In real-time applications of wireless sensor networks, the time used to deliver sensor-streams from source to sink nodes is a major concern. The amount of data in transit through these constrained networks has a great impact on the delay. In this work, we presented a data-centric strategy to meet deadlines in soft real-time applications for wireless sensor networks. This work represents shows how to deal with time constraints at lower network levels in a data-centric way.</p>
<p>With our data-centric strategy we met application deadlines in several scenarios. In additional, we showed how to design real-time sensor-stream reduction applications and a analytical model used to found the ideal sample size. Results showed the efficiency of the strategy by reducing the delay without losing data representativeness. If the application is not strongly dependent on data accuracy, or the network operates in exception situation (e.g., few resources remaining or urgent situation detection), then data reduction algorithms are powerful tool for real-time applications for resource-constrained networks.</p>
<p>As future work, we intend to match the proposed application-level solution with lower-level ones, for example, by considering some real-time-enabled signal processing method. In this case, not only data from a source is reduced, but similar data from different sources is also reduced, resulting in a more efficient solution. Another future work is to use feedback information to enable the source nodes to perform the reduction sooner. However, we intend to improve the central sampling algorithm complexity to <italic>O</italic>(<italic>n</italic>), by considering some rank selection algorithms.</p></sec></sec></body>
<back>
<ack>
<p>This work is partially supported by the Brazilian National Council for Scientific and Technological Development (CNPq) under the grant numbers 477292/2008-9 and 474194/2007-8.</p></ack>
<ref-list>
<title>References</title>
<ref id="b1-sensors-09-09666"><label>1.</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>40</volume><fpage>102</fpage><lpage>114</lpage></citation></ref>
<ref id="b2-sensors-09-09666"><label>2.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Lins</surname><given-names>A.</given-names></name><name><surname>Nakamura</surname><given-names>E.F.</given-names></name><name><surname>Loureiro</surname><given-names>A.A.F.</given-names></name><name><surname>Coelho</surname><given-names>C.J.N.</given-names><suffix>Jr</suffix></name></person-group><source>BeanWatcher: A Tool to Generate Multimedia Monitoring Applications for Wireless Sensor Networks</source><person-group person-group-type="editor"><name><surname>Marshall</surname><given-names>A.</given-names></name><name><surname>Agoulmine</surname><given-names>N.</given-names></name></person-group><publisher-name>Springer</publisher-name><publisher-loc>Belfast, UK</publisher-loc><year>2003</year><fpage>128</fpage><lpage>141</lpage></citation></ref>
<ref id="b3-sensors-09-09666"><label>3.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Nakamura</surname><given-names>E.F.</given-names></name><name><surname>Loureiro</surname><given-names>A.A.F.</given-names></name><name><surname>Frery</surname><given-names>A.C.</given-names></name></person-group><article-title>Information Fusion for Wireless Sensor Networks: Methods, Models, and Classifications</article-title><source>ACM Comput. Surv.</source><year>2007</year><volume>39</volume><fpage>9/1</fpage><lpage>9/55</lpage></citation></ref>
<ref id="b4-sensors-09-09666"><label>4.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>He</surname><given-names>T.</given-names></name><name><surname>Stankovic</surname><given-names>J.A.</given-names></name><name><surname>Lu</surname><given-names>C.</given-names></name><name><surname>Abdelzaher</surname><given-names>T.</given-names></name></person-group><source>SPEED: A Stateless Protocol for Real-Time Communication in Sensor Networks</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Providence, RI, USA</publisher-loc><year>2003</year><fpage>46</fpage><lpage>55</lpage></citation></ref>
<ref id="b5-sensors-09-09666"><label>5.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Li</surname><given-names>H.</given-names></name><name><surname>Shenoy</surname><given-names>P.J.</given-names></name><name><surname>Ramamritham</surname><given-names>K.</given-names></name></person-group><source>Scheduling Communication in Real-Time Sensor Applications</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Toronto, Canada</publisher-loc><year>2004</year><fpage>10</fpage><lpage>18</lpage></citation></ref>
<ref id="b6-sensors-09-09666"><label>6.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Lu</surname><given-names>C.</given-names></name><name><surname>Blum</surname><given-names>B.M.</given-names></name><name><surname>Abdelzaher</surname><given-names>T.F.</given-names></name><name><surname>Stankovic</surname><given-names>J.A.</given-names></name><name><surname>He</surname><given-names>T.</given-names></name></person-group><source>RAP: A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>San Jose, CA, USA</publisher-loc><year>2002</year><fpage>55</fpage><lpage>66</lpage></citation></ref>
<ref id="b7-sensors-09-09666"><label>7.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Aquino</surname><given-names>A.L.L.</given-names></name><name><surname>Figueiredo</surname><given-names>C.M.S.</given-names></name><name><surname>Nakamura</surname><given-names>E.F.</given-names></name><name><surname>Loureiro</surname><given-names>A.A.F.</given-names></name><name><surname>Fernandes</surname><given-names>A.O.</given-names></name><name><surname>Junior</surname><given-names>C.N.C.</given-names></name></person-group><source>On The Use Data Reduction Algorithms for Real-Time Wireless Sensor Networks</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Aveiro, Potugal</publisher-loc><year>2007</year><fpage>583</fpage><lpage>588</lpage></citation></ref>
<ref id="b8-sensors-09-09666"><label>8.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Li</surname><given-names>P.</given-names></name><name><surname>Gu</surname><given-names>Y.</given-names></name><name><surname>Zhao</surname><given-names>B.</given-names></name></person-group><source>A Global-Energy-Balancing Real-time Routing in Wireless Sensor Networks</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Tsukuba, Japan</publisher-loc><year>2007</year><fpage>89</fpage><lpage>93</lpage></citation></ref>
<ref id="b9-sensors-09-09666"><label>9.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Pan</surname><given-names>L.</given-names></name><name><surname>Liu</surname><given-names>R.</given-names></name><name><surname>Peng</surname><given-names>S.</given-names></name><name><surname>Yang</surname><given-names>S.X.</given-names></name><name><surname>Gregori</surname><given-names>S.</given-names></name></person-group><source>Real-time Monitoring System for Odours around Livestock Farms</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>London, UK</publisher-loc><year>2007</year><fpage>883</fpage><lpage>888</lpage></citation></ref>
<ref id="b10-sensors-09-09666"><label>10.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Peng</surname><given-names>H.</given-names></name><name><surname>Xi</surname><given-names>Z.</given-names></name><name><surname>Ying</surname><given-names>L.</given-names></name><name><surname>Xun</surname><given-names>C.</given-names></name><name><surname>Chuanshan</surname><given-names>G.</given-names></name></person-group><source>An Adaptive Real-Time Routing Scheme for Wireless Sensor Networks</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Niagara Falls, Ontario, Canada</publisher-loc><year>2007</year><fpage>918</fpage><lpage>922</lpage></citation></ref>
<ref id="b11-sensors-09-09666"><label>11.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Muthukrishnan</surname><given-names>S.</given-names></name></person-group><source>Data Streams: Algorithms and Applications</source><publisher-name>Now Publishers</publisher-name><publisher-loc>Hanover, MA, USA</publisher-loc><year>2005</year></citation></ref>
<ref id="b12-sensors-09-09666"><label>12.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Altiparmak</surname><given-names>F.</given-names></name><name><surname>Tuncel</surname><given-names>E.</given-names></name><name><surname>Ferhatosmanoglu</surname><given-names>H.</given-names></name></person-group><article-title>Incremental Maintenance of Online Summaries over Multiple Streams</article-title><source>IEEE Trans. Knowl. Data Eng.</source><year>2008</year><volume>20</volume><fpage>216</fpage><lpage>229</lpage><pub-id pub-id-type="doi">10.1109/TKDE.2007.190693</pub-id></citation></ref>
<ref id="b13-sensors-09-09666"><label>13.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Datar</surname><given-names>M.</given-names></name><name><surname>Gionis</surname><given-names>A.</given-names></name><name><surname>Indyk</surname><given-names>P.</given-names></name><name><surname>Motwani</surname><given-names>R.</given-names></name></person-group><article-title>Maintaining Stream Statistics over Sliding Windows</article-title><source>SIAM J. Comput.</source><year>2002</year><volume>31</volume><fpage>1794</fpage><lpage>1813</lpage><pub-id pub-id-type="doi">10.1137/S0097539701398363</pub-id></citation></ref>
<ref id="b14-sensors-09-09666"><label>14.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Guha</surname><given-names>S.</given-names></name><name><surname>Meyerson</surname><given-names>A.</given-names></name><name><surname>Mishra</surname><given-names>N.</given-names></name><name><surname>Motwani</surname><given-names>R.</given-names></name><name><surname>O'Callaghan</surname><given-names>L.</given-names></name></person-group><article-title>Clustering Data Streams: Theory and Practice</article-title><source>IEEE Trans. Knowl. Data Eng.</source><year>2003</year><volume>15</volume><fpage>515</fpage><lpage>528</lpage><pub-id pub-id-type="doi">10.1109/TKDE.2003.1198387</pub-id></citation></ref>
<ref id="b15-sensors-09-09666"><label>15.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Lian</surname><given-names>X.</given-names></name><name><surname>Chen</surname><given-names>L.</given-names></name></person-group><article-title>Efficient Similarity Search over Future Stream Time Series</article-title><source>IEEE Trans. Knowl. Data Eng.</source><year>2008</year><volume>20</volume><fpage>40</fpage><lpage>54</lpage><pub-id pub-id-type="doi">10.1109/TKDE.2007.190666</pub-id></citation></ref>
<ref id="b16-sensors-09-09666"><label>16.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Akcan</surname><given-names>H.</given-names></name><name><surname>Bronnimann</surname><given-names>H.</given-names></name></person-group><article-title>A New Deterministic Data Aggregation Method for Wireless Sensor networks</article-title><source>Signal Process.</source><year>2007</year><volume>87</volume><fpage>2965</fpage><lpage>2977</lpage><pub-id pub-id-type="doi">10.1016/j.sigpro.2007.05.007</pub-id></citation></ref>
<ref id="b17-sensors-09-09666"><label>17.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Bar-Yosseff</surname><given-names>Z.</given-names></name><name><surname>Kumar</surname><given-names>R.</given-names></name><name><surname>Sivakumar</surname><given-names>D.</given-names></name></person-group><source>Reductions in Streaming Algorithms, with an Application to Counting Triangles in Graphs</source><publisher-name>ACM</publisher-name><publisher-loc>San Francisco, CA, USA</publisher-loc><year>2002</year><fpage>623</fpage><lpage>632</lpage></citation></ref>
<ref id="b18-sensors-09-09666"><label>18.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Buriol</surname><given-names>L.S.</given-names></name><name><surname>Leonardi</surname><given-names>S.</given-names></name><name><surname>Frahling</surname><given-names>G.</given-names></name><name><surname>Sholer</surname><given-names>C.</given-names></name><name><surname>Marchetti-Spaccamela</surname><given-names>A.</given-names></name></person-group><source>Counting Triangles in Data Streams</source><publisher-name>ACM</publisher-name><publisher-loc>Chicago, IL, USA</publisher-loc><year>2006</year><fpage>253</fpage><lpage>262</lpage></citation></ref>
<ref id="b19-sensors-09-09666"><label>19.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Cammert</surname><given-names>M.</given-names></name><name><surname>Kramer</surname><given-names>J.</given-names></name><name><surname>Seeger</surname><given-names>B.</given-names></name><name><surname>Vaupel</surname><given-names>S.</given-names></name></person-group><article-title>A Cost-Based Approach to Adaptive Resource Management in Data Stream Systems</article-title><source>IEEE Trans. Knowl. Data Eng.</source><year>2008</year><volume>20</volume><fpage>202</fpage><lpage>215</lpage><pub-id pub-id-type="doi">10.1109/TKDE.2007.190667</pub-id></citation></ref>
<ref id="b20-sensors-09-09666"><label>20.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Indyk</surname><given-names>P.</given-names></name></person-group><source>A Small Approximately min–wise Independent Family of Hash Functions</source><publisher-name>ACM</publisher-name><publisher-loc>Baltimore, MD, USA</publisher-loc><year>1999</year><fpage>454</fpage><lpage>456</lpage></citation></ref>
<ref id="b21-sensors-09-09666"><label>21.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Abadi</surname><given-names>D.J.</given-names></name><name><surname>Lindner</surname><given-names>W.</given-names></name><name><surname>Madden</surname><given-names>S.</given-names></name><name><surname>Schuler</surname><given-names>J.</given-names></name></person-group><source>An Integration Framework for Sensor Networks and Data Stream Management Systems</source><publisher-name>Morgan Kaufmann</publisher-name><publisher-loc>Toronto, Canada</publisher-loc><year>2004</year><fpage>1361</fpage><lpage>1364</lpage></citation></ref>
<ref id="b22-sensors-09-09666"><label>22.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Babcock</surname><given-names>B.</given-names></name><name><surname>Babu</surname><given-names>S.</given-names></name><name><surname>Datar</surname><given-names>M.</given-names></name><name><surname>Motwani</surname><given-names>R.</given-names></name><name><surname>Widom</surname><given-names>J.</given-names></name></person-group><source>Models and Issues in Data Stream Systems</source><publisher-name>ACM</publisher-name><publisher-loc>Madison, WI, USA</publisher-loc><year>2002</year><fpage>1</fpage><lpage>16</lpage></citation></ref>
<ref id="b23-sensors-09-09666"><label>23.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Gehrke</surname><given-names>J.</given-names></name><name><surname>Madden</surname><given-names>S.</given-names></name></person-group><article-title>Query processing in Sensor Networks</article-title><source>IEEE Pervasive Comput.</source><year>2004</year><volume>3</volume><fpage>46</fpage><lpage>55</lpage><pub-id pub-id-type="doi">10.1109/MPRV.2004.1269131</pub-id></citation></ref>
<ref id="b24-sensors-09-09666"><label>24.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Madden</surname><given-names>S.R.</given-names></name><name><surname>Franklin</surname><given-names>M.J.</given-names></name><name><surname>Hellerstein</surname><given-names>J.M.</given-names></name><name><surname>Hong</surname><given-names>W.</given-names></name></person-group><article-title>TinyDB: An Acquisitional Query Processing System for Sensor Networks</article-title><source>ACM Trans. Database Syst.</source><year>2005</year><volume>30</volume><fpage>122</fpage><lpage>173</lpage><pub-id pub-id-type="doi">10.1145/1061318.1061322</pub-id></citation></ref>
<ref id="b25-sensors-09-09666"><label>25.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Xu</surname><given-names>J.</given-names></name><name><surname>Tang</surname><given-names>X.</given-names></name><name><surname>Lee</surname><given-names>W.C.</given-names></name></person-group><article-title>A New Storage Scheme for Approximate Location Queries in Object-Tracking Sensor Networks</article-title><source>IEEE Trans. Parallel Distrib. Syst.</source><year>2008</year><volume>19</volume><fpage>262</fpage><lpage>275</lpage><pub-id pub-id-type="doi">10.1109/TPDS.2007.70740</pub-id></citation></ref>
<ref id="b26-sensors-09-09666"><label>26.</label><citation citation-type="thesis"><person-group person-group-type="author"><name><surname>Elson</surname><given-names>J.E.</given-names></name></person-group><article-title>Time Synchronization in Wireless Sensor Networks</article-title><comment>PhD. Thesis</comment><publisher-name>University of California</publisher-name><publisher-loc>Los Angeles, CA, USA</publisher-loc><year>2003</year></citation></ref>
<ref id="b27-sensors-09-09666"><label>27.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Yu</surname><given-names>Y.</given-names></name><name><surname>Krishnamachari</surname><given-names>B.</given-names></name><name><surname>Prasanna</surname><given-names>V.K.</given-names></name></person-group><article-title>Data Gathering with Tunable Compression in Sensor Networks</article-title><source>IEEE Trans. Parallel Distrib. Syst.</source><year>2008</year><volume>19</volume><fpage>276</fpage><lpage>287</lpage><pub-id pub-id-type="doi">10.1109/TPDS.2007.70709</pub-id></citation></ref>
<ref id="b28-sensors-09-09666"><label>28.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Yuen</surname><given-names>K.</given-names></name><name><surname>Liang</surname><given-names>B.</given-names></name><name><surname>Li</surname><given-names>B.</given-names></name></person-group><article-title>A Distributed Framework for Correlated Data Gathering in Sensor Networks</article-title><source>IEEE Trans. Veh. Technol.</source><year>2008</year><volume>57</volume><fpage>578</fpage><lpage>593</lpage><pub-id pub-id-type="doi">10.1109/TVT.2007.905243</pub-id></citation></ref>
<ref id="b29-sensors-09-09666"><label>29.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Zheng</surname><given-names>R.</given-names></name><name><surname>Barton</surname><given-names>R.</given-names></name></person-group><source>Toward Optimal Data Aggregation in Random Wireless Sensor Networks</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Anchorage, AK, USA</publisher-loc><year>2007</year><fpage>249</fpage><lpage>257</lpage></citation></ref>
<ref id="b30-sensors-09-09666"><label>30.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Chen</surname><given-names>M.</given-names></name><name><surname>Know</surname><given-names>T.</given-names></name><name><surname>Choi</surname><given-names>Y.</given-names></name></person-group><article-title>Energy-efficient Differentiated Directed Diffusion (EDDD) in Wireless Sensor Networks</article-title><source>Comput. Commun.</source><year>2006</year><volume>29</volume><fpage>231</fpage><lpage>245</lpage><pub-id pub-id-type="doi">10.1016/j.comcom.2005.05.019</pub-id></citation></ref>
<ref id="b31-sensors-09-09666"><label>31.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Ganesan</surname><given-names>D.</given-names></name><name><surname>Ratnasamy</surname><given-names>S.</given-names></name><name><surname>Wang</surname><given-names>H.</given-names></name><name><surname>Estrin</surname><given-names>D.</given-names></name></person-group><article-title>Coping with Irregular Spatio-Temporal Sampling in Sensor Networks</article-title><source>ACM Sigcomm Comp. Commun. Rev.</source><year>2004</year><volume>34</volume><fpage>125</fpage><lpage>130</lpage><pub-id pub-id-type="doi">10.1145/972374.972396</pub-id></citation></ref>
<ref id="b32-sensors-09-09666"><label>32.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Gedik</surname><given-names>B.</given-names></name><name><surname>Liu</surname><given-names>L.</given-names></name><name><surname>Yu</surname><given-names>P.S.</given-names></name></person-group><article-title>ASAP: An Adaptive Sampling Approach to Data Collection in Sensor Networks</article-title><source>IEEE Trans. Parallel Distrib. Syst.</source><year>2007</year><volume>18</volume><fpage>1766</fpage><lpage>1783</lpage><pub-id pub-id-type="doi">10.1109/TPDS.2007.1110</pub-id></citation></ref>
<ref id="b33-sensors-09-09666"><label>33.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Matousek</surname><given-names>J.</given-names></name></person-group><article-title>Derandomization in Computational Geometry</article-title><source>Algorithms</source><year>1996</year><volume>20</volume><fpage>545</fpage><lpage>580</lpage><pub-id pub-id-type="doi">10.1006/jagm.1996.0027</pub-id></citation></ref>
<ref id="b34-sensors-09-09666"><label>34.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Bagchi</surname><given-names>A.</given-names></name><name><surname>Chaudhary</surname><given-names>A.</given-names></name><name><surname>Eppstein</surname><given-names>D.</given-names></name><name><surname>Goodrich</surname><given-names>M.T.</given-names></name></person-group><article-title>Deterministic Sampling and Range Counting in Geometric Data Streams</article-title><source>ACM Trans. Algorithms</source><year>2007</year><volume>3</volume><comment>Article number 16</comment></citation></ref>
<ref id="b35-sensors-09-09666"><label>35.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Nath</surname><given-names>S.</given-names></name><name><surname>Gibbons</surname><given-names>P.B.</given-names></name><name><surname>Seshan</surname><given-names>S.</given-names></name><name><surname>Anderson</surname><given-names>Z.R.</given-names></name></person-group><article-title>Synopsis Diffusion for Robust Aggregation in Sensor Networks</article-title><conf-name>Proceedings of 2nd International Conference on Embedded Networked Sensor Systems</conf-name><conf-loc>Baltimore, MD, USA</conf-loc><year>2004</year><fpage>250</fpage><lpage>262</lpage></citation></ref>
<ref id="b36-sensors-09-09666"><label>36.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Aquino</surname><given-names>A.L.L.</given-names></name><name><surname>Figueiredo</surname><given-names>C.M.S.</given-names></name><name><surname>Nakamura</surname><given-names>E.F.</given-names></name><name><surname>Buriol</surname><given-names>L.S.</given-names></name><name><surname>Loureiro</surname><given-names>A.A.F.</given-names></name><name><surname>Fernandes</surname><given-names>A.O.</given-names></name><name><surname>Junior</surname><given-names>C.N.C.</given-names></name></person-group><source>A Sampling Data Stream Algorithm For Wireless Sensor Networks</source><publisher-name>IEEE Computer Society</publisher-name><publisher-loc>Glasgow, Scotland</publisher-loc><year>2007</year><fpage>3207</fpage><lpage>3212</lpage></citation></ref>
<ref id="b37-sensors-09-09666"><label>37.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Aquino</surname><given-names>A.L.L.</given-names></name><name><surname>Figueiredo</surname><given-names>C.M.S.</given-names></name><name><surname>Nakamura</surname><given-names>E.F.</given-names></name><name><surname>Frery</surname><given-names>A.C.</given-names></name><name><surname>Loureiro</surname><given-names>A.A.F.</given-names></name><name><surname>Fernandes</surname><given-names>A.O.</given-names></name></person-group><source>Sensor Stream Reduction for Clustered Wireless Sensor Networks</source><publisher-name>ACM</publisher-name><publisher-loc>Fortaleza, Brazil</publisher-loc><year>2008</year><fpage>2052</fpage><lpage>2056</lpage></citation></ref>
<ref id="b38-sensors-09-09666"><label>38.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Nakamura</surname><given-names>E.F.</given-names></name><name><surname>Figueiredo</surname><given-names>C.M.S.</given-names></name><name><surname>Nakamura</surname><given-names>F.G.</given-names></name><name><surname>Loureiro</surname><given-names>A.A.F.</given-names></name></person-group><article-title>Diffuse: A Topology Building Engine for Wireless Sensor Networks</article-title><source>Sign. Proces.</source><year>2007</year><volume>87</volume><fpage>2991</fpage><lpage>3009</lpage><pub-id pub-id-type="doi">10.1016/j.sigpro.2007.05.014</pub-id></citation></ref>
<ref id="b39-sensors-09-09666"><label>39.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Reschenhofer</surname><given-names>E.</given-names></name></person-group><article-title>Generalization of the Kolmogorov-Smirnov test</article-title><source>Comput. Stat. Data Anal.</source><year>1997</year><volume>24</volume><fpage>422</fpage><lpage>441</lpage></citation></ref>
<ref id="b40-sensors-09-09666"><label>40.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Aquino</surname><given-names>A.L.L.</given-names></name><name><surname>Loureiro</surname><given-names>A.A.F.</given-names></name><name><surname>Fernandes</surname><given-names>A.O.</given-names></name><name><surname>Mini</surname><given-names>R.A.F.</given-names></name></person-group><source>An In-Network Reduction Algorithm for Real-Time Wireless Sensor Networks Applications</source><publisher-name>ACM</publisher-name><publisher-loc>Vancouver, British Columbia, Canada</publisher-loc><year>2008</year><fpage>18</fpage><lpage>25</lpage></citation></ref>
<ref id="b41-sensors-09-09666"><label>41.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Bustos</surname><given-names>O.H.</given-names></name><name><surname>Frery</surname><given-names>A.C.</given-names></name></person-group><article-title>Reporting Monte Carlo results in statistics: suggestions and an example</article-title><source>Rev. Soc. Chi. Estad.</source><year>1992</year><volume>9</volume><fpage>46</fpage><lpage>95</lpage></citation></ref></ref-list>
<sec sec-type="display-objects">
<title>Figures and Table</title>
<fig id="f1-sensors-09-09666" position="float">
<label>Figure 1.</label>
<caption>
<p>Build tree process.</p></caption>
<graphic xlink:href="sensors-09-09666f1a.gif"/>
<graphic xlink:href="sensors-09-09666f1b.gif"/>
<graphic xlink:href="sensors-09-09666f1c.gif"/></fig>
<fig id="f2-sensors-09-09666" position="float">
<label>Figure 2.</label>
<caption>
<p>Data-centric reduction design in WSNs real-time application, the sensor view.</p></caption>
<graphic xlink:href="sensors-09-09666f2.gif"/></fig>
<fig id="f3-sensors-09-09666" position="float">
<label>Figure 3.</label>
<caption>
<p>Reduction algorithms.</p></caption>
<graphic xlink:href="sensors-09-09666f3a.gif"/>
<graphic xlink:href="sensors-09-09666f3b.gif"/></fig>
<fig id="f4-sensors-09-09666" position="float">
<label>Figure 4.</label>
<caption>
<p>Minimum deadlines.</p></caption>
<graphic xlink:href="sensors-09-09666f4.gif"/></fig>
<fig id="f5-sensors-09-09666" position="float">
<label>Figure 5.</label>
<caption>
<p>Delay considering the half of deadlines without concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f5.gif"/></fig>
<fig id="f6-sensors-09-09666" position="float">
<label>Figure 6.</label>
<caption>
<p>ϒ-error considering the half of deadlines without concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f6.gif"/></fig>
<fig id="f7-sensors-09-09666" position="float">
<label>Figure 7.</label>
<caption>
<p>Φ-error considering the half of deadlines without concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f7.gif"/></fig>
<fig id="f8-sensors-09-09666" position="float">
<label>Figure 8.</label>
<caption>
<p>Delay considering the delay caused by relay nodes without concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f8.gif"/></fig>
<fig id="f9-sensors-09-09666" position="float">
<label>Figure 9.</label>
<caption>
<p>ϒ-error considering the delay caused by relay nodes without concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f9.gif"/></fig>
<fig id="f10-sensors-09-09666" position="float">
<label>Figure 10.</label>
<caption>
<p><bold>Φ</bold>-error considering the delay caused by relay nodes without concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f10.gif"/></fig>
<fig id="f11-sensors-09-09666" position="float">
<label>Figure 11.</label>
<caption>
<p>Delay considering the half of deadlines with concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f11.gif"/></fig>
<fig id="f12-sensors-09-09666" position="float">
<label>Figure 12.</label>
<caption>
<p>ϒ-error considering the half of deadlines with concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f12.gif"/></fig>
<fig id="f13-sensors-09-09666" position="float">
<label>Figure 13.</label>
<caption>
<p>ϒ-error considering the half of deadlines with concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f13.gif"/></fig>
<fig id="f14-sensors-09-09666" position="float">
<label>Figure 14.</label>
<caption>
<p>Delay considering the delay caused by relay nodes with concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f14.gif"/></fig>
<fig id="f15-sensors-09-09666" position="float">
<label>Figure 15.</label>
<caption>
<p>ϒ-error considering the delay caused by relay nodes with concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f15.gif"/></fig>
<fig id="f16-sensors-09-09666" position="float">
<label>Figure 16.</label>
<caption>
<p><bold>Φ</bold>-terror considering the delay caused by relay nodes with concurrent traffic.</p></caption>
<graphic xlink:href="sensors-09-09666f16.gif"/></fig>
<table-wrap id="t1-sensors-09-09666" position="float">
<label>Table 1.</label>
<caption>
<p>Simulation parameters.</p></caption>
<table frame="hsides" rules="groups">
<thead>
<tr>
<th align="left" valign="top"><bold>Parameter</bold></th>
<th align="left" valign="top"><bold>Values</bold></th></tr></thead>
<tbody>
<tr>
<td align="left" valign="top">Network size</td>
<td align="left" valign="top">Varied with density</td></tr>
<tr>
<td align="left" valign="top">Queue size</td>
<td align="left" valign="top">Varied with stream</td></tr>
<tr>
<td align="left" valign="top">Simulation time (seconds)</td>
<td align="left" valign="top">1100</td></tr>
<tr>
<td align="left" valign="top">Stream periodicity (seconds)</td>
<td align="left" valign="top">10</td></tr>
<tr>
<td align="left" valign="top">Radio range (meters)</td>
<td align="left" valign="top">50</td></tr>
<tr>
<td align="left" valign="top">Bandwidth (kbps)</td>
<td align="left" valign="top">250</td></tr>
<tr>
<td align="left" valign="top">Initial energy (Joules)</td>
<td align="left" valign="top">1000</td></tr></tbody></table></table-wrap></sec></back></article>
