## 6 Evaluation and Experimental Results
### End-to-End Transmission Delay Reduction
#### 6.3.3 Processing Overhead  
The processing delay (\(\mathrm{P_{ps}}\)) is defined as the elapsed time by a network device (generally the router) to process the header of a packet. Because the processing time is dependent on the header length, compressing the header packet (from 40 bytes to 25 bytes in the maximum case) has a direct impact in minimizing the overall E2E transmission delay of the handshake. In our evaluation, we measured the \(\mathrm{P_{ps}}\) belonging to the HIP DEX handshake in two different architectures: the first architecture (a1) is a WSN based-IPv4-IoT that represents a kind Peer-to-Peer Wireless Sensor Network where the communication between the Initiator and the Responder is established with no need for an intermediate router and, the second architecture (a2) is the WSN based-6 LoWPAN-IoT. For measuring the \(\mathrm{P_{ps}}\), we get results under Linux installed on A8-M3 nodes using _top_ command on the Initiator and the Responder. We performed 100 handshakes, and we noted the processing delays in the Initiator and Responder sides. Note that \(\mathrm{P_{ps}}\)(I1,I2) is processing delay of both II and I2 combined and the same for \(\mathrm{P_{ps}}\)(R1,R2). The obtained results in (a1), show that \(\mathrm{P_{ps}}\)(I1,I2) is about 0.083 s and, \(\mathrm{P_{ps}}\)(R1,R2) is about 0.078 s. In (a2) and before compression of HIP DEX packets, \(\mathrm{P_{ps}}\)(I1,I2) = 0.094 s and, \(\mathrm{P_{ps}}\)(R1,R2) = 0.084 s. After compression, \(\mathrm{P_{ps}}\)(I1,I2) = 0.078 s for both I1 and I2 packets and \(\mathrm{P_{ps}}\)(R1,R2) = 0.078 s. We compared the obtained results in LC-DEX with our previous results in [9].  
Table 9 recapitulates the obtained results from [9] in (a1), (a2) before compression and (a2) after compression. In (a2) after compression and in comparison with (a1), we perform a processing handshake that amounts to 6% for I1 and I2 packets. In (a2), we deduce that the gain in a processing delay of the HIP DEX handshake amounts to 44 ms (12.5%) with the proposed compression, in comparison with the standard HIP DEX. Table 10 presents a comparison of the HIP DEX processing packets in the initiator and the responder sides with HIP previous works. Figure 11 presents an overview of the consumed time during the  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Packet** & **P-HIP** & **[PERSON] et al. [9]** & **LC-DEX** \\ \hline I1 & 133 & 3.9 & 3.5 \\ R1 & 340 & 6.8 & 6.4 \\ I2 & 418 & 8.6 & 8.2 \\ R2 & 185 & 5.6 & 5.3 \\ Overall transmission delay & 1076 & 24.9 & 23.4 \\ \hline \hline \end{tabular}
\end{table}
Table 8: Comparison of handshake’s transmission delay (ms) with P-HIP and [PERSON] et al. [9].  
processing of initiator's and responder's daemon. We can observe that the maximum value is 0.146 s, and it is the same for processing initiators' packets and responders' packets.  
For the comparison with previous works, we considered the maximum value of the processing delays (see Figure 11) for both the initiator and the responder. The performed percentage gain is better, if we consider the average values. Comparing with [34], LC-DEX performs delay's gain of 85% and 82% in the Initiator and Responder sides, respectively. Comparing with [35], we performed 92% and 80% of delay gains in the Initiator and Responder side, respectively. LC-DEX gives 92% of delays gain for both Initiator and Responder sides. LC-DEX is faster, more than two times faster than P-HIP. In comparison with our solution in [9], the LC-DEX delay gains amount to 6.41% for both Initiator and Responder sides.