NB-IoT: How to test quality of service in NB-IoT networks (part 4)

Our measurement software R&S®ROMES4 commands NB-IoT modules and evaluates test results. Until now, these measurements have not been significantly different from standard QoS measurements in LTE networks. Apart from the enormous difference in the achievable data rate, however, we’ve observed that cheap NB-IoT modules behave quite differently than commercially available high-end LTE-A smartphones.

Depending on the used NB-IoT module, before actually starting a data transfer test, it may be necessary to actively switch the module on and command a network selection and attach procedure. Some modules allow establishing a connection to the Internet via the measurement computer’s modem or network card driver, while others require an AT command script to set tests up.

Test preparation in NB-IoT networks

How do you best simulate NB-IoT modules in the field? After several test sessions, we’ve come to the conclusion that using AT commands to control the IP traffic produces the best and most reliable results.

Most of the NB-IoT networks still do not support mobility. This means that the user equipment (UE) will camp on the current server until its signal is completely lost. To ensure that the module will camp on the best server, we recommend switching the module on and off before starting the actual test. To do so, simply add the following standard AT commands to the R&S®ROMES4 DQA test script:

• AT+CFUN=0 to switch off the module
• Wait some seconds
• AT+CFUN=1 to switch on the module
• Wait some seconds, or until the module is in RRC IDLE

After switching the module back on, make sure that it attaches to the target network. Unless the module supports auto attach, add the command AT+COPS=1,2,”cccnn” (where ccc is the MCC and nn the MNC) to the script. Finally, command the data test you want to perform.

Depending on the module, different commands apply, as they are specific to the manufacturer. For example, for ping tests you could add an AT+QPING=1,”8.8.8.8” command. AT command-based test scripts can be used for NB-IoT modules based on Qualcomm and Neul (from R&S®ROMES4 version 17.3ff).

Test execution in NB-IoT networks

R&S®ROMES4 commands the connected modules, as described in the DQA script. During the measurement, the test flow can be easily followed in the DQA message view showing the sent AT commands and received responses. Especially for ping tests via AT commands, R&S®ROMES4 now provides signals that show the result values of the AT ping. These values can be visualized in standard R&S®ROMES4 views, as a table, chart, or map.

For specific tests, which are not supported by AT commands, it may be necessary to use the windows IP connection. For example, if FTP is the choice of test, it is essential to let the test run on a Windows computer. R&S®ROMES4 can then build up a connection via either NDIS or the modules’ modem drivers.

This is the same test procedure as back in the good old days of GPRS. We use the R&S®ROMES4 DQA Connection Job to define the build-up of the connection and, once the connection is established, perform any IP-based test such as an FTP download. However, NB-IoT networks often do not allow full access to the Internet; therefore, it is important to ensure that the used test servers are accessible.

Troubleshooting NB-IoT networks

R&S®ROMES4 does not only offer the complete set of means for scripting tests to measure QoS and the quality of machine experience, but the universal engineering software platform also offers in-depth views of test processes and proceedings, from layer 1 to layer 3. For example, the NB-IoT Detail View allows digging into each TTI of an NB-IoT session. Such extensive detail information is also invaluable for troubleshooting when test results deviate from expected KPIs.

R&S®ROMES4 gives you all the answers you’re looking for when testing QoS in NB-IoT networks. It lets you command modules to establish a network connection; using AT commands or the Windows IP connection, it lets you set up tests. The software aggregates, visualizes, and reports results, while simultaneously collecting trace data from the Qualcomm or Neul chipset, in case of troubleshooting.