nRF9151 Configuration and UDP Data Transmission over NTN Issue

[JonesGW]

Hi,

I have been facing issues with the configuration of the nRF9151 for sending and receiving UDP packets via the Skylo NTN network.

I am running firmware version:

> AT+CGMR

mfw_nrf9151-ntn_1.0.0-1.alpha

OK

and the module's hardware version is:

> AT%HWVERSION

%HWVERSION: nRF9151 LACA A1A

OK

I have been following the documentation in package 'ntn-alpha-documentation-package-v2.zip', particularly 'NTN operation AT examples v1.3.pdf'.

I am able to successfully attach to the Skylo network:

%MDMEV: SEARCH STATUS 1

+CEREG: 2,"0FB6","0021A176",14

%MDMEV: PRACH CE-LEVEL 0

+CSCON: 1,7,4

+CEREG: 5,"0FB6","0021A176",14,,,"11100000","00111000"

%MDMEV: SEARCH STATUS 2

I can successfully set up a socket:

> AT#XSOCKET=1,2,0

#XSOCKET: 0,2,17

OK

> AT#XSOCKET?

#XSOCKET: 0,1,0,2,0

OK

However when I try to execute AT#XCONNECT, following the syntax in the documentation i.e.:

; Syntax: #XCONNECT=<handle>,<url>,<port>

> AT#XCONNECT=0,"192.168.217.100",4781

ERROR

I have to omit the handle and the AT command works:

> AT#XCONNECT="192.168.217.100",4781

#XCONNECT: 1

OK

I then try to execute the AT#XSEND command, again following the syntax in the documentation, i.e.:

AT#XSEND=<handle>,<mode>,<flags>,<data> when ``<mode>`` is ``0`` or ``1``

the commands fail:

> AT#XSEND=0,0,0,"24022026_6"

ERROR
> AT#XSEND=0,0,8192,"24022026_6"

ERROR

However, if I execute the command without any parameters apart from <data> it succeeds and I can see the UDP packet in the UDP server logs:

> AT#XSEND="24022026_2"

#XSEND: 10

OK

%MDMEV: PRACH CE-LEVEL 0

+CSCON: 1,7,4

The UDP server is configured to send an 'ACK' back to the module and I have seen this working on other manufacturers modules, that support NB-IoT over NTN. However, no ACK is received at the nRF9151. I have attached both the Cellular Monitor .mtrace files and .pcapng, the latter I've examined using Wireshark. I can see the 'ACK' being sent from the server to the module, whose SIM has been allocated a static IP address, but this is followed by an ICMP message stating that the port is unreachable. As I mentioned previously, the 'ACK' is successfully received when this has been tested with other manufacturers' modules.

Could you please:

1) Try and explain this behaviour and explain what I'm doing wrong ?

2) Why there appears to be a discrepancy between the syntax in the AT commands specified in 'NTN operation AT examples v1.3.pdf', and indeed 'NTN operation AT examples v1.3.pdf', together with the AT commands syntax at https://docs.nordicsemi.com/bundle/addon-serial_modem-latest/page/app/at_socket.html and the AT commands that I see being executed on the module ?

Many thanks in advance.

trace-2026-02-24T11-36-24.144Z.mtracetrace-2026-02-24T11-07-27.140Z.mtracetrace-2026-02-24T10-40-18.522Z.mtrace

MO_Test_No_ACK_24022026_2.pcapngMO_Test_No_ACK_24022026_1.pcapng

[Achim Kraus]

> 1)

What I see in the modem trace is, that you use different UDP service ports:

6    18.973786    192.168.217.141    192.168.217.100    UDP    50    61987 → 4781 Len=10
18    28.905335    192.168.217.100    192.168.217.141    UDP    43    4782 → 61987 Len=3

I don't know, why you use "connect" for UDP, but that enables mainly a packet filter for the destination address.

So, I guess with the other modem you don't use connect?

Would it be possible to send the message to the same UDP port back?
If not, try to not use "connect". Beside AS-RAI I don't see, that this is required.

[JonesGW]

Hi Achim,

Thank you for your response.

I use 'AT#XCONNECT' because that's what the Nordic documentation 'NTN operation AT examples v1.3.pdf' states I should use, i.e.:

; Or alternatively UDP over the IPv4 type PDN Connection. At the
; same time set the destination IP address and the port number.
; Syntax: #XCONNECT=<handle>,<url>,<port>
AT#XCONNECT=0,"FQDN-or-IP-address-dotted-format-for-your-server",port-address-as-integer
AT#XSEND=0,0,0,"Your Hello World(tm) payload"

Other manufacturer modules have their own proprietary AT commands. I'm just following the manufacturers' instructions because that's what our customers will do.

If there's another set of commands that I should use to send UDP packets to a UDP server, and get an ACK back, then I would be happy to use those.

Thank you.

[Achim Kraus]

Maybe you try to send your ACK from the socket/port you received the message?

(I'm an other user, maybe Nordic can help you more.)

[JonesGW]

Thanks for the suggestion Achim, but I'm reluctant to change the behaviour of the UDP server as it's used for other things (and has worked for testing other manufacturers' modules).

I will wait for an official response from Nordic.

Thank you.

[Achim Kraus]

> (and has worked for testing other manufacturers' modules).

as long as you "connect" the UDP socket to port 4781, it will filter a message from 4782. But the modem in general received the message (see modem trace).

> reluctant to change the behaviour of the UDP server as it's used for other things (and has worked for testing other manufacturers' modules).

As I wrote, if that works, then not with "connect". With "connect" other modems will fail as well.

It's pretty simply: even if I don't prefer to use "connect" for UDP, it's pretty common practice.I guess, therefore Nordic uses it. And so your server fails with a common practice used by Nordic's setup. 

Anyway, your server, your clients, your experience.

[JonesGW]

Thank you for the clarification Achim.

I have tried again, not using AT#XCONNECT, but instead

> AT#XSENDTO=0,0,0,"192.168.217.100",4781,"26022026_6"

#XSENDTO: 0,0,10

OK

%MDMEV: PRACH CE-LEVEL 0

+CSCON: 1,7,4

#XAPOLL: 0,1
> AT#XRECV=0,0,0,10

#XRECV: 0,0,3
ACK
OK

So with the new serial modem application firmware I am able to send a UDP packet and get an ACK back with the original UDP server configuration, i.e. the 'ACK' comes back from port 4782.

Thank you for explaining what I was doing wrong. This is the first time I've tested a Nordic model in detail, so these sort of things aren't obvious to me, I'm afraid.

[Achim Kraus]

You're welcome.

(I was luckily able to test the nRF9151 NTN stuff since Sept. 2025 and in my experience it works pretty well.)