Academia.eduAcademia.edu

Figure 7 – uploaded by sudheer kumar battula

See full PDFdownloadDownload figure
FIGURE 8_ Workflow of loTSim-Edge simulator [Colour figure can be viewed at wileyonlinelibrary.com]

Figure 8 _ Workflow of loTSim-Edge simulator [Colour figure can be viewed at wileyonlinelibrary.com]

Related Figures (17)

Note: L: low, M: medium, H: high, VS: very short, VL: very low. Abbreviations: BLE, bluetooth low energy; IoT, Internet of Things. TABLE 1 Overview of different communication protocols
Note: L: low, M: medium, H: high, VS: very short, VL: very low. Abbreviations: BLE, bluetooth low energy; IoT, Internet of Things. TABLE 1 Overview of different communication protocols
TABLE 2 Overview of different application-level messaging protocols Abbreviations: AMQP, advanced message queuing protocol; CoAP, constrained application protocol; MQTT, message queue telemetry transport; QoS, quality of service; SSL, secure sockets layer; TCA, transmissionm control protocol; XMPP, extensible messaging and presence protocol.
TABLE 2 Overview of different application-level messaging protocols Abbreviations: AMQP, advanced message queuing protocol; CoAP, constrained application protocol; MQTT, message queue telemetry transport; QoS, quality of service; SSL, secure sockets layer; TCA, transmissionm control protocol; XMPP, extensible messaging and presence protocol.
The application or services layer consists of different services that can be directly accessible to the users. These appli- cations will be accessed via a subscription model. The example services are a smart home, smart-City, smart healthcare, and smart transportation.
The application or services layer consists of different services that can be directly accessible to the users. These appli- cations will be accessed via a subscription model. The example services are a smart home, smart-City, smart healthcare, and smart transportation.
The architecture of the proposed simulator consists of multiple layers, as shown in Figure 2. A brief description of each component is presented in this section.
The architecture of the proposed simulator consists of multiple layers, as shown in Figure 2. A brief description of each component is presented in this section.
Nanagement engine. rigure 4 SHOWS a Simphiied Denavior OF the Simulators 1recycle as Steps and actions. For modeling an edge infrastructure, we designed and implemented numerous new classes. The main classes are Edge- DataCenter, EdgeBroker, EdgeDatacenterCharacteristics, EdgeDevice, MEL, and EdgeLet. The EdgeDataCenter class is ‘esponsible for establishing connection between edge and IoT devices based on the given IoT protocol (eg, CoAP) along with performing edge resource provisioning, scheduling policies, and monitoring edge processing. Furthermore, it is also ‘esponsible for EdgeDevice creation and EdgeLet submission, setting up a network connection between edge and IoT nfrastructure, checking network availability, among others. The characteristics of EdgeDataCenter (eg, types of policies, ypes of IoT protocols, and types of IoT devices) are fed by EdgeDatacenterCharacteristic class. The EdgeBroker class acts yn behalf of users in terms of establishing connection with edge and IoT devices, negotiating with resources, submitting
Nanagement engine. rigure 4 SHOWS a Simphiied Denavior OF the Simulators 1recycle as Steps and actions. For modeling an edge infrastructure, we designed and implemented numerous new classes. The main classes are Edge- DataCenter, EdgeBroker, EdgeDatacenterCharacteristics, EdgeDevice, MEL, and EdgeLet. The EdgeDataCenter class is ‘esponsible for establishing connection between edge and IoT devices based on the given IoT protocol (eg, CoAP) along with performing edge resource provisioning, scheduling policies, and monitoring edge processing. Furthermore, it is also ‘esponsible for EdgeDevice creation and EdgeLet submission, setting up a network connection between edge and IoT nfrastructure, checking network availability, among others. The characteristics of EdgeDataCenter (eg, types of policies, ypes of IoT protocols, and types of IoT devices) are fed by EdgeDatacenterCharacteristic class. The EdgeBroker class acts yn behalf of users in terms of establishing connection with edge and IoT devices, negotiating with resources, submitting
oT and edge requests, and receiving results. The EdgeDevice class presents the model of edge devices in terms of receiving nd processing IoT generated data where the data processing is carried out in accordance with the given EdgeLet policy. he MEL class models the abstract operation performed on IoT data on either edge or Cloud datacenters. For the current nplementation of MEL, we only consider it running on edge devices. The EdgeLet class model tasks need to be executed iside MEL. An edge device may contain a battery (eg, mobile phone) and be moving around; therefore, the battery and 10bility classes are designed to enable the edge device to obtain such characteristics. The MovingPolicy class dictates the 1oving conditions and behaviors of edge devices.
oT and edge requests, and receiving results. The EdgeDevice class presents the model of edge devices in terms of receiving nd processing IoT generated data where the data processing is carried out in accordance with the given EdgeLet policy. he MEL class models the abstract operation performed on IoT data on either edge or Cloud datacenters. For the current nplementation of MEL, we only consider it running on edge devices. The EdgeLet class model tasks need to be executed iside MEL. An edge device may contain a battery (eg, mobile phone) and be moving around; therefore, the battery and 10bility classes are designed to enable the edge device to obtain such characteristics. The MovingPolicy class dictates the 1oving conditions and behaviors of edge devices.
Algorithm 1. Update and Track Location
Algorithm 1. Update and Track Location
Every time the edge broker receives a new connection establishment (ACK), it will notify the IoT device about the connection. IoT device will then start sensing and generating data in the form of EdgeLets, transfer the EdgeLets to
Every time the edge broker receives a new connection establishment (ACK), it will notify the IoT device about the connection. IoT device will then start sensing and generating data in the form of EdgeLets, transfer the EdgeLets to
TABLE 3 Configuration file for Case 1 Abbreviation: BW, Bandwidth; IoT, Internet of Things. FIGURE 11 Simulation result for Case 1 showing the variation of battery hours for different scenarios [Colour figure car be viewed at wileyonlinelibrary.com]
TABLE 3 Configuration file for Case 1 Abbreviation: BW, Bandwidth; IoT, Internet of Things. FIGURE 11 Simulation result for Case 1 showing the variation of battery hours for different scenarios [Colour figure car be viewed at wileyonlinelibrary.com]
specific sites monitor the building activity and send the data to the associated edge device (eg, raspberry pi or single personal computer) for processing and analysis. Figure 12 shows an example of smart building constructed at Newcastle University (https://www.ncl.ac.uk/computing/about/usb/). Edge device does some local processing and sends the data o cloud if further storage or some complex analytics are required. Multiple IoT devices sends their data to one edge device following one specific communication protocol. Features like latency directly depend on the packet size and data rate. Research shows that one protocol is better than other protocols in terms of packet size and data rate.”! Again, since he IoT devices are battery operated, varying the data rate also changes the battery consumption. In the view of the fact hat energy conservation is one of the important features,”* recharging or replacing the battery at a frequent rate is not suggested. It is better to use a brotagal that consumes lesser renergy. a la ee: i ee a a
specific sites monitor the building activity and send the data to the associated edge device (eg, raspberry pi or single personal computer) for processing and analysis. Figure 12 shows an example of smart building constructed at Newcastle University (https://www.ncl.ac.uk/computing/about/usb/). Edge device does some local processing and sends the data o cloud if further storage or some complex analytics are required. Multiple IoT devices sends their data to one edge device following one specific communication protocol. Features like latency directly depend on the packet size and data rate. Research shows that one protocol is better than other protocols in terms of packet size and data rate.”! Again, since he IoT devices are battery operated, varying the data rate also changes the battery consumption. In the view of the fact hat energy conservation is one of the important features,”* recharging or replacing the battery at a frequent rate is not suggested. It is better to use a brotagal that consumes lesser renergy. a la ee: i ee a a
TABLE 4 Battery running hours using CoAP and XMPP protocol Abbreviations: CoAP, constrained application protocol; XMPP, extensible messaging and presence protocol.
TABLE 4 Battery running hours using CoAP and XMPP protocol Abbreviations: CoAP, constrained application protocol; XMPP, extensible messaging and presence protocol.
environment. Also, the number of IoT device varies from 1 to 50. The configuration of edge device for Case 2 is the same as explained in Case 1. The simulation results are presented in Figure 13. Figure 13A shows the average latency for each response. The figure clearly shows that initially the latency increases slowly with an increasing number of sensors; however, after the edge device got saturated, the latency becomes very high as the resource-constrained edge device will take more time to process the request. The result also shows that the latency of CoAP increases at faster rate as compared to XMPP. The reason is justified from Figure 13B where the iteration count (number of events generated during that particular scenario) for CoAP is higher as compared with XMPP. Since CoAP is a light-weight protocol, the battery also goes for longer time as compared with XMPP (see Table 4). The full-battery drainage hour using both the protocols is given in Table 4.
environment. Also, the number of IoT device varies from 1 to 50. The configuration of edge device for Case 2 is the same as explained in Case 1. The simulation results are presented in Figure 13. Figure 13A shows the average latency for each response. The figure clearly shows that initially the latency increases slowly with an increasing number of sensors; however, after the edge device got saturated, the latency becomes very high as the resource-constrained edge device will take more time to process the request. The result also shows that the latency of CoAP increases at faster rate as compared to XMPP. The reason is justified from Figure 13B where the iteration count (number of events generated during that particular scenario) for CoAP is higher as compared with XMPP. Since CoAP is a light-weight protocol, the battery also goes for longer time as compared with XMPP (see Table 4). The full-battery drainage hour using both the protocols is given in Table 4.
We modeled this scenario using our simulator. Figure 15 shows the schematic diagram of the model considered by our simulator. At time f1, the car found a new RSU. It first establishes a connection with the new RSU, RSU 1, and then starts
We modeled this scenario using our simulator. Figure 15 shows the schematic diagram of the model considered by our simulator. At time f1, the car found a new RSU. It first establishes a connection with the new RSU, RSU 1, and then starts
TABLE 5 Configuration file for
TABLE 5 Configuration file for
Abbreviations: IoT, Internet of Things; MPI, message passing interface; XMPP, extensible messaging and presence protocol. ee eee ee een eee en nn nen ne nen ne en nn ne nn eee ee eee ee ee en ene ee en nnn eee ee oe eee nen en ee nnn nee en en nn enn ne IS RSU 2. RSU 1 figures out that the car is now not in their range and based on the velocity information, it transmits the pro- cessed data to RSU 2, which delivers the information to the car as shown for time ¢4. This scenario validates the mobility feature as well as cooperative edge communication feature of our simulator. Table 5 gives the specific simulation config- uration of the specified case. Both the edge devices are identical except the location (£1 is at 0, 0, 0, while £2 is at 50, 0, 0). The simulation result is presented in Figure 16. The result in Figure 16A shows the average execution time with respect to the number of cars. The execution time increases as the number of car increases. With the increase in the num- ber of cars, the number of connection also increases. Since the number of edge devices is constant and the processing is done in a time-shared manner, requests are queued before processing, which leads to the increased execution time. Also, with the mobility of car, if the car moves away from the range of one RSU, then that RSU has to send the processed data to other RSUs, which further sends to the car. Since this is also added to the actual processing time, the execution time is higher. To process increased number of requests from car, edge will consume more energy as verified by our simulation (see Figure 16B), which shows that the average energy consumption of edge device increases with increasing number of cars (IoT).
Abbreviations: IoT, Internet of Things; MPI, message passing interface; XMPP, extensible messaging and presence protocol. ee eee ee een eee en nn nen ne nen ne en nn ne nn eee ee eee ee ee en ene ee en nnn eee ee oe eee nen en ee nnn nee en en nn enn ne IS RSU 2. RSU 1 figures out that the car is now not in their range and based on the velocity information, it transmits the pro- cessed data to RSU 2, which delivers the information to the car as shown for time ¢4. This scenario validates the mobility feature as well as cooperative edge communication feature of our simulator. Table 5 gives the specific simulation config- uration of the specified case. Both the edge devices are identical except the location (£1 is at 0, 0, 0, while £2 is at 50, 0, 0). The simulation result is presented in Figure 16. The result in Figure 16A shows the average execution time with respect to the number of cars. The execution time increases as the number of car increases. With the increase in the num- ber of cars, the number of connection also increases. Since the number of edge devices is constant and the processing is done in a time-shared manner, requests are queued before processing, which leads to the increased execution time. Also, with the mobility of car, if the car moves away from the range of one RSU, then that RSU has to send the processed data to other RSUs, which further sends to the car. Since this is also added to the actual processing time, the execution time is higher. To process increased number of requests from car, edge will consume more energy as verified by our simulation (see Figure 16B), which shows that the average energy consumption of edge device increases with increasing number of cars (IoT).
simulation time. Figure 17B shows that the average memory consumption does not increase considerably with increasing number of IoT devices. Maximum memory consumption is 19.14 MB for 50 IoT devices, which is acceptable.
simulation time. Figure 17B shows that the average memory consumption does not increase considerably with increasing number of IoT devices. Maximum memory consumption is 19.14 MB for 50 IoT devices, which is acceptable.
Abbreviation: DISSECT-CF, DIScrete event baSed Energy Consumption simulaTor for Clouds and Federations; IoT, Internet of Things. TABLE 6 Comparison of various open-source simulation tools that are currently using for IoT or edge simulation protocols, and mobility. To incorporate all these exclusive characteristics, we proposed a novel IoTSim-Edge simulator hat models numerous features, including the following: (i) device heterogeneity; (ii) application composition; (iii) vari- sty of loT communication protocols; (iv) device movement and mobility; and (v) battery features. It benefits researchers o develop their own prototype and test in a scalable simulation environment. They can identify the bottlenecks and est the performance of their methods and techniques with no cost, which will help them to improve the usability and performance of their proposed techniques. eer es eos
Abbreviation: DISSECT-CF, DIScrete event baSed Energy Consumption simulaTor for Clouds and Federations; IoT, Internet of Things. TABLE 6 Comparison of various open-source simulation tools that are currently using for IoT or edge simulation protocols, and mobility. To incorporate all these exclusive characteristics, we proposed a novel IoTSim-Edge simulator hat models numerous features, including the following: (i) device heterogeneity; (ii) application composition; (iii) vari- sty of loT communication protocols; (iv) device movement and mobility; and (v) battery features. It benefits researchers o develop their own prototype and test in a scalable simulation environment. They can identify the bottlenecks and est the performance of their methods and techniques with no cost, which will help them to improve the usability and performance of their proposed techniques. eer es eos
Related topics:
Computer ScienceSoftwareFog ComputingEdge ComputingPsychology and Cognitive SciencesEdge device
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved