## 5 Performance Evaluation and Results Analysis  
This section presents the performance assessment realized to evaluate the behavior of the proposed solution. The Cooja simulator/emulator, which is a part of the Contiki O.S. [27], was used for this purpose. Although the use computational simulations cannot precisely represent the behavior of a network in the real world, it can allow a fair comparison among routing protocols since it makes the reproduction of an identical environment possible for all studied proposals [25]. In addition, because it works as an emulator, Cooja permits the replication of the hardware conditions of real nodes such as Tmote Sky, Zolertia Z1, and others. Thus, each emulated node represents the identical hardware conditions of real devices in terms of memory usage and processing capacity. The proposed LOADng-IoT was compared with the most recent version of LOADng and LOADng-SmartRREQ. The objective was to analyze the behavior of the proposed solution with the other proposals in different scenarios. Thus, situations were created with three topology organizations: grid sparse, random dense, and mobility dense. For all the topologies, the number of nodes in the network changed from 16 to 64. This quantity was chosen because it can represent the majority of the existing small-scale IoT application scenarios, mainly in smart homes. The following itemization presents more details on the used grid, random, and mobility topologies. * Grid Sparse Scenarios: the network nodes were organized in linear grids of \(nxn\) nodes. The simulated area grew together with the number of nodes. Thus, a fixed network density was maintained where the nodes had between two and four neighbors. * Random Dense Scenarios: the different quantity of nodes was randomly deployed in an area of 200 square meters just once. Thus, the random deployments were the same for all compared proposals. The simulated area was the same for the different quantities of nodes. Hence, the network density grew with the increase in the number of nodes. * Mobility Dense Scenarios: the nodes were deployed with the same positions of random dense scenarios in an area of 200 square meters. However, the nodes with an Internet connection was able to move in the whole area of the studied environment. For all scenarios and the different quantities of nodes, the simulation time was 600 s. In the application, all network nodes generated and sent data messages in variable intervals of between 10 and 15 s. The minimum data message interval was defined as 10 to avoid the nodes being overloaded with several data messages while they were still realizing a route discovery process. This measure was required because the nodes do not implement a significant buffer for data messages in the routing layer. Thus, all data messages generated inside a route discovery process are lost. The data message generation should be able to address the requirement of Equation (1):  
\[2*(1+RREQ\_RETRIES)*NET\_TRANVERSAL\_TIME \tag{1}\]  
where \(RREQ\_RETRIES\) is the maximum number of route discovery retries and \(NET\_TRANSVERSAL\_TIME\) is the expected time to a control message traversing the whole network. The generated data messages were simple messages or Internet messages, as explained in Section 4.1. Both messages were generated randomly with a chance of 50%. Thus, the simulated scenarios created a network traffic pattern that merged P2P (sending simple messages from a local node to another local node) and MP2P (sending Internet message from local nodes without an Internet connection to a local node with an Internet connection). In the simulated scenarios, the number of INs grew according to the number of nodes in the network, representing around 10% of network devices.