IoT Data Acquisition using OMNeT++

OMNeT++ (Objective Modular Network Testbed in C++) on one of the leading modular simulation framework for developing network simulator. The OMNeT++ has no network protocol such as the IP or the HTTP. Data acquisition in the Iota is only successful if the data quality is high, and t data can be monitored and accrued in real time and is interoperable. IOT refers to the machine to machine interception technology that allows secure connectivity and infrastructure to transform data into useful forms with the right analytics. The most common foundations include hybrid compute and cloud stack or the big data technologies. The OMNeT++ discrete event simulation framework is widely accepted in most institutions and platforms and can be used freely and easily to model computer network. OMNeT++ simulation involves modules that communicate messages through the module to module channels implemented in the c++ to exploit the class hierarchy found in most of OMNeT++ simulation framework. Modules are active components mostly grouped into networks. The network simulation has inbuilt support from where physical channels characterized by latency, transmission delays, and message loss.

Figure 1: network topology for OMNeT++ simulator

Simulation model

The simulation model is based on the ATLAS Trigger and Data Acquisition (TDAQ) system that enables the ATLAS model to trigger and capture data at instantaneous luminosities adequately. It is important to note that the ATLAS TDAQ may be a simplified version but has three times data trigger and recording compared to the original LHC model an can sustain higher trigger thresholds. The simulation model assumes the network is infinite and ideal without data packet loss. The model uses simple configuration files in a modular environment. The simulation model used in this case has graphical and command line interface that enables parallel simulation to run at the same time.

Based on the simulation model to input values comprises of discrete data of 10 minute average of the actual operational data while the input will determine the output. For example, the output values include the number of event fragment in the Readout System (ROS), as well as the output bandwidth from the readout system to the PU. The speed determined by the number of processing PU.

The ATLAS inputs are very easy as the configuration and the model data used for the whole simulation process is acquired from the ATLAS database where historical records are stored about the operational state. The other input values to the simulation comprise of average values between 5 to 10 minutes of real data. However, normalization might also be required if different values that are already in averages. The performance of the simulation is quite easy as the simulator can be made to run independently. All the simulation are run for 60 seconds and can take up to 3GB of RAM. It is essential to allow each adequate simulation time to warm up. The simulation can also be run on four deferment machines. The readout systems on the model can only include the processing latency in addition to the network latency, and the software latency can be added to the model.

NED

OMNeT++ is adjustable to create and configure models in the various form including the NED files and the in- files. It is also has a functionality that can improve its ability to execute batch actions, analyze the simulation data, and enable c++ editing. The OMNeT++ editor is flexible and helps in creating compound modules and channels. The OMNeT++ has submodules that include the source of code editing mode. The main advantage of the NED editors is that it can allow uncountable undo/redo, cloning of objects as well as containing move and resizing. It can also allow modification such as alignment of the objects and proportionate zooming.

The in files source editors accommodate all the NED declaration including the simple modules, the compound modules as well as the channels. One essential functionality is that it can ultimately exploit the captured information to offer diagnostics and assistance to the user. For example, it can look up the network configuration key to provide top-level compound modules NED types and develop static pictures of the network. The NED can enumerate all the top level modules, the submodules, as well as any of the sub-sub modules, then relate the information to the in file contents.

INET framework

The INET framework is one of the simulation modules suites used with the OMNeT++. The INET is a suite for the TCP/IP and all the other internet related protocols used in the OMNeT++. The INET framework is composed of the IPv4, IPv6, TCP, as well as the SCTP, and UDP protocol implementations. The framework has some application modules. For example, the MPLS model has the RSVP-TE in addition to the LDP signalling. The other model is the link layer model composed of the PPP, the Ethernet as well as the 802.11. The INET framework can support the mobile simulation and has also been used with the wireless simulation

The INET can build on the OMNeT++ models allowing communication through message passing. The INET firework relies on the network of compound modules containing the hosts, the routers as well as multiple other modules. It is important to note that the compound module is mainly used to represent the hosts, the routers as well as the switches and other network devices. The compound modules can be assembled from one multiple simple modules. On the other hand, the host of simple modules may represent a wide range of protocols and application.

The main unique feature of the OMNeT++ modules is that they are grouped into packages based on the OSI layer. Currently, the INET 3.3 is in use, and the INET 4.0 will be expected to contain improvement that will require the OMNeT++++5.0. The current release of INET 3.3 can work with OMNeT++++4.6 and OMNeT++++5.0

In the current version of INET, there are simple Modules whose external interfaces can only be described in the NED files. The INET modules can be implemented in the c++ class such as the TCP and the IP. The INET combines most simple modules to form a wide range of hosts and network devices.

The interface table

The interface table of the INET modules is made up of a table of network interfaces such as the eth0, wlan0. On the other hand, the routing table is made up of ipv4 routing tables while the routing table 6 has the ipv6 routing tables. There is also a notification board that enables efficient communication of the modules.

At the network levels, it is important to note that there are quite a few modules such as the

Flat Network Configurator responsible for assigning an IP address to any of the selected host and sources. It can also set up basic static routing. The other modules are the scenario manager responsible for scripting the simulation the scenario manager can efficiently set up and control the INET simulation experiment, as well as complete the scheduling of events to occur at specific times. The other modules including the channels control to keep track of the nodes in the interface. The most coming INET models include the: Ethernet, IEEE 802.11, UDP, TCP, SCTP and MPLS. INET can be extended by adding own protocol onto the INET. the created subsidiary can be for only one of the protocols or any new protocol that to the corresponding OSI layer., it is also important to note that the new routing protocols for the OSI layer can be placed in the INET or its network subdirectory

Programming simple modules

The App, Routing, and Queue Simple ModulesThe compound modules are made up of the simple modules that are denoted by the use of simple keywords. The active activities in the modules are encapsulated, and the behaviours are determined with the C++ class. Only the net files are responsible for declaring all the gates are parameters that are externally visible. The node is, therefore, one of the simple modules but it has limited functionality due to the traffic generation and routing. The nodes are incomplete without the many simpler modules. The notes are responsible for traffic generation (app), routing, queuing the packets. The simple modules declaration is completed in the App.ned, Routing.ned and Queue.nedfiles

3.2.4 The HYPERLINK "https://omnetpp.org/doc/omnetpp/api/classomnetpp_1_1cTopology_1_1Node.html" Node Compound Module

The node is the compound modules and can be assembled in the form: App, Routing and Queue in compound modules such as the node. The compound modules box that groups modules into one large unit and can alternatively be used as a building block for most of the other modules into the network. The network is also considered as a compound module

Figure: The Node compound module

The programming of the compound modules such as the node can be as shown below:

Compound modules have parameter, gates. The nodes must have a parameter such as the address, gate vector, named port as well as the input port. The modules are made up of the submodules with app, routing and queue. There is also the connection part.

Running Simulations

The above simple and compound modules make up the NED definition. Whenever the OMNeT++++ simulation is programs are initiated, the programs load the NED files. The programs have the c++ classes responsible for implanting the needed simple modules such as the app, routing and the queue. It is important to note that the c++ codes is a component of the executable files or can be loaded from one of the shared liberties. OMNeT++ simulation program will also load the omnetpp.ini for the configuration which also determines if the simulation model that should be run is the "network" network. After the OMNeT++.ini has been configured, the network can then be instantiated for the simulation process.

Recording Omnet Simulation Results

The omnet is unique in that it provides the users with an inbuilt capability and support for recording the second by second simulation results. The omnet has output vectors and output scalars. The main difference between the two groups of data is that the output vectors are composed of the time series data. The scalars are results that are computed during the simulation

In the omnet framework, the output results are stored or saved in two main forms. They are either in scalar or vector type. The scalar (*.sca) is composed of summary statistic data including the mean, count, max, and minimum and this is automatically recorded from the time the simulation started till it is finished. The other type if the vector (*.vec) that comprises of finely grained data. The vectors are time series data for every second of that the simulation was run. The net results in the output fields format are highly coupled with their statistic mechanism discrete platform. The statistical data can be stored separately. For example, the results records for the nodes can be recorded and stored separately from the other nodes. For example, if the count, sum, and the mean vector using Command calls such as the this: record=count, mean, vector can be called

The results can be recorded in the form of a signal mechanism such as the declared statistics or directly from the C++ codes from the simulation library. The easiest way is to see the C++ codes, but the signal mechanism allows for easy tweaking of the whole simulation modules and does not involve heavy instrumentation. The scalar and statistical results are collected from the class variables stored inside the modules. The results are then recorded by their recordScalar ( ). On the other hand, the vectors can be recorded by way of the cOutvector objects. Additional information such as minimum and maximum values as well as the standards deviation can be acquired using the cStdDev andcWeightedStdDev. Other forms include the cDoubleHistogram, cLongHistogram,...