## 6 Evaluation
### Experimental Results
Therefore, we consider that this extra waste of energy is acceptable for these long-lived systems, considering that they will provide more flexible security levels than static systems. Summarizing, the resource consumption of FamiWare for the security dynamic reconfiguration is satisfactory and highly suited to the memory and battery constraints of real sensors. Scalability: We assess the scalability performance in terms of the number of plans that an ordinary node can load in its flash memory. This will be related to the number of different security policies that can be managed, since in the security context, we need a different plan to change from one security policy to another one. MICAz motes have 512 KB of flash, 384 KB of which are used for the routing protocol and for loading the binary code of the new images [27]. Therefore, if we reserve 98 KB for loading the plans, there is still 30 KB free, enough for applications or sensed data. The size average for the plans (after unnecessary tags of the OWL-S file are removed) is about 500 bytes, so there is enough space to load 200 plans, this is the upper limit of the number of plans. On the other hand, in an ordinary node (not sink or cluster-head), we can reduce the space reserved for plans, since these nodes do not need this high number of plans loaded inside the memory. The time needed to search a plan in the flash memory increases when there are numerous plans loaded. As Figure 10 depicts, the increase of time is linear with respect to the number of plans. Finally, the maximum time needed to find a plan, if we consider 200 plans loaded, is 1298 ms, an insignificant delay, compared with other sensor tasks. Considering that we need a plan to switch from one security policy to another, FamiWare works well with 14 different security policies, since, to quickly manage 14 policies, we need to have 14 \(\times\) 14 = 196 plans loaded in the sensors. In the case that we need to manage more policies, we  
Figure 10: Time that FamiWare takes for finding and reading a plan. can load new plans on the fly. This increases the reconfiguration time due to communication delay, as we see in the latency evaluation. Overhead and Latency: As for the negotiation, the generation of the new configuration and the selection of the plan are all done outside the sensor devices; we just measure the interval time from when the reconfiguration service receives the plan to change the security policy until the reconfiguration has been completed in all of the nodes. The average time taken by the reconfiguration service in different security policy modifications is 570 m. The longest time in this service corresponds to the execution of the tasks that comprise the plans. This is because many tasks implies the reconfiguration of several remote nodes. Therefore, this entails having to send several messages to different nodes, and the time this takes depends on the routing protocol used. For instance, using Drip protocol in one hop (without intermediate nodes), it takes 8 ms, but if we consider three intermediate nodes, this time increases up to 6.43 s. It is worth noting that if we increase the number of sensor nodes, but they are still one hop from the sink, the time needed to reconfigure them does not increase significantly. Nevertheless, if the sink has to use some intermediate nodes to reconfigure other nodes, the time greatly increases, but it depends on the structure of the network and the routing protocol used, as in other WSN platforms. Therefore, the overhead produced to reconfigure the system is insignificant when compared with the necessary time to send a packet.