## 4 Analysis and Performance Comparison
### Performance Evaluations in Terms of Energy Waste  
This section illustrates a simulative performance comparison between the proposed solution and the CoAP one, obtained by means of the COOJA simulator for the Contiki Operating System [19]. In both cases, nodes emulate the Tmote Sky platform and implement the 6 LoWPAN adaptation layer. The node behavior has been observed for the ContikiMAC [20] RDC (_Radio Duty Cicling_) layer mechanism, which is the default one in Contiki OS. The solution embedded in COOJA and described in [21] has been used for the energy estimation. During the simulation, a client node asks for a service to a server node with a periodicity of 10 seconds. In particular:  
* for the _proposed model_, _Node 1_ sends Service Management (SM) packets to _Node 2_ to access a _sensing_ service and it obtains a numerical value back
* for the _CoAP model_, the simulation environment consists of two nodes: a _REST Server_ and a _CoAP client_ (we used the CoAP implementation presented in [22]). The analysis is differentiated for four different service requests: light sensor, battery level, toggle and resource discovery  
Energy measurements, performed with a periodicity of one second, last for 300,000 ms and have been differentiated for the following components: _reception_ (Rx), _transmission_ (Tx), _processing_ (CPU), and _low-power-mode_ (LPM). The tables in this subsection (Tables 5 and 6) will show the _total_ energy consumption during the entire simulation interval. Also the results relevant to the _percentage distribution_ in Figure 9 refers to the illustrated simulation setup. As previously observed, the CoAP packet size may reach the potential maximum shown in Figure 3. Whilst, the proposed model, by using the Service ID code, does not make the service representation increase. Thus, we argue that for large resource representation transmissions, the proposed model may help in increasing the performance. \begin{table}
\begin{tabular}{|c|c|c|} \hline  & **SERVER** & **CLIENT** \\ \hline
**RX** & 84.114 mJ & 82.657 mJ \\
**TX** & 14.235 mJ & 13.952 mJ \\
**CPU** & 74.039 mJ & 72.517 mJ \\
**LPM** & 46.748 mJ & 46.694 mJ \\ \hline _Total_ & _219.136 mJ_ & _215.82 mJ_ \\ \hline \end{tabular}
\end{table} 
Table 5: SM-packet energy consumption calculation (ContikiMAC RDC layer). Tables 5 and 6 show the energy consumption values (in mJ) respectively for the introduced SM transmission and for the CoAP packet transmission. One can observe that for short resource representations the SM packet usage does not lead to any visible improvements. The \"Discover\" column in Table 6 gives information on what happens when larger resource representations are sent. The energy consumption trend is better investigated in Figure 8, for gradual increments of the CoAP packet size. In the relevant simulation setup, differently from above, a server periodically sends to a client a CoAP packet of the size shown in the \(x\) coordinate. The figure reports the _average energy_ values on the server side differentiated for each energy components. The analysis shows a significant dependency of the _transmission_ (Tx), _processing_ (CPU), and _reception_ (Rx) components from the amount of bytes sent. Whilst, the LPM component slope is much less significant. Figure 9, instead, shows the percentage energy distribution among all the components. By looking at these results, one can notice that the _reception_ (Rx) component is responsible for the highest energy cost, followed by the processing (CPU) one. For a larger data forwarding (_i.e._, the server in the discovery case), the transmission (Tx) component assumes comparable values.