Emulating geographical distances

The most basic network emulation use cases are related to emulating geographical distances. The effect of the distance, and network nodes and satellite hops can be modeled using delay, jitter, and drop.

In a real-life network, the received signal is never the same as the original signal. When the signal travels the network, some deviations will always happen. The physical distance the signal needs to travel in the network will cause an inevitable delay, be it from the distance between company sites or due to the signal being routed through a satellite. All the network nodes will add additional delay, but also add jitter and packet drop to the signal.

Emulating physical distances

Emulating a physical distance will let you see how the real distance will affect your service quality. With this data to back up your decision, you will be able to strengthen the network to withstand the challenges. Also, this will let you estimate the QoE (Quality of Experience) with a given level of network quality.

With the network emulator Rude, you can create scenarios of all of these deviations.  You can stress your system to the limits by creating a timed scenario with an increasing delay. The precision of the network emulator Rude lets you control the delay in the microsecond level and drop exactly the packets you want to ensure your system is fully tested.

Testing robustness of streaming services

In real life, IP traffic is not a constant flow of flawless packets. Instead, the traffic may be delayed or bursty. Sometimes the bandwidth may be limited or the line may be down entirely for periods of time. On the byte level, packets may be dropped or corrupted or fragmented into smaller packets, and data may be lost or changed on the way.

Focus on the important deviations

In streaming protocols, the initial delay is not the main concern. However, jitter may be the cause of the poor end-user experience. To test the system robustness, you can deviate the traffic in a precise way to find the limits.

The picture above outlines an example of a video streaming service. The service is used by a large group of users using various types of equipment to view the content.

Stream-specific deviations

Using the Network emulator Rude, it is possible to target only certain data streams for deviation, based on, for example, protocol or IP address. Then, you can focus the deviations on the chosen data streams by adding deviations that emulate realistic network conditions. It is also possible to vary those deviations over time, to observe gradual changes. This setup allows you to empirically test the resulting Quality of Experience.

The arrival of 5G changes the network topologies. The changes include splitting the base station elements into the Central Unit CU and the Distributed Unit, DU. This change introduces a new fronthaul interface between the units, that needs strict requirements for latency with attention to jitter.

A few examples of challenges the F1 interface include:

• The physical distance between the units may be as much as 15km. The distance causes an inevitable time delay. As a rule of thumb, the delay is 5us/km.
• The interface needs to maintain accurate time synchronization. Any deviations in the synchronization are likely to affect the system performance. Therefore, stressing the synchronization with deviations will reveal how much errors the systems can withstand.
• The 5G systems are designed to require a low BER. Testing with increasing the BER to close and above the threshold will reveal system limits.
• One of the several DUs may go dark, in which case recovery and replacement procedures need to be tested with emulated line breaks.

Creating complex scenarios with a simple setup

Network emulation use case: rare priority classes

Even rare occurrences happen. Events that happen rarely or at random can give the maintenance team headaches if they first occur in the live network.

The reason these events are often missed is that the testing teams are pressed for time. The good news is that this is exactly the kind of case where Deviation Emulator Rude can help. Using the Rude, it is possible to set up even complex scenarios quickly and easily.

Complex IP impairments, easy settings

For example, rare priority classes may occur simultaneously, affecting the system’s robustness. Creating each and every possible scenario would be a burden.

To create such scenarios in an easy and quick way, we have created the Data Content Modification feature. It allows you to modify headers and specific bytes in real-time on the selected flows. The Rude always works as a Man-In-The-Middle, and in that position, it can modify the bytes on the go. The feature allows you to reset the priorities of the selected traffic. In the receiving end, the traffic will seem to have been sent as it is.

You will be able to create the testing scenarios easily and quickly in real-time, without actually adjusting your system settings.

How does Data Content Modification work?

The data content modification feature allows you to directly alter the header fields in certain protocols. Also, you can modify certain bytes in the header by removing, adding or changing the bytes.

Network congestion

At times, everyone wants to be online at the same time. When there is a concert or a football match or new year’s eve, everyone will be online at the same time. This can cause traffic bursts where the network load increases suddenly.

A large number of users will affect network performance. To find out how your network behaves under a heavy traffic load, you can create the environment using our tools.

To emulate a congested network with Deviation Emulator Rude,  you can use ready-made traffic profiles that match real-life conditions in 3G and 4G networks. Alternatively, you can build the conditions from scratch in a few easy steps.

A severe case of congestion may lead to random call and message drops, that is due to the high packet drop caused by the congestion. In the above picture, you can see how the Rude deviates the traffic: the deviations can be focused on specific traffic flows, each with their deviation setting.

Traffic bursts

Traffic bursts can happen at the same time as traffic congestion. They can be easily emulated with the tool as well. The tool creates the scenario by buffering the traffic for a short period and then sending out the traffic in short, intense bursts. You can set the amount of buffered data and duration of bursts easily from the tool GUI. These traffic bursts will test the network capability to handle a sudden increase in the traffic.

Recovery from service breaks

The network service may be down due to a crash or planned maintenance. Testing the network’s ability to recover from such a break is critical to see if automatic recovery is possible or whether some manual configuration needed.

Stressing the recovery to the limit will let you find the limits of those recovery capabilities. For example, you can create a recurring line break scenario, that will surely expose any weaknesses, or in the best case, confirm that the recovery processes run smoothly.

You can use network emulation to test the robustness of the system. To know how your system handles broken and faulty packets, you need to test it. The Rude network emulator offers several possibilities to create suitable testing scenarios.

Using the Rude, you can directly modify values in the packet header, for example, the TTL value. You can choose to recalculate the checksum or leave it deliberately uncalculated. When the modified packet reaches the next network node, you will see how it responds to the faulty packet.

Another possibility to stress your system is to fragment the packets to very small fragments. Small fragments that are re-ordered load the system resources heavily. Dropping a few of the fragments will take an even heavier toll on the system resources.

Using these deviations will give you insight into how your system deals with bad packets. The CPU load caused by malformed packets may be enough to knock down your system. It can also open a window of opportunity for cybercriminals to enter your system.

Network challenges affecting timing and synchronization

Accurate timing is essential to any network, but especially when it comes to 5G, which relies on accurate timing and low latency. Also, in a distributed 5G system there are more interfaces than in a traditional, centralized system, and thus, more interfaces to be tested.

Timing messages, such as NTP or PTP messages, can be delayed or lost or corrupted. They may also be affected by the typical delay and jitter in the network. The message sequences can become scrambled. How will the system behave when faced with out-of-spec timing messages?

Using network emulation to test the robustness

Using network emulator Rude, it is possible to add errors into the timing messages. Some examples:

• Creating errors in the message timing by adding delay and jitter, in several interfaces at once. This is done to see how the system can manage under poor synchronization and to define limits for how sensitive each interface is to the errors.
• Scrambling the message sequence to create a more stressful scenario.
• Directly altering the message contents, to see how the system can handle errors and unexpected data.
•