NRF9160 Cell Tower Blacklist

[David]

NRF SDK 1.9.1

Modem Firmware 1.3.1

I currently have a production device out in the field that is connecting to a specific cell tower and has the ability to then connect and send data over MQTT to my backend services.

However after running for about 30mins to 1 hour it will swap over to another cell tower, and it is connected perfectly fine to the tower however it will no longer be able to connect to MQTT or actually send any data while being attached to this "rogue" tower.. I have a Jasper platform for my M2M sims and i can see that it is online and connected over  LTE however it is failing to actually connect and publish any messages over MQTT.

If the device gets power cycled it jumps back onto the "good" cell tower and can  connect send data over MQTT, for another 30mins until it swaps back to the rogue tower.

so as a terrible work around i have a WDT that kicks in after 30mins of  unsuccessful MQTT publishes. Here is some data it gathered while being in an "offline" state.. so this is information from the AT%CONEVAL command and a couple of other fields i included for diagnostics.. e.g. how many LTE connect attempts, how many MQTT connect attempts, how many publishes..

We can see that it is connected to a cell tower and is registered home (1) on ATT Mobility, however we attempted to connect over MQTT 170 times which matches up because i attempt to connect every 10 seconds (for 30mins = 180)

{ "connInfo": { "rrcState": 0, "energy": 5, "tau": 0, "ce": 0, "earfcn": 5110, "pathloss": 118, "rsrp": 44, "rsrq": 9, "txRep": 1, "rxRep": 1, "phy": 37, "band": 12, "snr": 21, "txPower": 8, "mcc": 310, "mnc": 410, "cell": 141012240, "regstats": 1, "evalResult": 0 }, "lteAttempts": 0, "mqttAttempts": 170, "pubAttempts": 0}

So with that i have 2 questions:
1.  Is it possible to blacklist a specific cell tower (so i can blacklist this rogue tower)

 - I have only seen locking for specific carriers or bands (however this will not work as the carrier and band is the same as the good cell tower)

2. Is there an AT Command or something i can call to determine whether we actually have "data" capabilities over this cell connection

EDIT:

Because this device is out in the field it is very hard for me to get physical access (its on the other side of the world). Also because the device is in a sort of  "offline"  state i have to gather information and write it to flash on the WDT callback which can then be read back out during the next reboot / successful connection... 

I have the ability to perform OTA update to it when it is connected, so if you have any ideas of any extra diagnostic information i could possible add it to the info that is written to flash while being in this "offline" state and send it to my backend service when it comes back online again.

[Achim Kraus]

I'm just an other user, so hopefully you get also more qualified help.

Anyway, to make sure, your analysis is right, and the "rogue" tower is the culprit:

Did you try, what happens, it the modem starts with the "rogue" tower?

Or what happens, if you just restart the modem, but not the nRF9160 SoC ("lte_lc_offline()" and "lte_lc_normal()" again)?

Be very careful. "lte_lc_offline()" may result in storing the "rogue" tower as current and on restart using this one. If it's really the tower, then this may result in being "bricked". But it's hard to belief, that there are such "rogue" towers, using even the same PLMN.

(In my opinion there are several reports, that the modem sometimes have problems to "reconnect" and then send successful data. In my experience this still happens with the 1.3.3. I got reports, that the upcoming 1.3.4 will fix it. Crossing fingers.)

[David]

So upon further investigation it appears that the device can send data over the same tower.. however it does just stop working until a reboot is performed. even calling lte_lc_offline doesnt seem to work. a reset is required..

I have another device in the same area, however this is using a different tower and has been up and working pretty well. it goes offline occasionally but generally is pretty good.

[Achim Kraus]

> the device can send data over the same tower.

Great! That's good news. If single towers would have been a real world issue, then it would have been much more complicated.

> a reset is required.

Yep.

I decided to wait for the 1.3.4. Usually Nordic requests nrf9160 - sent udp message do not longer reach destination after 4 weeks traces, which is in such cases not too easy to provide.