## 2 Background
### Wireless Sensor Network (WSN)
#### 2.2.1 TinyOS and nesC  
TinyOS [23] is an open-source and event-based operating system specially designed to run in devices with low computational power and limited storage as WSN nodes. TinyOS executes in many different motes (e.g., IRIS [24], MICAZ) and provide facilities for the development of applications. TinyOS was developed in nesC [25], an extension to C, optimized to meet the limited storage of sensor nodes. In terms of programming, an application in nesC is built out of components that are wired together. A component has a specification and an implementation in which the specification defines provided/used interfaces, whilst the implementation consists of the nesC code that implements the specification. In practice, the provided interface characterises the functionality of the component and the used interface defines the functionality required by the component. An interface in nesC is bidirectional and used to communicate the components. The interface specifies a set of functions named _command_ and _events_, in which _commands_ must be implemented by the interface's provider, whilst _events_ must be implemented by the interface's users. _Task_ is another function present in the component, beyond _commands_ and _events_. It is a special kind of function that neither returns anything (void) nor has arguments. A task works as an independent locus of control and unlike _events_ and _commands_, are posted in a queue and lately executed by a schedule (following a FIFO policy). In this way, interactions between components may be very complex and typically a component registers the interest in some _event_ that is signalized when it occurs. For example, a component that invokes a _command_ like \"read temperature\" must implement the _event_ \"read temperature done\" that is executed right after the completion of _command_ \"read temperature\". In practice, commands typically go \"downwards\" (from application to closer the hardware) and events call \"upwards\" (closer to the hardware to the application). nesC has an execution model consisting of run-to-completion tasks (non pre-empted) and interrupt handlers that are signalled asynchronously by the hardware. The aforementioned scheduler is responsible for executing the tasks in any order and, as the tasks cannot be pre-empted, they are atomic with respect to each other, but are not atomic with respect to interrupt handlers. As a consequence of this execution model, the code of a nesC application may be divided into two parts: synchronous code (SC) and asynchronous code (AC). The SC is only reachable from tasks and includes functions, commands events and tasks. On the other hand, the AC is reachable from at least one interrupt handler. In terms of programming, nesC has the same set of operators of the language C: math (+, \(\times\) -, /), function call, assignment (=, +=, --, \(\times\)=, /=), byte (\(<\), \(>\), &, \(|\)), logical (\(>\), \(>\)=, \(<\), \(<\)=, \(==\),!= ), cast, and primary expressions (identifiers, constants, string literals, parenthesized expression). The function call has new operators in nesC: _call_\(\alpha\) used to invoke a command (\(\alpha\)); _signal_\(\varepsilon\), for call an event (\(\varepsilon\)); and post_\(\Omega\), for invoking a task (\(\Omega\)). Additionally, the language has statements divided into three categories: selection, iteration and jump statements. Selection statements choose one branch to execute based on the evaluation of an expression (called controlling expression). Selection statements may have many branches and each branch has a Boolean expression and a body. The selection statement executes the first branch whose evaluation of the controlling expression is true. This kind of statement has two representations (_if-then-else_ and _switch_) as shown in the following\".