## 5 Results
### Network Results  
As far as the network is concerned, both the mobile device and the WSN employ a 128-bit AES encrypting mechanism. Two tests were performed to validate the safety device. Two tests were performed to validate the safety device. The first test consisted in introducing an unknown node from an outside network, which in contrast with network nodes, does not have its AES encrypting mechanism enabled. The second test consisted in introducing another unknown node that had an AES key enabled, but which did not correspond to the one used by the WSN. In both cases, the external nodes try to capture HELLO packets transmitted within the WSN. Table 4 shows the structure of packets collected by a network node within the WSN. Each packet begins with an identical byte of information. This is then followed by two bytes to indicate the packet length. The next byte defines the frame type which corresponds to the IEEE 802.15.4 standard (0 \(\times\) 81-R \(\times\) 16 indicator), followed by 2 bytes for the source address, 1 byte for the RSSI, and 1 byte for the method sent (0 \(\times\) 00 for unicast, 0 \(\times\)02 for broadcast), which, in this case, is broadcast mode. Finally, each packet contains a 2-byte payload and a 1-byte checksum to verify the integrity of the packet. Figure 12(a) provides the results of the first security test. Results show that HELLO packets generated by a network node (left terminal) cannot be intercepted (right terminal) because the unknown node does not share the same AES mechanism. Figure 12(b) provides results that show that an unknown node can receive HELLO packets, but cannot decipher the 11-byte packets as originally sent because they do not possess the same key. An analysis of the packet received by the right terminal external device shows that the first byte is a packet start character (0 \(\times\) 7E). The following two bytes provide the packet length (0 \(\times\) 00F), which in this case is 15 bytes, excluding the start bytes, length and checksum. The next byte indicates the frame type, which corresponds to the IEEE 802.15.4 standard 4 (0 \(\times\) 80) that defines the MAC address used (64 bits). For this reason, the next 8 bytes of the frame contain the physical address of the source node (0 \(\times\) 0013A20040905 DA6). The next byte of the frame indicates the packet's RSSI (0 \(\times\) 24). The subsequent byte (0 \(\times\) 02) whether the packet was transmitted by unicast or broadcast, which in this case was broadcast. The following 4 bytes (0 \(\times\) A6 FB643C) provide the packet payload. Lastly, the final byte provides the checksum (0 \(\times\) 90). A comparison of the original data with the information acquired by the unknown node shows that it could properly get the starting character of the packet, its RSSI, the broadcast mode and the checksum. However, it could not obtain packet information corresponding to the length, frame type, source address and payload correctly. The unknown node cannot acquire this information because it does not \begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline  & & & \multicolumn{6}{c}{**HELLO Packet Structure**} \\ \hline Begin & Length & API & Src. Address & RSSI & Opt. (1 byte) & Payload & CS (1 byte) \\ (1 byte) & (2 bytes) & (1 byte) & (2 bytes) & (1 byte) & Opt. (1 byte) & (2 bytes) & CS (1 byte) \\
0 \(\times\)7E & 0 \(\times\) 00 & 0 \(\times\) 07 & 0 \(\times\) 81 & 0 \(\times\)00 & 0 \(\times\)15 & 0 \(\times\)24 & 0 \(\times\)02 & 0 \(\times\)48 & 0 \(\times\)01 & 0 \(\times\) FF \\ \hline \hline \end{tabular}
\end{table} 
Table 4: HELLO Packet Structure. possess the network encryption key. Experimental results show, in sum, that critical information regarding network information cannot be successfully obtained by a node that does not form part of the network. Once we tested the security of the WSN network, we proceeded to analyze and validate the functioning of the network.