Modeling Real world Network conditions
Easily simulate network conditions such as network latency, jitter, packet drop and content corruption with our IoT Network Simulation tool and measure the performance of your IoT servers.
As more and more devices join the internet every day, the performance of IP network connectivity becomes critical for the overall system performance. As a result of global events such as undersea cable cut, or major outage of an Internet Service Provider, your IoT system performance could get severely affected. Another important consideration for IoT system design is to determine the optimal bandwidth and mimimum acceptable latency for your wireless communication medium. Would your system need an upgrade to 4G connectivity (requires more power and cost) vs. GPRS/EDGE? What is the worst case delay your MQTT broker could handle while delivering a QoS 2 to your device. How would your system perform under severe packet loss or corruption? If you are using UDP, how would packet reordering affect your system performance?
IoTIFY’s network simulation tool helps you answer these questions in a simple and intuitive way. Combining the ability to emulate Smart IoT endpoints in the network with simulating real life network condition, you could build a stable and reliable IoT system in advance. You could also fine tune your system parameters such as load balancers, reverse proxies to better handle the traffic without overprovisioning resources and burning holes in your pocket for your IT expenses.
So let’s get started.
For this demo we will use a simple template named hellonetwork. Go to the top level menu Network and click on Templates. Then click on New template icon.
The new template will be based on MQTT by default. Let’s keep it that way. The contents of the new templates are also prepopulated. For this exercise, we will only change the QoS value of MQTT message to 1 and keep the rest of the values to default.
Let’s just give a name to this new template hellonetwork and save it.
Important: In order to measure the latency of MQTT messaging its necessary to change the QoS to 1 or 2. This is because QoS > 0 requires the MQTT broker to ack your message. If you don’t use a higher QoS value than 0, the real latency can not be measured at the application level.
As soon as you save the template, you will be directed to simulate tab. The simulation tab is where you specify how do you want to run this simulation.
Choose your newly created template hellonetwork on the left hand side drop down menu. Choosing the template will automatically assign a name for this instance of simulation. We will change this to something easy to remember such as nolatency because for this run we are not simulating any Network latency.
Let’s provide number of clients to 100 and keep other settings to their default values.
You will notice the tab named Network Modelling. For this run, we dont change any thing into this tab as we are interested in measuring the current latency of the MQTT publish. Let’s just click Start Generation and wait for the simulation to complete.
The simulation will run for 5 minutes and at the end you will see the average message publish latency per client.
In our case we got an average publish latency of 242 ms over public MQTT broker. Note that this value could change significantly based on other clients, network load or status of public MQTT broker.
Well enough, now lets apply a delay of 300 ms on network level and see how the average publish latency changes.
Go back to the simulate tab and name this simulation 300ms. Change the number of clients to 100 again and this time, lets put a value of 300 into the average delay tab.
Notice that we have also specified a jitter of 50 ms. Since the average delay in the network is never a constant value, applying a jitter makes it more real life.
Now run this simulation once again and wait for the result.
Wow, the average publish latency is now changed to 571 ms which is around 330 ms more than our previous one. This is more or less what we would expect.
Any parameter you change here will only apply to outgoing packets from the network simulator. Currently we don’t support modifying latency for incoming packets.
Specified in milliseconds, this is the amount of minimum delay applied to each outgoing packet.
Specified in milliseconds, this is the amount of random variation applied over average latency. So the real delay applied at any given point of time would be Average +- Jitter.
Specified in %, this is the number of packets which will be randomly dropped from the outgoing stream. Note that in case of TCP, the IP stack will retransmit the dropped packets.
The drop is applied at burst mode, which means many packets are likely to be dropped sequentially.
Specified in %, this is the amount of packets which will be duplicated in outgoing stream.
Specified in %, this is the amount of packets which will have a single bit error at a random offset in the packet.
Specified in %, this is the amount of packets which will be sent out of order in outgoing stream.
The network modeling tab has many other parameters which can be controlled to accurately simulate your network condition. We have also created some predefined templates for commonly used media, which you could simply apply from the list. Note that these templates parameters are approximate and may not be accurately representing the conditions you may face. Feel free to change the settings and experiment with your system.
Note that excessive drop or corruption value could actually cause your simulation to fail entirely. It is therefore a good practice to keep the value to a moderate level (< 5%).
Following reference materials could be of great help if you want to dig deeper into the subject.