Example project with Connection ID or TLS_SESSION_CACHE_ENABLED for nrf9151

[Akuz]

I am currently experimenting with the nrf9151DK and was hoping to mimic a LTE-M sensor that would wake up once an hour, send a message over CoAP with DTLS, then go back to PSM. (I need to have as little power consumption as possible) On DevAcademy Cellular fundamentals Lesson 5 in exercise 2, it says that the NAT session timeout will close the connection in as little as 12 seconds which would be a problem, and one of the solutions to this is to use TLS_SESSION_CACHE_ENABLED. Doing some further research I found out that there is also a Connection ID (CID) that might be better for reestablishing this connection. However, I am struggling to find ways to implement either of these things into my code and I was wondering if there are any examples of how they work. For now, I am connecting to the "californium.eclipseprojects.io" server and posting my message to the echo resource. I am very much a beginner with cellular and firmware development (not sure if my approach is even correct) so any help will be greatly appreciated.

[Akuz]

Some further explanation and some follow up questions: The sensor is supposed to take some measurements and send a message over, but does not receive any messages. Do I need to worry about the NAT timer if I don't use DTLS? Am I using the correct method for the lowest power consumption possible? This is a bit far fetched and I know I might not get a straight answer here, but does AWS support session cache or CID with their CoAP servers? Thanks in advance!

[Achim Kraus]

Does AWS support coap at all?

DTLS CID is enabled using setsockopt:

int cid = NRF_SO_SEC_DTLS_CID_SUPPORTED;
err = setsockopt(sock, SOL_TLS, TLS_DTLS_CID, &cid, sizeof(cid));

> The sensor is supposed to take some measurements and send a message over, but does not receive any messages. 

While that may be the case from the view of the application (only transfer in one direction will be required, at least to begin with), from a technical perspective that will come with some common UDP downsides, you will find the using a web search or AI.

From the power consumption perspective, on large part of that energy is used to switch to RRC active. A so called one-way message will then save some energy, but that will be far away from something as 50% (you will need to measure it on your own for your case, but 20% may be more realistic).

I run my device with CoAP/DTLS 1.2 CID (see my zephyr-coaps-client and Californium (Cf) - Cloud CoAP-S3-Proxy Server ) and in the very very most cases with CON request and responses. That comes not only with the reliability, it also provides a "downlink channel" for config changes and/or FOTA.

[Akuz]

Thanks! I'll look into it