Additional to the information on page 39 of that paper, DTLS:
It’s quite common, that some network components will timeout their IP-routes, if no messages are exchanged for some time. That even happens on earth, e.g. if the device exchanges data only every hour. But since 2022, the IETF has specified an extension for DTLS, RFC9146 - Connection Identifier for DTLS 1.2 that overcomes that.
My experience (*1) is based on the CoAP/DTLS 1.2 CID stack.
September 2025 I patched NCS 3.1.0 to support the new NTN at-parameters (not that much work) and adapted my nRF91 client to the timing useful for NTN. That uses Eclipse/Californium - Cloud CoAP-S3-Proxy Server. Now, with the NTN support in NCS 3.2.4, it’s even easier to build clients for NTN.
What will be recommended, non-IP, VPN, or DTLS 1.2 CID depends on my view on a couple of aspects. Not everyone is happy and successful with that CoAP/DTLS 1.2 CID/UDP stack, especially if other implementations are used.
Using VPN helps to get better security with less overhead and complexity (in my opinion, it’s not the same security level as DTLS, but much better than plain communication.) It enables also to use eDRX (*2) to push data downstream (to the device). The downside my be the setup-costs and sometimes also a small usage based fee (compared with the current NTN subscription costs, both is not too relevant).
non-IP seems to be very popular in the US, but in some cases that may create a “lock-in”.
Therefore some seems to start for the first few device even with unencrypted protocols, just to get common with NTN. And only if the application has enough overall business value, they may switch then either to DTLS 1.2 CID, VPN, or, non-IP.
I didn’t test TCP over NTN, but from others I know, that it works better than expected, but much too bad to be really used. It will get surprisingly expensive (if you need to pay the control message but only a few application messages makes it to the other side). And it’s not supported by the providers to do so.
For now, I would consider the pricing of NTN (about 70-80 cent per KB) as the most challenging point, the gather enough overall business value. The power consumption will be only a secondary challenge, I guess the financial one will anyway throttle the number and size of messages, so that the energy will become less important. I run the nRF9151 feather from a 4000 mAh battery, exchanging 300 +100 bytes data every 9h, now for a couple of months and there is still 50% energy left.
(*1) OK, no wonder, I’m one of the co-authors of RFC 9146, project lead of Eclipse/Californium - Java/CoAP/DTLS, and committer of Eclipse/tinydtls - C, DTLS, DTLS 1.2 CID (feature branch/client only)
(*2) I didn’t use a VPN for my NTN tests, therefore I have no experience with eDRX. On earth the feature is in some case differently implemented. Sometimes the data reaches the device, sometimes it only the “RRC active” signal without data.
