## 3 Materials and Methods
### Methodology  
Once we have detailed the hardware and software resources we have used in this empirical study, we explain the methodology followed in our tests in this subsection. We have used two basic scenarios as presented in Figure 4. In the single-hop scenario, we only use two nodes, node N1 being the one in charge of periodically transmitting packets to node GW, which works as the gateway (that means the MAC is always in a listening state). In the multi-hop scenario, node N2 has enough radio coverage to reach nodes N1 and GW, but these two nodes do not have radio coverage between them. Therefore, in this case, the packets that N1 periodically sends to GW are routed through N2. We have chosen simple scenarios to focus on the influence that the processing tasks have on the communication performance, isolating it from other effects that may occur in deployments with more nodes, such as collisions, multipath effects, routing or spectral saturation. Next, we are going to present the experimental conditions of both scenarios. Since there are many configurable parameters in our system, we set some of them to fixed values while we vary the others in the different tests to determine their influence. With regard to the MAC layer, we set the number of packet slots to 3 for all tests since it is an acceptable value for a scenario in which many collisions are not expected. As a result, the value of \(T_{beacons}\) is always 13 ms, as it is the time used by the 3 beacon slots plus the guard time required to face tiny desynchronizations. In addition, the RDC value may be 10%, 15% or 20% depending on the running test, which means that the \(T_{MAC}\) and \(T_{packets}\) times change for each value of RDC as  
Figure 4: Single-hop and multi-hop scenarios implemented in our tests. Figure 3: Execution scheme of the reference task. presented in Table 1. These values have been chosen since they are representative of typical radio duty cycles in energy-constrained sensor networks. In each test, all the nodes in the scenario have the same RDC value. As for the processing tasks, we define 3 different types--TT1, TT2 and TT3--with an execution time \(T_{ON}\) of 2 ms, 5 ms and 50 ms respectively. In addition, we perform the tests varying the PTDC, which can take the value of 5%, 25% or 50%. Therefore, the \(T_{OFF}\) and \(T_{PROC}\) times change for each PTDC and task type according to Equation (2). Table 2 summarizes all the possible configurations of the processing task. It is very important to highlight that this processing task is only running in node N1. Nodes N2 and GW do not have this reference task running, they only route and receive packets respectively. In our tests, we also change the priorities of the communication tasks of the network stack and the processing one. However, as said before, the synchronization task has a fixed priority, which is the highest possible. This task is executed when a synchronization packet is received (once every 10 s), and runs for less than 100 \(\upmu\)s. Besides, there are other auxiliary tasks running in the OS (stdio task, tracing task), but their priority is the lowest possible and their combined CPU load is much lower than 1%. Therefore, we assume that the influence of both the synchronization and the auxiliary tasks can be considered negligible in our tests. This way, we define 3 different priority schemes, PS1, PS2 and PS3, by setting different priority levels to the communication tasks and the reference processing task. In PS1, the communication tasks have higher priority level than the processing task, while in PS2 they have the same priority level. Finally, in PS3, the processing task have higher priority level than communication tasks. Table 3 presents the priority levels for the different priority schemes, 1 being the lowest priority and 4 the highest possible one. As stated before, the processing task only runs in node N1, so these priority levels are always constant in nodes N2 and GW. For these nodes, the communication tasks have a priority level of 3 for all priority schemes.