Sensor Network Simulator Prototype With Real-Time Environmental Data Monitoring to Build Smart Application

This paper states an innovative proposal of a simulation/emulation tool for wireless sensor networks for getting real environmental data. The sensor network’s creation and design use a mathematical model that optimizes the sensor nodes’ location through geographic coordinates (latitude, longitude). The software uses a distributed computational architecture based on containers (Docker), a web application developed in React.js with the ANT Design framework. It is managed through micro-services using the Lagom framework. It also uses the FIWARE-Orion component that controls the flow of sensor data, storing them in the Neo4j database and giving the user the option of using them in any external application. The simulator presents a significant contribution in the WSN field because it allows obtaining data in real-time using a meteorological API. Finally, the application’s proposed architecture allows all the simulation data and the sensor network design to be used by creating any outdoors intelligent application.

the physical layer to the network scheme, allowing them to make comparisons that serve before implementation. However, the simulators may not generate the data that corresponds to a realistic environment, each node in a sensor network should be able to obtain data from the simulation environment (temperature, pressure, humidity, and more) to generate applications or case studies based on the location of the sensor network.
This paper presents a tool to simulate/emulate a WSN for outdoor environments and allow the interaction of the sensed data with other computer systems in real-time, and at the same time, use real environmental values of the area to be monitored using a meteorological API. The platform is designed through a distributed computational scheme using current technologies (Docker Containers). The user web application is designed/developed using React.js and the ANT Design framework, offering a non-intrusive, reactive, fast loading, and easy-to-manipulate web tool. The server consists of several micro-services through the Lagom framework. Also, It uses the FIWARE Orion Context Broker (OCB), one of the main components of the FIWARE platform [11]. It allows managing the entire life cycle of data in a sensor (create, read, update and delete) and sending it to other applications where the user needs them. This simulator aims to provide an external tool that allows the deployment of outdoor smart applications that need data for analysis.
The remainder of this paper is divided into seven sections. Section II presents state of the art, describing the components and necessary characteristics of a sensor network simulator and related work, emphasizing the current simulators and the benefit that this tool brings to the field of WSN. Section III describes the mathematical models for creating sensor networks, indicating the different mechanisms that the platform has to generate designs based on the separation radius of the nodes and the coverage area. Section IV presents the platform's distributed computational architecture, describing the graphical user interface, the data communication model, the micro-services, and the external components used to create the sensor networks. Section V describes the case studies to validate the platform (performance), and the hardware and software used in the development environment are indicated. Section VI presents a previous analysis of the platform using the Apache JMeter tool, in which the performance of the web application and the micro-services was analyzed using different metrics. Finally, Section VII presents a viability discussion of the platform with scenarios where the simulator can be used and a description of the future works.

II. BACKGROUND AND LITERATURE REVIEW
Sensor network simulation tools have allowed the deployment of multiple applications in different environments. There are currently many simulation tools where users can choose one depending on their other programming skills and understanding of wireless sensor networks. This section describes state-of-the-art on this topic, emphasizing current sensor network simulation tools and related work.

A. WSN SIMULATORS
The WSN's design-and-implementation are concrete for each application due to the work environment's peculiarity. It is rare to find predictive models that fit multiple sensor networks, mainly because of the network propagation model [12] and the kind of sensor. For this reason, to ensure that the WSN fulfills all its functions, robustness tests must be carried out with complex conditions that allow the variations of its different modules [13], [14], i.e. changes in events, the communication link, the work environment, the nodes, and sensors, transceiver and receiver, protocols and their applications.

1) COMPONENTS OF A NETWORK SIMULATOR
The simulators should have a range of configurations that help shape the required designs. These generally consist of some modules that the user can configure to establish a design of sensor networks. The main modules are [10]: • Events: Represents the moment when an event happens.
This module manages the necessary methods for the operation of the network, e.g. process events, compare them, and obtain them as a function of time.
• Communication Link: This module establishes the wireless/wired communication model. It allows the different sensor nodes to transmit and receive the data from the sensors. The link contains variable as a bandwidth, wavelength, and propagation model.
• Environment: This module sets the work environment similar to the real world, where the physical phenomena of interest to simulate are selected, e.g. temperature, light, humidity, sound, magnetic field, and more.
• Node (Sensors): It represents a single node in the design of a wireless sensor network. The components include, e.g. processor, transceiver, sensors, actuators, energy source (such as a battery), network protocols, location, and identification.
• Protocols: The protocols can be from physical and network layers. These can provide services for sending and receiving packets, detecting the load/energy used in each packet, and routing messages through different nodes.
Additionally, a sensor network simulator essential must-have characteristics allow knowing the network's behavior [10], e.g. the best communication protocol and the optimal design of a network. The main ones are described below: • Availability: Simulators are used to test novel techniques with realistic scenarios, where new techniques can be compared to existing ones.
• Performance and Scalability: These depend on the type of programming language or graphical user interface, and in turn, are limited to the memory, processor, and register storage size requirements of the computer.
• Graphical Interface: It facilitates the design of the experiments and the handling of the simulator modules. VOLUME 9, 2021 • Operability and Debugging: It must have interpreters (commands) that allow you to interact with the simulation and efficiently obtain the expected results. Also, it must incorporate tools that allow finding flaws in the designs.
The large number of variables involved in this type of simulation requires a high-level scripting language, a friendly graphical user interface (GUI), and, as far as possible, support the ingestion or retrieval of extensive data due to the multiple repetitions or the duration of the experiment [15]. However, some simulators are limited by the stack of protocols, precision, and designs' scalability, which compromises the development time, the understanding, and the characterization of the sensor networks in a natural environment.

2) SENSOR NETWORKS SIMULATORS
Given the great demand for current applications that use wireless sensor networks, particularly when measuring environmental variables, researchers have launched a range of WSN simulation tools, which allow users to analyze these networks from different perspectives. Table 1 shows an overview of the most popular proposals for WSN simulators. These can be executed in various operating systems (FreeBSD, Linux, Windows, Mac OS) [16], although, to carry out a sensor network's deployment, the user must know the simulator's programming language [17]- [19] and the tool's handling.
The simulators' variety does not necessarily mean that they can be used by all users, especially if they do not have a GUI that correctly shows the simulation's information/setting/output. Some simulators focus on a specific application, e.g. [20], [21] describe an early warning fire detection system, where a network of sensors monitors a specific area.

B. RELATED WORK
Simulators allow the study of a WSN from different perspectives, e.g. [22] describes a process to analyze the reliability and lifetime performance of a WSN from a set of parameters using the JSim simulation tool. The study provides a mechanism to predict the significant parameters of a WSN and avoid creating intricate designs. In [23] describes a study to reduce the energy consumption of a WSN. That paper proposes a technique for predicting battery life (NBLP) with scenarios using different life-cycle factors and voltages/energy the WSN with the BeanAir and XLP simulator. Likewise, In [24] describes a scenario that analyzes AODV (Adhoc on Demand Vector Protocol) in simulation execution time using four simulators NS-2, NS-3, OMNet++, and MATLAB, to provide insight into network protocols currently employed in a WSN. Finally, [25] states a simulation of a WSN using the NS-2 simulator. In this study, the physical and radio signal propagation environments' criteria are analyzed, allowing the classification of the radio-electric propagation models according to the environment, e.g. nature, position, and obstacles. Nevertheless, most simulation scenarios analyze WSN from a functional perspective (physical layer, communication network, propagation model, among others. . .); this has allowed the deployment of countless applications in different environments; however, If the WSN analyzes is from the point of view of the ingestion/collection of the ''data'', the following stand out. Ref. [26] describes a distributed data aggregation technique using modified K-means to improve WSN lifespan (energy reduction). This method is divided into three stages: 1. sensor reading, data collection, and storage, 2. K-means is used to group the data, and 3. a representative reading of each group is transmitted. The network's performance is managed through the OMNET++ simulator and is based on actual data collected from the WSN and [27] describes a WSN proposal focused on IoT, where the data collected by the sensors uses a machine learning technique that significantly reduces redundant and erroneous data. The proposal allows for greater precision in the grouping of data and improves energy efficiency.
The WSN deployment generally involves using several nodes with multiple sensors that collect data, e.g., temperature, humidity, carbon monoxide, carbon dioxide, and pressure, mainly if the implementation is carried out outdoors (forest, city, parks). There are multiple proposals for WSN deployment where it has been necessary to acquire the required equipment to carry out the tests on-site, e.g., [28] details the structure of a WSN for the detection and mitigation of forest fires. The proposal describes the detection system, prediction algorithms, WSN topology, and location techniques using satellites and drones for fire mitigation or in [29] describes the implementation of a precision agriculture system to mitigate the effects of soil and climate change on crops. This paper results in the optimal ranges to improve productivity and avoid losses due to uncontrolled agroclimatic variables such as relative temperature, soil temperature, humidity, soil humidity, and luminosity. These proposals design WSNs to collect data in real-time, generally to solve a specific problem. The data obtained by the sensors is of vital importance for creating prediction or detection algorithms in an application. However, most WSN simulators do not focus on collecting simulated or real-time data, or that an application external to the WSN or the simulation can use that data without the need to perform a data curation (delete duplicate data). Based on this context, a platform was designed that simulates an outdoor sensor network; the user can design the network with only a few configurations (node separation radius, study area, and starting point for the creation of the network), uses a mathematical model to find the optimal location of the sensor nodes (with choice of changes by the user). Simultaneously, a meteorological API collects real-time data from the nodes' location (latitude, longitude), and a micro-services scheme with a concentrator (gateway) allow external applications to subscribe to the simulated network design to receive the sensors' data. Finally, the sensor network provided by the simulator was previously tested for creating an external application described in [30]; this aims to know the spread of a wildfire while monitoring an area in real-time with the sensor network in the simulator. These features of sending, obtaining, and monitoring data in real-time highlight the simulation platform compared to others.

III. SENSOR NETWORK MODEL
The sensor network design requires a coverage area. The area is configured by four stationary points that draw a rectangle on Google Maps. The rectangle R is denoted by: where A, B, C, and D are polygon points with geographical coordinates (latitude, longitude, elevation), as shown in Figure 1. These points allow for the establishment of the coverage area of the sensor network in the simulator. The points are necessary to find the best location of the sensor nodes, i.e. find the points (x, y) within the nodes' coverage area. The coverage area A to draw the sensor network mesh is expressed by: where (x, y) are geographic coordinates (latitude, longitude) and t represents the simulation time.
The sensor node is defined by: where d is a range of transmission (radius), the area covered by radio signal for message exchange with a neighboring node S neighbour . f 0 is the frequency of regular transmissions (5 seconds by default). Each node uses the meteorological API to collect environmental values in real-time.

A. MODELING USING R POINTS
The sensor network can be assembled in five different ways; everything will depend on the initial configuration point and the nodes' separation radius. The mesh is created in swarm mode with a separation r, and it is created circularly, as shown in Figure 2. The mesh uses Joseph Louis Lagrange's theorem [31], according to which the arrangement of lattice circles with the highest density is when six other circles surround each circle. The density is defined by: Distance between two centers is equal to circle radius multiplied by 2: 2r. When selecting the size of r distance between circle centers should be less than the radio-signal range (d), i.e. 2r < d. This requirement only satisfies the communication between two neighboring nodes because a VOLUME 9, 2021  network is related to the terrain and other adverse conditions, e.g. type of sensor, weather, and more. Besides, the mesh is created in a 2D environment; currently, the simulator does not consider the variable ''z'' (terrain elevation). Figure 3 presents the different configurations of sensor networks using the R points. It shows how the mesh takes as S 0 one of the points A, B, C, or D, and in each case, the number of sensor nodes to monitor the area is different, e.g. Figure 3(a) shows the configuration of point A(x, y), which begins to create the mesh until it covers the region R (as shown in Figure 2). The number of nodes within R is 12 (green); however, if the user wants to extend the network's design, he/she can make use of the nodes of the contour; in this case, there are additionally 18 nodes (red).

B. MODELING USING THE CENTER POINT
The sensor network can be designed using the central point of the rectangle. The platform calculates this point and considers it S 0 (x 0 , y 0 ) with new latitude and longitude values. This model allows creating a more homogeneous network, and, as far as possible, the use of the sensor nodes is less than those used with the R points. Figure 4 shows a central point network, resulting in a sensor network with 11 primary nodes (green) and 16 complementary nodes (red).

IV. SIMULATION PLATFORM ARCHITECTURE
This section describes the different stages and technologies used in the platform's implementation. Figure 5 illustrates a general scheme of the distributed architecture of the application, where it is detailed how the technologies interconnect with each other and certain functionalities of the server.

A. USER WEB APPLICATION
The development of the user's web application was with Ant (https://ant.design) Design Framework and React.js (https://es.reactjs.org). These tools allow creating an application with fundamental characteristics such as multiple communication channels, event handling, reactive modules, and independent components/views [32]. This application deployment type helps the proposed architecture because several communication lines exist in the same web component. Thus, a sensor node can establish communication with the OCB and other applications to keep updated each variable's state-monitored. Figure 6(a) shows a general view once the sensor network has been configured/designed (Section III). Figure 6(b) shows the network nodes so that the user can interact with them (turn on, turn off). When the sensor node is on, an iterative process (5 seconds by default) reads information from the OCB component and displays it in an orderly fashion, as shown in Figure 7.

B. ORION CONTEXT BROKER (OCB)
OCB is one of the main components of the FIWARE platform (https://www.fiware.org/). This component allows an application to manage the entire flow of data by creating entities. The sensor node is configured as an entity within OCB, as shown in Figure 8; in each entity's parameter (temperature,  pressure, humidity), CRUD can be applied through REST API calls. The entity is described in detail in Appendix A.
OCB uses the publish-subscriber communication model defining NGSIv2 REST API messages (https://fiwareorion.readthedocs.io/en/master/). This model allows different external applications to connect to a sensor network's entities to receive the simulation's sensed data. In this way, subscriptions can be created based on the entire entity or specific data (Appendix B); the data can be used to create multiple applications in different environments. The OCB component uses the MySQL database by default to save entities information and subscription. It is important to note that the components work as Docker containers.

C. DATA COMMUNICATION MODEL
The different modules that make up the platform, from the user's web application to the micro-services (server), use the JSON format. However, different classes have been created in the Scala programming language to manage the data flow (server) to handle persistence and data serialization. Message schemes are described below.

1) WEB APPLICATION
The web application connects to the micro-services to extract data from the network (design, creation, storage). However, the ngsi.js (https://www.npmjs.com/package/ngsijs) library is used to connect with OCB; this allows a direct connection with the entities to manage the simulator's parameters in realtime.

2) METEOROLOGICAL API DATA
While the sensor node is on (simulation is running), a microservice begins to extract information using the node's position (latitude, longitude) from the web. The data is obtained through the interface provided by ''Weather API'' (https://openweathermap.org/api). The user needs to previously obtain an API key to be able to use the API. The following REST API call uses the ''Current Weather API'' with the format: http://api.openweathermap.org/data/2.5/ weather?lat=lat&lon=lon&appid=API key The web-service response model in JSON format is as follows (''latitude'': 40.1378,''longitude'': −8.6953): Finally, a micro-service receives the response; it is sent to the OCB component so that the web application can read the information.

3) MICRO-SERVICE TO OCB
The data received by the meteorological API is tagged to be sent to OCB. The message format is: The platform uses the Lagom framework (https://www.lagomframework.com) with ''Scala'' language programming to process the different functionalities of the application. Lagom allows the creation of micro-services that are responsible for the following functionalities: • Get data from the meteorological API. • Use the Google Maps API to obtain geographic data. • CRUD of sensor network designs. • Store the network in the Neo4j database. • Communication with OCB. • Periodic updating of network data. It should be noted that the functionalities described allowing to the management of the complete cycle of a simulation of a sensor network, i.e. the design, interaction, and data storage.

E. DATA STORAGE
The platform uses the Neo4j (https://neo4j.com) database to save the sensor networks' designs and the information of the nodes obtained from the meteorological API. The objective of using this database is because it stores the information in a graph so that the sensor network can use the benefits of this type of data structure, i.e. edges, to create relationships between sensor nodes (communication) and the nodes that would be each sensor node in the simulation. Figure 9 shows the structure of the graph in Neo4j. Each design of a sensor network handles the same scheme. The central node (WSN) can have one or many sensor nodes (Node), and in turn, each (Node) can have one or multiple nodes (Data). The application manages the nodes (Data) so that the information is not repeated; this is due to the OCB component's use, i.e. when there is a change in the entity's parameters, only that value or dataset will be stored in Neo4j. The purpose of this process is to avoid data redundancy and have better communication flow management. e.g. the temperature is a value that does not have sudden changes over time, and it would not be necessary to store that data every second; consequently, unnecessary data traffic on the network is avoided.

V. CASE STUDY
For the platform validation, it carried out two scenarios, which are described as follows: Scenario 1: The system is evaluated with various requirements per minute on different application pages (network design and configuration), and communication with Orion (OCB) is controlled through a distributed environment via CRUD requests. Hardware and Software requirements are described in Table 2.
Scenario 2: The microservice-based architecture using Lagom is evaluated by the Apache Jmeter application submitting various CRUD requests.

VI. APPLICATION ANALYSIS
This section presents an analysis of the application using the Apache Jmeter tool. The analysis is performed on the web application pages and the microservices. The test scenario involves using three computers to simulate the distributed environment within a wireless local area network (WLAN). The components are divided into:

A. APPLICATION PAGES AND ORION
In this scenario, the web application pages and the communication with Orion were tested. The analysis is carried out in: • Test 1 (Desing): Design/creation of the sensor network • Test 2 (Simulation): Simulation of the sensor network. • Test 3 (Orion): Read information. Table 3 shows the results of the test. Ten thousand samples (request) were performed for each test. It is observed that the error of the pages for the design and simulation of sensor networks is minimal, even with the libraries and mechanisms they use. The performance rate showing the number of requests (traffic/users) that the server has addressed every minute is 53.584,187/minutes, with a standard deviation of 511. Therefore, it is demonstrated that the page loading and the communication with Orion are exemplary and can withstand a maximum load.

B. MICRO-SERVICES
The analysis of the micro-services was carried out in two main ones:  Table 4 shows the results of the tests of these scenarios. 43.905 Samples (Request) for test one and 43855 samples for test two were used. The micro-services did not show any error of packet loss. The throughput (traffic/users) is 87.711,759/minutes, with a standard deviation of 15, demonstrating that the proposed architecture based on micro-services can address this type of simulation requirement.

VII. CONCLUSION AND FUTURE WORKS
This paper describes a platform for creating outdoor sensor networks. The platform makes use of a range of technologies that help to create a powerful web application. The sensor network creation model allows the deployment of five network models, where the user can choose the best design that adapts to a potential client's needs, i.e. consider the physical equipment of the sensor network. The simulator allows external applications that need a network of sensors (design) with environmental data (temperature, pressure, humidity, wind direction, and wind speed, among others) can obtain this information with basic configurations.
The user can simulate the network and use it to interact with other applications; this is due to Orion allowing applications to subscribe to entities to send them the information. The simulator has been used to monitor dry forests in Guayaquil (Ecuador) to predict ignition points, and forest fire spread. This example gives the assurance that the simulator has potential in the deployment of smart applications. The platform has certain limitations in its current state. It is necessary to have an infrastructure for the components' installation (servers) due to the distributed design of the web application; this differs from other simulators, which are generally installation packages for different operating systems. The sensor networks only contemplate a 2D modeling (surfaces), and it is only possible to choose one of the five models provided for network design compared with other simulators.
The platform is still under development, and functionalities are being incorporated that allow handling communication protocols and physical characteristics of the sensors, e.g. the type of sensor, the propagation of each node, sensor networks using Particle Swarm Optimization (PSO), type of micro-controller, node energy source (battery), energy consumption, and the elevation of the ground. However, all the previous sections' functionalities allow managing the sensors' data and their respective designs. The platform will soon be available for user use to get environmental data in real-time of a sensor network.

APPENDIX COMMUNICATION MODEL (NGSIv2) IN FIWARE-ORION TO CREATE AN ENTITY AND SUBSCRIPTIONS
A. SCHEME OF A NodeWSN ENTITY As shown at the bottom of the previous page.

B. SCHEME OF A SUBSCRIPTION
As shown at the bottom of the previous page.