nRF9151: Cellular forcibly traffic blocked for ~12 second interval after setting RAI_NO_DATA, continuous-mode GNSS (no fix yet)

[ddustin]

Setup

• Board: nRF9151 DK (nrf9151dk/nrf9151/ns)
• Software: NCS v3.4.1, Zephyr v4.4.2, modem firmware mfw_nrf9151-ntn_1.0.1
• Network: LTE-M, PLMN 310410 (AT&T, US). PSM requested off; the network reports active time −1. No eDRX.
• GNSS: continuous navigation (nrf_modem_gnss_fix_interval_set(1)), A-GNSS injected from nRF Cloud. Indoors, so no fix: it’s searching the whole time.
• Priority mode: nrf_modem_gnss_prio_mode_enable() is not called in this mode, and our log confirms it.

What the application does (a low-latency control loop):

1. Every 5 s it sends a small UDP packet on a connected socket and gets a reply from our server.
2. It listens 2.5 s for packets the server pushes unprompted.
3. It sets SO_RAI = RAI_NO_DATA on the socket so the network can release the connection, which gives GNSS radio time.
4. The next packet goes out at the 5 s mark.

The network releases the connection ~2.1 s after RAI_NO_DATA, every time.

What we see. After the release (+CSCON: 0), the modem doesn’t start random access (%MDMEV: PRACH) for a packet we’ve already sent until ~12.16 s after it went idle, however long it had been idle when the packet was sent. Pushes from the server don’t reach the device during this time either: they arrive together with the reply once the connection comes up. Once random access starts, everything is fast: connected in ~0.1 s, reply in ~0.4 s.

Uptime from our log, in seconds:

+CSCON: 0	packet sent	%MDMEV: PRACH	idle → PRACH
59.873	64.709 (4.8 s into idle)	72.035	12.162
79.395	79.711	91.555	12.160
96.663	97.089	108.836	12.173
114.103	114.542	126.276	12.173
137.865	138.128	150.037	12.172

Log excerpt from one cycle:

[109.539] (set SO_RAI = RAI_NO_DATA)
[114.103] +CSCON: 0
[114.542] UDP packet sent
[126.276] %MDMEV: PRACH CE-LEVEL 0
[126.400] +CSCON: 1
[126.539] (server push, sent by the server at ~123.0, received)
[126.947] (reply to the packet sent at 114.542 received)

During these windows the GNSS PVT frames show no DEADLINE_MISSED. They show several NOT_ENOUGH_WINDOW_TIME flags per window, and GNSS gets no fix (indoors).

Tests

1. GNSS stopped, everything else the same: the window is gone. PRACH starts within ~60 ms of each packet, and pushes reach the device while it’s idle (paging works).
2. GNSS running, with nrf_modem_gnss_prio_mode_disable() called after every nrf_modem_gnss_start() and before every RAI_NO_DATA (each returned 0): no change. Still 12.155–12.173 s.
3. The first idle period after nrf_modem_gnss_start() isn’t affected: a packet sent 5.4 s into that idle period started PRACH at once. From the second idle period on, the ~12.16 s window appears every time.

Questions

1. Is this expected? Does continuous-mode GNSS, while searching without a fix, get an uninterrupted window of ~12 s after an RRC release, during which application uplink doesn’t trigger random access and paging isn’t answered? The documentation suggests LTE has priority over GNSS.
2. Is there a setting that shortens or prevents this window, while keeping GNSS useful between transmissions? For example, the GNSS use case, power mode, periodic instead of continuous navigation, fix retry, or something on the LTE side.
3. If we call nrf_modem_gnss_stop() when a packet is due during such a window, does LTE get the radio at once? And does stopping and restarting GNSS lose search progress, beyond the stored ephemerides and almanac?
4. What’s the recommended configuration for an application that needs both a 5 s uplink/downlink cycle with latency of a second or two, and GNSS fixes when it can get them?

Thanks!