## 4 Analysis and Performance Comparison
### CoAP Packet Size Effects on Lower Levels  
Let us consider both cases in which an IPv6 node and a 6 LoWPAN node process the packet. Two hypotheses are valid: (i) no losses; (ii) no restrictions for the buffers size. For the calculation, we consider 48 bytes per packet overhead for the IPv6 node, since UDP is the transport protocol. For the 6 LoWPAN case, after the adaptation, this information is compressed into fewer bytes (from 6 to 11 bytes). Moreover, while in the IPv6 case we can rely on 1,280 bytes of MTU, in the 6 loWPAN case just 81 bytes of the 127 bytes of the IEEE 802.15.4 frame can be used by the upper layers (by assuming a secure transmission with AES-CCM-128 encryption). The remaining bytes of the IEEE 802.15.4 frame are used for both the MAC layer exigencies and for the compressed UDP and IPv6 headers. Figures 5 and 6 respectively show the trends in the number of IEEE 802.15.4 frames and bytes sent as a function of the CoAP packet sizes (chosen according to the packet sizes described in the previous section). As expected, the larger the packet size, the higher are both the number of IEEE 802.15.4 frames sent and the global overhead added to the CoAP packet (with respect to IPv6). This analysis helps to figure out the great disparity in the treatment of IPv6 and 6 LoWPAN nodes. The most constrained ones (6 LoWPAN) would have to process nearly 50% extra bytes with respect to the most efficient ones (IPv6). Finally, Table 3 reports the same values on a transaction basis, according to the CoAP method in use. Non-confirmable request and response messages are considered. Let us observe what happens when activating the _Blockwise transfer_ mode to guarantee the CoAP packet transmission. This is a new kind of data transfer for CoAP that splits a single REST operation into multiple CoAP message exchanges, by exploiting two new CoAP options. For major details, please refer to [15]. The main objective of the Blockwise transfer mode is to avoid creating a _conversation state_ at the server. This allows a transfer made on a block-basis; for each block two messages are \begin{table}
\begin{tabular}{|c|c|c|c|} \hline  & & **Total number of** & **Total number of** \\  & & **802.15.4-frames** & **Bytes** \\ \hline
**GET** & **Access** & 2 & 203 B \\
**POST** & **Subscribe** & 2 & 138 B \\
**PUT** & **Modify Subscription** & 2 & 138 B \\
**DELETE** & **Unsubscribe** & 2 & 132 B \\ \hline \end{tabular}
\end{table} 
Table 2: Analysis of the Proposed Solution. exchanged (_i.e._, in the \(\mathrm{GET}\) case, one packet is sent to request the \(i\)-th block and the other one is sent back with the requested information). Results of this analysis are obtained by assuming _ideal RF conditions_ (_i.e._, no losses) and real buffer sizes. Figure 5: Number of packets sent as a function of the CoAP packet size. Figure 6: Number of bytes sent as a function of the CoAP packet size. Table 4 shows the number of IEEE 802.15.4 frames and bytes sent on a transaction basis, according to the CoAP method in use and assuming the potential maximum CoAP packet size shown in Figure 3. For the computation, a block size of 128 bytes is chosen (enough to use a 1 byte-block option, since it has a 4-bit NUM field which allows to address 16 packets). The adoption of this transfer mode implies:  
* In case of a GET request, the client has to send the same CoAP request with all the options _nb_ times (with _nb_ equal to the number of blocks the server needs to send back the resource representation). This causes a waste of the server node computational resources (same request processed _nb_ times) and a relevant increase in the number of bytes sent (first line of Table 4). * The possible sizes of the blocks do not fit the 6 LoWPAN packet payload (81 bytes); thus, the payload space is wasted as many traveling frames are nearly empty.