Amarisoft

Iperf

The purpose of this tutorial is to show you how to do throughput test with iperf2. iperf would be the tool that have been used the most widely for IP throughput test in various situation. For some specific application, iperf may not be good enough and you may need some dedicated packet generator, but for a lot of ordinary IP throughput test as we do in wireless communication iperf would still be the most widely used tool. There are two types of iperf we can easily get : iperf2 and iperf3.In LTE days, as far as I recall, iperf2 was used dominatly and I see more and more users are using iperf3 more recently and in 5G. But which tool is better is still in debates and seems to be up to personal preferences.

In this tutorial, I used iperf2 but you can use iperf3 as well. Just a small adjustment for comman and options. For relatively low throughput I don't think it would not take much effort to achieve the rate you expected, but for very high throughput (like 1Gbps or higher), it would take some time and effort to figure out proper option values for iperf. Unfortunately it would not be possible to provide the best options and option values that fits for every situation. A set of iperf options that worked well with my setup would not work well with your setup. Therefore, you should anticipate that you should spend a considerable amount of time and effort to figure out the set of iperf options that works with your own setup.

At the earily stage of the test setup, it would be helpful for you to visit the Offical sites for iperf and check out some documents published there.

It is assumed that you are familiar with the basic operations of the callbox and I would not explain about the very basic operations of callbox. If you are not familiar with the basic operation of the callbox, refer to other tutorials like LTE Attach, SA setup, NSA setup etc.

NOTE : The purpose of this tutorial is mainly for setting up the data pipe for iperf testing and I have not tried to maximize the throughput.

Table of Contents

Introduction

In modern networking environments, evaluating and optimizing IP throughput is crucial for ensuring robust, high-performance communication across wired and wireless systems. iperf2 stands as one of the most widely adopted open-source tools for conducting reliable IP throughput testing, providing detailed insights into network bandwidth, latency, and overall performance. Originally developed for academic and enterprise environments, iperf2 enables users to generate TCP and UDP traffic between a client and server, allowing for granular control over test parameters such as data rate, protocol, buffer sizes, and parallel streams. Its architecture adopts a client-server model, where the client initiates connections to one or more servers, facilitating both unidirectional and bidirectional testing scenarios. In wireless communication domains such as LTE and 5G, iperf2 remains indispensable for validating end-to-end data transmission capabilities, diagnosing network bottlenecks, and tuning system parameters for optimal throughput. While iperf2 and its successor, iperf3, share similar core functionalities, subtle differences in command syntax, feature sets, and performance characteristics have led to ongoing debates regarding their relative merits. This tutorial focuses on iperf2, guiding users through practical throughput testing workflows, highlighting key configuration options, and addressing common challenges encountered in real-world deployments. By leveraging iperf2, network engineers and testers can systematically assess and enhance the efficiency of their data paths, ensuring systems meet the demanding requirements of contemporary IP-based communication.

Summary of the Tutorial

This tutorial covers multiple test procedures for verifying IP traffic (using iperf) over different Radio Access Technologies (RATs) and IP versions, utilizing both UE simulators and commercial mobile devices as Devices Under Test (DUT). The focus is on correct configuration matching, stepwise setup, and verification processes to ensure successful connectivity and throughput measurement.

The tutorial emphasizes the importance of configuration matching between UE and test network, systematic verification of connectivity and IP address allocation, and the use of iperf for throughput validation under various RAT and IP version scenarios.

Test 1 : UE Sim - NR SA, IPv4

This is the most basic test for iperf based on IPv4 and using UEsim as DUT. In this test, I used NR SA as RAT (Radio Access Technology), but type of RAT is not important. You can use any RAT (e.g, LTE, NR NSA) in the same way as explained here.

Test Setup

TestSetup Callbox UEsim 1sdr 01

Configuration

An important thing in using UE sim is to do proper matching between UE sim configuration and Call box configuration

If you use other Network (e.g, other network simulator or real network), you have to make it sure to configure UE sim according to the settings on network side.

On UEsim, I used ue-nr-sa-50M-iperf.cfg which is copied and modified from ue-nr-sa.cfg

Iperf Test 1 Config 01

On Callbox enb, I used gnb-sa-50Mhz.cfg which is copied and modified from gnb-sa.cfg.

Iperf Test 1 Config 02

On Callbox mme, I used mme-ims.cfg as it is.

Iperf Test 1 Config 05

Following is the configuration on Callbox (gnb-sa-50Mhz.cfg). You can specify TDD/FDD(NR_TDD), MIMO(N_ANTENNA_DL) and bandwidth(NR_BANDWIDTH) etc but these details is not so imporant in this test.

In this example, the basic NR radio parameters are configured first. NR_TDD is set to 1, so this test uses NR TDD. FR2 is set to 0, so this is an FR1 configuration. N_ANTENNA_DL is set to 2, which means 2 downlink antennas are used. N_ANTENNA_UL is set to 1, which means one uplink antenna is used. NR_BANDWIDTH is set to 50, so the NR cell bandwidth is 50 MHz.

Then the NR cell configuration is shown in nr_cell_list. The cell is configured with rf_port 0 and cell_id 0x01. Since NR_TDD is enabled and FR2 is not enabled, the FR1 TDD part of the configuration is used. In this case, band is set to 78, dl_nr_arfcn is set to 632628, and subcarrier_spacing is set to 30 kHz.

For this iPerf test, these radio parameters are not the main focus. The important point is that the Callbox brings up a working NR SA cell and allows the UEsim to attach and get IP connectivity. Once the UE is connected and IPv4 data path is established, the same iPerf test procedure can be used regardless of the detailed TDD/FDD, MIMO, antenna, or bandwidth settings.

Iperf Test 1 Config 09

You would see following in /root/mme/config/mme-ims.cfg file on Callbox

In this example, the user database configuration is included using ue_db-ims.cfg. This file contains UE subscription information used by the EPC/5GC side, such as IMSI, authentication key, OP/OPc, APN or DNN related settings, and IP allocation related information.

For this iPerf IPv4 test, this part is important because the UE must be known to the core network before it can attach or register successfully. Once the UE authentication and subscription information match between UEsim and Callbox, the UE can establish the data connection and get an IPv4 address. After that, iPerf traffic can be generated over the established user-plane path.

Iperf Test 1 Config 06

In this tutorial, following SIM information will be used. Make it sure to configure the same parameters on UE side as well. (NOTE : this is the contents of ue_db-ims.cfg)

The first UE entry uses the xor authentication algorithm. The IMSI is set to 00101123456789, and the authentication key K is set to 00112233445566778899aabbccddeeff. The AMF value is 0x9001, and the sequence number SQN is set to 000000000000. These values must match the SIM configuration used by UEsim. Otherwise, the UE registration will fail during authentication.

The IMS related parameters are also configured in this UE entry. The IMPI is set to [00101123456789@ims.mnc001.mcc001.3gppnetwork.org](mailto:00101123456789@ims.mnc001.mcc001.3gppnetwork.org), and the IMPU list includes tel:0600000000 and tel:600. The IMS domain is ims.mnc001.mcc001.3gppnetwork.org. Even though this test is mainly for iPerf data traffic, this IMS-style database file is used in the Callbox configuration, so the UE subscription information must still be consistent.

The important point in this step is not the IMS service itself. The important point is that the Callbox and UEsim use the same SIM credentials. Once IMSI, authentication algorithm, K, OP/OPc if used, AMF, and related subscription parameters are aligned, the UE can register successfully and establish the IPv4 data path required for the iPerf test.

Iperf Test 1 Config 07

Following is the configuration on UEsim(ue-nr-sa-50M-iperf.cfg )

In this example, the UEsim radio parameters are configured to match the Callbox cell configuration. N_ANTENNA_DL is set to 2, TDD is set to 1, and CELL_BANDWIDTH is set to 50. These values should be aligned with the Callbox configuration so that UEsim can properly search and connect to the NR cell.

The cell group is configured as NR. The bandwidth is set by CELL_BANDWIDTH, and the band is set to 78. The dl_nr_arfcn is set to 632628, which matches the downlink ARFCN used in the Callbox configuration. This is important because UEsim must know where to search for the NR carrier.

One important difference from the Callbox configuration is the SSB ARFCN setting. On Callbox side, ssb_nr_arfcn can be omitted, and gNB can automatically calculate it. However, on UEsim side, ssb_nr_arfcn should be explicitly configured. In this example, ssb_nr_arfcn is set to 631584.

The easiest way to find this value is to run cell phy command on the Callbox service screen. In the output shown at the bottom of this example, the SSB ARFCN is displayed as 631584 with SCS 30. This value is then copied into the UEsim configuration.

For this iPerf test, the most important point is that UEsim can detect the NR cell and complete registration. Once the RF parameters, DL ARFCN, SSB ARFCN, band, bandwidth, and TDD mode are correctly matched, UEsim can attach to the Callbox and establish the IPv4 data path used for the iPerf traffic test.

Iperf Test 1 Config 10

In the UE list, the SIM information for UEsim is configured. The IMSI is set to 001010123456789 and the authentication key K is set to 00112233445566778899aabbccddeeff. These values should match the corresponding UE database configuration on the Callbox side. If the IMSI or K value is different, the UE may find the cell, but registration will fail during authentication.

The UE capability part defines what kind of UE capability UEsim reports to the network. In this example, as_release is set to 15 and ue_category is set to nr. This means the simulated UE behaves as an NR UE with Release 15 capability. The nr_forced_cqi and nr_forced_ri values are also configured. These values can affect the radio performance behavior during the test, but they are not the main focus of this basic IPv4 iPerf test.

The most important parameter in this part is tun_setup_script. It is set to ue-ifup. This enables UEsim to create a TUN interface for the UE PDN/PDU session. This is required when you want to use external IP tools such as ping, iperf, or other traffic generators outside the UEsim internal environment.

Without this TUN interface setup, the UE may still register and establish a data session, but the host Linux system would not have a normal IP interface that external tools can use. Therefore, for any iPerf-based test, make sure tun_setup_script is enabled and correctly configured.

Iperf Test 1 Config 11

Peform the Test

Before starting the iPerf test, first check the cell configuration on the Callbox side and confirm that the radio parameters are configured as intended. This can be done from the Callbox service screen using the cell phy and cell commands.

In this example, cell phy shows that the NR cell is running on band n78 with 50 MHz bandwidth. The downlink ARFCN is 632628, the uplink ARFCN is also 632628, and the SSB ARFCN is 631584. The subcarrier spacing is 30 kHz. It also shows that the downlink antenna configuration is 2 layers and the uplink antenna configuration is 1 layer.

The cell command gives another summary of the active cell. It shows cell ID 0x001, RAT NR, band n78, TAC 0x000064, dl_arfcn 632628, PCI 500, PRACH sequence 1, downlink gain 0.0, uplink disabled flag N, and PLMN 00101.

This step is useful because it confirms that the running cell configuration matches the configuration file. It also gives the exact SSB ARFCN value that should be used on the UEsim side. Once these values are confirmed, you can proceed to start UEsim and perform the IPv4 iPerf test.

Iperf Test 1 Run 01

Power on UE and Get UE attached to the cell.

After UEsim is started, you can check the Callbox service screen using the t command. This command shows the live trace and radio status of the connected UE. In this example, PRACH is detected first, which means the UE has found the cell and started random access. The PRACH line shows cell=01, seq=5, ta=6, and snr=20.8 dB.

After the UE is attached, the UE status appears in the table. The UE_ID is 2, the cell is 001, and the RNTI is 4602. This indicates that the UE has been assigned a radio connection by the gNB. The table also shows CQI, RI, MCS, bitrate, SNR, PUCCH status, HARQ statistics, PHR, path loss, and timing advance.

The downlink side shows relatively good radio condition. The CQI is around 5, RI is 1 or 2, and SNR is around 32 to 36 dB in the shown output. The downlink bitrate changes depending on the current traffic and scheduling condition. The uplink side also shows received MCS, received OK count, bitrate, and other scheduling statistics.

At this point, the UE is connected at the radio level. This confirms that the UEsim can detect the NR cell, complete random access, and stay attached to the Callbox. Once the UE also gets an IP address through the PDU session and the TUN interface is created, external tools such as ping or iPerf can be used for the actual IPv4 traffic test.

Iperf Test 1 Run 02

Figure out the IP address that is allocated to the UE.

After the UE is attached and the PDU session is established, you can check the UE information from the Callbox MME service screen using the ue command.

In this example, the UE with SUPI 001010123456789 is registered to the 5GC. The REG field shows Y, which means the UE registration is completed. The TAC is shown as 0x64, and the bearer number is 1.

The most important field for this test is IP ADDR. In this example, the UE is assigned the IPv4 address 192.168.2.2. This is the IP address that will be used for the iPerf test.

At this point, the UE has both radio connection and IP connectivity. The next step is to use this UE IP address, or the corresponding TUN interface on the UEsim host, to run ping or iPerf traffic.

Iperf Test 1 Run 03

Check if the network namespace for each UE instance is established on the UEsim side.

After UEsim is started and the UE is attached, run ip netns list on the UEsim machine. This command shows the Linux network namespaces created for UE instances. In this example, only one namespace is shown as ue1 with id 0.

This means UEsim has created a separate network namespace for the simulated UE. The UE TUN interface is created inside this namespace, so external IP tools such as ping or iPerf should be executed through this namespace.

In this tutorial, only one UE instance is used, so only one entry appears in the list. If multiple UE instances are configured, you would see multiple namespaces, one for each UE instance.

Iperf Test 1 Run 08

Run the following command on the UEsim side, where the UE works as the IP traffic receiver.

In this example, the command is executed inside the UE network namespace using ip netns exec ue1. This is important because the UE IP interface is created inside the ue1 namespace, not in the default Linux network namespace.

The command starts iPerf in UDP server mode. The option -s means server mode, -u means UDP mode, and -i 1 means the result will be printed every 1 second.

After the command is executed, iPerf starts listening on UDP port 5001. The output also shows that it is receiving 1470 byte datagrams and the UDP buffer size is 208 KByte by default.

At this point, the UEsim side is ready to receive UDP traffic. The next step is to run the iPerf client from the other side and send UDP traffic toward the UE IP address, which was shown earlier as 192.168.2.2.

Iperf Test 1 Run 04

Run the following command on the Callbox side, where the Callbox works as the IP traffic sender.

In this example, iPerf is started in UDP client mode. The option -u means UDP mode, and -c 192.168.2.2 specifies the destination IP address. This IP address is the UE IPv4 address that was allocated earlier. The option -b 500M sets the target sending bitrate to 500 Mbps, -i 1 prints the result every 1 second, and -t 600 runs the test for 600 seconds.

After the command starts, the Callbox connects to 192.168.2.2 on UDP port 5001. The output shows that the local side uses 192.168.2.1, and the traffic is sent to the UE address 192.168.2.2. This confirms that the traffic direction is from Callbox to UE, so this is a downlink IP traffic test from the network side to the simulated UE.

The result shows around 62.5 MBytes transferred every 1 second, corresponding to about 524 Mbits/sec. This is close to the configured UDP target rate of 500 Mbps. Since UDP does not have TCP-style flow control, iPerf tries to send traffic at the requested bitrate. The actual radio throughput and packet loss should be checked together with the receiver-side iPerf output and the Callbox radio trace.

At this point, the downlink UDP iPerf traffic is running successfully toward the UE. The next useful checks are the iPerf receiver result on UEsim side and the Callbox t trace, so you can confirm not only the generated bitrate but also the received bitrate, packet loss, MCS, retransmission, and radio scheduling behavior.

Iperf Test 1 Run 05

The following tx_gain and rx_gain values were used on UEsim and Callbox to achieve the throughput shown in the next example.

On the UEsim side, tx_gain is set to 89.8 dB for TX0. The rx_gain is set to 50.0 dB for both RX0 and RX1. This means the simulated UE uses one transmit path and two receive paths in this setup.

On the Callbox side, tx_gain is set to 73.0 dB for both TX0 and TX1. The rx_gain is set to 40.0 dB for RX0. This matches the 2 DL antenna and 1 UL antenna configuration used in the previous NR SA setup.

These gain values are not universal values. They are only the values that worked well in this specific test environment. The optimal values can change depending on the RF connection, cable loss, attenuator value, SDR hardware, antenna setup, frequency band, and expected throughput.

So these values should be used only as a reference. In your own setup, you may need to tune tx_gain and rx_gain while checking the Callbox trace, UE trace, SNR, MCS, retransmission count, and iPerf result. The goal is not just to increase gain as much as possible. The goal is to find a stable RF level where the UE keeps good SNR, low retransmission, and stable throughput.

Iperf Test 1 Run 06

Iperf Test 1 Run 07

Verify the throughput

While the iPerf test is running, verify the radio-side throughput using the t command on the Callbox service screen. This gives you a live view of the UE radio status and helps you check whether the achieved throughput is limited by IP traffic generation or by radio link condition.

In this example, the UE is connected with RNTI 4603. The CQI is around 11 to 13, and RI is 2. This means the UE is using two downlink layers, matching the configured 2-layer MIMO setup. The downlink MCS is around 17 to 18, and the downlink bitrate is around 211 to 217 Mbps in the shown trace.

However, this is still not the maximum possible value. For 256QAM, the maximum CQI is 15. If 64QAM is used, the practical maximum CQI is usually around 28. If CQI is low, MCS will also stay low, and the throughput cannot reach the expected maximum.

Also check retx and txok together. In this example, retx is relatively high. This means many retransmissions are happening, so the scheduler cannot use the full radio capacity for new data. Even if the CQI looks reasonably high, high retransmission can reduce the effective throughput. This usually indicates that the radio link quality is not optimal, or that there are CRC errors on the air interface.

To improve the result, tune the radio link condition. You can adjust antenna distance, antenna direction, cable connection, attenuator value, tx_gain, and rx_gain on both UEsim and Callbox. The goal is to get high CQI, correct RI, low retransmission, and stable bitrate at the same time.

If UEsim and Callbox are close enough but CQI is still low, try tuning tx_gain and rx_gain. This usually requires some trial and error. Increasing gain blindly is not always better. Too low gain may cause poor SNR, but too high gain may cause saturation or distortion.

If you are using antennas, it may be difficult to reach maximum CQI due to fading, interference, or antenna placement. For a more stable high-throughput test, an RF cable connection with proper attenuation is usually better than over-the-air antenna testing.

Iperf Test 1 TpCheck 01

Test 2: Commercial Mobile Phone - NR SA, IPv4

This test is to show a case of iperf based on IPv4 and using a Commercial UE as DUT. In this test, I used NR SA as RAT (Radio Access Technology), but type of RAT is not important. You can use any RAT (e.g, LTE, NR NSA) in the same way as explained here.

Test Setup

Test setup for this tutorial is as shown below.

TestSetup Callbox UE 1sdr 01

Configuration

In this test, I used theconfiguration file gnb-sa-50M-sdr0.cfgthat are modified from gnb-sa.cfg as shown below.

Iperf Test2 Config 01

In gnb-sa-50M-sdr0.cfg , I configured as follows. You can specify TDD/FDD(NR_TDD), MIMO(N_ANTENNA_DL) and bandwidth(NR_BANDWIDTH) etc but these details is not so imporant in this test.

NR_TDD is set to 1, so this test uses NR TDD. FR2 is set to 0, so the cell is configured for FR1. NR_TDD_CONFIG is set to 2, which selects the TDD pattern used by the cell. N_ANTENNA_DL is set to 2, so the Callbox uses 2 downlink antenna ports. N_ANTENNA_UL is set to 1, so one uplink antenna port is used. NR_BANDWIDTH is set to 50, meaning the NR channel bandwidth is 50 MHz.

These parameters should be selected according to your target test setup and the capability of the commercial phone. For example, the phone should support the configured NR band, bandwidth, SCS, TDD mode, and MIMO configuration. If the phone does not support the selected combination, it may fail to camp, register, or reach the expected throughput.

However, for this IPv4 iPerf test, these radio details are not the main focus. The important point is to bring up a stable NR SA cell where the commercial phone can attach, get an IPv4 address, and establish a working user-plane path. Once the phone is connected, the same iPerf procedure can be used to measure traffic throughput.

Iperf Test2 Config 02

The nr_cell_list section defines the actual NR cell used by the Callbox.

In this example, rf_port is set to 0 and cell_id is set to 0x01. Since NR_TDD is enabled and FR2 is not enabled, the FR1 TDD configuration is selected. In this branch, the cell uses band 78, dl_nr_arfcn 632628, and subcarrier_spacing 30 kHz. This corresponds to an NR n78 carrier at around 3489.42 MHz.

The ssb_pos_bitmap is set to 1000000. This defines which SSB position is transmitted within the SSB burst. For this test, only one SSB position is enabled. This is enough for a basic commercial UE attach and iPerf throughput test.

The FR2 and LTE/FDD-related branches are also shown in the configuration, but they are not used in this test because FR2 is set to 0 and NR_TDD is set to 1. So the active configuration is the n78, 30 kHz SCS, TDD configuration.

For this test, the important point is to configure a cell that the commercial phone can support. The phone should support NR SA on band n78, 50 MHz bandwidth, and 30 kHz subcarrier spacing. Once the phone can detect the SSB, camp on the cell, and complete registration, the IPv4 iPerf test can be performed in the same way as in the UEsim case.

Iperf Test2 Config 03

On the test UE, an iPerf application was installed by default. In this example, the application shown on the phone is Magic iPerf.

You do not have to use exactly the same application. You can install and use any iPerf app that supports the required test mode, such as UDP server or UDP client mode. The important point is that the app should allow the commercial phone to send or receive IP traffic using the IP address assigned by the Callbox.

In this test, the phone is used as the DUT, so the iPerf operation on the UE side is done through the mobile app instead of the Linux network namespace used in the UEsim test. Once the phone is attached to the NR SA cell and has IPv4 connectivity, the iPerf app can be used to receive traffic from the Callbox or send traffic toward the Callbox.

For the downlink throughput test, the iPerf app on the phone is usually started in server mode. Then the Callbox runs the iPerf client and sends traffic to the phone IP address.

Iperf Test2 Config 04

Peform the Test

Before starting the iPerf test with the commercial phone, first check the running cell configuration on the Callbox side. This can be done from the Callbox service screen using the cell phy and cell commands.

In this example, cell phy shows that the NR cell is running on band n78 with 50 MHz bandwidth. The downlink ARFCN is 632628, and the uplink ARFCN is also 632628. The SSB ARFCN is 631584, and the SSB SCS is 30 kHz. The downlink antenna configuration shows 2 layers, and the uplink antenna configuration shows 1 layer.

The cell command gives another summary of the active cell. It shows cell ID 0x001, RAT NR, band n78, TAC 0x000064, dl_arfcn 632628, PCI 500, PRACH sequence 1, downlink gain 0.0, uplink disabled flag N, and PLMN 00101.

This step is important because the commercial phone must support and detect this exact cell configuration. If the frequency, band, bandwidth, SCS, or PLMN is not configured as intended, the phone may not camp on the cell or may fail to register.

Once this configuration is confirmed, power on the commercial phone, select the proper test SIM or network setting if needed, and wait until the phone attaches to the Amarisoft NR SA cell. Then you can continue with the IPv4 address check and iPerf traffic test.

Iperf Test 2 Run 01

Power on the commercial UE and wait until it attaches to the cell. After the UE is attached, check the Callbox service screen with the t command.

In this example, PRACH is detected first. The PRACH line shows cell=01, seq=1, ta=5, and snr=20.3 dB. This means the phone has detected the NR cell and started the random access procedure.

After the UE is connected, the UE status is shown in the trace table. The UE_ID is 1, the cell is 001, and the RNTI is 4601. This confirms that the commercial phone is connected to the gNB at the radio level.

The downlink status shows CQI 15 and RI 2. This is a good condition for downlink throughput testing. CQI 15 indicates very good channel quality, and RI 2 means the phone is using two downlink layers. This matches the configured 2 DL antenna setup. The downlink MCS is around 23 to 24 in this example.

The uplink side also shows received MCS, rxok, rxko, and bitrate. These values are useful to monitor uplink radio behavior, but for a downlink iPerf test, the most important values are CQI, RI, DL MCS, DL retransmission, and DL bitrate.

At this point, the phone is attached to the NR SA cell. The next step is to check the IP address assigned to the phone from the Callbox side. This IP address will be used as the destination address when running iPerf from the Callbox toward the commercial UE.

Iperf Test 2 Run 02

Check the output of the ue command in the MME service screen and make sure that the UE has at least one IP address allocated. In this test, IPv4 is used.

In this example, the UE with SUPI 001010123456789 is registered to the 5GC. The IMEISV is also shown, which indicates that this is a commercial mobile phone rather than UEsim. The REG field is Y, so the UE registration is completed successfully.

The #BEARER value is 1, meaning one user-plane bearer or PDU session is established. The IP_ADDR field shows 192.168.3.2. This is the IPv4 address assigned to the commercial UE.

This IP address is important for the iPerf test. When the phone works as the iPerf receiver, the Callbox should use this address as the destination IP address. In this example, the iPerf client on the Callbox should send traffic to 192.168.3.2.

Iperf Test 2 Run 03

Run the iPerf app on the commercial UE and start the iPerf server.

In this example, Magic iPerf is used on the phone. The command field is configured with -s -u -i 1. This means the phone runs as an iPerf server, uses UDP mode, and prints the status every 1 second.

After entering the command, press the iPerf button. If the server starts correctly, the status changes from Stopped to Started. The output window also shows Server listening on UDP port 5001. This means the phone is now ready to receive UDP traffic from the Callbox.

The output also shows that it is receiving 1470 byte datagrams and the UDP buffer size is 208 KByte by default. This is the same kind of iPerf server behavior that was used in the UEsim test, but here it is running inside the phone app instead of a Linux network namespace.

At this point, the UE side is ready. The next step is to run the iPerf client command on the Callbox and send UDP traffic to the phone IP address, which was shown earlier as 192.168.3.2.

Iperf Test 2 Run 04

Open another terminal on the Callbox and start ping toward the UE IP address. In this example, the UE IP address is 192.168.3.2, so the command is ping 192.168.3.2.

This step is used to confirm that basic IP connectivity is working before starting the iPerf traffic. In the output, the Callbox receives ICMP replies from 192.168.3.2. This means the phone is reachable through the established NR SA user-plane path.

It is recommended to keep this ping running during the whole test period. This keeps a small amount of IP traffic active between the Callbox and the UE. If there is no IP traffic for some time, the Callbox may release the RRC connection and move the UE to idle mode.

Once the UE goes to idle mode, the iPerf traffic may not always trigger reconnection immediately depending on the test condition or phone behavior. In that case, the iPerf result may show no throughput even though the UE was attached before. Keeping ping running is a simple way to keep the UE active and avoid this problem during the throughput test.

Iperf Test 2 Run 05

Run the following command on the Callbox to transmit UDP traffic to the commercial UE.

In this example, the iPerf client is started on the Callbox with destination IP address 192.168.3.2. This is the IPv4 address assigned to the commercial phone. The option -u enables UDP mode, -b 500M sets the target bitrate to 500 Mbps, -i 1 prints the result every 1 second, and -t 600 runs the test for 600 seconds.

After the command starts, the Callbox connects to 192.168.3.2 on UDP port 5001. The output shows that the local Callbox IP is 192.168.3.1 and the remote UE IP is 192.168.3.2. This confirms that traffic is being sent from the Callbox toward the phone.

The result shows around 62.5 MBytes transferred every second, corresponding to about 524 Mbits/sec. This means the iPerf sender is generating traffic close to the requested 500 Mbps target rate.

This value is the sender-side result. To confirm the actual received throughput, you should also check the iPerf app output on the phone. In addition, monitor the Callbox t trace to check CQI, RI, MCS, retransmission, and radio bitrate. This helps you determine whether any throughput limitation comes from the radio link, UE capability, IP path, or iPerf application behavior.

Iperf Test 2 Run 06

Verify the throughput

While the iPerf traffic is running, check the Callbox trace using the t command. This gives you the live radio-side throughput and helps you confirm whether the radio link is good enough to support the target iPerf rate.

In this example, the commercial UE is connected with RNTI 4603. The CQI is 15, which is the maximum CQI value. This indicates that the downlink radio quality reported by the UE is very good. The RI is 2, so the UE is using two downlink layers. This matches the 2 DL antenna configuration used in this test.

The downlink MCS is around 23.0, and the downlink bitrate is around 285 to 287 Mbps in the shown trace. This means the radio scheduler is actively sending downlink data to the UE, but the achieved radio throughput is still lower than the 500 Mbps iPerf target.

One important point is the retx value. In this example, retx is relatively high, around 350 in each trace interval. This means many downlink retransmissions are happening. Even though CQI is already at the maximum value, high retransmission can still reduce the effective throughput. So CQI alone is not enough to judge the link quality.

To improve the throughput, tune the radio link condition while watching CQI, RI, MCS, retx, txok, and brate together. The target is to keep CQI close to maximum, keep RI at the expected MIMO layer count, and reduce retx as much as possible.

You can tune the result by adjusting antenna distance, antenna direction, cable connection, attenuator value, tx_gain, and rx_gain. If you use antennas, the result may change due to fading, interference, or phone position. For more stable maximum-throughput testing, RF cable connection with proper attenuation is usually preferred.

Iperf Test 2 TpCheck 01

You would see the throughput logs printed on the iPerf app on the UE as shown in this example.

In this test, the phone is running as the UDP iPerf server. After the Callbox starts sending UDP traffic to the UE IP address, the app prints the received throughput every 1 second. This is the receiver-side result, so it is very important for checking the actual throughput delivered to the UE.

In the example, the app shows that traffic is received from the Callbox IP address 192.168.3.1. The received bandwidth is around 200 to 223 Mbits/sec in most intervals. This is lower than the sender-side iPerf rate shown on the Callbox, which was around 524 Mbits/sec.

This difference can happen because UDP iPerf on the sender side only shows how much traffic it tries to send. It does not guarantee that all packets are successfully delivered to the UE. The receiver-side result on the phone shows the actual received traffic. So, for throughput verification, you should always check both sides.

The Lost/Total column is also important. In this example, packet loss is shown in several intervals. This means some UDP packets were lost before reaching the iPerf app. The cause can be radio retransmission, scheduler limitation, UE processing limitation, app limitation, or general IP path limitation.

Usually, the throughput shown in the phone iPerf app is lower than the radio-side bitrate shown by the t command on the Callbox. The t command shows radio scheduling and PHY/MAC-side activity, while the iPerf app shows the final IP application throughput. So it is normal that these two values are not exactly the same.

Iperf Test 2 TpCheck 02

Test 3: UE Sim - LTE, IPv4v6

This test is to show a case of iperf based on IPv4 and using a Commercial UE as DUT. In this test, I used LTEas RAT (Radio Access Technology), but type of RAT is not important. You can use any RAT (e.g, NR NSA, NR SA) in the same way as explained here.

Test Setup

TestSetup Callbox UEsim 1sdr 01

Configuration

An important thing in using UE sim is to do proper matching between UE sim configuration and Call box configuration

If you use other Network (e.g, other network simulator or real network), you have to make it sure to configure UE sim according to the settings on network side.

On UEsim, I used ue-lte-ipV4V6.cfg which is copied and modified from ue.default.cfg

Iperf Test 3 Config 01

On Callbox enb, I used enb.default.cfg as it is.

Iperf Test 3 Config 02

On Callbox mme, I used mme-ims-internet-ipv4v6.cfg which is copied and modified frommme-ims.cfg /

Iperf Test 3 Config 05

Following is the configuration enb configuration on Callbox (enb.default.cfg ). You can specify TDD/FDD(TDD), MIMO(N_ANTENNA_DL) and bandwidth(N_RB_DL) etc but these details is not so imporant in this test.

In this example, the LTE cell is configured with TDD set to 0. This means the cell uses LTE FDD. N_RB_DL is set to 25, so the LTE downlink bandwidth is 5 MHz. N_ANTENNA_DL is set to 2, meaning the eNB uses 2 downlink antennas for MIMO 2x2. N_ANTENNA_UL is set to 2, so two uplink receive antennas are configured.

CHANNEL_SIM is set to 0, so the channel simulator is disabled. G_ENB is also set to 0, meaning this is a normal eNB configuration, not an ng-eNB configuration.

Since TDD is disabled, the FDD branch of the configuration is used. In this example, dl_earfcn is set to 350, which corresponds to LTE Band 7 with downlink center frequency 2680 MHz. Other EARFCN examples for different LTE bands are also shown in the file, but they are commented out and are not used in this test.

For this IPv4v6 iPerf test, these LTE radio parameters are not the main focus. The important point is that the Callbox brings up a working LTE cell and that UEsim can attach to it. Once the UE attaches and receives IP configuration, iPerf can be used to verify the user-plane traffic path.

Iperf Test 3 Config 09

You would see following in /root/mme/config/mme-ims-internet-ipv4v6.cfg file on Callbox. Here you see both ipv4 configuration(first_ip_addr, last_ip_addr) andipv6 configuration(first_ipv6_prefix, last_ipv6_prefix) are set to support both IPv4 and IPv6.

In this example, the PDN type is set to ipv4v6. This means the APN can provide both IPv4 and IPv6 connectivity to the UE. The APN name is internet.

For IPv4, first_ip_addr is set to 192.168.2. and last_ip_addr is set to 192.168.3.254. This defines the IPv4 address pool that can be assigned to UEs. The ip_addr_shift value is set to 2, so the allocated IP addresses are spaced with an offset.

For IPv6, first_ipv6_prefix is set to 2001:468:2000:1:: and last_ipv6_prefix is set to 2001:468:2000:ffff::. This defines the IPv6 prefix range that can be assigned to UEs. The DNS address list also includes both IPv4 DNS 8.8.8.8 and IPv6 DNS 2001:4860:4860::8888.

In the default enb.default.cfg setup, the internet APN may be configured for IPv4 only. For this tutorial, the PDN type is changed to ipv4v6 and the IPv6 prefix range is added. This allows the UE to receive both IPv4 and IPv6 information after attach.

At the bottom of the configuration, ue_db-ims.cfg is included as the user database file. So the UE subscription information is still taken from that file, while this mme configuration controls the APN, IP address pool, IPv6 prefix pool, DNS, and bearer configuration used for the data connection.

Iperf Test 3 Config 06

In this tutorial, following SIM information will be used. Make it sure to configure the same parameters on UE side as well. (NOTE : this is the contents of ue_db-ims.cfg)

The first UE entry uses the xor authentication algorithm. The IMSI is set to 001010123456789, and the authentication key K is set to 00112233445566778899aabbccddeeff. The AMF value is 0x9001, and SQN is set to 000000000000. These values must match the UE configuration. If any of these values are different, the UE may detect the LTE cell but fail during the attach authentication procedure.

The same entry also includes IMS related information, such as IMPI, IMPU, and IMS domain. In this specific iPerf test, IMS service itself is not the main focus. However, this UE database file is included by the MME configuration, so the UE subscription data should still be valid and consistent.

The important point here is that the SIM credential on Callbox and the SIM credential on UEsim should match. Once IMSI, authentication algorithm, K, AMF, and related subscription parameters are aligned, the UE can attach successfully and establish the IPv4v6 PDN connection required for the iPerf test.

Iperf Test 1 Config 07

Following is the configuration on UEsim(ue-lte-ipV4V6.cfg ). You can specify TDD/FDD(TDD), MIMO(N_ANTENNA_DL) and bandwidth(CELL_BANDWIDTH) etc but these details is not so imporant in this test.

In this example, the LTE radio parameters are configured to match the Callbox eNB configuration. TDD is set to 0, so UEsim uses LTE FDD. CELL_BANDWIDTH is set to 5, so the LTE bandwidth is 5 MHz. N_ANTENNA_DL is set to 2, meaning the UE is configured for 2 downlink antennas. N_ANTENNA_UL is set to 1, so one uplink transmit antenna is used. UE_COUNT is set to 1, so only one simulated UE is created.

In the cell configuration, the bandwidth is set by CELL_BANDWIDTH. Since TDD is disabled, the FDD branch is used. The dl_earfcn is set to 3350, which corresponds to LTE Band 7 with downlink center frequency 2680 MHz. This should match the Callbox LTE cell configuration.

In the ue_list section, the IMSI is set to 001010123456789 and K is set to 00112233445566778899aabbccddeeff. These values should match the UE database configured on the Callbox side. The UE capability is set with as_release 13 and ue_category 13.

The APN is set to internet, and attach_pdn_type is set to ipv4v6. This is important for this test. With this setting, UEsim sends a PDN Connectivity Request for the internet APN with IPv4v6 PDN type. Therefore, the Callbox MME configuration should also have a matching internet APN configured for IPv4v6.

The tun_setup_script is set to ue-ifup. This creates the TUN interface for each UE PDN connection. This is required when using external IP tools such as ping or iPerf from the Linux host. Without this setting, the UE may attach and get a PDN connection internally, but normal Linux IP tools would not have an interface to send or receive the UE traffic.

Iperf Test 3 Config 10

Peform the Test

Before starting the iPerf test, check the LTE cell configuration on the Callbox side and confirm that the frequency, band, bandwidth, MIMO, and other radio parameters are configured as intended.

In this example, the cell phy command shows that the LTE cell is running on Band 7 with 5 MHz bandwidth. The downlink EARFCN is 3350, and the uplink EARFCN is 21350. The downlink antenna configuration shows 2 antennas and 2 layers, while the uplink side shows 2 receive antennas and 1 layer.

The subcarrier spacing is shown as 15 kHz, which is the normal LTE subcarrier spacing. The downlink modulation capability is shown as 256QAM, and the uplink modulation capability is shown as 64QAM.

This step is useful because it confirms that the running LTE cell matches the configuration file. For this test, the important point is that the Callbox LTE cell is active and that UEsim can search this EARFCN, attach to the cell, and establish the IPv4v6 PDN connection. Once this is confirmed, you can start UEsim and proceed to the IP address and iPerf test.

Iperf Test 3 Run 01

On the Callbox side, run ifconfig and confirm that the IPv6 address is assigned as configured in the MME configuration.

In this example, several TUN interfaces are shown. Each interface has an IPv4 address and, depending on the APN configuration, an IPv6 address as well. For this IPv4v6 test, the important point is to find the TUN interface that is mapped to the internet APN used by the UE.

In the shown output, tun1 has IPv4 address 192.168.3.1 and IPv6 address 2001:468:2000:1::. This confirms that this interface received both IPv4 and IPv6 configuration. This matches the internet APN configuration where the PDN type was set to ipv4v6 and the IPv6 prefix range was added.

The IPv4 address 192.168.3.1 is the Callbox-side gateway address for this UE data path. The UE side should receive a corresponding IPv4 address from the same pool. The IPv6 prefix 2001:468:2000:1:: is also assigned on the Callbox side, and the UE should receive an IPv6 address or prefix derived from the configured IPv6 range.

This check is useful before running iPerf because it confirms that the Callbox data interface is created correctly for IPv4v6. If this interface has only IPv4 and no IPv6 global address, the IPv6 part of the APN configuration may not be applied correctly, or the UE may not have requested IPv4v6 as expected.

Iperf Test 3 Run 02

Power on UE.

After starting UEsim, check the UEsim log and confirm that the UE can detect the LTE cell. In this example, the RF information shows sample_rate 5.760 MHz, downlink frequency 2680.000 MHz, uplink frequency 2560.000 MHz, LTE Band 7, downlink antenna 2, and uplink antenna 1. These values match the LTE FDD Band 7 configuration used in this test.

The log also shows Cell 0: SIB found. This means UEsim successfully detected the LTE cell and decoded the system information. This is the first important step before attach.

Once SIB is found, UEsim can continue with the attach procedure using the configured IMSI, K, APN, and PDN type. For this test, the expected PDN type is IPv4v6, so after attach you should check whether both IPv4 and IPv6 information are assigned properly.

Iperf Test 3 Run 03

Make sure that the UE completes the attach procedure.

After UEsim is powered on, check the Callbox trace using the t command. In this example, PRACH is detected first with cell=01, seq=28, ta=1, and snr=29.0 dB. This means the UE has found the LTE cell and started the random access procedure.

After the attach is completed, the UE appears in the trace table. The UE_ID is 1, the cell is 001, and the RNTI is 003d. This confirms that the UE has an active radio connection with the eNB.

The table also shows CQI, RI, MCS, retransmission, bitrate, SNR, PUCCH, uplink MCS, uplink rxok/rxko, PHR, path loss, and timing advance. In this example, CQI is around 6, RI is 1, and the SNR is around 15 to 17 dB. This is enough to confirm that the UE is connected, although it may not be an optimal radio condition for maximum throughput.

At this point, the UE is attached at the LTE radio level. The next step is to confirm that the IPv4v6 PDN connection is established and that the UE has received the expected IPv4 and IPv6 addresses.

Iperf Test 3 Run 04

In Callbox mme, confirm that the UE is attached and got the IPv4 and IPv6 address allocated. (NOTE : notice that mme shows just network prefix part of the UE IPv6 address (not the full address). This would be because interfaceidentifier part of the UE ip address would be assigned differently depending on UE implementation. Some UE would use the interfaceidentifier specified NAS message and some UE use generate a random interface identifier).

In this example, the ue command shows that the UE with SUPI 001010123456789 is registered. The REG field is Y, so the attach procedure is completed successfully. The #BEARER value is 1, meaning one PDN connection is established.

The IP_ADDR field shows both IPv4 and IPv6 information. The IPv4 address is 192.168.3.2. The IPv6 part is shown as 2001:468:2000:1::. This confirms that the UE has established an IPv4v6 PDN connection for the internet APN.

One thing to note is that the MME screen may show only the network prefix part of the UE IPv6 address, not the full IPv6 address. This is because the interface identifier part can be assigned differently depending on UE implementation. Some UEs may use the interface identifier provided in the NAS message, while others may generate their own interface identifier.

So, in this screen, the key point is to confirm that the IPv4 address is assigned and that the expected IPv6 prefix is also shown. This means the IPv4v6 PDN configuration is working as intended.

Iperf Test 3 Run 05

On UEsim, confirm the ue completed the attach and get IP address allocated. (NOTE : Only interface indentifier of ipv6 is displayed, not the full ipv6 address).

In this example, the ue command on UEsim shows the UE status. The UE is listed as 4G, with UE_ID 0, cell 1, and RNTI 3d. The EMM_STATE is registered, which means the LTE attach procedure completed successfully.

The IP_ADDR field shows both IPv4 and IPv6 information. The IPv4 address is 192.168.3.2. The IPv6 information is shown as ::2001:468:2000:1. This confirms that the UE received IPv4v6 configuration from the network.

One thing to note is that UEsim may display only the IPv6 interface identifier part, or may display the IPv6 information in a shortened form instead of showing the full IPv6 address exactly as it would appear on the Linux interface. So this screen should be used mainly to confirm that IPv6 information was assigned together with IPv4.

At this point, the UE is attached and the IPv4v6 PDN connection is established. The next step is to check the UE network namespace and interface, then run ping or iPerf using the IPv4 or IPv6 address depending on the test target.

Iperf Test 3 Run 06

On UEsim side, confirm that the UE network namespace is created.

After the UE completes attach and the PDN connection is established, run ip netns list on the UEsim host. In this example, ue1 is shown with id 0. This means UEsim has created a separate Linux network namespace for this UE instance.

This namespace is important because the UE TUN interface is created inside it. So when you run external IP tools such as ping or iPerf for this UE, you should execute them through this namespace.

In this tutorial, only one UE instance is configured, so only ue1 is listed. If multiple UEs are configured, you would see multiple namespaces such as ue1, ue2, and so on.

Iperf Test 3 Run 07

On UEsim, check ifconfig for ue1 and make it sure that it got the network interface with proper ipv6 address.

In this example, the command is executed with ip netns exec ue1 ifconfig. This means the ifconfig command is running inside the ue1 network namespace, where the UE TUN interface is created.

The interface pdn0 is the network interface created for the UE PDN connection. It has IPv4 address 192.168.3.2, with destination address 192.168.3.2. It also has a global IPv6 address 2001:468:2000:1:eef6:dab4:e4d2:981 with prefix length 64.

This confirms that the UE received both IPv4 and IPv6 configuration. The IPv6 network prefix, 2001:468:2000:1, comes from the MME/APN configuration. The remaining part, eef6:dab4:e4d2:981, is the interface identifier generated or assigned for this UE.

One thing to note is that the IPv6 interface identifier can be different every time you run the test. So you should not expect the full IPv6 address to always be exactly the same. The important point is that the prefix matches the configured IPv6 range and that the pdn0 interface has a valid global IPv6 address.

Iperf Test 3 Run 08

Try ping from the Callbox network side to the UE IPv6 address.

In this example, the UE IPv6 address is 2001:468:2000:1:eef6:dab4:e4d2:981. This is the full IPv6 address shown on the UEsim pdn0 interface. From the Callbox, run ping toward this address.

The ping result shows replies from the UE IPv6 address. This confirms that IPv6 connectivity is working between the Callbox and the UE through the LTE user-plane path. The ICMP sequence number increases normally, and the response time is around 24 to 33 ms in this example.

This step is important because IPv4v6 attach alone does not always guarantee that IPv6 traffic is actually working end to end. By pinging the full UE IPv6 address, you can confirm that the IPv6 address assignment, routing, and user-plane forwarding are all working properly.

Once this IPv6 ping is successful, you can continue with IPv6-based iPerf testing. The same basic iPerf concept applies, but the server and client should use the UE IPv6 address instead of the IPv4 address.

Iperf Test 3 Run 09

On UEsim side, run iPerf in UDP server mode for IPv6 traffic.

In this example, the command is executed inside the UE network namespace using ip netns exec ue1. This is required because the UE PDN interface is created inside the ue1 namespace.

The command is ip netns exec ue1 iperf -s -u -V -i 1. The option -s starts iPerf in server mode, -u enables UDP mode, -V allows IPv6 operation, and -i 1 prints the result every 1 second.

After the command is started, iPerf listens on UDP port 5001. The output also shows that it is receiving 1470 byte datagrams and that the UDP buffer size is 208 KByte by default.

At this point, the UE side is ready to receive IPv6 UDP traffic. The next step is to run the iPerf client on the Callbox side and send traffic to the full IPv6 address assigned to the UE pdn0 interface.

Iperf Test 3 Run 10

On the Callbox side, run iPerf in UDP client mode and confirm that IPv6 traffic is going out toward the UE.

In this example, the command uses the full IPv6 address assigned to the UE pdn0 interface. The option -u enables UDP mode, -V enables IPv6 operation, -c 2001:468:2000:1:eef6:dab4:e4d2:981 specifies the UE IPv6 destination address, -b 100M sets the target bitrate to 100 Mbps, -i 1 prints the result every 1 second, and -t 100 runs the test for 100 seconds.

After the command starts, iPerf connects to the UE IPv6 address on UDP port 5001. The output shows that the local Callbox IPv6 side is 2001:468:2000:1::, and the remote side is the UE IPv6 address. This confirms that the test is using the IPv6 path, not the IPv4 path.

The result shows about 12.5 MBytes transferred every second, corresponding to around 105 Mbits/sec. This is close to the configured 100 Mbps UDP target rate. Since this is the sender-side iPerf output, it mainly confirms that the Callbox is generating IPv6 UDP traffic at the requested rate.

To verify the actual received throughput, check the iPerf server output on the UEsim side. You should also monitor the Callbox t trace to check whether the radio link can support the traffic without excessive retransmission or unstable MCS.

Iperf Test 3 Run 11

On UEsim side, confirm that IPv6 iPerf traffic is coming in.

In this example, the iPerf server is running inside the UE namespace with ip netns exec ue1 iperf -s -u -V -i 1. The server is listening on UDP port 5001 and receives traffic from the Callbox IPv6 address.

The output shows that the local UE IPv6 address is 2001:468:2000:1:eef6:dab4:e4d2:981. The remote sender is 2001:468:2000:1::, which is the Callbox-side IPv6 address. This confirms that the iPerf traffic is using the IPv6 path.

However, the received throughput is much lower than the sender-side target rate. Even though the Callbox was sending around 100 Mbps, the UE-side iPerf result shows only around 3.8 to 4.2 Mbps. The Lost/Total Datagrams column also shows very high packet loss, around 96% in most intervals.

This means IPv6 connectivity itself is working, but the actual UDP traffic delivery is not good in this condition. The packets are being sent from the Callbox, but many of them are not reaching the iPerf server on the UE side.

In this kind of case, check the Callbox t trace together with the iPerf output. If radio retransmission is high, MCS is unstable, or the radio bitrate is low, the limitation may come from the LTE radio link. You can also reduce the iPerf target bitrate, for example from 100M to 10M or 5M, and then increase it gradually while checking packet loss.

For UDP iPerf, the receiver-side result is the most important result. The sender can generate 100 Mbps, but the real delivered throughput should be judged from the UEsim iPerf server output.

Iperf Test 3 Run 12

Test 4: UE Sim - LTE, IPv6 Only

This test is to show a case of iperf based on IPv6 and using a Commercial UE as DUT. In this test, I used LTEas RAT (Radio Access Technology), but type of RAT is not important. You can use any RAT (e.g, NR NSA, NR SA) in the same way as explained here.

Test Setup

TestSetup Callbox UEsim 1sdr 01

Configuration

An important thing in using UE sim is to do proper matching between UE sim configuration and Call box configuration

If you use other Network (e.g, other network simulator or real network), you have to make it sure to configure UE sim according to the settings on network side.

On UEsim, I used ue-lte-ipV6.cfg which is copied and modified from ue.default.cfg

Iperf Test 4 Config 01

On Callbox enb, I used enb.default.cfg as it is.

Iperf Test 3 Config 02

On Callbox mme, I used mme-ims-internet-ipv6.cfg which is copied and modified frommme-ims.cfg /

Iperf Test 4 Config 05

Following is the configuration enb configuration on Callbox (enb.default.cfg ). You can specify TDD/FDD(TDD), MIMO(N_ANTENNA_DL) and bandwidth(N_RB_DL) etc but these details is not so imporant in this test.

In this example, the LTE cell configuration is the same basic radio setup used in the previous LTE test. TDD is set to 0, so the cell uses LTE FDD. N_RB_DL is set to 25, which means the LTE bandwidth is 5 MHz. N_ANTENNA_DL is set to 2, so the eNB uses 2 downlink antennas. N_ANTENNA_UL is set to 2, so two uplink receive antennas are configured.

CHANNEL_SIM is set to 0, meaning the channel simulator is disabled. G_ENB is set to 0, so this is a normal LTE eNB configuration, not an ng-eNB configuration.

Since TDD is disabled, the FDD branch of the configuration is used. In this example, dl_earfcn is set to 3350, which corresponds to LTE Band 7 with downlink center frequency 2680 MHz. Other EARFCN examples are shown in the configuration file, but they are commented out and are not used in this test.

For this IPv6-only iPerf test, the LTE radio parameters themselves are not the main focus. The important point is that the Callbox brings up a working LTE cell and that UEsim can attach to it. Once the UE attaches and establishes an IPv6-only PDN connection, IPv6 ping and IPv6 iPerf can be used to verify the user-plane traffic path.

Iperf Test 3 Config 09

You would see following in /root/mme/config/mme-ims-internet-ipv6.cfg file on Callbox. Here you see only ipv6 configuration(first_ipv6_prefix, last_ipv6_prefix) are set and no IPv4 configuration.

In this example, the internet APN is configured for IPv6 only. The pdn_type is set to ipv6, so this APN does not allocate an IPv4 address to the UE. It only provides IPv6 connectivity.

The APN name is internet. The IPv6 prefix range is configured with first_ipv6_prefix set to 2001:468:2000:1:: and last_ipv6_prefix set to 2001:468:2000:ffff::. This defines the IPv6 prefix pool that can be assigned to the UE.

The DNS address list also contains only an IPv6 DNS address, 2001:4860:4860::8888. There is no IPv4 DNS address in this configuration.

Compared to the default configuration, the internet APN was changed from IPv4-only to IPv6-only for this tutorial. This means the UE should request an IPv6 PDN connection, and after attach it should receive only IPv6 information.

At the bottom, ue_db-ims.cfg is included as the user database file. So the SIM and subscription information still comes from ue_db-ims.cfg, while this MME configuration controls the IPv6-only APN, IPv6 prefix range, DNS, and bearer configuration used for the iPerf test.

Iperf Test 4 Config 06

In this tutorial, following SIM information will be used. Make it sure to configure the same parameters on UE side as well. (NOTE : this is the contents of ue_db-ims.cfg)

The first UE entry uses the xor authentication algorithm. The IMSI is set to 001010123456789, and the authentication key K is set to 00112233445566778899aabbccddeeff. The AMF value is 0x9001, and SQN is set to 000000000000. These values should match the UEsim configuration.

Even though this test is for IPv6-only iPerf traffic, the SIM authentication part is the same as in the previous tests. The UE still needs to pass the normal LTE attach procedure before it can establish the IPv6 PDN connection.

The UE database also includes IMS-related parameters such as IMPI, IMPU, and domain. These parameters are not the main focus of this iPerf test. The important point is that the UE subscription exists in the Callbox database and that the authentication parameters match the UE side.

Once the IMSI, authentication algorithm, K, AMF, and SQN are aligned between Callbox and UEsim, the UE can attach successfully. Then the IPv6-only APN configuration can be applied, and the UE can receive the IPv6 address required for the IPv6 iPerf test.

Iperf Test 1 Config 07

Following is the configuration on UEsim(ue-lte-ipV6.cfg ). You can specify TDD/FDD(TDD), MIMO(N_ANTENNA_DL) and bandwidth(CELL_BANDWIDTH) etc but these details is not so imporant in this test.

In this example, the LTE radio parameters are configured in the same way as the previous LTE test. TDD is set to 0, so UEsim uses LTE FDD. CELL_BANDWIDTH is set to 5, so the LTE bandwidth is 5 MHz. N_ANTENNA_DL is set to 2, meaning the UE is configured for 2 downlink antennas. N_ANTENNA_UL is set to 1, so one uplink transmit antenna is used. UE_COUNT is set to 1, so only one UE instance is created.

In the cell configuration, the FDD branch is used because TDD is disabled. The dl_earfcn is set to 3350, which corresponds to LTE Band 7 with downlink center frequency 2680 MHz. This should match the eNB configuration on the Callbox side.

In the ue_list section, the IMSI is set to 001010123456789 and K is set to 00112233445566778899aabbccddeeff. These values should match the SIM information configured in ue_db-ims.cfg on the Callbox side. The UE capability is set with as_release 13 and ue_category 13.

The APN is set to internet, and attach_pdn_type is set to ipv6. This is the key point for this test. With this setting, UEsim sends a PDN Connectivity Request for the internet APN with IPv6 PDN type. Therefore, the Callbox MME configuration should also have the internet APN configured as IPv6 only.

The tun_setup_script is set to ue-ifup. This creates the TUN interface for the UE PDN connection. This is required when using external IP tools such as ping or iPerf. In this IPv6-only test, this interface should get a valid IPv6 address, but no IPv4 address is expected for the PDN connection.

Iperf Test 4 Config 10

Peform the Test

Before starting the IPv6-only iPerf test, check the LTE cell configuration on the Callbox side and confirm that the radio parameters are configured as intended.

In this example, the cell phy command shows that the LTE cell is running on Band 7 with 5 MHz bandwidth. The downlink EARFCN is 3350, and the uplink EARFCN is 21350. The downlink side is configured with 2 antennas and 2 layers, and the uplink side is configured with 2 receive antennas and 1 layer.

The subcarrier spacing is 15 kHz, which is the normal LTE subcarrier spacing. The downlink modulation capability is shown as 256QAM, and the uplink modulation capability is shown as 64QAM.

This step confirms that the LTE cell is active and matches the configuration file. For this IPv6-only test, the radio configuration itself is not the main focus. The important point is that UEsim can find this LTE cell, attach successfully, and establish an IPv6 PDN connection using the internet APN. Once this is confirmed, you can power on UEsim and check whether the IPv6 address is assigned correctly.

Iperf Test 3 Run 01

On Callbox, Do ipconfig and confirm that the IPv6 address is assigned as you configured in mme configuration.

In this IPv6-only test, the important interface is the TUN interface mapped to the internet APN. In the shown output, tun1 has the global IPv6 address 2001:468:2000:1:: with prefix length 48. This matches the IPv6 prefix range configured in mme-ims-internet-ipv6.cfg.

Unlike the previous IPv4v6 test, this interface does not show an IPv4 address. This is expected because the APN is configured with pdn_type set to ipv6. So the network should allocate only IPv6 information for this PDN connection.

Other TUN interfaces are also shown, such as tun0, tun2, and tun3. Some of them may have IPv4 or IPv6 addresses depending on other APN or previous configuration. For this test, focus on the interface that corresponds to the internet APN used by the UE.

This check confirms that the Callbox side IPv6 data path is created correctly. Once the UE attaches and receives an IPv6 address, you can use IPv6 ping and iPerf with the full UE IPv6 address.

Iperf Test 4 Run 02

Power on UE.

After starting UEsim, check the UEsim log and confirm that the LTE cell is detected correctly. In this example, the RF line shows sample_rate 5.760 MHz, downlink frequency 2680.000 MHz, uplink frequency 2560.000 MHz, LTE Band 7, downlink antenna 2, and uplink antenna 1. These values match the LTE FDD Band 7 configuration used in this IPv6-only test.

The log also shows Cell 0: SIB found. This means UEsim successfully found the LTE cell and decoded the system information. This is the first confirmation that the RF and cell configuration are aligned between Callbox and UEsim.

Once SIB is found, UEsim continues with the LTE attach procedure. Since this test uses IPv6-only PDN type, the next important check is to confirm that the UE completes attach and receives IPv6 information without IPv4 allocation.

Iperf Test 3 Run 03

Make sure that the UE completes the attach procedure.

After powering on UEsim, check the Callbox trace using the t command. In this example, PRACH is detected with cell=01, seq=28, ta=1, and snr=29.0 dB. This confirms that the UE found the LTE cell and started the random access procedure.

After the attach procedure is completed, the UE appears in the trace table. The UE_ID is 1, the cell is 001, and the RNTI is 003d. This means the UE has an active radio connection with the eNB.

The table also shows the live radio condition. In this example, CQI is around 6, RI is 1, and the downlink MCS changes around 3.5 to 7.5. The SNR is around 15 to 17 dB. This is enough to confirm that the UE is attached, but it is not necessarily an optimized radio condition for high throughput.

At this stage, the UE is attached at LTE radio level. Since this test is IPv6 only, the next important step is to confirm that the UE received IPv6 information and that no IPv4 address is assigned for this PDN connection.

Iperf Test 3 Run 04

In Callbox mme, confirm that the UE is attached and got the IPv4 and IPv6 address allocated. (NOTE : notice that mme shows just network prefix part of the UE IPv6 address (not the full address). This would be because interfaceidentifier part of the UE ip address would be assigned differently depending on UE implementation. Some UE would use the interfaceidentifier specified NAS message and some UE use generate a random interface identifier).

In this example, the ue command shows that the UE with SUPI 001010123456789 is registered. The REG field is Y, so the attach procedure is completed successfully. The #BEARER value is 1, meaning one PDN connection is established.

The IP_ADDR field shows 2001:468:2000:1::. This confirms that the UE has established an IPv6-only PDN connection. Since this test is configured with pdn_type set to ipv6, no IPv4 address is shown for this UE. This is the expected behavior for the IPv6-only test.

One thing to note is that the MME screen may show only the network prefix part of the UE IPv6 address, not the full IPv6 address. This is because the interface identifier part can be assigned differently depending on UE implementation. Some UEs may use the interface identifier provided in the NAS message, while others may generate a random interface identifier.

So, in this screen, the key point is to confirm that the UE is registered and that the expected IPv6 prefix is shown in the IP_ADDR field. The full IPv6 address should be checked later on the UEsim network interface.

Iperf Test 4 Run 05

On UEsim, confirm the ue completed the attach and get IP address allocated. (NOTE : Only interface indentifier of ipv6 is displayed, not the full ipv6 address).

In this example, the ue command shows the UE status. The UE is listed as 4G, with UE_ID 0, cell 1, and RNTI 3d. The EMM_STATE is registered, so the LTE attach procedure completed successfully.

The IP_ADDR field shows ::2001:468:2000:1. Since this is an IPv6-only test, no IPv4 address is shown. This is the expected result because the UE requested IPv6 PDN type and the Callbox APN was also configured as IPv6 only.

One thing to note is that this UEsim display may not show the full IPv6 address. It may show only the IPv6 prefix or interface identifier information in a shortened form. The full IPv6 address should be checked later from the Linux network interface inside the UE namespace.

At this point, the UE is attached and the IPv6-only PDN connection is established. The next step is to check the UE network namespace and confirm the actual IPv6 address assigned to the UE interface.

Iperf Test 4 Run 06

On UEsim, confirm that you got the ue listed in the network name space.

After the UE completes attach and the IPv6-only PDN connection is established, run ip netns list on the UEsim host. In this example, ue1 is shown with id 0.

This means UEsim has created a separate Linux network namespace for this UE instance. The UE PDN interface is created inside this namespace, so IPv6 ping or IPv6 iPerf should be executed through this namespace.

In this tutorial, only one UE instance is used, so only ue1 is listed. If multiple UE instances are configured, you would see multiple namespaces such as ue1, ue2, and so on.

Iperf Test 3 Run 07

On UEsim, check ifconfig for ue1 and make it sure that it got the network interface with proper ipv6 address.

In this example, the command is ip netns exec ue1 ifconfig. This runs ifconfig inside the UE network namespace, where the UE PDN interface is created.

The pdn0 interface is created for the UE PDN connection. Since this is an IPv6-only test, pdn0 does not show an IPv4 address. It shows only IPv6 addresses. This is the expected result.

The global IPv6 address is shown as 2001:468:2000:1:7098:9268:31e0:fe3e with prefix length 64. The first part, 2001:468:2000:1, comes from the IPv6 prefix configured on the Callbox MME side. The remaining part, 7098:9268:31e0:fe3e, is the interface identifier generated or assigned for this UE.

There is also a link-local IPv6 address starting with fe80::. This is normal for IPv6 interfaces, but it is not the address normally used for the end-to-end iPerf test. For ping or iPerf from the Callbox, use the global IPv6 address.

One important point is that the interface identifier may change every time you run the test. So the full IPv6 address may not always be the same. Before running IPv6 ping or iPerf, always check the actual IPv6 address from the pdn0 interface and use that address in the test command.

Iperf Test 4 Run 08

Try ping from the callbox (network) to UE.

In this example, the full UE IPv6 address is 2001:468:2000:1:7098:9268:31e0:fe3e. This address was checked from the pdn0 interface inside the ue1 namespace on UEsim.

From the Callbox, run ping toward this IPv6 address. The output shows replies from the UE address, so IPv6 connectivity is working through the LTE user-plane path.

The first response time is relatively high, around 497 ms. This can happen during the initial packet exchange while the radio connection, routing, or buffering becomes active. After that, the response time becomes stable, around 29 to 36 ms in this example.

This step confirms that the IPv6-only PDN connection is not just established at NAS level, but also works for real IPv6 packet transfer. Once this ping is successful, you can proceed with IPv6 iPerf testing by using the same full UE IPv6 address as the iPerf destination.

Iperf Test 4 Run 09

On UEsim, run the iperf in udp server mode. -V option is to allow IPv6 address.

In this example, the command is executed inside the UE network namespace using ip netns exec ue1. This is required because the UE PDN interface is created inside the ue1 namespace.

The command is ip netns exec ue1 iperf -s -u -V -i 1. The option -s starts iPerf in server mode, -u enables UDP mode, -V enables IPv6 operation, and -i 1 prints the result every 1 second.

After the command is started, iPerf listens on UDP port 5001. The output shows that it is receiving 1470 byte datagrams, and the UDP buffer size is 208 KByte by default.

At this point, the UE side is ready to receive IPv6 UDP traffic. In the next step, run the iPerf client on the Callbox side and use the full IPv6 address assigned to the UE pdn0 interface as the destination address.

Iperf Test 3 Run 10

On Callbox, run the iperf in udp client mode and confirm that the ip iptraffic is going out.

In this example, the destination address is the full IPv6 address assigned to the UE pdn0 interface:

2001:468:2000:1:7098:9268:31e0:fe3e

The command uses -u for UDP mode and -V for IPv6 mode. The -c option specifies the UE IPv6 address, -b 100M sets the target bitrate to 100 Mbps, -i 1 prints the result every 1 second, and -t 100 runs the test for 100 seconds.

After the command starts, iPerf connects to the UE IPv6 address on UDP port 5001. The output shows that the local Callbox IPv6 address is 2001:468:2000:1::, and the remote address is the UE IPv6 address. This confirms that the traffic is using the IPv6 path.

The sender-side result shows about 12.5 MBytes transferred every second, corresponding to around 105 Mbits/sec. This means the Callbox is generating IPv6 UDP traffic close to the configured 100 Mbps target rate.

This output only confirms the transmitted traffic from the Callbox side. To check the actual received throughput, you should also check the iPerf server output on UEsim. For UDP tests, the receiver-side result is more important because packet loss can make the received throughput much lower than the sender-side throughput.

Iperf Test 4 Run 11

On UEsim, confirm that IP traffic is coming in.

In this example, the iPerf server is still running inside the ue1 namespace with IPv6 UDP server mode. The output shows that the local address is the UE IPv6 address 2001:468:2000:1:7098:9268:31e0:fe3e, and the remote sender is the Callbox IPv6 address 2001:468:2000:1::.

This confirms that IPv6 UDP traffic is reaching the UE through the LTE IPv6-only PDN connection.

The received throughput is around 2.6 to 2.8 Mbits/sec in the shown intervals. This is much lower than the 100 Mbps target rate configured on the Callbox iPerf client. Since this is UDP, the sender-side result only shows how much traffic the Callbox tries to transmit. The receiver-side result shows how much traffic actually reaches the UE application.

The first interval shows high loss, but after that the Lost/Total Datagrams value becomes 0%. This means that after the initial period, the traffic that reaches this rate is being received cleanly. However, the delivered rate itself is still low compared to the configured 100 Mbps target.

In this situation, check the Callbox t trace together with this iPerf result. If the radio link has low CQI, low MCS, high retransmission, or low scheduled bitrate, the received iPerf throughput will also be low. You can reduce the iPerf target rate first, then increase it gradually while checking packet loss and radio status.

Iperf Test 4 Run 12

© 2025 All rights reserved | Legal notice |