Data Throughput

  

 

 

 

Check-up before test

 

Even before you try any throughput test (e.g, UDP, TCP), there are several critical steps to go through. In many cases, I had been asked to be on-site saying "SOMETHING is NOT WORKING" (These two words are what we most frequently use, but most ambiguous word. What is the "SOMETHING" ? What do you mean by "NOT WORKING". .. Let'snot get into this too much -:).

Followings are some of the items that I recommend you to try before you starting throughput test. I call this as 'Connection Test' or 'Data Path Check'.

 

 

 

Check IP Allocation

 

First thing you have to check is to check if your device get assigned any IP address that a network or Network Emulator assigned. If you have UE logging tool or special menu/tool on your UE to show the IP address, it will be great help.

 

Another way to check the IP allocation for UE if the UE is a data card or connected to PC as a modem (tethered to PC), try ipconfig command as follows.

 

C:\> ipconfig

Ethernet adapter Local Area Connection 9:

        Connection-specific DNS Suffix  . :

        IP Address. . . . . . . . . . . . : 192.168.1.1

        Subnet Mask . . . . . . . . . . . : 255.255.255.0

        Default Gateway . . . . . . . . . :

 

In some case, this result (i.e, ipcofig shows the IP address allocated to UE) is enough signal for you to go to next step like ping. But sometimes just ipconfig result would not be a guarantee for next step. (I think it depends on UE driver implementation).

 

A better insurance in this case would be as follows. Open up the Network Connection Menu and see if you see the Modem and Network interface card properly configured and connected.

 

 

And openup the LAN card property for the UE and set the IP allocated to UE.

 

 

Now you are ready to take real first step for the test, which is PING test. I am using Ping for two purpose. One is to check if the end to end (from server to client) data path is established and the other is to figure out the latency (delay time) between server and client.

 

 

Try Ping and Ping Delay

 

First I would do "ping to self". In my test, I allocated 192.168.1.1 to UE and 192.168.1.2 to server. All of these test was done on client PC, the PC to which the UE is connected.

 

< Ping to Local IP (Ping to itself) >

 

This would always works.. but I did to give you some reference for latency for local loop. It is under 1 ms as you see.

    C:\>ping 192.168.1.1 -l 1400 (WCDMA DL 384K / 64 K, Local Loopback)

     

    Pinging 192.168.1.1 with 1400 bytes of data:

     

    Reply from 192.168.1.1: bytes=1400 time<1ms TTL=128

    Reply from 192.168.1.1: bytes=1400 time<1ms TTL=128

    Reply from 192.168.1.1: bytes=1400 time<1ms TTL=128

    Reply from 192.168.1.1: bytes=1400 time<1ms TTL=128

     

    Ping statistics for 192.168.1.1:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 0ms, Maximum = 0ms, Average = 0ms

 

< Ping to Gateway - Wireline >

 

For another reference, I ping to the Gateway my PC is connected to via wireline LAN. In my case, it shows almost same latency as local loop.

    C:\>ping 10.10.10.180 (on Wireline, to Gateway)

     

    Pinging 10.10.10.180 with 32 bytes of data:

     

    Reply from 10.10.10.180: bytes=32 time<1ms TTL=128

    Reply from 10.10.10.180: bytes=32 time<1ms TTL=128

    Reply from 10.10.10.180: bytes=32 time<1ms TTL=128

    Reply from 10.10.10.180: bytes=32 time<1ms TTL=128

     

    Ping statistics for 10.10.10.180:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 0ms, Maximum = 0ms, Average = 0ms

 

< Ping to Distant Server - Wireline >

 

Now for another reference, I pigned to a server which is far away from my PC. I don't know how many routers are there between my PC and the other PC. I don't know how far it is away from my PC geographically. Anyway the result is as follows. Now you see pretty long response delay here which is around 220 ms.

    C:\>ping 64.233.183.99 (on Wireline)

     

    Pinging 64.233.183.99 with 32 bytes of data:

     

    Reply from 64.233.183.99: bytes=32 time=222ms TTL=43

    Reply from 64.233.183.99: bytes=32 time=221ms TTL=43

    Reply from 64.233.183.99: bytes=32 time=221ms TTL=43

    Reply from 64.233.183.99: bytes=32 time=222ms TTL=43

     

    Ping statistics for 64.233.183.99:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 221ms, Maximum = 222ms, Average = 221ms

 

< Ping to Server PC - (WCDMA DL 384K / UL 64 K) - Test Equipment >

 

Now let's get into the situation that we are really interested. I connected UE to my Network Emulator with WCDMA DL 384K /UL 64 K radio bearer and got the following result. If you try with your device, you may have different number.. so the exact number for the time delay would not be so important, but you see pretty long delay which is around 323 ms. I put "-l" optionto send almost full size IP packet. It is direct connection from UE to Network emulator. But if you see the delay value here, it is greater than the delay between my PC and a remote server on wireline network which may have over 100 hops along the line.

    C:\>ping 192.168.1.2 -l 1400 (WCDMA DL 384K / UL 64 K)

     

    Pinging 192.168.1.2 with 1400 bytes of data:

     

    Reply from 192.168.1.2: bytes=1400 time=332ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=326ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=324ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=323ms TTL=128

     

    Ping statistics for 192.168.1.2:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 323ms, Maximum = 332ms, Average = 326ms

I used exactly same UE and same driver. Only changed radio bearer to HSDPA DL 3.6 M/UL 5.6 M. Pinged and got the result as follows. Delay time decreased almost 3 times.

    C:\>ping 192.168.1.2 -l 1400   (HSDPA DL 3.6 M/UL 5.6 M)

     

    Pinging 192.168.1.2 with 1400 bytes of data:

     

    Reply from 192.168.1.2: bytes=1400 time=112ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=107ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=116ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=115ms TTL=128

     

    Ping statistics for 192.168.1.2:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 107ms, Maximum = 116ms, Average = 112ms

 

 

< Ping to Server PC - (HSDPA DL 7.2 M/UL 5.6 M)- Test Equipment >

 

And tried the ping with a little bit higher data rate HSPA Bearer (HSDPA DL 7.2 M/UL 5.6 M). It is almost same delay time as before (lower data rate HSPA). Definately you will see different throughput comparing to previous bearer, but in terms of ping delay we don't see much difference here.

    C:\>ping 192.168.1.2 -l 1400  (HSDPA DL 7.2 M/UL 5.6 M)

     

    Pinging 192.168.1.2 with 1400 bytes of data:

     

    Reply from 192.168.1.2: bytes=1400 time=116ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=111ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=110ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=108ms TTL=128

     

    Ping statistics for 192.168.1.2:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 108ms, Maximum = 116ms, Average = 111ms

 

< Ping to Server PC - (HSDPA DL 14.4 M/UL 5.6 M)- Test Equipment >

 

From previous two test, I don't depect any big different with this test, but anyway I gave it another try with higher HSDPA bearer.

    C:\>ping 192.168.1.2 -l 1400  (HSDPA DL 14.4 M/UL 5.6 M)

     

    Pinging 192.168.1.2 with 1400 bytes of data:

     

    Reply from 192.168.1.2: bytes=1400 time=126ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=113ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=112ms TTL=128

    Reply from 192.168.1.2: bytes=1400 time=110ms TTL=128

     

    Ping statistics for 192.168.1.2:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 110ms, Maximum = 126ms, Average = 115ms

 

< Ping to Server PC - (HSDPA 65QAM/Single Carrier) - Test Equipment >

 

Now I pushed the same device one more step upward. I get it connected to HSPA+ Bearer (Category 14, 64 QAM). You see the difference ? The delay time get halved comparing to conventional HSDPA.

    C:\>ping 192.168.1.2  -l 1400 (HSPA 64 QAM / Single Carrier)

     

    Pinging 192.168.1.2 with 32 bytes of data:

     

    Reply from 192.168.1.2: bytes=32 time=58ms TTL=128

    Reply from 192.168.1.2: bytes=32 time=54ms TTL=128

    Reply from 192.168.1.2: bytes=32 time=53ms TTL=128

    Reply from 192.168.1.2: bytes=32 time=52ms TTL=128

     

    Ping statistics for 192.168.1.2:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 52ms, Maximum = 58ms, Average = 54ms

 

< Ping to Server PC - (HSDPA 65QAM/Dual Carrier) - Test Equipment >

 

Now I upgraded the bearer one step further to HSPA+ Dual Carrier (Category 24) and I don't see much improvement comparing to previous one.

    C:\>ping 192.168.1.2 -l 1400 (HSPA+ Dual Carrier)

     

    Pinging 192.168.1.2 with 32 bytes of data:

     

    Reply from 192.168.1.2: bytes=32 time=53ms TTL=128

    Reply from 192.168.1.2: bytes=32 time=48ms TTL=128

    Reply from 192.168.1.2: bytes=32 time=47ms TTL=128

    Reply from 192.168.1.2: bytes=32 time=56ms TTL=128

     

    Ping statistics for 192.168.1.2:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 47ms, Maximum = 56ms, Average = 51ms

 

 

< Ping from Server PC to UE - LTE - Test Equipment >

 

Now let's try with the LTE. I setup a EPS Bearer in Test Equipment (Network Simulator) and get UE connected to it with EPS Bearer which is large enough to transmit the whole ping package in a single PDSCH / PUSCH.

 

First tried with a large ping packet size, I got following result. Here, you see about 14 ms turn around time.. but for some UE I get 11 ms turnaround time.

    C:\>ping 192.168.1.1 -l 1400

     

    Pinging 192.168.1.1 with 1400 bytes of data:

    Reply from 192.168.1.1: bytes=1400 time=15ms TTL=64

    Reply from 192.168.1.1: bytes=1400 time=14ms TTL=64

    Reply from 192.168.1.1: bytes=1400 time=15ms TTL=64

    Reply from 192.168.1.1: bytes=1400 time=15ms TTL=64

     

    Ping statistics for 192.168.1.1:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 14ms, Maximum = 15ms, Average = 14ms

 

Then I tried with smaller packet size (default ping packet size) and I tend to get a little bit short turnaround time but not so different.

    C:\>ping 192.168.1.1

     

    Pinging 192.168.1.1 with 32 bytes of data:

    Reply from 192.168.1.1: bytes=32 time=16ms TTL=64

    Reply from 192.168.1.1: bytes=32 time=13ms TTL=64

    Reply from 192.168.1.1: bytes=32 time=11ms TTL=64

    Reply from 192.168.1.1: bytes=32 time=12ms TTL=64

     

    Ping statistics for 192.168.1.1:

        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 11ms, Maximum = 16ms, Average = 13ms

 

 

More to think of

 

Now let's get into each of different radio technologies and see if we can explain why we have different throughput and even different ping delay.

 

I haven't completed the remaining part... but it would be good to give all of you a couple of days to think about this issue.

  • What kind of failure mode you see for each technology ? (Data rate lower than you expected ? Data rate no problem.. but all of the sudden call drop ? )

  • The failure mode is same for all technology or different ?

  • Recalling each of the steps along the data path, which one do you think would be the bottleneck for the throughput ?

  • Would the bottleneck be the same for all technology ? or different ?

  • Can you explain technically about the root cause of the failure ?

Don't expect that I would know all the answer and give you the clear answer. I also have to think a lot and will give you my opinion just based on my experience and based on my shallow knowledge a couple of days later.