Using https with NB-IoT, instead of COAP,DTLS

[lseg]

Hi,

I am a bit confused, I understand from some technical discussions that we should use COAP/UDP (with DTLS) instead of HTTP/TCP (with TLS) when using NB-IoT.

For LTE-M  HTTP/TCP should work properly. 

I am mainly concerned about FOTA where we download files up to 2Mb. I see that even with LTE-M the connection is sometimes lost and it reconnects without any issue.

Now what is my confusion: we actually never used COAP before and we have devices which are perfectly doing a FOTA over NB-IoT using HTTPS. So what exactly is the reason to use COAP instead of HTTPS. In which cases will the HTTPS download over NB-IoT fail? And in which cases is COAP really needed?

We only have very few devices connected over NB-IoT, so if I want to do this effort I want to know first if it is really needed. And on the other hand if I send devices to countries with only NB-IoT (e.g. Greece): will it give issues if I use HTTPS for FOTA download.

Kind regards,

Luc Segers

[Achim Kraus]

NB-IoT is not NB-IoT.

Used with normal radio conditions, the RTT (Round Trip Time) of NB-IoT is larger than for LTE-M, but not too much.

Once you use it in a "deep building base" (pretty low signals), the things are changing, and the RTT gets much larger.

The question you will be faced therefore is, if you operate your device in regions/locations, where TCP over NB-IoT works, or if regions/locations are relevant, where it doesn't work. In the past I put a Thingy:91 in a steel cooking pot and close the lid to demonstrate that. Not too easy, in some pots nothing works, in some pot both works, but there are pots, where only UDP works.

[Didrik Rokhaug]

Hi,

As Achim said, in most cases, HTTP and TCP works fine over NB-IoT.

However, depending on the network, signal conditions and server, the latency might become too big in some cases.

As UDP is more flexible when it comes to handling latency (the latency and acknowledgements are handled at the application level rather than the transportation level), it can be better suited in situations with high latency.

If the device is moving, and can be expected to move out of bad coverage situations, and/or you can do tests before deploying to new networks and locations, you will probably be fine with just TCP.

If not, you might want to consider having some back-up options.

Though if the device is mobile and battery driven, I would also consider just postponing the FOTA upgrade, as sending and receiving data with bad coverage consumes more power than in good coverage.

Best regards,

Didrik

[lseg]

Thank you for your answer we will have a look in our kitchen and see which pots are working best/worst...
I noticed you are somewhat active in the Coap community. Could you give some advice on what the easiest way would be to setup a COAP server to download/upload from/to a S3 bucket. 
I have been looking around (Eclipse Californium, Apache Camel) but they both feel complicated (could be me, it is not really my cup of tea). And are lacking some examples in my opinion.

[Achim Kraus]

lseg said:

I noticed you are somewhat active in the Coap community.

I'm the project lead of Eclipse/Californium and co-author of RFC 9146 .

I'm currently working on a CoAP-S3-Proxy, see Californium (Cf) S3-proxy-server .

The point with the complexity is caused a lot by the past. Californium was developed quite a long time mainly as library for some server application. With different interests and use-cases in mind. And with not too many people, resulting to be (too) short on documentation.

Two years ago I decided to have a demo-cloud-server "out-of-the-box". Unfortunately, I also had to convert my engagement into a "free time" one. So for now I mainly consider that S3-proxy to be very useful for first field-tests. In combination with my Zephyr coaps-client for nRF9160 the initial time to invest is reduced a lot (hope to 2 afternoons ;-) ). You get a setup to collect field-data from battery for a couple of months with a couple of devices (I guess usually about 50-100).

For "productive use" it will still take a while...