Terminal testing for network operators: the applications and limitations of a network simulator: Page 5 of 7

July 13, 2015 //By Francois Ortolan, Anritsu (EMEA)
Mobile phone subscribers care nothing about the complex mix of factors underlying the performance of their handset in the real world. By and large, if the user experiences a dropped call, or a low data download rate, or poor voice quality, he or she will blame the network operator. The real cause of the poor performance might be the handset, or the backhaul network - factors outside the direct control of the operator. To subscribers, this is irrelevant: they pay for mobile network service, and if they do not get it, the service provider must be at fault.
The developers of these applications are typically platform-neutral. That is, they design their application to run on a core IP network: they do not care how the IP packets are delivered.

In fact, IP packet transmissions are strongly affected by the operation of the physical radio layer and the media access control (MAC) layer - both of which form part of the cellular network. Understanding the behaviour of mainstream applications under a range of simulated radio conditions can help the operator to optimise either their infrastructure or their own applications.

For example, Voice over LTE applications produce a continuous stream of small packets; the transmissions require very low latency and have a high tolerance for dropped packets. Operators may optimise this traffic by allocating a specific radio bearer to provide for this traffic profile. For this application, adapting and optimising the lower layers is absolutely essential to ensure good performance and high quality of service.

Operators might also use a network simulator to:

  1. Perform thousands of mobile payment transactions (which are protected by cryptographic routines) while undergoing a cell-to-cell handover, in order to measure the transaction failure rat;
  2. Test emergency service call operation.

Troubleshooting

Live network monitoring can reveal problems with a specific device. Getting to the root of the problems, however, is difficult in the live network, because of the constantly changing conditions at each layer of the network infrastructure. By replicating the live network on a simulator, the operator can more quickly test hypotheses about the root cause, and repeat the suspected conditions on demand.

The operator can also use a simulator to do preventive maintenance or anticipate network failures. Generating abnormal conditions in the simulator, the operator can see how successfully each terminal copes with them. Such conditions, not normally or repeatably found in the live network, include: server unavailability; cross-border roaming; rejected connection.

Design category: