## 6 Evaluation
### Experimental Results  
To evaluate whether our approach is feasible we have installed an instantiation of FamiWare with the new contexts of our case study (detailed in Section 4.2), and we have measured the interval time from which the context-awareness service receives the context information and detects a context change until the reconfiguration is completed. This interval time encompasses the following: the context-awareness service receives the monitored data (via several monitoring services implemented in MicaZ and Sun SPOTs sensors), analyzes them to detect a context change, chooses the suitable plan, and finally the reconfiguration service receives and executes the plan, reconfiguring diverse devices. Table 2 reports these results. The measurements were taken using the emulator provided in the r07-x86 SDK of the Android version for Linux, and also using the HTC Desire smartphone device. The implementation for the motes has been realized in TinyOS 2.1.1 and the experiments have been performed using two simulators, TOSSIM and AVRORA beta-1.7.106, and also in real MICAz motes (equipped with CC2420 radio and an ATmega128L microcontroller). Finally, for the Sun SPOTs sensors the implementation has been done using the Sun SPOT Development Kit (rev8), yellow-101117-1 (v6.0). The tests have been performed in the Solarium emulator and in Sun SPOTs devices (with CC2420 radio and the microcontroller AT91 SAM9G20). The total time of the context-awareness service is 8.22 ms, an insignificant time compared with the time taken by the reconfiguration service until the system is reconfigured, 1756.98 ms. The longest time in the reconfiguration service corresponds to the execution of the tasks that comprise the plan (see Table 2). This entails sending several events to nodes which takes a time highly depending on the routing protocol used, the structure of the network, and the number of nodes. Therefore, the overhead produced to reconfigure the system is insignificant compared with the time of sending a packet. However, from the user point of view, the total time taken to detect changes and reconfigure the system (less than 2 seconds) is satisfactory. We quantify the memory footprint used by FamiWare, since memory constraints are very strong in AmI devices. FamiWare consists of a microkernel and a variable set of services, so the memory usage on a device depends on the actual configuration. For TinyOS, the minimal core platform consists of the microkernel and the data delivery service. Also, since any TinyOS application is compiled together with TinyOS in one image, we also have to include it as part of our measures. Specifically, to be aware of the context, the minimal instantiation must have one monitoring service, the context-awareness service and the reconfiguration service. Considering the RAM memory of MICAz is 4 Kb, this \begin{table}
\begin{tabular}{|c|c|} \hline
**Operation** & **Time** \\ \hline Receive monitored data & 5.37 ms \\ \hline Detect a context change and choose the plan & 2.85 ms \\ \hline Total Context-Awareness time & 8.22 ms \\ \hline Receive plan chosen & 4.64 ms \\ \hline Get and read the plan file & 15.92 ms \\ \hline Interpret and execute the tasks of the plan & 1736.42 ms \\ \hline Total Reconfiguration time & 1756.98 ms \\ \hline \end{tabular}
\end{table} 
Table 2: Latency for the reconfiguration of the system. FamiWare version consumes 54.4% (2,229 bytes) of RAM. On the other hand, as average considering 12 monitoring services and 7 other services FamiWare uses 79.9% (3,274 bytes) of the memory, so there is still 20.1% free. The FamiWare project with the context-aware services for the Sun SPOTs version uses as average 298 bytes, that means 29% of the total RAM memory of SunSpot devices, 1 Mb. Finally, for the Android version, the Android processes share a memory region, so the memory footprint of FamiWare remains _constant_ although the number of services increases.