I am experiencing an issue where our RUTX50 (equipped with the Quectel RG501Q modem) is completely unable to attach or register onto our Private 5G Standalone (SA) network. The router remains indefinitely stuck in a searching state (+C5GREG: 0,2).
On the exact same Private 5G gNodeB and Nokia Core infrastructure, our Cisco IR1101 and Nokia 5G industrial routers connect instantly and operate without issue.
Our Nokia Core team has confirmed that the network is running 3GPP Release 15 and above deployment.
Troubleshooting Already Attempted on RUTX50:
Configured the WebUI Mobile Interface to match the exact custom APN (), IPv4 PDP type, and CHAP credentials.
Set the Network Type to “5G SA Only” in the WebUI.
Issued CLI AT commands to disable all LTE and 5G NSA bands (AT+QNWPREFCFG="lte_band",0 and "nsa_nr5g_band",0) to avoid scanning loops.
Attempted to hard-lock the modem directly to the broadcast channel via AT+QNWLOCK="mod/nr5g",1,658944,51.
Attempted to force the private PLMN via AT+COPS=1,2,"999040".
Despite these changes and cellular stack reboots (AT+CFUN=1,1), AT+C5GREG? continues to return 0,2. The modem appears completely blind to the gNodeB RF layer, suggesting a potential issue with how the RG501Q handles Private 5G synchronization signals, subcarrier spacing (SCS), or Release 15 tracking areas compared to enterprise Cisco/Nokia hardware.
Device Information:
Product Code: RUTX50
Serial: 6003645259 Batch no:029
Firmware Version: RUTX_R_00.07.23.7
Internal Modem Firmware: RG501QEUAAR12A10M4G
Could you please review this behaviour and advise if there is a specific modem firmware update, an updated configuration path to sort out this issue?
Thank you for the detailed information and for providing the troubleshooting steps already performed.
We have reviewed the reported behaviour. The RUTX50 supports 5G SA on Band n77, so the reported band itself is supported by the device.
Regarding the reported +C5GREG: 0,2 status: this indicates that the modem is currently searching for a 5G network, but this value alone does not show at which stage the registration process is failing. Therefore, before determining whether the issue is related to RF synchronization, cell selection, or 5G registration, we would like to collect additional information directly from the modem.
Please connect to the RUTX50 CLI and provide the output of the following commands while the router is attempting to connect:
gsmctl -A 'AT+CPIN?'
gsmctl -A 'AT+CFUN?'
gsmctl -A 'AT+COPS?'
gsmctl -A 'AT+CEREG?'
gsmctl -A 'AT+C5GREG?'
gsmctl -A 'AT+QNWINFO'
gsmctl -A 'AT+QCSQ'
gsmctl -A 'AT+QENG="servingcell"'
Also: gsmctl -y - This will show us the exact modem firmware installed on the router
gsmctl -A is supported method for sending AT commands to the modem.
In particular, the AT+QENG="servingcell" result will help us determine whether the modem is detecting a serving cell or remaining in the search state.
We would also recommend reverting the modem from the manually applied band and cell locks after collecting the requested information, so that the next test is performed using the standard network selection procedure. This will help exclude the possibility that the manual restrictions are affecting the test.
Once we have the above outputs, we can determine the next troubleshooting step based on the actual registration and cell-selection state.