# Sensorial Network Framework Embedded in Ubiquitous Mobile Devices
## 4 Evaluation and Discussions
### Discussion of Results  
The most important of the measured results of the system functionalities is the processing time, battery consumption, and the amount of transmitted data. The implemented solution was tested in a local 2.4 GHz WiFi network, with a single router in the area of a distance less than 2 m. The sensorial provider was a mobile device (Android Sony ZT3-blade), the sensorial consumer was a tablet device (Google Nexus 7), and the backend was a tower server (HP ProLiant ML150 Gen9). These details are outlined in a test scenario (Figure 11). Figure 10: Tuning client with Android the Dalvik Debug Monitoring Server (DDMS). Over 100 measurements for each sensor, from the sensorial provider to the sensorial consumer, were transported, and the time delivery of all of the components was measured. The granularity of the measurement is defined by each component, which has an independent system clock. The starting point is on the mobile device, where sensor data are gathered by listeners, and the processing time of each sensor is the measured delta of the data delivered to our application from the Android middleware [42]. Then, the data are processed and sent to the backend, where another time consumption is measured as the delta between the start time of the message delivery and the stop time, when it is acknowledged that the message has been received. Finally, the message is captured by the backend and stored in the database, where the delta of the start and stop time of the storing measurement entity are measured. The results (Table 4) highlight that, in a local network, it is possible to use TCP, rather than UDP, of which the time consumptions are comparable. However, TCP has a certain payload delivery. We decided to use TCP to test the bit rate in order to be as close as possible to the HTTP REST protocol for data transfer, which was initially considered as the only way to exchange data with the cloud service, however, we are currently considering the benefits of UDP as an ideal way to propagate sensory data, although it may be unreliable. \begin{table}
\begin{tabular}{l l l} \hline \hline
**Component** & **Time *** [ms]** & **Description** \\ \hline sensor proximity * & - & interactive \\ \hline sensor accelerometer * & 12 & tested on Sony ZT3-blade \\ \hline sensor magnetic field * & 46 & tested on Sony ZT3-blade \\ \hline sensor orientation * & 69 & tested on Sony ZT3-blade \\ \hline network rtt tcp ** & 30 & tested on WLAN (single router) \\  & & 332B HTTP Rest Header \\  & & 116B JSON payload \\ \hline network rtt udp * & 15 & tested on WLAN (single router) \\  & & 66B UDP Header \\  & & 547B Java serializable payload \\ \hline \hline \multicolumn{2}{l}{mono database} & 57 & \multicolumn{1}{c}{\textless{}}3000 records \\ \hline \hline \end{tabular}  
* tested on Sony ZT3-blade; ** tested in a local WiFi network with a router; *** arithmetic average time consumption is taken from 1000 measurements.  
\end{table} 
Table 4: Performance results from testing. Figure 11: Testing sensor informational flow of the sensorial framework. Moreover, transferring data is less time consuming than sensorial event data gathering on a low-end mobile device. Therefore, in future research, it would be useful to consider the test scenario on a wide area network (WAN) with different providers and also change the information distribution principal. Currently, the basic sensors of mobile devices are covered, which are visualized in a comprehensive form on mobile devices by an Android application. The sensorial data can be captured locally by mobile devices and can be provided to local applications. Furthermore, data are propagated on a remote backend, where they can be distributed to proper consumers, such as other mobile devices or different servers, for analysis. For further research, a group of users could be established, who are willing to share their sensorial data from a personal mobile device. The cooperation with other developer members, who would like to link their solutions in a framework, would also be very useful.