Skylo NTN: Signal Quality Check feature

[JordanYates]

The NTN AT command guide documents a "Signal quality check" option for performing a pre-check before attempting to re-attach to the Skylo network:

https://docs.nordicsemi.com/r/bundle/ref_at_commands_nrf91x1_ntn/page/ref/at_commands/ntn/skylo_set.html

I can't find any information on how this feature works elsewhere in the docs:

• When the check runs
• Whether it can be manually triggered by the application (without the attach step if it passes)
• How the application is notified on failure or success

Being able to manually trigger the check and receive a result in the application (ideally with signal strength information) would be extremely advantageous for quickly evaluating connection strength without having the send dozens of packets to calculate success rates. In a production environment, getting a notification on failure is important for handling pending data.

Alternatively, does `AT%XMONITOR` serve the purpose of application-level signal strength evalulation for NTN?

[Syed Maysum Abbas Zaidi]

Hi,

Thanks a lot for waiting. After consulting with the modem team, here is our response to your questions:

The signal quality check is an automated modem process specified by 3GPP. If a lower layer failure occurs (example an RRC connection release, radio link failure, or random access channel timeout before receiving a network response), the modem detects this and performs operations such as incrementing failure counters, backing off, or entering a limited service state, depending on the EMM cause code. If lower layer failures have occurred, before retrying a connection (such as an Attach Request, Tracking Area Update (TAU), or Service Request), the modem evaluates the signal conditions; if they have not improved, no new connection attempt is made.

This blocking (back-off) is visible in the +CGEV notification and the requested procedure is restricted:

+CGEV: RESTR <cause>,<validity>

<cause>
4 – Signal quality check fails at connection establishment. See %FEACONF <feature_id> value 7.

<validity>
1 – Permanent restriction. Clearing requires a power-off, UICC change, or a configuration change.
2 – Temporary restriction. Clearing requires, for example, back-off timer expiry.

However It is not possible to manually trigger this evaluation. One option to evaluate signal and cell availability without enabling the power-hungry TX is to use RX-only mode, so you can activate LTE in RX-only mode (cell selection with no network signaling; only search, SI reception, and NW evaluation are performed):

1. Case where cell is available:
   

   => AT+CFUN=2
   <= +CEREG: 51,"0001","01A2D101",14,,,"11100000","11100000"

   
   After CEREG: 51, it is possible to evaluate the RX signal quality
   

   => AT%XMONITOR
   <= %XMONITOR: 1,"","","90198","3A9B",14,255,"0004CE7B",3,228821,20,27,"","00001000","00111000","11100000",20,3,8,4

2. Case where no suitable cell is available:
   Activate LTE in RX-only mode and observe the search status:
   

   => AT+CFUN=2
   <= %MDMEV: SEARCH STATUS 1 (light search complete)
   <= %MDMEV: SEARCH STATUS 2 (full search complete)

   
   Receiving search-status events without a +CEREG: 51 indicates that no suitable PLMN was found.

I hope it helps.

[JordanYates]

Hi Syed,

Thanks for the response. The described method roughly matches what we have already been performing to evaluate signals. Can you confirm how frequently the RX signal quality values are updated? My colleague had to cycle airplane mode each time we wanted a new reading.

In the final application, we will want to send a location every few hours from a mobile asset that could be indoors. One approach we were hoping to utilize was to check the NTN signal quality (from the PSM idle state), and skip the expensive GNSS fix if the signal has been lost, since we can't send the location anyway. But based on your description, it sounds like this can't be done without trying to send a packet to trigger the evaluation?