User in Guernsey cannot connect to the network with NRF9160

[lzpons]

Hi,

I have a customer in Guernsey that received one of our Thingy91 hubs and he's not able to connect.

Here is some troubleshooting facts :

- when he moves to London the device connects successfully

- when he looks to the available networks locally with his iphone, there is actually an LTE network see snapshot.

- if he puts our SIM in his phone, it works properly establishing a connection.

- when he looks to the available networks through the Thingy:91 with the LTE Link Monitor using AT+COPS? command : nothing is reported

What may be wrong with this location? are there "special" LTE networks that the NRF9160 cannot see?

What troubleshooting would you suggest to move ahead?

Thanks for your help

LP

[Didrik Rokhaug]

Hi,

Is there LTE-M or NB-IoT coverage on Guernsey?

The nRF9160 only works with LTE-M and NB-IoT, and not "normal" LTE like a cell phone.

- when he looks to the available networks through the Thingy:91 with the LTE Link Monitor using AT+COPS? command : nothing is reported

This would indicate that there isn't LTE-M or NB-IoT (whichever the modem is configured to use) coverage at that location.

Best regards,

Didrik

[lzpons]

That's right, nothing reported with AT+COPS?  See the trace below.

To better understand the underlying topic, an LTE and an LTE-M network are two different protocols that do not necessarily go together?

It depends on how the overall network (or maybe the single antenna) are configured?

How can we check the coverage then? checking with a smartphone may be misleading since it will find 4G=LTE but not check for LTE-M

Is there any available documentation on this practical aspect? I am not finding it on the web.

LP

2022-12-13T09:36:22.369Z DEBUG Application data folder: C:\Users\user\AppData\Roaming\nrfconnect\pc-nrfconnect-linkmonitor
2022-12-13T09:36:22.466Z INFO Using nrf-device-lib-js version: 0.4.13
2022-12-13T09:36:22.466Z INFO Using nrf-device-lib version: 0.12.8
2022-12-13T09:36:22.466Z INFO Using nrfjprog DLL version: 10.16.0
2022-12-13T09:36:22.467Z INFO Using JLink version: JLink_V7.82a
2022-12-13T09:36:22.501Z DEBUG App pc-nrfconnect-linkmonitor v2.0.2 official
2022-12-13T09:36:22.501Z DEBUG App path: C:\Users\user\.nrfconnect-apps\node_modules\pc-nrfconnect-linkmonitor
2022-12-13T09:36:22.502Z DEBUG nRFConnect 3.12.0, required by the app is (^3.12.0)
2022-12-13T09:36:22.502Z DEBUG nRFConnect path: C:\Users\user\AppData\Local\Programs\nrfconnect\resources\app.asar
2022-12-13T09:36:22.502Z DEBUG HomeDir: C:\Users\user
2022-12-13T09:36:22.502Z DEBUG TmpDir: C:\Users\user\AppData\Local\Temp
2022-12-13T09:36:22.504Z INFO Installed JLink version does not match the provided version (V7.66a)
2022-12-13T09:36:30.205Z INFO Modem port is opened
2022-12-13T09:36:30.222Z DEBUG modem >> AT+CFUN?
2022-12-13T09:36:30.264Z DEBUG modem << +CFUN: 0
2022-12-13T09:36:30.269Z DEBUG modem << OK
2022-12-13T09:36:59.885Z DEBUG modem >> AT+CFUN=1
2022-12-13T09:36:59.937Z DEBUG modem << OK
2022-12-13T09:37:06.439Z DEBUG modem >> AT+CFUN?
2022-12-13T09:37:06.449Z DEBUG modem << +CFUN: 1
2022-12-13T09:37:06.469Z DEBUG modem << OK
2022-12-13T09:37:06.477Z DEBUG modem >> AT+CGSN=1
2022-12-13T09:37:06.488Z DEBUG modem << +CGSN: "352656101505934"
2022-12-13T09:37:06.494Z DEBUG modem << OK
2022-12-13T09:37:06.502Z DEBUG modem >> AT+CGMI
2022-12-13T09:37:06.517Z DEBUG modem << Nordic Semiconductor ASA
2022-12-13T09:37:06.520Z DEBUG modem << OK
2022-12-13T09:37:06.527Z DEBUG modem >> AT+CGMM
2022-12-13T09:37:06.536Z DEBUG modem << nRF9160-SICA
2022-12-13T09:37:06.538Z DEBUG modem << OK
2022-12-13T09:37:06.546Z DEBUG modem >> AT+CGMR
2022-12-13T09:37:06.554Z DEBUG modem << mfw_nrf9160_1.3.2
2022-12-13T09:37:06.557Z DEBUG modem << OK
2022-12-13T09:37:06.560Z INFO Nordic Semiconductor ASA nRF9160-SICA [mfw_nrf9160_1.3.2] SerNr: 352656101505934
2022-12-13T09:37:06.564Z DEBUG modem >> AT+CEMODE?
2022-12-13T09:37:06.575Z DEBUG modem << +CEMODE: 2
2022-12-13T09:37:06.578Z DEBUG modem << OK
2022-12-13T09:37:06.593Z DEBUG modem >> AT%XCBAND=?
2022-12-13T09:37:06.604Z DEBUG modem << %XCBAND: (1,2,3,4,5,8,12,13,18,19,20,25,26,28,66)
2022-12-13T09:37:06.608Z DEBUG modem << OK
2022-12-13T09:37:06.625Z DEBUG modem >> AT+CMEE?
2022-12-13T09:37:06.635Z DEBUG modem << +CMEE: 0
2022-12-13T09:37:06.637Z DEBUG modem << OK
2022-12-13T09:37:06.645Z DEBUG modem >> AT+CMEE=1
2022-12-13T09:37:06.651Z DEBUG modem << OK
2022-12-13T09:37:06.655Z DEBUG modem >> AT+CNEC?
2022-12-13T09:37:06.664Z DEBUG modem << +CNEC: 0
2022-12-13T09:37:06.666Z DEBUG modem << OK
2022-12-13T09:37:06.671Z DEBUG modem >> AT+CNEC=24
2022-12-13T09:37:06.678Z DEBUG modem << OK
2022-12-13T09:37:06.684Z DEBUG modem >> AT+CGEREP?
2022-12-13T09:37:06.693Z DEBUG modem << +CGEREP: 0,0
2022-12-13T09:37:06.695Z DEBUG modem << OK
2022-12-13T09:37:06.700Z DEBUG modem >> AT+CGDCONT?
2022-12-13T09:37:06.709Z DEBUG modem << OK
2022-12-13T09:37:06.714Z DEBUG modem >> AT+CGACT?
2022-12-13T09:37:06.720Z DEBUG modem << OK
2022-12-13T09:37:06.726Z DEBUG modem >> AT+CGEREP=1
2022-12-13T09:37:06.733Z DEBUG modem << OK
2022-12-13T09:37:06.738Z DEBUG modem >> AT+CIND=1,1,1
2022-12-13T09:37:06.745Z DEBUG modem << OK
2022-12-13T09:37:06.750Z DEBUG modem >> AT+CEREG=5
2022-12-13T09:37:06.760Z DEBUG modem << OK
2022-12-13T09:37:06.764Z DEBUG modem >> AT+CEREG?
2022-12-13T09:37:06.774Z DEBUG modem << +CEREG: 5,4
2022-12-13T09:37:06.778Z DEBUG modem << OK
2022-12-13T09:37:06.796Z DEBUG modem >> AT%CESQ=1
2022-12-13T09:37:06.804Z DEBUG modem << OK
2022-12-13T09:37:06.810Z DEBUG modem >> AT+CESQ
2022-12-13T09:37:06.820Z DEBUG modem << +CESQ: 99,99,255,255,255,255
2022-12-13T09:37:06.822Z DEBUG modem << OK
2022-12-13T09:37:06.834Z DEBUG modem >> AT%XSIM=1
2022-12-13T09:37:06.843Z DEBUG modem << OK
2022-12-13T09:37:06.849Z DEBUG modem >> AT%XSIM?
2022-12-13T09:37:06.860Z DEBUG modem << %XSIM: 1
2022-12-13T09:37:06.862Z DEBUG modem << OK
2022-12-13T09:37:06.872Z DEBUG modem >> AT+CPIN?
2022-12-13T09:37:06.882Z DEBUG modem << +CPIN: READY
2022-12-13T09:37:06.885Z DEBUG modem << OK
2022-12-13T09:37:06.898Z DEBUG modem >> AT+CPINR="SIM PIN"
2022-12-13T09:37:06.917Z DEBUG modem << +CPINR: "SIM PIN",3
2022-12-13T09:37:06.920Z DEBUG modem << OK
2022-12-13T09:37:06.934Z DEBUG modem >> AT+CIMI
2022-12-13T09:37:06.943Z DEBUG modem << 234500093370919
2022-12-13T09:37:06.946Z DEBUG modem << OK
2022-12-13T09:37:06.947Z INFO IMSIdentity: 234500093370919
2022-12-13T09:38:08.689Z DEBUG modem << +CEREG: 4
2022-12-13T09:40:25.786Z DEBUG modem >> AT+COPS=?
2022-12-13T09:40:26.795Z ERROR Error: 'AT+COPS=?
' timed out
2022-12-13T09:40:44.284Z DEBUG modem << +CEREG: 2
2022-12-13T09:41:17.932Z DEBUG modem << +CEREG: 4
2022-12-13T09:41:55.439Z DEBUG modem << +CEREG: 2
2022-12-13T09:43:04.800Z DEBUG modem << +CEREG: 4
2022-12-13T09:43:24.958Z DEBUG modem << +COPS:
2022-12-13T09:43:24.961Z DEBUG modem << OK
2022-12-13T09:46:27.658Z DEBUG modem >> AT+COPS=?
2022-12-13T09:46:59.168Z DEBUG modem << +CEREG: 2
2022-12-13T09:47:01.356Z DEBUG modem << +CEREG: 4
2022-12-13T09:47:44.749Z DEBUG modem << +CEREG: 2
2022-12-13T09:47:44.755Z DEBUG modem << +COPS:
2022-12-13T09:47:44.761Z DEBUG modem << OK
2022-12-13T09:47:44.771Z DEBUG modem >> AT+COPS?
2022-12-13T09:47:44.780Z DEBUG modem << +COPS: 1
2022-12-13T09:47:44.783Z DEBUG modem << OK
2022-12-13T09:48:18.300Z DEBUG modem << +CEREG: 4
2022-12-13T09:49:00.558Z DEBUG modem << +CEREG: 2
2022-12-13T09:50:10.201Z DEBUG modem << +CEREG: 4

[Didrik Rokhaug]

Hi, and sorry for the late reply.

Yes, that combination should let you take a modem trace.

lzpons said:

(trace collector produces a bin file so I have no means to check what it's doing..)

You should see the file size increasing, which is a pretty good indication that the trace is captured correctly. In this case, I would expect the trace to be at least 200-300 kB, but there is a good amount of guesswork in that number, so as long as the modem has found and tried to connect to the base station (I believe you should be able to see the "+CEREG: 2,"09CF","00021408",9" in the application log), we should be good.

You can also use the Trace Collector v2 preview, which will let you see the communication with the network live if you select the "live" option together with the "raw" option.

P.S. I have some days off after newyer as well, so I might not be able to reply until late next week.

[lzpons]

Hi Didrik Rokhaug it took us a while to be set with the testing but here we are. This is the output of Trace Collector running in Guernsey. Hope you can tell us what you find in the bin.

trace-2023-01-23T10-59-57.872Z.bin

[Didrik Rokhaug]

Thanks for the trace.

To me, it looks like the device finds some networks that it either cannot roam on, or are "normal" LTE cells that it cannot connect to.

I have asked our modem team to look at it as well, to confirm why it cannot connect.

[lzpons]

That question is the one to go deeper indeed.
On that test we have been using a worldwide Hologram SIM.

If this was to be helpful for you, we could also do the same test with a SIM purchased locally to one of the available carriers

[Didrik Rokhaug]

This is what the modem team replied:

The log shows that customer has done manual network selection to 208 20 (Bouygues Telecom) but the only networks found are 234 03 (Jersey Airtel Limited) and 208 10 (Société Française du Radiotéléphone). The latter one was found only once and signal was weak. Would either one of these be suitable for their subscription?

The search results were from NB-IoT and there were no results from CAT-M1. From which system they expect 208 20 to be found? Have they done restrictions to the scanned bands using AT%XBANDLOCK which could explain not finding the network? Of course, one possibility is that Bouygues Telecom just doesn't have coverage on the island.

Also, I looked at Hologram's coverage site, and in both France and the UK (they don't list Guernsey specifically), they only list LTE-M (CAT-M1) as supported.

[lzpons]

This is a weird answer,

Bouygues Telecom  and Société Française du Radiotéléphone are two french carriers. I have them at home (I'm in france) but my customer shouldn't have them in Guernsey and he took the trace with a NRF DK board in the island. The only way to explain those networks being found is that some signal from continental France, 50km, away is reaching the island ?  https://www.ariase.com/mobile/carte-antennes?iframe=1&partner=ariase&lat=49.43889157913611&lng=-2.2973269173533026&zoom=9.133815980236399&interactive=1

or that the device has some memory in the trace from when I had it home in france?

Maybe the root cause is related with this to explain what's going on there...

I do not thing user made an AT%XBANDLOCK because we used the original nordic app to run the tests

img_app_bl/debug/thingy91_asset_tracker_v2_debug_2022-12-08_188a1603.hex               =>  Asset tracker v2 firmware for nRF9160, modem debug enabled, NB-Iot and LTE-M network modes

Hologram covers Guernsey with Sure carrier (https://support.hologram.io/hc/en-us/articles/360035213914-What-countries-and-carriers-do-you-support-)

As I told you we can also use a SIM from Jersey Air limited. This network seems to have NB-IoT active. Using thingy91_asset_tracker we should see it and be able to connect with their own SIM right?

What kind of test would you suggest to do now?

[Didrik Rokhaug]

Hi, and sorry for the late reply.

What board are they using?

lzpons said:

he took the trace with a NRF DK board

lzpons said:

mg_app_bl/debug/thingy91_asset_tracker_v2_debug_2022-12-08_188a1603.hex

That file is for a Thingy:91, not a DK.

lzpons said:

Hologram covers Guernsey with Sure carrier

I am not able to see if this agreement supports LTE-M and/or NB-IoT or not. It might not be covered.

Getting a modem trace with the Jersey Air SIM would also be useful.

[lzpons]

 Didrik Rokhaug below are two tests traces run by the customer on Thingy91 board (no DK) using the thingy91_asset_tracker_v2_debug_2022-12-08_188a1603.hex app together with a locally purchased Jersey Airtel SIM.

- First test runs app in default mode

trace-2023-02-08T19-14-25.294Z_JerseyAirtel_SIM.bin

trace-2023-02-08T19-14-25.294Z_JerseyAirtel_SIM.bin

- Second test has been forced to nbiot

trace-2023-02-09T10-28-05.811Z_JerseyAirtel_SIM_NBIOT_forced.bin

AT%XSYSTEMMODE=0,1,0,0
AT+CGDCONT=0,"IPV4V6","cdp.iot.t-mobile.nl"
AT+COPS=1,2,"23403",9
AT+CFUN=1

trace-2023-02-09T10-28-05.811Z_JerseyAirtel_SIM_NBIOT_forced.bin

As a reminder (because there is already a long tread here) what we are seeking is to undersdand

- is there or not any LTE-M network available we can connect to?

- otherwise can we connect to nb-IoT as an alternative?

- If none are available what is the suspected reason?

Hope you can diagnose something.

[Didrik Rokhaug]

In the JerseyAritel_SIM trace, manual network selection requested to 208 20 (Bouygues Telecom) which is not found. Could you try to send AT+COPS=0 (set automatic network selection), then AT+CFUN=0 (store the settings to non-volatile memory), and then reset the device?

In the JerseyAirtel_SIM_NBIOT_forced trace, this was the teams analysis:

Not forced to use NBIOT (looking at the trace, it looks like you tried to set NB-IoT only mode  while the modem is running. This is not allowed. %XSYSTEMMODE must be used while the modem is offline), but forced (i.e. manual network selection) to 234 03 (Jersey Airtel). There is one tracking area available (in NBIoT), but network rejects Attach with cause #15 "No suitable cells in tracking area". This means that device is not allowed to operate in this tracking area with this SIM subscription. In the end of the log modem finds another tracking area and initiates Attach procedure. This time the Attach is not successful because signalling connection is lost before receiving Attach Accept. This is a bit unexpectable, because mapped RSRP was 47 at the time the cell was found. Although, there were some change in radio conditions because at first this cell was not found at all. Assuming the SIM subscription should work with Jersey Airtel, for some reason network releases the RRC connection in the middle of Attach procedure. We don't know the reason, but have seen similar now and then.

Looking at the traces, it also looks like you are trying to set the APN manually. Are you sure you are using the pre-compiled applications, and not a custom one?

It might also be that these settings has been stored in the modem previously. You can try to delete all saved data in the modem with the %XFACTORYRESET AT command. Resetting the user data should be enough. Note that this command also must be used while the modem is offline, so it can be a good idea to use AT+CFUN=4 first.

[Didrik Rokhaug]

As a way forward, the modem team suggest you ask Airtel if the device/SIM card is supposed to be able to connect at that location:

I can see from IMSI that the home network is 234 03 Jersey Airtel. From log we can see that tracking area 0A33 gives the Attach reject #15 "No suitable cells in tracking area". Customer could ask from the operator why their SIM subscription is not allowed to work in that tracking area. In another tracking area (09CF) network releases the RRC connection before Attach Accept is received, which seem not to be due to signal quality from modem point of view. This kind of unexpected RRC connection releases we have seen earlier but we have no workarounds for that and we don't know why this happens. But I think this is not network's way to reject the device, meaning that without this unexpected release the Attach might even get accepted.