## 4 Results and Discussion
### Measurements for Composing a New Virtual Event Source  
The periods of time required to have the virtual representation of the composed virtual event source can be expressed as in Equation (2):  
\[t_{\textit{composed virtualization}}=t_{\textit{simple virtualization}}+t_{\textit{composing event source}} \tag{2}\]  
In the test scenario, the sensor that was composing the new virtual event source was programmed to request and retrieve information from the already deployed temperature sensors that were available at the moment of its own deployment. This means that any other temperature sensor that was turned on after the composing sensor was not taken into account for the composed event service.  
For test purposes the composing sensor did not require a minimum number of temperature sensors in order to provide either the average temperature service or the fire event service. Obviously, this can be modified if required by the scenario where it is going to be used.  
The fire detection was conducted following the guidelines of [16]. This standard determines the response of a fire alarm based on heat detectors as the result of an increase on the air temperature, and the response time is determined by the speed of the increase. Thus, for the virtual sensor the operation is quite simple: it just checks periodically the registered temperature services, and compares a set of  
Figure 6: Time to subscribe the gateway to an event source.  
consecutive readings in order to calculate the approximate speed of change in the temperature. Consequently, when it detects an increase on the temperature at a rate in the ranges determined by the standard, it generates a new event.  
Before that, the time period required to have a new virtual sensor deployed in the network was tested. In Figure 7 we have the results after 210 tests. The lower value, in blue, corresponds to the setup time of the device. It is the time used to deploy all the nSOM components, just before sending the PROBE message to locate the required services. As it can be observed, it is almost constant.  
On the other hand, the timespan spent from the delivery of the PROBE message to the reception of the first PROBEMATCH, which defines the actual moment when the new virtualized event source is created, has also been considered. As expected, this second value is more irregular, because it depends on the transmission of both messages, and even in a small network there can be interferences.  
When considering the total time, a maximum of 15,235 milliseconds, a minimum of 4142, with a mean of 5229.12 and a standard deviation of 2118.72, are obtained as the most representative values.  
Regarding event generation, the composed sensor sends a request periodically containing the current temperature value in the registered temperature sensors. The response is asynchronous, so the detection of a fire condition depends on the time required to retrieve the information from the implied temperature sensor and the lapse since the request was sent. Figure 8 shows the results for this part of the system after 300 tests.  
For this test the maximum time required to generate an event once a fire condition has been detected in one of the nodes has been of 569 milliseconds, with a minimum of 243. The average mean has been of 295.05 milliseconds and the standard deviation 75.37 milliseconds.  
This data, along with the previous ones, show what seems to be a periodical extra delay in the actions that require wireless communications between the devices involved both actions. This might be due to the routing protocol used by the devices, that is, the SunSPOT, which is an improved version of AODV called LQI. In this routing protocol the routes between two nodes in the network are discovered on  
Figure 7: Time to event source composition.  
demand, and stored for a predefined interval, so it makes sense that this extra time is precisely due to the extra amount of messages required to update the routing tables.