RTT Analysis
This tutorial is for showing how to check / analyze various factors that may affect RTT and help with RTT optimization
- Ask yourself on why you want to minimize RTT (In many cases, you may not need to minimize it)
- Importance of RTT would vary depending on Application.
- In some cases, Jitter (variance of RTT) would be more important than RTT
- Except for Voice, realtime video RTT is not so important for most of application
In many case, RAN side portion would be relatively small out of the whole RTT (end-to-end RTT), but people want to minimize it just by tweaking RAN parameters
If you want to estimate / compare Core network impact on end-to-end RTT, RAN side RTT is not so important. What's important about RAN side impact on the end-to-end RTT is the exact range of RAN side delay and variation of the delay. If you know of the exact delay of RAN side delay, you can just substract the value from the end-to-end RTT to estimate the core network impact on end-to-end RTT
NOTE : For the technical tips of RTT improvement with Amarisoft solution, refer to this wiki.
Table of Contents
- RTT Analysis
Test Setup
Test setup for this tutorial is as shown below.
- SIM Card used in this tutorial is the one delivered with the system as it is.
- If you want to change the configuration, The tutorial Configuration Guide would help
Following shows the location of the Callbox and the DUTs. Callbox and DUTs are in different rooms separated by a wall at a distance of about 3 m. (NOTE : Usually other test equipment does not provide stable connectivity in this kind of situation)
The wireless connectivity among Callbox and all the DUTs used in this tutorial is as shown below.
There are several many ways to provide internet access to your CallBox. Followings are some of them I can think of. In this tutorial, I used the Case 4.
If you decided to use Case 2 and Case 3, following tips would be helpful.
Since Amari Callbox is running command line mode of Linux (Fedora or Ubuntu) NOT on GUI , it is not straightforward to enable / connect WiFi.
Followings are some of the command line command you would need to get WiFi connectivity. You may search these commands on internet for the detailed usage.
# nmcli dev status
# nmcli radio wifi
# nmcli device wifi rescan
# nmcli dev wifi list
# nmcli dev wifi connect network-ssid password "network-password"
Configuration
You can use any configuration that will assign at least one IP to UE with internet apn. For example, you can use LTE attach configuration or SA or NSA configuration.
Check Up before trying UE connection
Before you trying internet connection with UE, you need to check several basic things shown in this section and make it sure everything works as shown here, otherwise Internet connection from UE may not work.
Make it sure that the network interface with internet connectivity is up and tun0,1,2,3 are up.
Check up the routing table on CallBox PC. It would usually be as follows. (NOTE : The gateway Iface name may be different on your system depending on your system configuration. But you should see tun0, tun1, tun2, tun3 as shown below)
Make it sure that the call box can reach a server over the internet. I am checking the connectivity as follows
Try ping to 8.8.8.8. This is google DNS and this is configured as DNS by default in mme.cfg
Try ping to a url to check the DNS is working
[Optional] you may find the IP address to a specific url and try ping to the server with both in direct IP and url
Setting Logging Property
For the detailed analysis, I set the (ENB) logging properties as follows. Increased Max size to capture the full IP header.
For the same purpose, set the (MME) logging properties as follows. Increased Max size to capture the full IP header.
Test 1 : WiFi
This Test is NOT a main purpose of the tutorial. This is just to show a comparative setup (a reference) to other tests. This Test is done with WiFi and PC. No cellular protocol and mobile phone is involved
ping from the point (A) to point (C). This is to check the connectivity within Local WiFi Network.
ping from the point (A) to point (B). This is also to check the connectivity within Local WiFi Network.
ping from the point (C) to point (B). This is also to check the connectivity within Local WiFi Network.
ping from the point (C) to Google. This is to check the connectivity and RTT from the callbox to Google DNS located in US
ping from the point (C) to a PC located in France to check Connectivity and RTT.
ping from the point (C) to a PC located in Korea to check Connectivity and RTT.
Test 2 : LTE Ping
In this test, I ran the test with enb.cfg file (LTE, 5 Mhz Bandwidth)
You can check on ping packet (ICMP packet) at higher layer (GTPU) log
You can check the exact timing when the ICMP packet is transmitted at PHY layer by checking the contents of PHY frame. This is for the packet transmitted from the callbox. This is why I set the large value to (ENB) log property at the beginning.
You can check the exact timing when the ICMP packet is recieved at PHY layer by checking the contents of PHY frame. This is for the packet received by the callbox.
If you assume that the processing time in MAC~PDCP is negligibly short, you can check the delay time caused by RAN by comparing the PHY frame timing for Echo Request and Echo Reply.
You can also check on the end to end delay from an Application layer using a speed test tool. Not all speed test tool shows delay time (like Ping delay). It would be good to find the speed test tool that shows the delay (and jitter).
If you compare the delay at the application layer and the delay by RAN as shown above, you can break down the end to end delay into RAN delay and Core/Internet delay.
Test 3 : NR/SA Ping
In this test, I used gnb-sa.cfg with CONFIG = 2. The RTT may vary depending on TDD UL/DL Configuration pattern.
You can check on ping packet (ICMP packet) at higher layer (GTPU) log
You can check the exact timing when the ICMP packet is transmitted at PHY layer by checking the contents of PHY frame. This is for the packet transmitted from the callbox. This is why I set the large value to (ENB) log property at the beginning.
You can check the exact timing when the ICMP packet is recieved at PHY layer by checking the contents of PHY frame. This is for the packet received by the callbox.
If you assume that the processing time in MAC~PDCP is negligibly short, you can check the delay time caused by RAN by comparing the PHY frame timing for Echo Request and Echo Reply.
You can also check on the end to end delay from an Application layer using a speed test tool. Not all speed test tool shows delay time (like Ping delay). It would be good to find the speed test tool that shows the delay (and jitter).
If you compare the delay at the application layer and the delay by RAN as shown above, you can break down the end to end delay into RAN delay and Core/Internet delay.
