GSM Registration Status Issue

Legacy Open AT
1

Good day,

I’m having a very similar issue as these 2 posts
[url]https://forum.sierrawireless.com/t/gsm-network-problem/4906/6]
[url]https://forum.sierrawireless.com/t/can-not-catch-gsm-disconnection/5225/3]

I’ve noticed on a number of our units in the field that there are occasions when SMSs do not deliver, but at that time, the firmware believes it is on the network.
Initially I thought there was the possibly that the application had simply missed the disconnect event, but it now polls the creg status every minute and have confirmed that creg passes back that it is registered on the home network when this is happening. The unit does reboot itself periodically, and this fixes the issue and the SMS then delivers.

Product:SL6087
FW:7.47.4

  1. Is this a known issue? I have not found any documentation on it though
  2. Is there more effective way of checking the registration status?

Thanks

2

hi,
can you check the below….

  1. What is the LED status? Is it blinking or it’s stable?
  2. You can come to know the registration status through Wind indication. Set the indication level by AT+WIND=32767
  3. What exactly are you doing in your application? What is the exact use case?
  4. Can you try with latest FW to see the issue is still there or not
  5. Also can you check the response of AT+CSQ, AT+COPS? commands

Thanks,
Rex

3

Is it the same as this issue: Received SMS messages not reaching the SMS Handler

Symptoms:

  • SMS Delivery Notifications at the sender indicate that the message was delivered;
  • The “missed” messages are stored on the SIM.
4

Thanks for the replies rex_alex and awneil.

This is a different issue. There is no SMS delivery. Only after a the unit resets, does the SMS deliver.

I haven’t found this issue on a unit on the bench yet, so I haven’t been able to do the test rex_alex has suggested. Unfortunately, I’ve only noticed this from units we have out in the field that are with customers. It’s intermittent, but happens often enough to warrant some concern.

The customer sends an SMS to the unit and there is no delivery. Through our debug information we send up from the unit periodically, we can see that the unit believed it was on the network at this point. At some point later, the unit resets itself (for whatever reason) and then registers again on the network and the SMS then delivers.

How the unit is currently checking it’s network registration: Subscribing to unsolicited CREG messages, and also a periodically querying through AT+CREG? as a backup.

We have taken this up with our local distributor and are investigating the root cause. I will post back any findings. The initial feedback is that it may be something particular to the network these units are on.

Thanks

5

Do you also monitor WIND 7 & 8 :question:

I seem to recall that there may be cases where you don’t get an unsolicited +CREG with a corresponding WIND 7 or 8…?

Rather than a full reset, have you tried AT+COPS=0 to re-scan for available networks?

Are you using a roaming SIM; particularly one which attempts to “steer” to favoured networks?

It’s definitely worth having a “keepalive” as part of your higher-level protocol - to detect loss of end-to-end comms.

6

That could just be a network issue.

I have seen cases with mobile phones where Text Messages seem to get “lost” - and resetting the phone will kick the network back into life.

SMS is a ‘Store-and-Forward’ service: it’s as if the network Stores the message, but then “forgets” to Forward it - the phone re-registering (after the reset) causes the network to “remember”…

What network are you using :question:

7

Thanks again for the replies

Yes, this is monitored.

I have not tried this yet, this is something I will look to do

Nope

That does sound like a possibility. The network is MTS in Russia.
Although, another product of ours, in the same area and same network doesn’t seem to encounter this (or at least not to the extent where it’s being noticed by customers). It’s using a different modem, but a similar algorithm to handle it’s GSM connectivity.

Actually, to add to this… I have been going through the logs from a unit that had this issue, the unit eventually reset itself because of a GPRS failure. It was “on the GSM network”, and then some event happened on the unit which required TCP communication, so the unit attempted to connect the GPRS bearer and that failed. The unit then reset to recover from this GRPS issue, the SMS delivered, and the GPRS connection was established.

From this, I would think that the issue is more than simply SMSs not delivering.

8

Try to add AT+CLIP? and AT+CLCK=“AO”,2 every few minutes. A common failure is +CME ERROR: 30.
A failure here and there is no reason for panic, but if it fails every time over, say, 30 minutes, you can try to restart or re-register the module.
Also make sure that the operator is the preferred one. You may be registered, but to a different network, for emergency calls only. I use AT+CCED=0,5 but AT+COPS? may be enough.

9

That case should be obvious from the monitoring of WIND and CREG already mentioned.

10

Continued testing and managed to replicate this after weeks of evaluation.

The unit booted up, connected to the GSM and GPRS network, made a TCP connection and sent info to my server. About 2 hours later I could not deliver SMSs to the unit and also could not call it. I managed to connect to it via a comm port and tried querying the state. AT+CREG? returned that the unit was on the home network. I did find that any network class AT Commands (AT_CLASS_NETWORK +CCED, +COPN, +COPS, +CPLS, +CPOL, +CSQ, +WMBS, +WOPN, +WOLM) responded with CME ERROR 536. All other classes I tried executed fine.

Are there any known reasons why a particular class would lock up completely? As far as I understand, a class will lock when you’ve sent an AT Command of that class and it is still busy processing it. Once the AT command has been processed and responded to, it will release that class.