## 8 Performance Evaluation  
In this section of the paper, the performance of the proposed work is evaluated and discussed. The network testbed is based on Mininet emulator [70] which is utilising ONOS SDN controller for  
Figure 14: Snapshot of Rate Monotonic Algorithm’s Simulation using Physical IoT Tasks. managing the entire network flow [71]. We have built a custom topology which has been exhibited in Figure 14(a). The network is based on Asia region, and it has a variety of switches and hosts. The switch named cloud-switch is the gateway for the traffic coming to the edge nodes. Different hosts are connected to the edge switches receiving and sending the traffic to different hosts. There are six hosts in this setup acting as IoT gateways where the sensors and actuators are connected. The Raspberry PI-based hosts are named by their respective resources names. For simplicity, it is assumed that only one IoT resource is connected to the Raspberry PI gateway. The actuators are an LED and a fan whereas the sensors are a temperature sensor, a humidity sensor, and a camera and a gas sensor. Simple flask web servers have been deployed on every host to listen on port 8080, and different hosts are sending data of different sizes and their respective response times are recorded. For every terminal, Wireshark has been run as a daemon process to log the network traffic and different packets as shown in Figure 14(b). The edge-to-edge communication is emulated with a low communication delay of 10 ms while the cloud to edge communication is emulated with a high delay of 100 ms. Figure 15(c) shows the response time and jitter of the interpacket delay of the communication between Camera Sensor and Fan Actuator. For this setup, we have taken the link bandwidth between 760 kbps to 1 Mbps and the communication delay of 105 ms. Moreover, the communication between different hosts have  
Figure 15: Snapshots of the Network Setup for Performance Analysis. been performed with varying sizes of data and the response time is recorded. Figure 15(a) exhibits the response time in milliseconds. For a low bandwidth of around 1 Mbps, the response time is very low even for a massive data of size 15,000. As the data size is increased, the response time also keeps increased but overall the response graph is steady, and if no external disruptions occur, the upper bound on the communication delay can be determined. This can also be verified by the jitter graph which is shown in Figure 15(b). Apart from the randomness on the packet number 33, the graph is steady which proves that the communication medium is stable and the inter-packet delay is uniform in many cases. For the latter case, the delay is decreased 10 ms, and the bandwidth is increased to 9 Mbps, and it has been found the effect of the response time for the same data sizes are very abrupt. Figure 17 shows the response time and jitter of the interpacket delay of the communication between Gas Sensor and Led Actuator. In this case, the link bandwidth between 9 Mbps and 12 Mbps and the communication delay of 10 ms. Similarly, the communication between different hosts have been performed with the same data sizes as the previous case and the response time is recorded. Figure 16(a) displays the response time in milliseconds. It is evident that when the bandwidth is increased, and the communication delay is decreased which is usually in the case of edge-to-edge communication, the response time is very little as compared to the former scenario. As the data size is increased, the response time also keeps increased but overall the response graph is steady, and if no external disruptions occur, the upper bound on the communication delay can be determined. The jitter in this can also prove the stability of the medium which is shown in Figure 16(b). Apart from the randomness on the packet number 33, the graph is steady which demonstrates that the communication medium is stable and the inter-packet delay is uniform in many cases.