iFogsim Entities

What is an Entity? and what is it’s Role?

Entities are the building blocks for the Cloudsim as well as iFogsim simulation toolkit.

The iFogsim simulation toolkit is basically used for simulating the scenarios based on Fog computing, where the workload is supposed to be submitted to the nearest available computing resource, if not possible only then it will be moved to connected cloud for the further processing.

Now to simulate the behavior of the real world Fog computing, iFogsim simulation toolkit, provides a set of API’s which contains a set of classes representing the components available in the real world Fog setup. All these set of classes are known as the Entities, because they actively take part in the simulation process by initiating the process events and passing the messages to share their work with other entities or status of work under processing.

As the iFogsim uses the simulation engine from cloudsim all these entity classes are ultimately derived from the simentity.java class and implements the processEvent() or processOtherEvent() method to support the actions required during the simulation process.

Entities in iFogsim simulation toolkit

There are eight entities available in iFogsim:

  1. FogDevice: This class simulates the computing resource, responsible for the actual computation of the tasks/jobs submitted to the network. The jobs are being shared through the Tuples class instance contains the signature for its sensor & corresponding actuator.
  2. FogBorker: This class simulates the broker/agent node, primarily responsible for the load(job/task) distribution of the computing devices available on the network.
  3. Sensor: This class is the end node and is going to simulate the working of some sort of Hardware, like a camera, temperature measuring device, etc. This is the source from where the tuples are generated representing the job/task and propagate them to the network for their computation
  4. Actuator: This class is again simulating the end node which is again representing some sort of hardware device which will be activated based on the processing of the tuple produced by the sensor class. This can be a storage device, motor, furnace, etc.
  5. EndDevice: This class models the device other than the sensor or actuator and is generally used for the purpose of additional network device simulations.
  6. Switch: This class represents a model of a real-life switch, whose primary role is to propagate the data among the network nodes. Here, in iFogsim, it propagates the tuples across the topology
  7. Link: This class is one of the most important classes as this defines the model of communication medium and defines the connections between the Sensor, FogDevice, FogBroker, Actuator, etc.
  8. Controller: This class is responsible for the simulation of allocation of application modules which are basically simulating over the fog devices and are in-turn processing the tuples through modules. Primarily controller class is going to do the scheduling of AppModules to the network nodes and manage their working.

Entity Class Hierarchy

image

Here in the above diagram, you can clearly see that SimEntity is the parent class for all the entities. Also in the case of FogBroker, the hierarchy proceeds through the PowerDatacenterBroker followed by DatacenterBroker as well as FogDevice, hierarchy proceeds through PowerDatacenter followed by Datacenter class. So the FogBroker and FogDevice inherits the majority of their features from the basic cloudsim simulation toolkit classes and then extends more features to support the iFogsim based Fog simulation scenarios.

Why SimEntity is inherited?

SimEntity is a class from the basic Cloudsim simulation toolkit and it has an abstract implementation of Cloneable class. This class includes the implementation of core methods used for scheduling events through an entity which are overloaded as schedule() method, startEntity(), shutdowEntity() & processEvent() methods define the default behaviors for the individual entities through overriding in the child classes, the run() method is used to process the events by the entities during the simulation runtime. So using this class as the parent reduces the redundancy of the code required by each individual entity and allows the developers to put up abstraction for the underlying simulation engine.

How does individual entity process events?

Every individual Entity is responsible for its execution of a particular event, whenever its call is made by the other entity through the simulation engine. These events processing are initiated through the inherited run() method from SimEntity class, which ultimately sends a call to the processEvent() method with event instance as a parameter, which inturn sends a call to processOtherEvents() method. These events are unique and defined inside the FogEvents.java class. Now based on the FogEvent the further method/procedure is called to process the desired action corresponding to the specified event. For example: The FogDevice() is supposed to process an event “FogDevice.TUPLE_ARRIVAL” then in this case the method processTupleArrival(ev) will be called for further processing.

image 1
Code Snippet of procesOtherEvent() method of FogDevice.java

Therefore, all the FogEvents are associated with procedures and the simulation engine periodically sends the call to individual entities with event details and the further simulation proceedings are done through the entities itself. Once the processing is over the result is sent back to the simulation engine based on which there may be further scheduling of new events to other entities.

Here, we have a video explaining all the details about the entities, this video will help you have a better understanding on how these entities are processing the individual FogEvents.

In case you are interested to learn more about iFogsim simulation scenario implementations. Feel free to have a look at a Unique course prepared to accelerate the learning for the researchers at https://www.superwitsacademy.online/essential-ifogsim-tutorials

Leave a Reply

Your email address will not be published. Required fields are marked *