# Modeling and Fault Tolerance Analysis of ZigBee Protocol in IoT Networks
## 4 Analysis of the Simulation Results Concerning the Fault Tolerance Issues in ZigBee Protocol
### Results of the Research
Most networks of reasonable size (more than 100 nodes) can only handle about four to five transmissions at a time. It is therefore recommended where possible to unicast transmissions instead of broadcasting. Unicasts consume much fewer resources in the form of bandwidth and RAM. It should be taken into account that ZigBee uses unicasts to transmit data along a route, but any node near any hop can hear such a unicast. It is discarded by all the nodes except the destination node, but the transmission still consumes bandwidth, which also unicasts directly affects the lifetime of the nodes. A detailed analysis of all four scenarios shows that as the number of removed nodes increases, the control traffic obviously decreases, as shown in Figure 10. The value of control traffic decreased from 8570 b/s to 2 b/s for received traffic, and 1810 b/s, to 1 b/s for sent control traffic in scenario 4. The situation is similar to the number of sent/received data. The throughput of the nodes is limited, which directly affects the number of transmitted/received packets. Figure 11 shows that as the number of disconnected nodes increases, the values also decrease until the network is completely disabled. It can be seen that the number of  
Figure 10: Comparison of control traffic values across all four study scenarios. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Parameter** & **Top Value I** & **Top Value IV** & **The Ratio TI/TTV** \\ \hline Control traffic received & 8570 b/s & 2.2 b/s & 3895.45 \\ \hline Control traffic sent & 1810 b/s & 1.4 b/s & 1292.86 \\ \hline Received data & 109,200 b/s & 7 b/s & 156 \\ \hline Sent data & 143,400 b/s & 4.7 b/s & 30510.64 \\ \hline Received management data & 1750 b/s & 3410 b/s & 1.95 \\ \hline Sent management data & 570 b/s & 3230 b/s & 56.67 \\ \hline Throughput & 24,025 b/s & 2.3 b/s & 10445.65 \\ \hline Rejected data & 8640 packets & 60,500 packets & 7 \\ \hline \hline \end{tabular}
\end{table} 
Table 8: The statistics of the network operation in scenarios I and IV. received data decreases systematically with the number of disconnected nodes (from 190,200 b/s--Scenario I, to 7 b/s--Scenario IV). The situation is similar for the number of packets sent. The number of data sent decreases from 143,400 b/s--Scenario I, to 4-5 b/s--Scenario IV). Figure 12 shows the dependence of throughput on the number of failed nodes. The decrease in the maximum throughput can be clearly seen. This has to do with the previously mentioned limitations of the nodes themselves. An interesting phenomenon is the increasing number of rejected packets in this case. It is evident that the network is not able to handle the incoming traffic which translates into an increase in the number of lost packets. As shown in Table 6, the throughput dropped from 24,025 b/s to nearly 2 b/s, and the number of rejected packets dropped from 8640 to 60,500, which is nearly 700% degradation. Interesting conclusions can be drawn after analyzing the values of management traffic and control traffic (Figure 13). It can be seen that as the control traffic decreases (both received and sent), the number of management packets increases. The dependence of throughput on the number of failed nodes is shown. It can be clearly seen that the maximum throughput decreases. This is related to the number of packets lost. The network  
Figure 11: Comparison of sent/received traffic values across all four study scenarios. Figure 12: Correlation of throughput versus the number of rejected packets. consumes its resources for management due to the need to redirect traffic associated with the increasing number of unavailable nodes.