STGen: A Novel Lightweight IoT Testbed for Generating Sensor Traffic for the Experimentation of IoT Protocol and its Application in Hybrid Network

Abstract.

A Wireless Sensor Network (WSN) is a network that does not rely on a fixed infrastructure and consists of numerous sensors, such as temperature, humidity, GPS, and cameras, equipped with onboard processors that manage and monitor the environment in a specific area. As a result, building a real sensor network testbed for verifying, validating, or experimenting with a newly designed protocol presents considerable challenges in adapting a laboratory scenario due to the significant financial and logistical barriers, such as the need for specialized hardware and large-scale deployments. Additionally, WSN suffers from severe constraints such as restricted power supply, short communication range, limited bandwidth availability, and restricted memory storage. Addressing these challenges, this work presents a flexible testbed solution named STGen that enables researchers to experiment with IoT protocols in a hybrid environment that emulates WSN implementations with the physical Internet through a dedicated physical server named STGen core, which receives sensor traffic and processes it for further actions. The architecture of the STGen testbed adopts a modular and layered abstraction that facilitates experimentation, evaluation, and design decisions based on empirical studies. The STGen testbed is lightweight in memory usage and easy to deploy. Most importantly, STGen supports large-scale distributed systems, facilitates experimentation with IoT protocols, and enables integration with back-end services for big data analytics and statistical insights. In summary, STGen is an essential simulation tool for IoT researchers and developers, enabling them to accelerate their IoT experimentation through a command line interface (CLI) or a web interface. The key feature of STGen is the integration of real-world IoT protocols and their applications with WSN. Its modular and lightweight design makes STGen efficient and enables it to outperform other popular testbeds, such as Gotham and GothX, reducing memory usage by 89%. While GothX takes approximately 26 minutes to establish a large topology with four VM nodes and 498 Docker nodes, STGen requires only 1.645 seconds to initialize the platform with 500 sensor nodes.

1. Introduction

Wireless sensor networks (WSNs) refer to networks of spatially dispersed and dedicated sensors that wirelessly collect and transmit data about physical or environmental conditions. These are similar to wireless ad hoc networks in the sense that they rely on wireless connectivity and the spontaneous formation of networks so that sensor data can be transported wirelessly. A typical sensor node consists of a radio transceiver, a microcontroller, sensor interfaces, and a power source, usually a battery or an embedded form of energy harvesting. These characteristics, along with limited computation capability of sensor nodes, restrict the node’s capabilities (Saginbekov and Shakenov, 2016). However, these sensor nodes are equipped with various types of sensors, processing units, and wireless communication modules. It enables them to measure parameters such as temperature, humidity, pressure, motion, and more. The sensor nodes used in the WSN are connected to the sink node, which acts as a processing unit in the WSN system. In this work, we refer to the sink node as the STGen Core, which extracts and transmits sensor data for further processing. STGen uses a hybrid environment consisting of an emulated WSN and a physical STGen Core, with the emulated WSN effectively operating as a large network of sensor nodes. The STGen Core is a physical computational resource that facilitates communication between virtual sensor nodes and external systems. The STGen core facilitates the delivery of specific sensor data to client nodes over the public Internet upon request, enabling seamless interaction between the emulated network and real-world applications.

As Internet of Things (IoT) adoption continues to grow, the need for scalable and cost-effective sensor network simulation becomes increasingly critical for experimentation, verification, and validation of IoT systems. The concept of the IoT is wide-ranging from the commercial and technical point of view, such as smart cities, smart homes, pollution control, energy savings, smart transportation, and smart industries. However, setting up the IoT environment is time-consuming and expensive, especially with physical resources (Silmi et al., 2020). To address the issues, this article presents a lightweight testbed named STGen, which generates enormous sensor traffic by mimicking an IoT-based WSN ecosystem. Therefore, STGen provides a promising approach to test research ideas using real-time traffic without interfering with the regular operation of the IoT ecosystem.

A crucial component in the development and prototyping process of network protocols is verification and validation. Evaluating a new feature involves balancing realism with cost considerations. Testbeds can offer valuable insight into how a new feature behaves, especially in WSN and IoT contexts. However, actual networking takes place on production environments, such as those found in campus, enterprise, and government environments. The research community uses simulators, emulators, and testbeds to conduct experiments in a controlled and reproducible environment. Without the need for physical devices and the complexity of real-world network deployment, the STGen provides seamless support for experimentation, verification, and validation. STGen could be a great tool for students and researchers to experiment with device integration and improve the performance of their IoT application services like real-time monitoring, traffic shaping, and edge-level data analytics. The most attractive and fascinating feature of the STGen tool is the ability to create and simulate thousands of connected IoT devices without having to configure and manage physical devices. In short, this work is intended for students, researchers, and developers who work on IoT protocols and applications and, therefore, need the verification and validation of their prototype through experiments on the IoT testbed, particularly in the early stage.

To the best of our knowledge, no prior research has introduced an emulated testbed tailored for hybrid network architectures, particularly those combining physical machines with large-scale virtualized sensor environments. The key contributions of this work are the following.

1. Development of a lightweight, easily extensible, and customizable sensor traffic generator testbed for the experimentation of the IoT protocol.

2. Easy-to-replicate and easy-to-deploy STGen platform in distributed networking systems.

3. Platform independent, easy to control, and easy to configure through the STGen GUI and command line interface (CLI) in both Windows and Unix operating systems.

4. Developed a hybrid simulation model of emulated Wireless Sensor Networks (WSNs), where virtual sensor nodes transmit data to a centralized STGen Core (sink node), which then streams the traffic to clients over the public internet.

5. Integrating the ELK stack (Elasticsearch, Logstash, and Kibana) for real-time traffic ingestion and visualization, enabling dynamic and interactive graphing capabilities (Ngo et al., 2023).

Section 3 presents the state-of-the-art of existing IoT testbeds and highlights how STGen improves scalability and flexibility. Section 4 outlines the core components of STGen and their role in supporting scalable simulations. Sections 6 and 7 present the system architecture and technical details about the serialization of data, the transmission in real time, and the design of interoperable middleware with the STGen. The setup of the environment in 8 describes the tools needed to deploy STGen. The Results section 9 presents performance metrics that demonstrate the efficiency of the testbed. The comparison Section 10 briefly describes the effectiveness of STGen in simulating large-scale IoT environments compared to recent testbeds. The Related Work compares STGen with other IoT testbeds. Finally, Section 12 concludes the work with the future direction of this work.

Table 1. Comparison of IoT Testbed Platforms

Features	Gotham	GothX	IoT Flock	PatrIoT	STGen
Lightweight	No	No	Yes	No	Yes
Memory Footprint	Very High	Very High	High	n/a	Low
Sensor Node Initialization Time	Very High	Very High	n/a	High	Low
Deployment test on Single Machine	Up to 140 nodes	Up to 450 nodes	n/a	n/a	Up to 6k nodes
Real Time Log Analysis	No	No	No	No	Yes
CLI support	No	No	No	Yes	Yes
Stress Testing Capability	Lacks support	Lacks support	Yes	Hardcoded	Yes
Message Rate Customization	No	Yes	Yes	Hardcoded	Yes
Protocol Customization	No	No	No	No	Open for extension
Modularized	n/a	n/a	No	Yes	Yes
Simplicity	Not user-friendly	Complex	Complex	Hardcoded	Simple and intuitive
Node Count Customization	Hardcoded	Yes	Yes	Yes	Yes
Data Archival	Yes	Yes	Yes	Yes	Yes
Reproducible Sensor Configuration	Yes	Yes	Yes	Yes	Yes
Application Level Logs	Yes	Yes	Yes	Yes	Yes
GUI	Yes	Yes	Yes	No	Yes
OpenSource Project	Yes	Yes	Yes	Yes	Planned release

2. Motivation and Scope

The key motivation and vision of this work is introducing a novel and lightweight IoT testbed for the IoT research community, in particular those who are working on the development of a novel IoT protocol and require the verification of their prototype at the early stage of their development, as well as the processing of the voluminous sensor traffic. Building an interoperable and universal testbed for the IoT with different types of physical devices/sensors embedded in the microcontrollers is very expensive. The research community working on the development of IoT protocols requires a testbed for the verification and validation (Minani et al., 2024) of the prototype, particularly in the early stages of development. Early-stage researchers need significant time to become familiar with the microcontroller, to learn how to embed different types of sensors in the microcontroller, and to experiment with the whole ecosystem. However, researchers and students need a reasonably affordable and efficient environment to evaluate the ongoing development of IoT protocols. In response to this constraint, this research introduces STGen, a lightweight, scalable, and easy-to-use tool designed to address the challenges effectively. Due to its lightweight architecture, STGen can emulate thousands of virtual sensor nodes efficiently, making large-scale testing feasible on commodity hardware. Its design inherently adapts to the available system resources, supporting a wide range of IoT scenarios without the burden of managing physical infrastructure. Furthermore, the proposed architecture of the STGen not only simplifies the simulation but also supports scalable and customized environments for experimenting with various IoT protocols and opens a great opportunity for back-end services, such as big data analytics.

3. State of the Art

In recent years, several experimental testbeds have been developed to support a large-scale IoT environment for the experimentation of IoT protocols and their applications. For example, SmartSantander (Sanchez et al., 2014), Phynetlab(Falkenberg et al., 2017), and FIT IoT-LAB (Adjih et al., 2015) have advanced the field by providing researchers with extensive sensor networks. However, these testbeds often come with limitations in node accessibility and complex configurations. For instance, the main limitations of SmartSantander are its battery life and limited user reprogramming options, while FIT IoT-LAB focuses on providing access to bare metal but at the expense of scalability. In contrast, STGen is a highly flexible and scalable platform that enables the configuration of thousands of nodes with ease. This approach not only minimizes the cost of developing a physical IoT platform but also maximizes the efficiency of data transport across thousands of nodes, making it a state-of-the-art solution for developing an IoT protocol.

Figure 1. Hybrid model of STGen testbed integrating an emulated WSN with a sink node, enabling remote clients to receive IoT traffic via the public internet.

The authors in (Tsakalidis et al., 2023) introduce an open-source IoT testbed constructed on the OpenHAB platform, incorporating diverse components, including wireless interfaces, Z-Wave, ZigBee, Wi-Fi, 4G-LTE, and infrared, as well as numerous sensors. This testbed concentrates in delivering real-time monitoring and sustaining a robust, persistent layer. IoT-flock (Ghazanfar et al., 2020) is also an open-source framework for the generation of IoT traffic to develop security solutions for smart homes based on real-world IoT devices. IoT-flock supports the widely used IoT application layer protocols, MQTT and CoAP. However, it does not include memory‑footprint measurements or performance benchmarks across varying node counts, nor does it discuss its limitations or compare resource efficiency with other testbeds. Similar work has been done in this paper (Shahid et al., 2020) but with a different strategy to generate different data categories. Another work similar to STGen, the Patriot (Bures et al., 2021), has been developed to provide a flexible IoT system testbed that provides scalability from a physical testbed to an emulated environment to an experimental IoT testbed. The dependency on JUnit 5 of PATRIOT requires the hardcoding of simulation settings in individual test classes. Conversely, STGen provides a command-line interface enabling users to dynamically adjust simulation settings during execution, hence enhancing customisation and permitting seamless incorporation into automated workflows.

According to the author’s study (Papadopoulos et al., 2013), testbeds and simulators serve as complementary validation tools for successful real-world deployment experiments. The STGen platform functions as an IoT testbed capable of simulating wireless sensor networks, with users controlling network traffic patterns through configurable CLI parameters. A clean and modular testbed with a proper coding structure improves maintainability, simplifies modification, and guarantees flexible usability for researchers. This underscores the importance of a virtual testbed that provides reusability, as “reinventing the wheel” in such circumstances is inefficient and unnecessary.

The authors of this research (Buratti et al., 2015) have tested various communication protocols, including ZigBee, IPv6, and SDWN (which employs a centralised network layer protocol), using the EuWIn Platform. ZigBee and IPv6 are two of the most common standards for IoT applications; more recently, another approach based on the software-defined network (SDN) paradigm has been proposed. However, the authors experimented on very few nodes, which showed the limitations of the physical testbeds.

The authors in (Pan et al., 2015) have developed a physical IoT testbed by integrating sustainable and energy-efficient features and analyzing energy consumption trends related to environmental conditions and occupancy rates. The lessons learnt from this IoT testbed indicate that estimating environmental and human-related parameters is crucial to enhancing sustainability. However, the work needs more details on the scalability of large-scale IoT systems; it also requires information on how to simulate the testbed or process data, limiting its applicability in broader research scenarios and reproducibility.

Gothx (Poisson et al., 2024), a flexible traffic generator, and Gotham (Sáez-de Cámara et al., 2023), a reproducible IoT testbed, have been developed to create IoT data sets with legitimate and malicious traffic. They support validation across three different communication protocols (MQTT, Kafka, and SINETStream). The STGen platform is complementary to Gothx but is more efficient in terms of memory usage and runtime performance. The MakeSense (Jiang et al., 2020) is a flexible and easy-to-install testbed for real-life large-scale IoT applications that was introduced by the researchers in (Jiang et al., 2020). In this case, real-life testing was performed on the designed testbed only for two IoT applications: homes and offices. However, other promising IoT applications are not evaluated here, whereas the modules of this testbed are cost-minimizing.

This work (Alsukayti, 2020) presents an analogy that shows how modular design could make a testbed efficient, scalable, and extensible. Various Internet of Things (IoT) properties were taken into account during the development of this framework. Although this study covers the architecture and use case, it does not go into detail on the testbed system, such as its performance or memory footprint. However, the primary goal of this article was to provide the groundwork for developing a lightweight testbed system. Due to a lack of comparison with other testbeds, this is merely a simulation with a small number of sensor nodes.

Current IoT research trends show that researchers are increasingly striving to improve existing IoT protocols to enable device cognition and intelligence, which is why researchers need to rely on experimentation-based prototyping for proof-of-concept development. According to (Papadopoulos et al., 2017), the majority of concepts that were validated by simulation were later confirmed using experimental testbeds. The primary benefit of testbeds is the reproducibility of several instances of the same situation by researchers who did not design the testbed themselves (Chernyshev et al., 2017).

OpenTestBed (Munoz et al., 2019) is an open-source IoT testbed to evaluate and benchmark IoT solutions. This testbed needs standard components such as Raspberry Pi single-board computers, OpenMote B low-power wireless devices, and glass domes. Nevertheless, STGen is complementary to OpenTestBed but without “heavy” installations with dedicated wiring, switches, servers, etc. However, a comprehensive summary of STGen with the most recent existing simulators, emulators, and testbeds for different IoT application environments is shown in Table 1.

Figure 2. Sequence diagram of STGen testbed illustrating client applications requesting the STGen Core Node with sensor metadata and receiving sensor data over a custom application layer protocol. The STGen core node collects sensor data from the testbed at configurable intervals, stores it in a cloud database, and forwards it to the ELK Stack for real-time traffic analysis.

4. STGen as Hybrid Network Model

In STGen, the emulated Wireless Sensor Network (WSN) nodes are not constrained to a single physical machine. These software-defined nodes can be distributed across multiple systems and communicate with the STGen Core either via wired channels (such as Ethernet or LAN switches) or wirelessly (e.g., Wi-Fi). This architectural flexibility enables the formation of spatially separated WSN clusters that still maintain synchronized communication with the core. The STGen Core itself is decoupled from the emulated node’s host systems, thus enabling a hybrid network model—one that integrates both wired and wireless communication modalities. Building on this foundation, STGen serves as an IoT testbed, as illustrated in Figure 1, offering a powerful platform for traffic generation and protocol evaluation in ybrid IoT networks. The testbed is designed to simulate thousands of sensors and actuators, which, in the real world, are typically resource-constrained (Shelby et al., 2022), that is, are powered/operated by batteries and have a limited amount of storage and processing capabilities. Therefore, communications in IoT are sensitive to time. In such scenarios, the User Datagram Protocol (UDP) (Eggert et al., 2017) is the appropriate transport protocol for the communication of sensor data in WSN. Within Wireless Sensor Networks (WSNs), sensor nodes are generally deployed within the boundaries of a private network. As a result, direct communication with external systems is generally mediated through a designated sink node. In the proposed hybrid network model, a physical machine is designated as the STGen core, which assumes the role of the sink node, effectively offloading the computational and communication burdens from the emulated sensor nodes.

The fundamental idea of STGen aligns with the well-known phrase, “You cannot see the forest for the trees”. Despite its complexity, STGen aims to provide a platform for researchers or students engaged in the development of IoT protocols that require prototype verification during the initial or intermediate stages of development. The key components of the STGen testbed are the following:

• Sensors: These are emulated sensor devices that generate sensor traffic.

• STGen core as Middleware/Sink Node: This component collects sensor traffic and stores data for future inspection.

• Transport Protocol: This design choice is crucial in constrained environments where resources are scarce. Unlike TCP (Eddy, 2022), which ensures reliable data delivery using a connection-oriented approach, UDP is a connectionless protocol and requires less overhead compared to TCP. Since most of the IoT protocols are developed on top of UDP, STGen employed a custom, extensible application-layer protocol over UDP to facilitate flexible and lightweight communication.

• Real-Time Log Analysis: A key component of the STGen testbed is its ability to support real-time traffic visualization. Researchers can experiment with their protocols using the testbed while leveraging this feature to monitor and measure performance dynamically through visualization graphs with the ELK stack. Even though big data analytics frameworks such as Apache Hadoop and Apache Spark are not integrated with STGen, its modular design allows the possibility of future integration. This makes it possible for researchers to enhance the capabilities of the testbed for processing massive amounts of data, which, in turn, enables more in-depth analysis and optimization of Internet of Things protocols.

STGen enables independent simulation of its STGen core server, sensors, and client applications via both the Web UI and CLI. As illustrated in Figure 5, the STGen Core can be initialized by opening a designated port, allowing the client application to communicate with it, along with defining the sensor data receiving port for the incoming sensor traffic from the sensor nodes. Since sensor nodes operate independently, users must specify the STGen Core address to ensure seamless communication between the locally running sensors and the STGen Core. Additionally, the simulation allows sensors to be configured for a pre-defined duration, allowing control over the number of nodes and their respective transmission behaviors. Similarly, as shown in Figure 5, the client application can be executed with a defined STGen Core address to establish communication. Users must also specify an archive directory to store sensor data, facilitating data retrieval based on specific sensor identifiers of interest. This modular approach improves the flexibility and scalability of IoT simulations within the STGen framework. As shown in Figure 2, the sequence diagram details the step-by-step communication among the key components of the STGen architecture.

5. Key Requirements of IoT Simulation

The STGen testbed provides a scalable and efficient hybrid environment for large-scale IoT research and experimentation. It incorporates the following key capabilities (Almutairi et al., 2024):

Scalability Testing::

STGen emulates extensive IoT networks through a simulated Wireless Sensor Network (WSN), facilitating scalable and adjustable sensor deployments for the research, testing, and validation of IoT communication protocols and data processing.

Cost-Effective Deployment::

By providing a virtualized environment, STGen eliminates the need for extensive physical hardware. Researchers can configure and test IoT protocols, sensor interactions, and data transmission efficiently without additional infrastructure investments.

Simulation Tools and Platforms::

STGen offers platform-agnostic support, facilitating smooth functionality across various environments. The testbed’s cross-platform interoperability allows deployment and operation on several operating systems, enhancing flexibility and usability for researchers and developers.

Latency and Throughput Analysis::

STGen allows researchers to simulate network failures, apply controlled delays, and examine throughput fluctuations to assess system resilience and fault tolerance. Metrics including latency, packet loss, and performance trends are monitored and visualised through the ELK stack for real-time analysis.

Lightweight Communication and Protocol Flexibility::

STGen employs a custom application layer protocol on top of UDP for efficient and low-latency communication. It utilizes BSON encoding for packet payloads, guaranteeing optimized data transport and interoperability across various IoT applications.

Prototyping and Validation::

The testbed enables rapid prototyping of IoT systems by supporting virtual sensor deployments and application-layer protocol testing. The STGen facilitates the validation of sensor data transmission, processing workflows, and system integrations before real-world deployment.

Simulation of a real-world scenario::

STGen provides configurable environmental conditions. Researchers can utilize the traffic tool to simulate packet loss, generate latency, set bandwidth limits, and more to test an IoT system in different environments.

Big Data Analytics and Storage::

The STGen core efficiently aggregates and stores large quantities of sensor data in MongoDB for further analysis, while logs are maintained on the local disk for debugging and performance evaluation. These large-scale datasets can be fed into machine learning models for big data analytics.

Training and Educational Use::

STGen provides an intuitive interface for configuring and visualizing simulations, allowing students and developers to experiment with IoT systems and understand network behaviors without requiring physical hardware.

6. STGen System Architecture

The architecture of the STGen testbed is designed with a strong focus on scalability and customization, ensuring that each module can be individually deployed and operated independently without dependencies on other components. Each layer is built to ensure that the modules remain decoupled, preventing dependencies that could impact each other. Each module has a well-defined and specific responsibility, allowing for seamless integration, flexibility, and efficient evaluation of IoT prototypes. The key features of the STGen system architecture are discussed below.

6.1. Core Components

The core components of STGen considered at the early stage of prototyping are described as follows:

Sensors::

The sensor nodes of the STGen platform resemble real-world IoT sensors that generate values of a wide variety of variables, such as temperature, GPS, and camera data, at varying rates. One of the key advantages of STGen is its modular and extensible architecture, which allows seamless integration of new sensor types with minimal effort. The framework is designed to accommodate diverse IoT applications by providing a plug-and-play mechanism for sensor modules. Adding a new sensor type requires only two fundamental steps:

Defining the Sensor’s Default Behavior::

Implement the logic for generating data and defining the transmission characteristics of the sensor.

Configuring its transmission parameters::

Use the current configuration system to dynamically manage data transmission rates.

STGen Core::

The STGen core is the central component of the STGen design, located between the client and the sensor nodes. It includes a node registry that records the states of both the client and the sensor nodes. STGen core acts as a sink node, accumulating data from the sensor nodes and facilitating delivery to the client application through the public Internet. In addition, the STGen core stores the collected sensor data and application logs on the local hard disk and periodically stores the sensor data in MongoDB at runtime for further use.

Client Application::

Client applications of the STGen platform are connected to the STGen core to interact indirectly with the sensor nodes. Although sensor nodes do not recognize client nodes, their main task is to transmit data to the STGen core. Clients can retrieve the traffic from the STGen core by submitting a request for sensor nodes. The objective of this separation of concerns is to ensure that the core handles the complexities of sensor data management, allowing clients to focus just on the sensor data itself. This architecture accommodates numerous clients who are interfacing with the identical STGen core.

BSON Serialization for Compact Data::

In contrast to traditional testbeds, the primary advantage of STGen lies in its simplicity, with each configuration meticulously designed to optimize access patterns. To enhance efficiency in the STGen testbed, BSON (Binary JSON) serialization has been employed, prioritizing payload compactness and minimizing bandwidth consumption. BSON, as a binary encoded representation of JSON, offers a significantly reduced payload size – our experimental benchmarks demonstrate that BSON achieves approximately 76% of the size of an equivalent JSON payload. This reduction in payload size directly contributes to faster data traversal across the network, a critical factor for real-time IoT communication systems. Although BSON introduces higher serialization and deserialization overhead compared to JSON, its compact format effectively mitigates network latency and bandwidth usage. This ensures efficient data transmission, even in resource-constrained IoT environments, making BSON a suitable choice to optimize performance in such scenarios.

6.2. Flexible Configuration

The STGen testbed can operate in the command-line interface (CLI) mode and WEB server mode, providing different configuration options. The Web-based GUI provides a convenient interface for configuring and accessing the testbed smoothly without prior knowledge of the CLI mode. The Web interface converts user choices into API calls, and the Web server transforms those API calls into CLI commands to execute the desired setup and control actions on the testbed. However, STGen can be described as a user-friendly tool that features very simple and intuitive parameter options. STGen can be a very useful tool for researchers and developers in modeling complicated settings easily because of the adaptability of the STGen tool in a broad range of IoT research domains.

Figure 3. The STGen OpenAPI definition displayed in the Swagger UI (/swagger-ui/index.html).

To further enhance usability and automation, users can run the backend service that exposes these REST endpoints, converting REST API query parameters into the appropriate CLI commands—an approach particularly beneficial for those who prefer to avoid direct terminal command execution. This backend service simplifies and automates processes such as sensor, client, and core creation, reducing manual intervention and enhancing reproducibility. Additionally, API calls stream real-time application logs directly to the browser when utilizing the front-end service, providing transparent insight into ongoing operations. For researchers relying solely on the REST API endpoints, we have defined a comprehensive OpenAPI specification 3, which is available through the Swagger UI at /swagger-ui/index.html. This includes detailed documentation, interactive testing capabilities, and version control features, further facilitating integration, reproducibility, and ease of use. Moreover, for those who prefer direct interaction with the CLI, all available CLI commands are provided in the appendix section for reference.

6.3. Real-Time Data Transmission and Customization

The primary issue of IoT networks lies in the varied characteristics of sensors, actuators, and devices. This encompasses “heterogeneity of devices,” “heterogeneity in data formats,” and “interoperability issues arising from heterogeneity” (Noaman et al., 2022; Sowe et al., 2014; Moon et al., 2019). When forecasting heterogeneous IoT data values, temporal and geographic dependencies become particularly evident and are influenced by numerous additional factors, as they are dependent on specific situations. Our system incorporates a default transmission rate that can be modified through input parameters, allowing researchers to customize the rate for particular sensor types or applications, hence improving the versatility of the testbed.

7. Key features of STGen Architecture

The key features offered by the STGen architecture are summarized as follows:

STGen Core as the Core Processing Unit::

The framework simulates the behavior of sensor nodes publishing data to the STGen core, which acts as a rendezvous of the simulation ecosystem. The core serves as the portal between the client application and the sensor nodes. The client application carries out the communication with the STGen core, while the core stores and processes the sensor data.

Dual-Archiving for Redundancy and Scalability::

As the STGen core is ephemeral, it is essential to aggregate the data transmitted by the different sensor nodes in a storage system. For this, the STGen architecture performs two distinct tasks: first, distributing the data to MongoDB for efficient retrieval and analysis, and second, ensuring that the sensor data is aggregated locally. This dual-archiving strategy ensures redundancy and facilitates access in real-time or temporal analysis later on. The network traffic log is indexed and stored in Elasticsearch for real-time visualization and meaningful insights.

Decoupling Sensors and Clients through STGen Core::

The scalability of the simulation environment is achieved through the decoupling of different components of the STGen Core, which is briefly summarized as follows:

Decoupling for Focused Sensor Operation::

By separating the client applications from the sensor nodes, the STGen design allows the sensors to concentrate on data collection while the middleware (an instance of the STGen core unit node) processes, routes, and aggregates the data locally or in a cloud database.

Middleware as the Communication Gateway::

The STGen core instance acts as middleware between the sensor nodes and the client applications. The core manages all communication as the sensor nodes are resource-constrained. The client applications interact only with the sensors through the STGen core.

Scalability through Decoupling::

By offloading the sensor-generated data to the different storage systems by the STGen core, the system achieves high scalability and can simulate millions of sensor nodes from the distributed testbed without increasing the complexity of client applications. This approach supports the deployment of large-scale IoT networks, reducing the operational load on a particular cluster.

Figure 4. Distributed STGen testbed setup for experimenting with various IoT protocols and big data analytics on sensor data. Emulated testbeds feed sensor data to the STGen Core, which processes and provides real-time traffic analysis via the ELK Stack. Client applications access data using a custom UDP protocol, with sensor data backed up to a MongoDB cloud database.

8. Distributed Setup of STGen Testbed

Parameter	Description
STGen Core IP	IP address of the server to connect the sensors.
STGen Core Sensor Incoming Port	Port number on the STGen Core to which sensors send data.
Simulation Time	Total simulation time in seconds.
Sensor Config	Configuration for each sensor type in the format sensor_type:number_of_sensors:data_rate.
Sensor Type	Type of sensor available in the simulation (switch, temp, gps, camera)
Number of Sensors	Number of sensors of this type to simulate.
Data Rate	Percentage of the base transmission rate at which the sensor generates and transmits data

Table 2. Simulation Parameters for STGen Sensor Testbed

Parameter	Description
STGen Core IP	IP address where the server listens for incoming connections.
Sensor Port	UDP port where the server receives sensor data from simulated sensors.
Client Port	UDP port where client applications request to receive sensor data.
Simulation Time	Total simulation time in seconds.

Table 3. Simulation parameters for STGen Core

Parameter	Description
Log Directory	Specifies the directory for storing output sensor logs on the client side.
STGen Core IP	The IP address of the STGen Core.
STGen Core Client Port	The port number of the STGen Core where the client sends requests.
Simulation Time	The total duration of the simulation in seconds.

Table 4. Simulation Parameters for STGen Client

This section describes the recommended environments for the deployment of sensor nodes for simulation and how to configure those nodes in the simulation. In addition, this section presents how to benchmark the STGen platform in both the local machine and the distributed networking system.

Tables 2, 3, and 4 delineate the respective parameters for the STGen Sensor Testbed, the STGen Core, and the STGen Client.

Deployment of Sensor Nodes::

The STGen environment currently supports five different types of sensors for deployment, such as temperature, humidity, camera, GPS, and switch (on / off). These sensors are selected by CLI or the Web interface. The number of sensors for the experiment depends on the configuration of the workstation system.

Hardware Configuration of the Workstation::

The system configuration of the workstation used in the experiment is the following:

1. Processor: AMD Ryzen 3600X

2. RAM: 36 GB

3. SWAP Memory: 6 GB

4. GPU: NVIDIA 4060 Ti

5. Operating System: Ubuntu 24.10

Traffic Control Configuration::

The tc (Traffic Control) tool (Developers, 2020) was used to simulate network conditions that mimic real-world environments. The following configurations were applied:

• Bandwidth Limitation: Unbounded / 100 Kbps / 10 Kbps

• Packet Loss Simulation: 0%, 1%, 5%, 10% packet loss using netem

• Latency: 10 ms maximum latency for packets

⬇

$sudotcqdiscadddevlorootnetemrate10kbpsloss10%

The commands stated above illustrate how bandwidth limitation and packet loss were applied in the experiment.

Figure 5. STGen Testbed Launcher Web UI.

Figure 6. Real-Time Delay Statistics of Network Traffic in STGen Traffic Analyzer – This graph shows the minimum, average, standard deviation, and 95th percentile of frame time delta (delay) over time, visualized using the ELK stack for real-time traffic analysis.

Testbed Simulation with Web UI::

A web-based user interface (WebUI), as shown in Figure 5, has been implemented to set up and control the experiments with the STGen testbed. The WebUI makes the testbed more user-friendly compared to the CLI mode for monitoring sensor nodes in the IoT network. The testbed also supports the control of the system. Users can assign values to different parameters and start simulations using the user interface and trigger the direct streaming of the process logs to the interface, which improves transparency and makes debugging easier by providing real-time feedback.

Realtime Network Log Analysis::

To determine the efficacy of the underlying protocols, network performance analysis is crucial during client-sensor interactions through the STGen middleware. Capturing real-time network traffic at the designated STGen middleware ports is achieved using TShark, the command-line version of Wireshark. However, raw traffic data lacks structure and requires transformation for meaningful analysis, necessitating the identification of key performance metrics such as latency, jitter, packet loss, retransmissions, and protocol overhead. To address this, Logstash preprocesses and transforms the raw traffic data into a structured format in real time, extracting relevant insights before transmitting it to Elasticsearch, where the data is indexed and stored for efficient querying and analysis (Elastic, nd).

The STGen core node captures this network traffic by extracting real-time data from specific UDP ports and outputting it in JSON format, making it easier to feed into Elasticsearch for further processing. Researchers evaluating communication protocols can leverage this indexed data to analyze protocol performance under various conditions. By integrating Elasticsearch with Kibana, researchers gain access to dynamic, real-time visualizations that enable effective benchmarking of network behaviors. Kibana’s dashboards, time-series charts, and heatmaps provide insights into latency trends, traffic congestion points, and packet size distributions across different sensor nodes. By tailoring these visualizations to emphasize specific network performance metrics, researchers can extract actionable insights from STGen’s network traffic, optimizing both protocol design and middleware efficiency. Figure 6 illustrates real-time delay statistics visualized in Kibana, showcasing the effectiveness of this TShark and ELK workflow in STGen’s testbed analysis.

(a) The start-up time of the STGen platform for varying the number of sensor nodes from 1K to 6K under different RAM configurations.

(b) Memory footprint of the STGen platform for varying the number of sensor nodes from 1K to 6K under different RAM configurations.

Figure 7. Performance Analysis of the STGen Platform Under Varying Sensor Node Configurations

Figure 8. CPU (6 core) Utilization percentage of 3000 concurrent sensor node processes over a 5-minute monitoring interval.

9. Results and Observations

Table 5. Delay Statistics for Temperature Data Packet Transmission from STGen Core to Client at Varying Bandwidth and Packet Loss Rates.

Client	(Bandwidth, Packet Loss Rate)	Mean Delay (s)	Max Delay (s)	Min Delay (s)	Variance Delay (s)
1	(Unbounded, 0%)	0.000224	0.001	0	0.0000001915
2	(100 kbps, 5%)	0.01297	0.013	0.012	0.00000049
3	(100 kbps, 10%)	0.01228	0.013	0.012	0.000000483
4	(10 kbps, 5%)	0.07277	0.517	0.033	0.02515
5	(10 kbps, 10%)	0.04164	0.316000	0.034000	0.00191

(a) Contribution of each sensors over 1 hour time intervals (1 hour)

(b) Frequency of each sensors

Figure 9. Packet Distribution Analysis of different sensors deployed on the STGen Testbed.

In this work, we have investigated the time taken to start up the STGen platform by varying the number of sensor nodes. In addition, the average latency for retrieving particular information from the STGen ecosystem has been considered an important KPI. The observations for the STGen system to boot are summarized as follows:

1. Time taken to boot STGen platform consisting of six thousand sensors: 21.981 seconds

2. Average latency to retrieve information from a particular sensor: 0.01965 seconds

3. Memory consumption by the STGen platform with the 6K nodes (including swap memory): 38.3 GB

Since the sensor nodes of the STGen are predominantly memory-constrained, the simulations were primarily conducted on a machine with 36 GB of RAM, with additional tests performed on machines with 16 GB and 28 GB of RAM. Each experiment was performed for 30 seconds while varying the number of nodes and maintaining an equal distribution of each sensor type. This procedure was carried out ten times to guarantee predictable outcomes. We observe from Figure 7a & 7b that decreasing memory not only limits the number of deployable nodes it also affects boot times with available memory. The root cause behind this observation may be the operating system, which spends extra time managing memory allocations.

To evaluate the system’s capacity limits, all three components of the STGen core, client, and sensor nodes were deliberately co-located on a single machine. This configuration caused system breakdowns during the experiments due to substantial computational overhead and the simultaneous logging of sensor traffic data to local storage.

(a) Heatmap representation of temperature variations over time.

(b) ON/OFF state visualization of switch activity along the route.

(c) Spatial distribution of camera data, with intensity indicating high packet activity.

(d) Visualizations of GPS sensor locations data.

Figure 10. Visualizations of packet transmission patterns over a geographic region, showcasing density, state changes, spatial distribution, and sensor interactions.

The experiment of benchmarking the startup of 7k sensor nodes has failed due to our experiment’s limited system resources. We observe that initializing more than 6k sensor nodes causes issues with our experimental setup’s available RAM, swap, and virtual memory. However, our workstation can handle up to 6k nodes with a memory footprint of about 38.3 GB, while the physical memory is only 36 GB. The benchmark is run with CLI commands, as the backend (Java) and frontend (Next.js) of the web application cause extra memory overhead. The system.process.cpu.total.norm.pct metric, as shown in Figure 8, represents the total percentage of CPU time consumed by 3000 sensor node processes. It was observed to peak at 0.6% during sensor startup and remain at 0% during subsequent periods when simulating thousands of sensor nodes concurrently. This behavior indicates minimal CPU usage per process, particularly during periods of low system load. Since the modules are decoupled, and in real-world scenarios, clients can request sensor data at any time, each module operates with an independent simulation period, ensuring they do not interfere with one another. The execution time $T$ for generating sensor data is determined by the simulation time period $S$:

(1)$$T=S$$

Every sensor type on the STGen testbed is programmed with the default transmission rate. The waiting time between consecutive data transmissions, which defines the data rate, can be adjusted without altering the execution time $T$. Given an initial transmission interval $I$ (the default timeout for a sensor type), the adjusted interval $I^{\prime}$ is determined by a percentage factor $P$ (ranging from 1 to 100), which will be taken as input through the CLI arguments:

(2)$$I^{\prime}=I\times\frac{100}{P}$$

An increase in $P$ results in a decrease in $I^{\prime}$, leading to a higher data transmission rate. However, a decrease in $P$ increases $I^{\prime}$, reducing the transmission frequency of the data. Since the execution time $T$ remains unchanged, this approach allows dynamic control over data rates without interfering with the real-time execution of the sensor modules.

All simulations were conducted on 5 different components, such as temperature, humidity, GPS, switch, and camera, to ensure systematic analysis. Figure 9a represents the number of packets transmitted over one-hour time intervals in a six-hour-long simulation. The packets are categorized according to the contributing components: camera, humidity, temperature, device, and GPS. The total number of packets remains relatively stable across the time intervals, with some variations in each sensor type’s contribution, which is shown in Figure 9b. The camera sensors are the most data-intensive due to high-resolution data transmission, whereas devices and GPS sensors contribute significantly less.

Figure 10 is derived from the simulated dataset for elaborated visual representations, providing insights into sensor activities and their spatial-temporal patterns. These visualizations are crucial for understanding the data quality and behavior of simulated sensor nodes, helping improve data transmission efficiency, and anomaly detection. Figure 10a is a heatmap of temperature fluctuations along the simulated path, where warmer colors represent higher temperatures and lighter colors represent lower temperatures. Similarly, A binary visualization of switch ON/OFF states along the route is depicted in Figure 10b, with active states in green and inactive (OFF) states in red. The visualization of Figure 10c highlights regions with frequent image or video capture events. Here, the intensity of yellow and orange hues signifies higher packer activity. Lastly, Figure 10d provides the correlation between GPS sensor locations and packet transmission counts. These insights, generated from STGen simulations, enable researchers to assess and optimize the quality of traffic data generated by simulated sensor nodes.

10. Comparision with Gotham & GothX

Figure 11. Memory Footprint Comparison: STGen vs Gotham for Varying Sensor Node Counts.

In this article, STGen has been compared with the two most popular testbeds, Gotham and GothX, respectively, with the latter being developed as an improved version of the former to meet further demands and challenges in IoT simulations. The purpose of this comparison is to demonstrate the effectiveness of STGen in terms of resource utilization and startup time in performing large-scale simulations. As shown in Figure 11, STGen consistently outperforms Gotham in terms of memory usage, with reductions ranging between 84% and 89% as the number of nodes increases. The percentage reduction decreases slightly as the number of nodes increases. This result indicates a diminishing return but still a substantial reduction overall. The lightweight design of STGen results in approximately 87.5% lower memory usage, requiring just 2.56 GB of RAM to initialize 450 nodes, compared to the 20.4 GB exploited by GothX. GothX takes approximately 26 minutes to set up a large topology with four VM nodes and 498 Docker nodes, whereas STGen takes just 1.645 seconds to initialize 500 sensor nodes along with one client and one core node. This represents a significant improvement, reducing the setup time by 99.9%. Despite the fact that virtual machines (VMs) and Docker nodes are effective in complex virtualized environments, it is clear that Gotham and GothX incur significant overhead due to their reliance on them. The lightweight architecture of STGen thus provides a more efficient and rapid initialization process, making it highly suitable for scenarios requiring quick setup and scalable IoT simulations.

Figure 12. The Ecosystem of the distributed STGen Testbed and potential future work based on Big Data Analytics

Gotham & GothX enables the deployment of complex network topologies by leveraging virtual machine (VM)-based nodes, each requiring substantial computational resources. However, this approach incurs significant processing overhead, which makes large-scale IoT simulations on a single machine computationally impractical. The allocation of resources to multiple VM nodes leads to excessive CPU and memory consumption, resulting in system bottlenecks and resource contention. Consequently, the high computational demand restricts scalability and degrades the performance of other concurrent processes running on the system. To maintain a lightweight architecture, STGen does not natively support the deployment of complex network topologies; rather, it prioritizes a streamlined setup process to facilitate efficient protocol evaluation and experimentation.

The features of STGen enhance its capability and scalability as a tool for the experimentation of the IoT protocol while ensuring adaptability for future developments. STGen provides a solid basis for simulations of varying scales, effectively connecting controlled testing settings. In addition, STGen supports comprehensive guidance on streamlining the process of test environment setup and maintenance to facilitate seamless IoT testing composed of different types of sensors. The Web-Based UI adds easy interaction and visualization of IoT simulations in the user-friendly web application. The modular architecture of STGen allows for the distributed deployment of the entire ecosystem across various premises. This feature enables STGen to scale from thousands to millions of sensor nodes with almost no configuration effort.

11. Future Work

This section explains how STGen can serve as a suitable tool for research on the Internet of Things (IoT) to automate decision-making and Big Data Analytics. According to the figure 12, The STGen core, acting as a middleware, has the potential to serve as a large-scale data generator. The generated data, after being parsed into the processed data, can be fed into a statistical tool to derive meaningful statistical insights. To ensure that the STGen testbed remains competitive and future-ready, its development will be guided by many crucial areas. Traffic data will initially undergo preprocessing, followed by comprehensive visualization and analysis utilizing machine learning methods. Based on analysis, the intelligent system can dynamically adjust the STGen core parameters to make traffic more realistic and contextually relevant. Since all traffic data and network packets will be analyzed, predictive analytics will be used to proactively detect system performance bottlenecks and optimize data generation processes in real time. This adaptive approach will improve automation and efficiency while refining intelligence in IoT simulations, paving the way for more responsive and self-optimizing systems. However, considering the low-cost model of cloud resources, usability and accessibility can be further enhanced by deploying the STGen testbed in the cloud using Terraform (Infrastructure as Code) (HashiCorp, nd) for large-scale testbed simulations.

12. Conclusion

This paper introduced STGen, a scalable and cost-effective sensor traffic generator designed to facilitate the experimentation of IoT protocols by emulating wireless sensor networks (WSNs) in a hybrid environment that addresses key challenges associated with the deployment of real-world testbeds, including financial constraints, resource limitations, and scalability problems, by providing a lightweight yet powerful alternative. Its modular design enables researchers to conduct empirical studies on IoT protocols, which also allow new integrations or enhancements to be developed and deployed in isolation without affecting other modules, such as the integration of the ELK stack, enabling real-time traffic analysis, offering immediate insights into sensor activity and protocol behavior. Researchers can interact with STGen through various interfaces, a command-line tool (CLI), a web dashboard, and REST API endpoints following OpenAPI standards. Researchers can utilize these interfaces for a wide range of experiments, such as simulating and mitigating DoS attacks, automating test environments, and assessing protocol performance under high-traffic loads. Although most popular testbeds struggle to run hundreds of sensor nodes on a single machine, the lightweight design of STGen enables it to handle thousands with ease. STGen offers a fast start time of 21.981 s for 6,000 nodes and uses only 38.3 GB of memory, outperforming recent testbeds like Gotham and GothX. Looking ahead, a key direction for STGen is automating the deployment in cloud environments using Terraform, an Infrastructure-as-Code (IaC) tool that ensures scalable, repeatable, and automated provisioning of cloud resources.

Appendix A STGen Usage Guideline

This appendix contains the prerequisites & installation process to run STGen.

A.1. Prerequisites

• 1: Python3 is also a prerequisite. You can check if Python is installed on your device by running the following command.

  ⬇

  $python3

A.2. Installation to run in terminal mode

• Step 1: Download the GitHub repository or clone it using the following command .

  ⬇

  $gitclonegit@github.com:rahmanmehraj182/Hybrid-IoT-Platform.git

• Step 2: Open a terminal in your computer. Now, change the directory to run the server.

  ⬇

  $cdSTGen-Sensor-Traffic-Generator/launcher

• Step 3: Run the Server.

  ⬇

  $python3STGen_server.pylocalhost50045005100

• Step 4: Open another terminal tab and stay in the launcher directory. Now, run the Sensor(s).

  ⬇

  $python3STGen_launcher.pylocalhost5004200temp:30:1gps:10

• Step 5: Open one more terminal tab and change the directory to run the client.

  ⬇

  $cdSTGen-Sensor-Traffic-Generator/iot/application

• Step 6: Run the client.

  ⬇

  $./STGen_client-lclient1_sensor_log-slocalhost-rtemp_1-p5005

A.3. Installation to run from WebUI

System Requirements: Node.js 18.17 or later.

• Step 1: Download the GitHub repository or clone it using the following command .

  ⬇

  $gitclonehttps://github.com/subratanath123/STGen-A-Novel-Lightweight-Sensor-Traffic-Generator-Web-UI

• 2: Open a terminal on your computer. Now, change the directory to the downloaded codebase.

  ⬇

  $cdSTGen-A-Novel-Lightweight-Sensor-Traffic-Generator-Web-UI

• Step 3: Run the WebUI.

  ⬇

  $npmrundev

• Step 4: Open another terminal window.

• Step 5: Download the WebUI backend GitHub repo or clone it using the following command .

  ⬇

  $gitclonehttps://github.com/subratanath123/STGen-A-Novel-Lightweight-Sensor-Traffic-Generator-Backend-Launcher

• Step 6: Change the directory to the downloaded codebase.

  ⬇

  $cdSTGen-A-Novel-Lightweight-Sensor-Traffic-Generator-Web-UI

• Step 7: Run the WebUI Backend

  ⬇

  $./gradlewbootRun