NTN Support and Application Feasibility on nRF9151

[Priyesh Shahi]

Inquiry: NTN Support and Application Feasibility on nRF9151

I would like to seek clarification regarding Non-Terrestrial Network (NTN) support on the nRF9151.

There have been discussions and references suggesting NTN capability on the nRF9151, and I would like to better understand the current level of support and practical limitations.

Specifically, I am interested in the following:

1. Resource Availability

• Which nRF Connect SDK versions include sample applications or support for NTN on nRF9151?

• Are there example projects, reference code, or documentation demonstrating NTN connectivity in practice?

• If official samples are not yet available, is there a roadmap or expected timeline for when they might be provided?

• What type of antenna is required or recommended for NTN operation on the nRF9151?

2. Application Feasibility

We are currently using the nRF9151 with a Hologram eSIM in India, and our solution is working reliably:

• connectivity

• Cellular IoT stack

• Data transmission to a CoAP server

Given this setup:

• Is a similar application architecture feasible over NTN?

• Can CoAP-based data transmission be supported over NTN in a comparable manner?

3. SDK Support and Examples

• I could not find any nRF Connect SDK samples, documentation, or application notes specifically related to NTN on nRF9151

• Are there any example applications, experimental features, or recommended references available?

• If not, could you please advise on the current status and roadmap for NTN support on nRF9151?

Any guidance, documentation links, or clarification would be greatly appreciated.

Thank you for your support.

[Achim Kraus]

Though I'm an other user, that's just my experience:

AFAIK, there is still no NCS support, but to add that (extend some link control function with new values), was on my side a work of two afternoons. The new AT-cmds and/or parameter and/or  parameter-values are documented.

You will need a SIM card, that supports some NTN provider, and considering that, you may also check and consider the (much) higher costs.

I use CoAP/DTLS 1.2 CID over NTN (own device DTLS stack (Eclipse/tinydtls) to relax the timing (timeout to 30s), Eclipse/Californium (also with relaxed timing). Depending on antenna, boards and what ever, it works, but sometimes the modem requires a couple of retransmissions (not sure, if the messages are lost before they billed or after ;-) ). The overhead of IP/UDP/DTLS 1.2 CID/CoAP is about 100 extra bytes. If you want to use an ACK or CoAP response, you will need a second 100 bytes for that message. Using tinydtls allows you also to offload the dtls session from the socket, so that works pretty well to have an "handshake on TN" and the switch to "NTN". If that's a good idea depends on your usage. Statically located without TN requires to do some handshakes over NTN, with DTLS 1.2 CID, they are rare.

I run that now since September. with an send interval of 9h.

Alternatively you may use a VPN from your provider to your server or maybe OSCORE, if you have a implementation for that.

Hope that gives you a first impression.