# Lightweight CoAP-Based Bootstrapping Service for the Internet of Things
## 4 Experimental Results
### Performance Evaluation  
#### 4.2.1 Message Length  
In general, the message length may influence the time the Smart Object takes to process it but, more importantly, the time that takes to send and receive it over the network. This aspect gains relevance in lossy networks where, for example, fragmentation becomes a matter of utmost importance [103]. Currently, the IEEE 802.15.4 defines a MTU of 127 bytes. Table 2 shows the message length (in bytes) for CoAP-EAP and PANATIKI. We show the length of the EAP lower-layer, excluding the length of the EAP message (_LL_) and including the EAP message length (_LL+EAP_). Thus, in the case of CoAP-EAP, _LL_ column includes the length of CoAP header (4 bytes), the (variable) list of CoAP options and payload, excepting the length of EAP message itself. As PANATIKI is an implementation of PANA, it follows the standard, so the PANA message length is the same as specified in RFC 5191 [55]. Thus, _LL_ column for PANATIKI includes the length of the PANA message excepting the EAP message length. In short, a PANA message includes the PANA header (16 bytes) and a variable length payload. This payload is formed for a list of _Attribute Value Pairs_ (AVPs) (e.g., the PANA message containing the EAP success, _PAR(EAP Success)_, includes a list of 5 AVPs). Each AVP has a _Tag-Length-Value_ (TLV) format and its length is _8 bytes_ plus the length of the content of the AVP. For the specific list AVPs carried in each PANA message during a PANA authentication, the interested reader can refer to [55]. Finally, _LL+EAP_ column adds the EAP message length to the values in column _LL_ in both cases. As a consequence, all the messages related with CoAP-EAP have a shorter length in comparison with PANATIKI's. In fact, it is worth noting that CoAP is designed with a _short fixed-length binary header_ and compact binary options [22] and PANA was not designed with the constraints of IoT environments in mind. Overall, there is \(\approx\)32% reduction in the number of bytes between both alternatives when looking at LL+EAP. Apart from IEEE 802.15.4 networks, we foresee that this will be also important, \begin{table}
\begin{tabular}{l l} \hline \hline  & **Testbed PC** \\ \hline CPU & Intel(R) Core(TM) i5-2400 CPU @ 3.10 GH \\ RAM & 4 GiB DIMM DDR3 Synchronous 1333 MHz \\ O.S. & Ubuntu Server 12.04.5 LTS - 32 bits \\ Kernel & 3.13.0-32-generic \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Specifications of the computer used for the testbed. \begin{table}
\begin{tabular}{l c c c c c c c} \hline \hline  & **CoAP-EAP** & & & **PANATIKI** & & **\% CoAP-EAP Reduction** \\ \hline
**Msg.** & **LL** & **LL+EAP** & **Msg.** & **LL** & **LL+EAP** & **LL** & **LL+EAP** \\ \hline POST & 13 & 13 & PCI & 16 & 16 & & \\ POST(nonce-c) & 18 & 18 & PAR & 40 & 40 & & \\ ACK(nonce-s) & 20 & 20 & PAN & 40 & 40 & & \\ POST(Ieq/Id) & 17 & 22 & PAR(Req/Id) & 27 & 32 & & \\ ACK(Res/Id) & 9 & 20 & PAN(Res/Id) & 25 & 36 & & \\ POST(EAP-PSK 1) & 17 & 46 & PAR(EAP-PSK 1) & 27 & 56 & & \\ ACK(EAP-PSK 2) & 9 & 69 & PAR(EAP-PSK 2) & 24 & 84 * & & \\ POST(EAP-PSK 3) & 17 & 76 * & PAR(EAP-PSK 3) & 25 & 84 * & & \\ ACK(EAP-PSK 4) & 9 & 52 & PAR(EAP-PSK 4) & 25 & 68 & & \\ POST(EAP Success) & 36 & 40 & PAR(EAP Success) & 84 & 88 * & & \\ ACK & 27 & 27 & PAN & 52 & 52 & & \\ \hline
**Total** & 192 & 403 & & 385 & 596 & 50.1\% & 32.4\% \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Message length. for example, in low power wide area networks [75] where sending a single byte is usually very costly. If we pay attention just to the CoAP-based EAP lower-layer that we have designed, since the EAP implementation is common in both approaches, the reduction increases about 50%. We expect additional impacts of our solution as a consequence of the reduction of message length in networks where the bandwidth is really low. In particular, several discussions are going on in the context of the IETF _IPv6 over the TSCH mode of IEEE 802.15.4e_ (6 tisch) WG [52] about the use of CoAP as transport of EAP in this type of networks.