Testing both NB-IoT and LTE-M

[Vincent44]

Hello,

I am trying to evaluate differences between NB-IoT and LTE-M in real world (power consumption, coverage, etc) using a nRF9160DK.

I started a simple project with the included iBasis SIM : works great on LTE-M in France, but NB-IoT is not supported.

I ordered a SIM supposed to be handling both NB-IoT and LTE-M, but I am running in some trouble.

This SIM card connects to NB-IoT, but does not connect using LTE-M ... eventhough it reaches some antennas. No matter if I set the NB-IoT or LTE-M as preferred network.

Here is what I get from my custom firmware.

Button 2 pressed - Waking up !

Reading probe (blocking) ...

> Temperature: 22.44

> RHumidity: 23.26

Resetting modem done

Setup cellular modem : Done

> Check events for connection status

[LTE LC event] Network registration - Searching

[LTE LC event] Cell Update - id:13827****, tac:3****

[LTE LC event] Modem mode has changed to LTE-M

[LTE LC event] RRC Connected

[LTE LC event] RCC Idle

[LTE LC event] Cell Update - id:13828****, tac:3****

[LTE LC event] RRC Connected

[LTE LC event] RCC Idle

[LTE LC event] RRC Connected

[LTE LC event] RCC Idle

[LTE LC event] RRC Connected

[LTE LC event] RCC Idle

[LTE LC event] RRC Connected

[LTE LC event] RCC Idle

[LTE LC event] Cell Update - id:1428****, tac:1****

[LTE LC event] RRC Connected

[LTE LC event] RCC Idle

[LTE LC event] Cell Update - id:15787****, tac:4****

[LTE LC event] RRC Connected

[LTE LC event] RCC Idle

[LTE LC event] Cell Update - id:-1, tac:-1

[LTE LC event] Modem mode has changed to none/off

[LTE LC event] Cell Update - id:13827****, tac:2****

[LTE LC event] Modem mode has changed to NB-IoT

[LTE LC event] RRC Connected

[LTE LC event] Network registration - Connected, Home network

[LTE LC event] PSM Update - TAU: 3960, Active time: 60

SIM ICCID : 89332011************

Modem info :

> MMC + MNC (3+2 digits): 20820

> APN: ido.net

> LAC: 0x5*** = 2****

> Cell ID: 0x083D**** = 13827****

* * * Server resolve skipped for debug * * *

* * * Send data to server skipped for debug * * *

Current PSM timings (TAU=3960 - AT=60) don't match desired values (TAU=900 - AT=16)

Requesting PSM timing.

> Request TAU: 900 sec (Rounded to: 900)

> Request AT: 16 sec (Rounded to: 16)

[LTE LC event] PSM Update - TAU: 2520, Active time: 32

Depending on the SIM card I use, with the same firmware, my DK can connect to either NB-IoT or LTE-M, which makes me believe that:

- There is no hardware problem.

- There is no configuration problem in the firmware.

- Both LTE-M and NB-IoT are covered in my area.

The service provider is telling me that the SIM card should be working with both network, and suggests an issue with my hardware/firmware.

Is there a sample project that I can test, implementing switching between NB-IoT and LTE-M ?

Is there something else I need to check and/or add to my project ?

Thanks.

[Didrik Rokhaug]

Hi,

Could you take a modem trace?

That will let us see what communication happens between the device and the network, which should give us an idea of why it cannot connect.

Also, what SIM card/operator are you using?

Best regards,

Didrik

[Vincent44]

Attached the trace. I hope I made this properly. Is trace supposed to be readable by non-Nordic people ?

Operator is Bouygues Telecom (France), which provided me some test M2M SIM card.

Thanks.

trace-2023-03-29T06-47-23.613Z.bin

[Didrik Rokhaug]

Vincent44 said:

Is trace supposed to be readable by non-Nordic people ?

If you use the Trace Collector v2, you can convert the trace to a Wireshark .pcap. This will let you see the communication between the device and the network and server. It can even do this live, so you can see the communication happening in real-time.

However, there is more information that what Wireshark will show in the .bin files. That information is not readable for non-Nordic people though.

Vincent44 said:

I hope I made this properly

The trace seems a bit short, and I couldn't see any connection attempts from the modem. However, I do see some communication with a network, so there seems to be some information missing.

However, I can confirm that it did find a cell from Bouygues Telecom.

Could you try to take a new trace?

If you are using a DK, you can use this .hex file, which I have configured correctly: 72343.merged.hex

It is the at_client, so you will have to send the AT commands manually.

If you do use it, I am particularly interested in the output from these commands (they enable notifications from the modem, and will not give information directly):

AT+CEREG=5
AT%MDMEV=1
AT+CMEE=1
AT+CNEC=24
AT%CESQ=1

It would be nice if you could run those commands before you start the modem with AT+CFUN=1

[Vincent44]

Thanks Didrik.

Attached the test requested.

I also re-run a trace on my custom app, it might give some addition info ?

trace - AT Commands.bin

Fullscreen AT-log.txt Download

2023-03-31T08:55:09.597Z DEBUG Application data folder: C:\Users\axelc\AppData\Roaming\nrfconnect\pc-nrfconnect-linkmonitor
2023-03-31T08:55:09.819Z DEBUG App pc-nrfconnect-linkmonitor v2.0.3 local
2023-03-31T08:55:09.820Z DEBUG App path: C:\Users\axelc\.nrfconnect-apps\node_modules\pc-nrfconnect-linkmonitor
2023-03-31T08:55:09.820Z DEBUG nRFConnect 4.0.1, required by the app is (>=4.0.0)
2023-03-31T08:55:09.820Z DEBUG nRFConnect path: C:\Users\axelc\AppData\Local\Programs\nrfconnect\resources\app.asar
2023-03-31T08:55:09.821Z DEBUG HomeDir: C:\Users\axelc
2023-03-31T08:55:09.824Z DEBUG TmpDir: C:\Users\axelc\AppData\Local\Temp
2023-03-31T08:55:11.180Z INFO Installed JLink version does not match the provided version (V7.80c)
2023-03-31T08:55:11.324Z INFO Using nrf-device-lib-js version: 0.6.5
2023-03-31T08:55:11.324Z INFO Using nrf-device-lib version: 0.14.7
2023-03-31T08:55:11.325Z INFO Using nrfjprog DLL version: 10.19.1
2023-03-31T08:55:11.325Z INFO Using JLink version: JLink_V7.82 
2023-03-31T08:55:20.301Z INFO Modem port is opened
2023-03-31T08:55:20.316Z DEBUG modem >> AT+CFUN?
2023-03-31T08:55:20.347Z DEBUG modem << +CFUN: 0
2023-03-31T08:55:20.356Z DEBUG modem << OK
2023-03-31T08:55:27.232Z DEBUG modem >> AT+CEREG=5
2023-03-31T08:55:27.247Z DEBUG modem << OK
2023-03-31T08:55:34.832Z DEBUG modem >> AT%MDMEV=1
2023-03-31T08:55:34.847Z DEBUG modem << OK
2023-03-31T08:55:41.429Z DEBUG modem >> AT+CMEE=1
2023-03-31T08:55:41.446Z DEBUG modem << OK
2023-03-31T08:55:49.080Z DEBUG modem >> AT+CNEC=24
2023-03-31T08:55:49.094Z DEBUG modem << OK
2023-03-31T08:55:54.592Z DEBUG modem >> AT%CESQ=1
2023-03-31T08:55:54.608Z DEBUG modem << OK
2023-03-31T08:56:05.128Z DEBUG modem >> AT+CFUN=1
2023-03-31T08:56:05.170Z DEBUG modem << OK
2023-03-31T08:56:07.566Z DEBUG modem << %CESQ: 35,1,14,2
2023-03-31T08:56:07.603Z DEBUG modem << +CEREG: 2,"7F46","083DEC07",7
2023-03-31T08:56:08.203Z DEBUG modem << %CESQ: 40,2,16,2
2023-03-31T08:56:21.628Z DEBUG modem << +CEREG: 2,"7F46","083E0306",7
2023-03-31T08:56:24.115Z DEBUG modem << %CESQ: 35,1,15,2
2023-03-31T08:56:30.514Z DEBUG modem << %CESQ: 35,1,10,1
2023-03-31T08:56:31.784Z DEBUG modem << %CESQ: 40,2,13,1
2023-03-31T08:56:34.354Z DEBUG modem << %CESQ: 36,1,18,2
2023-03-31T08:56:43.729Z DEBUG modem << %CESQ: 41,2,16,2
2023-03-31T08:56:45.875Z DEBUG modem << %CESQ: 36,1,16,2
2023-03-31T08:56:55.607Z DEBUG modem << %CESQ: 41,2,16,2
2023-03-31T08:56:56.610Z DEBUG modem << %MDMEV: SEARCH STATUS 1
2023-03-31T08:56:57.394Z DEBUG modem << %CESQ: 34,1,11,1
2023-03-31T08:57:01.235Z DEBUG modem << %CESQ: 35,1,16,2
2023-03-31T08:57:24.720Z DEBUG modem << %CESQ: 255,0,255,0
2023-03-31T08:57:25.000Z DEBUG modem << %CESQ: 43,2,12,1
2023-03-31T08:57:25.039Z DEBUG modem << +CEREG: 2,"C111","09690608",7
2023-03-31T08:57:25.446Z DEBUG modem << +CNEC_ESM: 111,0
2023-03-31T08:57:25.461Z DEBUG modem << +CNEC_EMM: 11
2023-03-31T08:57:25.472Z DEBUG modem << +CEREG: 2,"C111","09690608",7,0,11
2023-03-31T08:57:26.735Z DEBUG modem << %CESQ: 255,0,255,0
2023-03-31T08:57:28.210Z DEBUG modem << %CESQ: 38,1,14,2
2023-03-31T08:57:28.252Z DEBUG modem << +CEREG: 2,"3621","00D9E805",7
2023-03-31T08:57:28.543Z DEBUG modem << %CESQ: 31,1,14,2
2023-03-31T08:57:28.658Z DEBUG modem << +CNEC_EMM: 14
2023-03-31T08:57:28.694Z DEBUG modem << +CEREG: 2,"3621","00D9E805",7,0,14
2023-03-31T08:57:30.004Z DEBUG modem << %CESQ: 255,0,255,0
2023-03-31T08:57:30.020Z DEBUG modem << +CEREG: 2
2023-03-31T08:57:59.414Z DEBUG modem << %CESQ: 52,2,24,3
2023-03-31T08:57:59.439Z DEBUG modem << +CEREG: 2,"5836","083DEC22",9
2023-03-31T08:58:03.209Z DEBUG modem << %MDMEV: SEARCH STATUS 2
2023-03-31T08:58:03.214Z DEBUG modem << +CEREG: 1,"5836","083DEC22",9,,,"11100000","11100000"
2023-03-31T08:58:03.247Z DEBUG modem >> AT+COPS=3,2
2023-03-31T08:58:03.272Z DEBUG modem << OK
2023-03-31T08:58:03.279Z DEBUG modem >> AT+COPS?
2023-03-31T08:58:03.299Z DEBUG modem << +COPS: 0,2,"20820",9
2023-03-31T08:58:03.305Z DEBUG modem << OK
2023-03-31T08:58:03.336Z DEBUG modem >> AT%XCBAND
2023-03-31T08:58:03.360Z DEBUG modem << %XCBAND: 20
2023-03-31T08:58:03.366Z DEBUG modem << OK
2023-03-31T08:58:03.392Z DEBUG modem >> AT+CGDCONT?
2023-03-31T08:58:03.411Z DEBUG modem << +CGDCONT: 0,"IPV4V6","ido.net","10.98.75.104 0000:0000:0000:0000:0000:004D:238A:0C01",0,0
2023-03-31T08:58:03.417Z DEBUG modem << OK
2023-03-31T08:58:03.429Z DEBUG modem >> AT+CGACT?
2023-03-31T08:58:03.448Z DEBUG modem << +CGACT: 0,1
2023-03-31T08:58:03.454Z DEBUG modem << OK
2023-03-31T08:58:04.450Z DEBUG modem << %CESQ: 49,2,19,2
2023-03-31T08:58:08.531Z DEBUG modem << %CESQ: 47,2,25,3
2023-03-31T08:58:14.683Z DEBUG modem << %CESQ: 48,2,19,2
2023-03-31T08:58:16.721Z DEBUG modem << %CESQ: 49,2,24,3
2023-03-31T08:58:24.940Z DEBUG modem << %CESQ: 50,2,19,2
2023-03-31T08:58:29.010Z DEBUG modem << %CESQ: 50,2,25,3

trace - My App.bin

[Didrik Rokhaug]

Does your application use UART1 (or SPI1 or TWI/I2C1)?

The trace from the at_client is fine, but the trace from your application seems to be missing parts, similar to your first trace.

You didn't set the system mode in the at_client trace (though that might have been bad instructions from me), but it starts by trying to connect to some LTE-M networks, before ending up connecting to an NB-IoT network in the end.

The first connection attempt (LTE-M) is to Bouygues Telecom. The connection attempt goes as expected until the network asks for the devices capabilities. After the device responds, the network stops communicating (it closes the RRC connection). However, it does not give a reject cause.

The device then tries to connect again a few times, both to the same cell, and to a different one (still Bouygues Telecom), but the same thing happens.

After a total of 6 connection attempts, it gives up, and tries to search for other networks. In the end, it tries to connect to Altice, but is rejected with "PLMN not allowed".

Next, it tries Orange, but is rejected with "EPS services not allowed in this PLMN".

Both of these rejects can probably be explained by missing roaming agreements between the operators.

It then switches over to NB-IoT, where it finds a cell from Bouygues Telecom, and this time it is able to connect.

I will have to ask the modem team why the network releases the device after it sends its capability information. However, due to Easter, it might take longer than normal to get a response.

In case you are interested, here is the communication between the device and the different networks: trace - AT Commands.pcapng

[Didrik Rokhaug]

Hello again, and sorry for this taking a while, but Easter came in the way.

Do you know what Bouygues' M1 (LTE-M) subscription assumes (or could you ask them)? For example, what FGI bits must be set (in the UECapabilityInformation)? Do they expect the UE has IMS capability?

Best regards,

Didrik

[Didrik Rokhaug]

Hello,

Did you manage to solve your problems?

Did you ask Bouygues what they require of LTE-M devices?

Best regards,

Didrik

[Vincent44]

Hello,

I asked but did not get any response. It seems that the issue is due to the bad coverage in my area. At least, that's what has been suggested by Bouygues.

I have to say that I don't fully understand, since the iBasis SIM works perfectly fine in LTE-M. But it might be due to some agreements between service providers.
Anyway, I don't have much time to spend on this particular issue right now, so I will close this ticket. Thanks.