IP impairment use cases
Improve the time to market
Delay, jitter, and drop
The most basic building blocks of IP impairment are delay, jitter, and drop. Our tools allow you to focus these deviations in the specific traffic flow you want, and in high data rates.
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. 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 by altering these basic IP impairments 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 deviation emulator Rude, it is possible to create scenarios of all of these deviations. To find out the maximum limits the network can take, it is possible to create a timed scenario where the amount of delay, for example, is gradually increased.
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 IP impairments
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.
Using the Rude IP deviation emulator, 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
Rare priority classes as an example
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 to create the scenario you want.
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.
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 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.