OMNeT++ and Riverbed: Comparing the Features and Accuracy of Network Simulators for Throughput Using a Network Testbed

1. Introduction

The network performance study using a testbed measurement approach is preferable because it inherently includes the interactions between the real hardware/software and the environment. It also provides an unbiased representation of the radio channel without any assumptions on how signals propagate in the environment. Although this testbed approach is time and labour intensive, it can be significantly reduced by automating the testbed experimental system and process as highlighted in [1]. While the testbed results are credible, it takes lot of resources such as hardware and software to set up properly for a medium to large sized network. For instance, it is not very practical to set up a testbed for a network performance study for nodes greater than 20. Due to not having adequate time and resources to conduct such testbed measurements for design and performance study, most turn to network simulators due to their flexibility and easy to setup and run simulation for any number of nodes. Simulation are also being used for validating analytical models and to generalization the research findings. As there are various network simulators available, it is difficult to select which one to utilize since they each have their strengths and weaknesses. There are numerous published and white papers that go over different network simulators, but they solely touch on the inner workings of each network simulator and don’t compare results against a network testbed [2].

Comparing results obtained from both OMNeT++ and Riverbed Modeler against the physical network testbed results obtained through field experiments [3]. The testbed results add credibility to our findings because it is used as baseline to compare the features and accuracy of two selected simulators investigated. The data obtained in the network testbed allows us to closely replicate the network with similar parameters and compare the accuracy of results against one another in this paper. Backed up by Arvind, T. [4], OMNeT++ is a component-based, modular, and open-source network simulator that is a C++-based discrete event simulator, whereas Riverbed Modeler (formerly OPNET Modeler) is a commercial network simulation package that offers GUI-based debugging and analysis. Assessing these reputable network simulators against a network testbed reveals the level of accuracy that both simulators operate at. In this paper, we therefore select an indoor field experiment at the university library building to replicate in each respective network simulator to obtain throughput results for comparison.

We conducted a testbed measurement campaign through indoor field experiments to measure the Gigabit Wi-Fi (802.11ac) link throughput by varying AP-Rx separation (Rx: Receiver; a wireless laptop) as reported in [3]. This link throughput is used as baseline and taken into consideration when validating the simulation results of OMNeT++ and Riverbed Modeler. The average link throughput collected from each network simulator is the main vector recorded in this paper to better compare the two network simulators. Although IEEE 802.11ax and IEEE 802.11be (the latest Wi-Fi standards) are available for testbed link throughput study, we used 802.11ac Wi-Fi card because of its availability in both simulators under study.

The AP-Rx separation ranging from 5 to 25m was considered due to the simplicity in setting up things and to create an accurate network simulation with as little mistakes as possible. Due to 802.11ac only utilizing 5 GHz band, AP-Rx separation would also show more drastic throughput degradation on the high-bandwidth channel, and short distance coverage that this technology offers. A constant stream of multimedia traffic was implemented in both simulators to match the criteria of the network testbed. We also ensure that the increment of AP-Rx separation (5m, 10m, 15m, 20m, and 25m) and the simulation parameters and system configuration are identical in both simulators to avoid bias results.

The purpose of this paper is not to generalize or label one network simulator as “better” over the other, as there are many simulator-specific factors to take into consideration. The objective of this study is to outline the accuracy of the network simulators regarding AP-Rx separation in the hope that it can guide network researchers to select an appropriate network simulator for modelling and simulation purposes that can provide unbiased results.

1.1. Research Challenges/Questions

In this study, we address the following two research questions/challenges.

RQ1: Given that both network simulators operate and function differently, how can we ensure that the results obtained are fair and unbiased?

To address RQ1, we developed a network model on both network simulators that matched the conditions that the network testbed was conducted. The network simulation models developed were put under the same radio propagation model, AP-Rx separation, same Wi-Fi networking standard, 5GHz band, and ensured that all available configurations were as close to one another as possible.

RQ2: Given that the network testbed results obtained from field experiments, how can we ensure that the results are fair and accurate when comparing results from both simulators?

To address RQ2, we had to try and fine tune and replicate the conditions that the network testbed had for the configuration of both simulators. Since both network simulators didn’t have the same model of access point (AP) and end point devices, we had to edit the configuration of both simulators to ensure that they have similar specifications to one another so that throughput bottlenecks or other relevant issues would not occur.

1.2. Research Contributions

The main contributions of this paper are summarized as follows.

• We analyze and compare the accuracy of results obtained from two credible network simulators, namely OMNeT+ and Riverbed Modeler. The comparison involves creating and analyzing both ad-hoc and infrastructure network scenarios.
• We develop and configure network simulation models and parameters for both simulators to obtain relevant performance metrics. To this end, we develop various practical scenarios to run and extract useful simulation statistics, especially network link throughputs for system level performance validation.
• We validate the simulation models of both simulators against the testbed results. To this end, we set up a Wi-Fi network testbed to conduct various field experiments involving Wi-Fi links in the multistory university building under line-of-sight indoor conditions.

1.3. Structure of the Article

The rest of the paper is structured as follows: The related work is discussed in Section 2. The testbed approach and field experiments are discussed in Section 3. Section 4 provides an overview of simulation methodology and tools used for network simulation and modelling. The network modelling is discussed in Section 5 and results are presented in Section 6. The comparative results analysis is presented in Section 7. The guidelines for best practice in network simulation and model validation are provided in Section 8 and a brief conclusion in Section 9 ends the paper.

2. Related Work

For telecommunication network performance study, many researchers have used various credible simulation tools including ns-2, ns3, OMNET++, and GloMoSiM for network simulation purposes [1]. Implementation and utilization of a simple topology control algorithm has been conducted against network simulators J-Sim, OMNeT++, ns-2, and ShoX [2]. Research and investigation of functionality and features such as GUI support, memory usage, and simulation capabilities have been conducted for various network simulators, such as ns2, ns3, JSIM, OMNeT++, Riverbed Modeler, and QualNet comparing them against each other [4]. Scalability and performance requirements of five different network simulation tools, such as ns-2, ns-3, OMNeT++, JiST, and SimPy are compared to make recommendation for network researchers [5]. The throughput performance degradation of Wi-Fi network in dense environments is investigation by simulation in [6]. In this paper we compare and validate the link throughputs of Wi-Fi ad-hoc network obtained from OMNET++ and Riverbed Modeler against testbed results.

The summary of the related work on network simulators is presented in Table 1. The author’s paper reference is listed in Column 1, and the corresponding main contribution is presented in Column 2. The accuracy of sumulation results and throughput study are shown in Columns 3 and 4, respectively. The use of network testbed for system performance validation is checked in Column 5.

3. Testbed and Field Experiment

The following section details the network testbed along with field experiment environment [3].

3.1. Network Testbed

Figure 1 shows the network testbed used to study the effect of AP-Rx separation on system performance. The distance between the client and the router is the independent variable that is incremented by 5 meters for every scenario (5m to 25m), and the average throughput is the dependent variable that will change based on the AP-Rx separation value. The Transmitter (Tx) and Receiver (Rx) are both HP Pavilion laptops, with the AP being a TP-Link Archer VR2100. We selected 802.11ac Gigabit Wi-Fi technology (5GHz) due to its availability on both simulators. Going into the AP configuration panel, all other network standards other than 802.11ac have been disabled.

While the network testbed is simple to set up and test, it is important to maintain easy to create network simulation model using 802.11ac is the newest network standard implemented into both OMNeT++ and Riverbed simulators and so they could behave unpredictably at times. The host is a transmitter (Tx) that sends packets to the client (receiver/Rx) via an AP. The client is a wireless laptop that can be moved around for increasing and/or decreasing AP-Rx separation for various field experiments. The field study environment is discussed next.

3.2. Field Experiment Environment

The field experiments were conducted on the 6^th floor of the university library building, Auckland University of Technology (Figure 2). The library building (corridor space) was selected for easy access and appropriate for our study. Since the corridor is 39 meters, it will allow plenty of space to set the field experiments up, since the only variable that should be changed is the distance between the AP and Tx. The Tx and AP were kept at a fixed position on one end of the corridor; Rx was moved at varying distances from the AP (5m – 25m). Additionally, there are no other devices in the corridor that could be transmitting data and potentially altering the collected results. The transmission time, throughput, and throughput degradation are recorded for each increment of AP-Rx separation.

4. Overview of Simulation Methodology

Network simulators emulate networks in different ways and carry out mathematical calculations to capture the interactions between various networking devices. Both simulators used in this paper utilize discrete event simulations in which events are stored and processed to simulate a network more accurately [4,5]. The only problem with discrete event simulations is that they generally take quite a while to simulate as they have a high load on computing resources. The selected two network simulators are discussed next.

4.1. Network Simulators

This section provides an overview and capabilities of both OMNET++ and Riverbed Modeler simulators.

OMNeT++: It is a C++-based discrete event simulator for modeling communication networks, multiprocessors and other distributed or parallel systems [7]. Additionally, OMNeT++ is open-source simulation software that can be downloaded and installed at no cost. Utilizing individual modules and the ability to create new modules, OMNeT++ is built around the Eclipse IDE and supports various simulation models such as the INET Framework or Mobility Framework. OMNeT++ defines the structure of the model as NED, which is their topology description language, where they provide the ability to drag and drop network modules onto a created network, as well as allow the user to edit the source file directly. OMNeT++ has INI (initialization) files that allow for configuration implementation to set up the network under different scenarios, along with allowing for the creation of source and header files for the network model as it is built for use around the C++ programming language.

Riverbed Modeler: It is a commercial network simulation package where the simulation library is based on C [8]. We selected this Riverbed in the study because we had an academy license for Modeler Wireless Suite.

Riverbed utilizes a hybrid model, using a finite state machine in conjunction with an analytical model. It has a rich library of standard models, with many existing models being provided by the vendors themselves. It offers an easy-to-use GUI to create any network, allowing the user to change parameters on each model to fine tune the models to their specific needs. There are many quality-of-life features that can help to create larger networks with ease, instead of having to do everything individually. It additionally has an IDE for the development of devices, protocols, network mechanisms, and algorithms if they are not pre-existent.

5. Modelling the Network

5.1. Scenario 1: Modelling Ad-Hoc Network

We first develop an ad hoc network considering five scenarios based on AP-Rx separation of 5m, 10m, 15m, 20m, and 25m for each simulator. It is very important that the network simulations are modelled in the exact same way and configuration for comparison purposes.

The OMNeT++ network model was set up by utilizing modules available from the most recent INET framework [9,10]. As such, the standard Host module was used for the server (transmitter), the access Point module was used for access points, and the wirelessClient module was used for wirelessClient1 (receiver), with a 1Gbps link being used between the receiver and the AP. The physical Environment module, Ipv4NetworkConfigurator (configurator) module, and Ieee80211ScalarRadioMedium (radioMedium) module were also implemented in the network (Figure 3).

The Riverbed Network Model was set up by utilizing the modules that were available after selecting the Wireless LAN technology upon starting the project [11,12]. A wired host named node0 (transmitter) was implemented, along with the wireless router named AP, and the WLAN client named client (receiver). All these models were located within the Wireless LAN technology category to ensure that there were no incompatibility issues. A 1Gbps link was also implemented between node0 and the AP. The application definition (appConfig) and profile definition (proConfig) were also implemented in the network. The modules implemented can be seen below in Figure 4.

Multimedia traffic [13] is characterized by a consistent stream of audio or video data that in our case will have a high bandwidth requirement to best obtain a consistent throughput average result in our network simulations. In both network simulators, a consistent stream of video traffic is simulated by setting up a video size of 10Gb to allow for longer simulation. Additionally, the packet length was set to 1400-byte, along with the send interval was set to 0.001s.

We implemented a Video traffic into Riverbed modeler by creating an application within the application definition module. This enables video streaming and fills the above parameters into the corresponding fields. Implementing this type of traffic for OMNeT++ required a bit more than just selecting the traffic type and entering in the matching parameters. After combing through the parameters listed in [14], the following configuration was added to the INI file to enable multimedia traffic as shown in Figure 5

The physical environment [15] needed to exist within both network simulators to ensure that we were achieving accurate results. Upon starting up the new Riverbed project, it made you set up a few parameters in which office space was selected for our network model, along with x = 1m, and y = 1m so that we could appropriately set the AP-Rx separation without a problem. For OMNeT++, there is no such configuration during the setup and just to be sure, a physicalEnvironment module was implemented in the network alongside the Ieee80211ScalarRadioMedium (radioMedium) module to ensure that a similar physical environment is reached.

As shown in Figure 6, mobility is implemented [16] to ensure that the same distance is being set for OMNeT++ model. Additionally, the physical environment is set to the Flat Ground model, and the radio medium propagation model set to Two Ray Ground Reflection model. Additional parameters were set to ensure that only 802.11ac technology is being used. For Riverbed, we simply selected 802.11ac only’ option and it didn’t require additional steps to confirm that we only wanted to use the 802.11 technology.

We also set up network simulation time to 600 seconds for each scenario to obtain steady-state results across both simulators. The throughput parameter is enabled in both network simulators, through the INI configuration and NED file for OMNeT++ [17], and through the selection of statistics for Riverbed [18].

5.2. Scenario 2: Wireless Infrastructure Network

For our second set of network models, we don’t have the luxury of being able to comparatively analyze results obtained from both simulators against the network testbed. Regardless, this second set of network models are used to compare against each other to compare how close the results are to one another. The number of wireless clients (independent variable) used to carry out simulations and with increasing AP-Rx separation ranging from 10m to 50m. The performance metrics that are recorded for each simulation are throughput (bps), end-to-end delay (sec), and packet loss (%).

The OMNeT++ network model for increase of wireless clients was created similarly to the first set of network models except a video length wasn’t assigned for multimedia traffic so that it would simply keep transmitting data. The OMNeT++ network model for N=10 clients (Figure 7). Likewise, we have developed network models for larger scenarios such as N = 20 and 40 clients (not shown here due to space limitation). Table 2 shows parameters used in the simulation.

The Riverbed network model for increase of wireless clients was created like the first set of network models. Figure 8 is the network model used for 10 wireless client scenarios, and the other two scenarios simply added 20 and 40 nodes, respectively.

6. Results and Discussion

The following section will include data obtained from running experiments in both network simulators for each corresponding set of network models, along with a brief description of our findings.

6.1. Results for Ad-Hoc Network (Scenario 1)

Table 3 shows testbed throughput results along with transmission time, and throughput degradation. [3]. In Figure 9, we plot AP-Rx separation along X-axis and average throughput long Y-axis.

Figure 10 shows the average throughput obtained for the 25m scenario using OMNeT++ simulator (length of simulation 600 seconds). The only variable that has been changed across the various scenarios is the AP-Rx separation for a 5m, 10m, 15m, 20m, and 25m scenarios. No other variable across scenarios were changed across each experiment as they were all kept constant for the sake of keeping the results as accurate as possible. For OMNeT++, an analysis file was created for each of the vector files generated of each individual scenario, and then the average throughput was selected after clicking on the vector tab. After collecting the average throughput, there is a major discrepancy in the results as they don’t reflect the throughput trend through incrementing AP-Rx separation. Figure 10 shows a consistent average throughput of 11.2 Mbps, which is the same across all scenarios.

After collecting the average throughput results, there is a minor discrepancy in the results as they don’t reflect the throughput trend through incrementing AP-Rx separation (Figure 9) for the network testbed. The trend can however be visualized when comparing 5m, 10m, 15m scenarios (13.00475 Mbps) against 20m and 25m as there is a drop in average throughput for 20m (down to 13.002 Mbps) and then a major drop in average throughput for 25m (0.05 Mbps).

Figure 11 compares the throughput collected from all scenarios in the Riverbed simulator against one another onto a single chart. The 5m, 10m, 15m, and 20m scenarios all have drastically higher average throughput compared to what was collected for the 25m scenario. It was necessary to group this data together due to the drastic change of data. The AP-Rx separation of 5m, 10m, and 15m scenarios, we had mean throughput of 13 Mbps, whereas AP-Rx separation of 20m gave us mean throughput of 13.002 Mbps. Surprised by the small drop in mean throughput, we were expecting much greater throughput drops, and therefore lower throughput results but the network simulation model did not obtain as expected. As a result, the scenarios were checked against one another to ensure that only the AP-Rx separation was different across the scenarios and simulations for each scenario was run again. However, the exact same results were captured once again.

There is no comparison chart against the OMNeT++ simulations run because the average throughput captured was the same the whole way through each scenario as discussed earlier.

6.2. Results for Infrastructure Network (Scenario 2)

The following custom tables display the average of each parameter against each scenario for the corresponding network simulator used. Average throughput, end-to-end delay, and packet loss were obtained, and the results are presented in Table 4 and Table 5 for OMNeT++ and Riverbed modeler, respectively.

Figure 12 compares the throughput collected from all scenarios in the OMNeT++ and Riverbed simulator against one another onto a single chart. The results were obtained from their respective methods of viewing the recorded information. Both sets of results follow the same trend where the throughput degrades as more wireless clients are added to the network. As the number of wireless clients goes up, the average throughput received for each client is drastically reduced. The primary difference between the two sets of results however is the magnitude of throughput results obtained from the Riverbed scenarios when directly compared to the results obtained from the OMNeT++ scenarios. While the results are clearly quite higher, this is more than likely due to the way the networks were modeled and not the simulators themselves, which will be touched on more in the discussion and comparative study.

Figure 13 compares the end-to-end delay collected from all scenarios in OMNeT++ and Riverbed simulator against one another which were obtained from their respective methods of simulation output. Both sets of results follow the same trend where the end-to-end delay increases as more wireless clients are added to the network. As the number of wireless clients goes up, the average end-to-end delay for each client increases drastically. The primary difference between the two sets of results however is the magnitude of end-to-end delay results obtained from the OMNeT++ scenarios when directly compared to the results obtained from the Riverbed scenarios. While the results are clearly quite higher, this is more than likely due to the way the networks were modeled and not the simulators themselves, which we discuss in detail later the comparative study section (Section 7).

Figure 14 compares the packet losses for OMNeT++ and Riverbed simulators against one another. The results were obtained from their respective methods of viewing the recorded information, in which packets sent, and packets received were used to calculate the packet loss (%).

Both sets of results follow the same trend where the packet loss increases as more wireless clients are added to the network. As the number of wireless clients goes up, the packet loss for each client increases. The primary difference between the two sets of results however is that Riverbed Modeler recorded packets received, and packets sent as being the exact same for 10 wireless clients, which means that there was a packet loss of 0%. An additional experiment was run, and the same result was obtained. While the results are a little different from one another, this is more than likely due to the way the networks were modeled and not the simulators themselves, which we discuss next.

7. Comparative Study and Validation

7.1. Radio Propagation Model

Riverbed Modeler utilizes the free space propagation model [19], which assumes that the modules are in line of sight (LOS) and takes distance into account. Using Figure 11, the results from each scenario are compared against one another depending on how drastic the results are from one another.

One can observe that scenarios 5m to 20m are all within a range of 13 Mbps for average throughput whereas the 25m scenario has an average throughput of around 50,000bps (0.05Mbps). We also observe that scenarios 5m to 15m are all within a range of 13 Mbps when compared to the 20m scenario which is slightly lower at around 13 Mbps. Based on the results obtained using 802.11ac Wi-Fi technology within Riverbed Modeler communication between AP and Rx heavily drops after 20m separation [20].

The OMNeT++ Model requires you to set the propagation model and path loss model [21], which has been set to both Two Ray Ground Reflection, and Free Space Path Loss for the path loss model. OMNeT++ only lets you pick between ConstantTimePropagation, and ConstantSpeedPropagation for the propagation model and in our case, ConstantSpeedPropagation was used. Looking at Figure 10, we can observe that the average throughput recorded is the exact same across all scenarios so we will have to run additional tests to make sure that nothing is wrong with our INI or NED file.

It is difficult to discuss the accuracy of the two network simulators regarding the accuracy of throughput since OMNeT++ couldn’t utilize a propagation model for the throughput calculations despite the path loss model being set to Two Ray Ground Reflection. To ensure that the path loss model wasn’t interfering with the propagation calculations, the path loss model was set to Free Space Path Loss model, and an additional test was run. Another check was conducted to ensure that 802.11ac technology [22] was in use. Unfortunately, the results remained the same, with the network simulator not taking the propagation model or path loss model into account for the throughput calculations. An additional scenario was created to increase the maximum AP-Rx separation from 25m to 150m. Even after conducting an additional simulation with the separation parameter increased drastically, the results were still the same.

7.2. Model Validation

Comparing all the results obtained from both simulators against the network testbed, one can observe that the average throughput is drastically higher for the network testbed, with both Riverbed and OMNeT++ still having average throughput within the same range. The Riverbed model didn’t produce throughput results that followed the trend of network testbed results. Throughput drops were only clearly noticeable for the AP-Rx distance separation of 20m and 25m. The OMNeT++ model on the other hand could not take AP-Rx separation into consideration when calculating the throughput, no matter what was changed.

There are various possibilities as to why the models could not closely replicate the trend of data that is displayed in Figure 9. For OMNeT++, it relies on the INET framework, whereas Riverbed utilizes its own framework. Despite this, both simulators don’t support 802.11ax technology yet, and with 802.11ac technology being their most recent 802.11 wireless technology yet, there is a chance that there is a problem with implementation of the propagation model, path loss model, or physical environment implementation.

It could also be because 802.11ac only uses 5GHz band, and this might lead to complications in either network simulator. Additional tests with different network testbeds should be carried out to compare our findings and identify the limitations preventing the network simulators from accurately portraying results obtained from the testbed field experiment. Table 6 compares the results of both network simulators against the network testbed.

An additional set of experiments were conducted to further compare the simulators against one another. Due to the absence of a network testbed to compare the results against, the sole purpose was to compare how close the results were to one another, and to see whether the parameters mentioned followed the theoretical trend of data that we were expecting.

By observing the results in Table 6; the average throughput is quite high for Riverbed than OMNeT++. This is most likely due to Riverbed utilizing the low traffic video streaming option when selecting multimedia traffic. The trend of data obtained for Figure 12, Figure 13, and Figure 14 is as expected with the only abnormality across all experiments being that the scale of results is different. Since both network simulators utilize the setup of multimedia traffic differently, it’s safe to assume that the network modeler itself is not at fault. Table 7 compares the key features of both network simulators.

7.3. Wi-Fi Technology Considered in the Testbed

We have used IEEE 802.11ac (Wi-Fi 5) technology in setting up a testbed to validate OPNET++ and Riverbed modeler results. This is because both simulators supported 802.11ac media access control (MAC) protocol. The latest Wi-Fi standard such as 802.11be (Wi-Fi 7) or even 802.11ax (Wi-Fi 6) was not available in both simulators. However, our 802.11ac throughput results (both testbed and simulations) can be used as baseline to validate 802.11ax results when both simulators will support Wi-Fi 6 in future development.

8. Guidelines for Network Simulation Results Validation and Best Practice Checklist

The common network performance evaluation methodologies include analytical modelling, system simulation, and testbed. Simulation methodology is becoming increasingly popular among network engineers and researchers, especially master’s and PhD students for network modelling and simulation purposes. This popularity is because of the availability of various powerful simulation packages, and their flexibility in model development and validation. While simulation can be used to validate analytical modelling, simulation results can be validated using various techniques, including testbed, simulation log file, and compared with similar work. In this section we provide six recommendations that can be used as checklist to validate and report network simulation results.

• Define validation objectives: Listing target system performance metrics (e.g., throughput, delay, and packet loss) and specify acceptable error bounds and confidence level (CI). For instance, 95% CI with a relative statistical error ≤ 5%.
• Select credible simulation tools: Choosing a credible network simulator which is more flexible in model development and validation. The credible simulator offers appropriate analysis of simulation output data, pseudo-random number generators, and statistical accuracy of the simulation results. It is also important to ensure that the results generated by the simulators are valid and credible.
• Validate simulation results against testbed: Comparing simulation results against testbed or published datasets when available. Need to explain any deviations and relate them to model assumptions.
• Statistical validation: Running multiple independent seeds; compute mean, variance, and 95% CI. Applying significance tests (t-test/ANOVA) when comparing scenarios. Reporting sample size and effect sizes and avoid single-run conclusions [23].
• Documentation and reproducibility: Archiving configs, scripts, seeds, and figures with metadata (date, version). Listing assumptions, limitations, and known threats to validity.
• Reporting: Presenting KPIs with CIs, number of runs, and statistical tests. Discussing validity, generalizability, and future work. Including an appendix with parameter tables and topology diagrams.

9. Concluding Remarks

In this paper, two credible network simulators, namely OMNeT++ and Riverbed Modeler, are compared for the accuracy of throughput results against a testbed. For simulation results validation purposes, we developed a network testbed using Wi-Fi cards (IEEE 802.11ac) and an access point (AP) to carry out various field experiments involving Wi-Fi links in the university building under line-of-sight propagation conditions. We obtained WiFi link throughputs to validate simulation models of both simulators. The validation involves configuring and analyzing both ad-hoc and infrastructure network scenarios. Despite Riverbed modeling showing a clear drop in link throughput for increased AP-Rx separation, it seemed to group 5m, 10m, and 15m scenarios close to one another as the average throughput recorded is near identical to one another. In contrast, OMNeT++ throughput didn’t drop with an increased AP-Rx separation (5 to 25 m) which is unusual. Both network simulators seem to struggle to take throughput drops into consideration for only one variable which is AP-Rx separation across the scenarios considered. It is difficult to pinpoint exactly which area the network model is having trouble in; however, everything was done correctly by observing the corresponding platforms, especially for OMNeT++. Despite following the wiki closely however, the trend of the throughput decreasing as distance increased that was expected to appear from the use of both network simulators only seemed apparent to a degree in Riverbed Modeler. This discrepancy in throughput results between two well-known simulators provides a useful lesson for network researchers and practitioners in selecting the most appropriate simulator for network simulation and performance modelling purposes. In this paper, we highlighted several guidelines for best practice in network simulation and model validation.

The link throughput performance comparison of two network simulators using the latest Wi-Fi technology 802.11be (Wi-Fi 7) is suggested as future research work. Other parameters could also be explored, such as end-to-end delay, to confirm that the network model is taking the AP-Rx separation into consideration before measuring the results.