GSM connection lost in high signal strength areas

Legacy Legacy AirPrime modules
1

I have an streaming video (cctv) application that requires a constant HSDPA connection.

Normally the SL808xT module works very well, but in areas of high signal strength with multiple base stations it regularly loses it’s connection to the mobile network and has to reconnect. This can happen as regularly as every two minutes and the disconnect/reconnect cycle can go on for hours. The device is in a static location and not moving.

The problem only seems to exist where there are multiple base stations. If there is just one base station, even at very high signal strength levels, the connection is never dropped.

I’ve searched through the logs and done all sorts of testing but I cannot see any reason why the device drops from the network in these situations. I can modify the application to automatically re-establish the data connection once the connection to the mobile operator is restored, but the regularly drops in data connection is making the application unusable.

Has anyone experiencing a similar problem, or can anyone suggest some options to stop the connection being lost? I’ve been trying to figure this out for weeks.

1: Connection is fine, using one base station:

2014/01/27;17:39:09:708;002;ATI;1;AT+CREG?<CR>
2014/01/27;17:39:09:708;004;ATI;1;<CR><LF>+CREG: 2,1,"002F","00C64698",2<CR><LF>
2014/01/27;17:39:09:708;006;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:12:703;002;ATI;1;AT+CREG?<CR>
2014/01/27;17:39:12:703;004;ATI;1;<CR><LF>+CREG: 2,1,"002F","00C64698",2<CR><LF>
2014/01/27;17:39:12:703;006;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:15:714;001;ATI;2;Rec AT_APPLI_SEND_COMMAND
2014/01/27;17:39:15:730;001;ATI;1;AT+CREG?<CR>
2014/01/27;17:39:15:730;003;ATI;1;<CR><LF>+CREG: 2,1,"002F","00C64698",2<CR><LF>
2014/01/27;17:39:15:730;005;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:18:740;001;ATI;2;Rec AT_APPLI_SEND_COMMAND
2014/01/27;17:39:18:740;002;ATI;1;AT+CREG?<CR>
2014/01/27;17:39:18:740;004;ATI;1;<CR><LF>+CREG: 2,1,"002F","00C64698",2<CR><LF>
2014/01/27;17:39:18:740;006;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:19:364;001;ATI;2;Rec V24_AT_CMD_IND_EXTENDED
2014/01/27;17:39:19:364;002;ATI;2;Rec AT_APPLI_SEND_RSP_EXTERNAL

2: Connection suddenly drops, apparently for no reason:

2014/01/27;17:39:21:439;001;L3RR;3;+CREG: 0
2014/01/27;17:39:21:439;002;L3RR;3;+CGREG: 0
2014/01/27;17:39:21:439;003;ATI;2;Rec I_MMT_MM_SERVICE_IND
2014/01/27;17:39:21:455;001;ATI;1;<CR><LF>+WIND: 8<CR><LF>
2014/01/27;17:39:21:455;003;ATI;1;<CR><LF>+CREG: 2<CR><LF>
2014/01/27;17:39:21:470;001;ATI;2;Rec MMT_GM_SERVICE_IND
2014/01/27;17:39:21:470;002;ATI;1;<CR><LF>+CGEV: ME DETACH<CR><LF>
2014/01/27;17:39:21:470;004;ATI;1;<CR><LF>+CGREG: 0<CR><LF>
2014/01/27;17:39:21:470;006;ATI;2;Rec AT_APPLI_SEND_UNS_EXTERNAL
2014/01/27;17:39:21:470;007;ATI;2;Rec AT_APPLI_SEND_UNS_EXTERNAL
2014/01/27;17:39:21:470;032;ADL;16;[ADL port] IsAvailable(80) : 1
2014/01/27;17:39:21:486;001;ATI;2;Rec AT_APPLI_SEND_COMMAND
2014/01/27;17:39:21:486;002;ATI;1;AT+CGACT=0,1<CR>
2014/01/27;17:39:21:486;004;ADL;31;[ADL] GPRS unsubs 107B5595 : 0
2014/01/27;17:39:21:486;005;ATI;2;Rec AT_APPLI_SEND_UNS_EXTERNAL
2014/01/27;17:39:22:874;001;L3RR;3;+CGREG: 0
2014/01/27;17:39:22:890;001;ATI;2;Rec I_MMT_MM_SERVICE_IND
2014/01/27;17:39:23:296;001;ATI;1;<CR><LF>+WIND: 7<CR><LF>
2014/01/27;17:39:23:296;003;ATI;1;<CR><LF>+CREG: 1,"002F","00C63F5F",2<CR><LF>
2014/01/27;17:39:23:311;001;ATI;2;Rec MMT_GM_SERVICE_IND
2014/01/27;17:39:23:311;002;ATI;2;Rec MMT_GM_SERVICE_IND
2014/01/27;17:39:23:311;003;ATI;1;<CR><LF>+CGREG: 1,"002F","00C63F5F",2<CR><LF>
2014/01/27;17:39:23:311;005;ATI;2;Rec MMT_SESSION_RELEASE_RSP
2014/01/27;17:39:23:311;006;ATI;1;<CR><LF>+CGEV: ME DEACT "IP", "10.19.32.19",1<CR><LF>
2014/01/27;17:39:23:311;008;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:23:311;010;ATI;2;Rec AT_APPLI_SEND_UNS_EXTERNAL
2014/01/27;17:39:23:311;011;ATI;2;Rec AT_APPLI_SEND_UNS_EXTERNAL
2014/01/27;17:39:23:311;012;ATI;2;Rec AT_APPLI_SEND_UNS_EXTERNAL
2014/01/27;17:39:23:311;013;ATI;2;Rec AT_APPLI_SEND_COMMAND

3: Device registers back onto home network, on a different base station (not sure if that’s relevant):

2014/01/27;17:39:23:311;014;ATI;1;AT+CREG?<CR>
2014/01/27;17:39:23:311;016;ATI;1;<CR><LF>+CREG: 2,1,"002F","00C63F5F",2<CR><LF>
2014/01/27;17:39:23:311;018;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:23:311;020;ADL;4;(Gprs) Registered on GSM network.
2014/01/27;17:39:23:311;021;ADL;4;(Gprs) SIM initialised, going online
2014/01/27;17:39:23:311;022;ATI;2;Rec AT_APPLI_SEND_COMMAND
2014/01/27;17:39:23:311;023;ATI;1;AT+CGDCONT?<CR>
2014/01/27;17:39:23:311;025;ATI;1;<CR><LF>+CGDCONT: 1,"IP","apn.com",,0,1<CR><LF>
2014/01/27;17:39:23:327;001;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:23:327;003;ADL;1;OpenAndStartBearer()
2014/01/27;17:39:23:327;004;NET;11;GPRS-USER gprs0 open: -> DISCONNECTED
2014/01/27;17:39:23:327;005;ADL;1;apn.com
2014/01/27;17:39:23:327;008;ADL;31;[ADL] Gprs subs 107B5595 : 0
2014/01/27;17:39:23:327;009;ADL;16;[ADL port] IsAvailable(80) : 1
2014/01/27;17:39:23:327;010;ATI;2;Rec AT_APPLI_SEND_COMMAND
2014/01/27;17:39:23:327;011;ATI;1;AT+CGDCONT=1,"IP","apn.com",,0,1<CR>
2014/01/27;17:39:23:327;013;ATI;1;<CR><LF>OK<CR><LF>
2014/01/27;17:39:23:327;015;ADL;31;[ADL] Gprs setup 1 : 0
2014/01/27;17:39:23:327;016;ADL;16;[ADL port] IsAvailable(80) : 1
2014/01/27;17:39:23:327;017;ATI;2;Rec AT_APPLI_SEND_COMMAND
2014/01/27;17:39:23:327;018;ATI;1;AT+CGACT=1,1<CR>
2

Hi David,

Normally if module and network decide to handover to another base station, the data connection will be maintained and no need to manually re-establish it.

Are you running your custom OpenAT application?
What if you disabled the OpenAT and start a PPP session (to simulate the data connection) to check if same issue happens?

Also what FW version you are using?

Thx

3

Thanks for your reply.

I’ll try testing with the PPP connection and see what the outcome is.

I agree that normally the data connection is maintained during cell handovers, and in fact for the majority of the time the module performs flawlessly and a connection is maintained even during extensive drive testing. It seems the problem only appears in locations where there are a number of high power base stations in a small area.

I don’t understand why the network seems to completely drop the connection.

Here is the version information:

16:58:35:985 - "DWL"," S4_1_0_8ABT R1803 CNSZXD00000155 2013/08/22 13:53:40","","Sierra Wireless",0,"","00000000","00000000"
16:58:35:985 - "FW","FW_752_45.SL808Fx","R7.52.0.201308300753.SL8082T","Sierra Wireless",1782216,"083013 07:53","937f7958","10002020"
16:58:35:985 - "MODEM 3G+","Revision: S4_1_0_8AAP R1803 CNSZXD00000155 2013/08/22 13:53:40"
16:58:35:985 - "OAT","1.7.20131204165350","Radio","CCTVLink",1047596,"120413 16:54","29087ad0","10700000"
16:58:36:001 -  -"Developer Studio","2.3.2.201310241753"
16:58:36:001 -  -"Open AT OS Package","6.50.0.A1.201302051441"
16:58:36:001 -  -"Firmware Package","7.50.0.A1.201302131100"
16:58:36:001 -  -"Internet Library Package","5.53.0.A1.201211071132"
16:58:36:001 -  -"Location Library Package","1.4.6.201309111006"
16:58:36:001 - "ROM","8400000"
16:58:36:001 - "RAM","4000000"
16:58:36:001 - "DWLNAME","SL808x"
4

The signal strength might just be a red herring?

It might be that you just happen to be in a position where you’r getting inter-BSC or even inter-MSC handovers, or some other “funny” up the network tree such that it can’t maintain the PDP context…?

Do you have a technical contact at the Network operator?

5

Hiya,

There is a whole lot of info that can be obtained from the internal traces of the modem to track down issues like this.

I suspect that you’ll need to get in touch with your FAE to (a) find out which traces and levels to turn on & (b) get help to decode what they mean. Your FAE might have to raise a ticket with Sierra Wireless to get this info.

This additional trace info is not readily available other than from Sierra Wireless themselves.

ciao, Dave

6

I’m working with the FAE, but in case anyone is interested it seems (from my interpretation of the logs) there is a bug around cell handover:

2014/02/04;12:15:58:550;001;ATI;5;ati_WholeCmd: 0
2014/02/04;12:15:58:550;002;ATI;1;AT+CREG?<CR>
2014/02/04;12:15:58:550;003;ATI;5;Rec Msg Len= 9
2014/02/04;12:15:58:550;004;ATI;5;Cmd Len= 13
2014/02/04;12:15:58:550;005;ATI;1;Storing AT Command
2014/02/04;12:15:58:550;006;ATI;1;41 54 2b 43 52 45 47 3f 1a
2014/02/04;12:15:58:550;007;ATI;1;ati_SndIntermediateAtRsp: Len=34
2014/02/04;12:15:58:550;008;ATI;1;<CR><LF>+CREG: 2,1,"002F","00C64BB1",2<CR><LF>
2014/02/04;12:15:58:550;009;ATI;1;0d 0a 2b 43 52 45 47 3a 20 32 2c 31 2c 22 30 30 32 46 22 2c 22 30 30 43 36 34 42 42 31 22 2c 32 0d 0a
2014/02/04;12:15:58:550;010;ATI;3;Snd AT_APPLI_INTERMEDIATE_IND
2014/02/04;12:15:58:550;011;ATI;1;ati_Rsp RspType = 1 CmdClass = 1
2014/02/04;12:15:58:550;012;ATI;1;ati_Rsp() : FlowID= 128
2014/02/04;12:15:58:550;013;ATI;1;ati_SendText( 1, 1, 0, 0x80 )
2014/02/04;12:15:58:550;014;ATI;1;ati_SendRsp: Len=6 PortId = 80
2014/02/04;12:15:58:550;015;ATI;1;<CR><LF>OK<CR><LF>
2014/02/04;12:15:58:550;016;ATI;1;0d 0a 4f 4b 0d 0a
2014/02/04;12:15:58:550;017;ATI;3;Snd AT_APPLI_SEND_COMMAND_RSP
2014/02/04;12:15:58:550;018;ATI;1;Begin: ati_ResetAutomata(): AutoNb: 64, CmdClass:1
2014/02/04;12:15:58:550;019;ATI;1;End: ati_ResetAutomata()

2014/02/04;12:15:59:892;001;ATMGR;13;+CREG: 0                 <--------------------- BUG HERE
2014/02/04;12:15:59:892;002;ATMGR;13;+CGREG: 0
2014/02/04;12:15:59:892;003;ATMGR;13;+CREG: 1,"002F","00C64694",2
2014/02/04;12:15:59:892;004;ATMGR;13;+CGREG: 1,"002F","00C64694",2

The radio has switched cell 00C64BB1 to 00C64694. While doing so, it has gone through a zero-time period of not being attached to a cell. The code handling that (“L3RR”) spots the CREG: 0 message coming from some lower layer in the modem, and decides to shut down the GPRS bearer:

2014/02/04;12:15:59:939;079;ADL;16;[ADL port] IsAvailable(80) : 1
2014/02/04;12:15:59:939;080;ATI;5;ati_WholeCmd: 0
2014/02/04;12:15:59:939;081;ATI;1;AT+CGACT=0,1<CR>
2014/02/04;12:15:59:939;082;ATI;5;Rec Msg Len= 13
2014/02/04;12:15:59:939;083;ATI;5;Cmd Len= 21
2014/02/04;12:15:59:939;084;ATI;1;Storing AT Command
2014/02/04;12:15:59:939;085;ATI;1;41 54 2b 43 47 41 43 54 3d 30 2c 31 1a
2014/02/04;12:15:59:939;086;ATI;26;ati_TreatCmd_gprs()
2014/02/04;12:15:59:939;087;ATI;5;Verify CMD: Min 1, Max 9, State 14
2014/02/04;12:15:59:939;088;ATI;26;ati_CGACT(): One or more CID specified
2014/02/04;12:15:59:939;089;ATI;26;ati_CGACT(): State 0 : Deactivation requested
2014/02/04;12:15:59:939;090;ATI;26;ati_CGACT(): deactivation count=1
2014/02/04;12:15:59:939;091;ATI;26;ati_CGACT(): Cid=1 ,TEAR DOWN=0

These zero-duration network loss events impact the entire stack, and results in a 10 second drop in connection while the bearer is disconnected and re-established, which probably isn’t necessary.

I don’t know what the triggers are that causes this behaviour. In most locations cell handover is smooth but in an increasing number of locations this problem is experienced continually.

Hopefully this is of interest as I’m sure it’s probably impacted other applications where continual connectivity is required (such as streaming video).

7

Hmm… sounds a bit similar to a case I had a while back where the modem would lose signal, but then not reconnect when the signal came back…

8

Update: Our FAE believes this is a firmware bug and has escalated to the SW engineering team.

We can reproduce the disconnects when using the SL808xT module as a modem so that rules out any strange behaviour by our application.