How big is the DTLS 1.2 CID message header for CoAP messages?

I'm using the Cloud Multi-Service app on nRF9160 to test the CoAP DTLS 1.2 CID support while connected to nRF Cloud to evaluate, and want to check the data size for messages sent to help estimate total data use over time. In coap_client.c I can see the size of the CoAP message layer sent and received, but I need to know how big the underlying DTLS overheads are.

1) In DTLS 1.2. CID - How big is the CID used by the nRF SDK 2.6.1 + Modem v1.3.6?


2) Using AT%XCONNSTAT to help check the message overheads for a CoAP POST (after DTLS has already connected)

Using AT%XCONNSTAT? to check the modem states (with AT%XCONNSTAT=1 just before temperature data sent) returns:

%XCONNSTAT: 0,0,0,0,139,97 - where: max_packet = 139, min_packet = 97

Where the coap POST (confirmable) len = 51 (for header_len=12(token=8), options len=11, data len=28).

Does this mean the total data pkt overhead = 139 - 51 = 88 bytes for this POST? And 97 bytes is the size for the Coap Ack (including overheads) ?

3) After a Google search on DTLS overheads - I had expected total data overheads for DTLS 1.2 CID + UDP/IP to be approx = ~57 bytes if CID length is say 16 bytes long.

Assuming IP(20) + UDP(8) + DTLS(13) + CID (16) = 57.  So I'm not sure if the results from XCONNSTAT implies a much bigger CID length is being used?

In conclusion - Can you please confirm the actual data overheads for DTLS 1.2 CID with nRF SDK. This will be very helpful for estimating data use over time

  • > The total DTLS 1.2 CID overheads are bigger than I expected, but they're not a deal breaker.

    For DTLS 1.2 it's pretty much the same as TLS 1.2. The bytes saved in the TLS header are then spend more in the TCP header.

    The overall saving comes from the reduced number of handshakes. How much that is depends then more from the communication pattern. If you send something every 5 minutes, you may not need it. But to save energy I guess sending every 60 min (and on events) will be the better approach. If sending every 24h (and on events) does match the requirements depends mainly in the required "fail safe". Frequent messages also indicate the system health, and missing ones may start the "fail safe procedure"., what ever that is. 

    Beside of the data volume savings, in my experience CoAP/DTLS 1.2 CID is more reliable than TCP based stuff. Even if Nordic still sometimes write, that TCP will be slightly better, that's not my experience and I'm still open for an competition to see, what the "wild" will really show.

    As an example from an Thingy:91

    179-22:26:04 [d-hh:mm:ss], Thingy:91 v0.9.0+0, 0*4499, 1*48, 2*0, 3*0, failures 4
    !3873 mV 63% (358 days left) battery
    !CE: down: 8, up: 1, RSRP: -95 dBm, CINR: 12 dB, SNR: 13 dB

    180 days, about 4500 messages, some retransmissions, 1%% failures.

    github.com/.../zephyr-coaps-client

  • If %XCONNSTAT reports different numbers for UDP or TCP then I guess someone from Nordic will know the reason and may answer this.

    Thanks for the active helping in Devzone. I can confirm %XCONNSTAT statics cover all data running through IP protocol, which is also the data usage count by the network operators.

  • Thank you Charlie - that's good to know that it covers all IP data sent and received (for UDP and TCP).
    I must have mis-calculated the message lengths with my previous MQTT testing.

    Regards, Rory

Related