Gemalto is now part of the Thales Group, find out more.

You are here

First message after a pause always slower in 3G than 2G using EHS5-E | Thales IoT Developer Community

jcalvarez

May 19, 2017 - 1:05pm, 870 views

Hi,

I have noticed that the first ping after a long pause takes a while in 3G using the EHS5-E modem. Below is a trace that shows the issue:

1) Ping 8.8.8.8 just after connection, first ping takes ~9934ms, then goes to ~320:

root@Phoenix /appfs/apps/share#ping 8.8.8.8 -c3
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=934.448 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=330.330 ms
64 bytes from 8.8.8.8: seq=2 ttl=56 time=320.128 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/*** = 320.128/528.302/934.448 ms

Quickly request PIN again several *****, now the first message is not delayed...

root@Phoenix /appfs/apps/share#ping 8.8.8.8 -c3
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=324.081 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=320.523 ms
64 bytes from 8.8.8.8: seq=2 ttl=56 time=330.353 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/*** = 320.523/324.985/330.353 ms
root@Phoenix /appfs/apps/share#ping 8.8.8.8 -c3
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=344.319 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=320.470 ms
64 bytes from 8.8.8.8: seq=2 ttl=56 time=320.122 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/*** = 320.122/328.303/344.319 ms

Now wait for like 10 min. It takes 2s for the first ping and 1 sec for the 2snd one:

root@Phoenix /appfs/apps/share#ping 8.8.8.8 -c3
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=2004.842 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=1005.411 ms
64 bytes from 8.8.8.8: seq=2 ttl=56 time=100.340 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/*** = 100.340/1036.864/2004.842 ms

I also see "psinfo" URC being sent when the long delay happens:

066233.582HEX DUMP: Buffer address = 0x4004B2B4, size = 21

     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF.
     -----------------------------------------------  ----------------.
000| 0D 0A 2B 43 49 45 56 3A 20 70 73 69 6E 66 6F 2C  ..+CIEV: psinfo`.
010| 36 0D 0A 0D 0A                                   6....           .
     -----------------------------------------------  ----------------.
066234.242HEX DUMP: Buffer address = 0x4004B2B4, size = 22
     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF.
     -----------------------------------------------  ----------------.
000| 0D 0A 2B 43 49 45 56 3A 20 70 73 69 6E 66 6F 2C  ..+CIEV: psinfo`.
010| 31 30 0D 0A 0D 0A                                10....          .
     -----------------------------------------------  ----------------.

Is this something related to the cell putting the module in low priority after a delay in traffic? I do not see the same issue when using a 2G modem, like the BGS2-W.

Is there any way to prevent this? My application is very sensitive to latency.

Many thanks in advance,

Jose