## 3 Data-Centric Reduction Design in Real-Time WSNs Applications  
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 Figure 2, which shows the data-centric design in real-time WSNs applications, this design represents the sensor node view.  
Basically, we have three steps to characterize the stream flow in each node: received data, data classification, and data processing. Considering the received data, \(\mathbf{V}\) can be generated by the application or received from other nodes. In both cases, \(\mathbf{V}\) is delivered to the routing layer. _Application parameters_, used to help the reduction phase, are also received whenever the routing tree is rebuilt. Once a sensor  
Figure 1: Build tree process.  
Figure 2: Data-centric reduction design in WSNs real-time application, the sensor view.  
node receives \(\mathbf{V}\), we need to classify its type (classification step). In our case, the types considered are the _sensing_ received from the application and the _infrastructure_ received from other nodes. This classification is important because the routing layer behavior will be different for each one. When the node receives the _application parameters_, the _real-time information_ 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, _real-time requirements_ are verified. These requirements are used to decide the more suitable reduction strategy (_stream solution choice_), it is important highlight that this requirements are dynamically updated when the stream is received, _i.e._, 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 \(|\mathbf{V}^{\prime}|\) according to the deadline requirements. The sample size determination and the reduction algorithm will be presented latter on. Finally, in the data out step, \(\mathbf{V}^{\prime}\), which may be reduced, is routed towards the sink.  
In Figure 2, we can identify the software components required in real-time applications: a classification component to identify the type of \(|\mathbf{V}|\); 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 \(|\mathbf{V}^{\prime}|\), when necessary; a reduction component to perform the reduction; and a data out component to set the new parameters aggregated to \(\mathbf{V}^{\prime}\).  
Finally, the hardware resources necessary must be identified considering the \(|\mathbf{V}|\) supported and the reduction algorithm complexity. \(|\mathbf{V}|\) and \(|\mathbf{V}^{\prime}|\) 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.