Quectel RM520N-GL Wont Connect to NSA Network

Just like what title says, my x62 module cant connect to NSA network and its a growing problem with my other known RM520 users. LTE and SA modes works just fine. I also tried with different network providers, resetting it, upgrading its firmware version, all of the possible debugging steps, locking commands, and even transferring it to another board but still no avail. There was no special configuration and can confirm that I have a working 5G cell signal on my area since my other RM520 devices works with no problem with average -65 RSRP on NSA band. Any ideas on how to fix? Its becoming an alarming case here in PH.

Might help:

Checking if the module can scan the available NSA bands (it returns none):
image

Dear @misuzuu
Please check the combinations of NSA on your region.
Then I will check if they are supported or not.

LTE B1 + B3 + N41, sometimes it can support B1 + B41 + N41. Also this is not a country compatibility issue since my other RM520N-GL devices works fine. Its just these other RM520N-GL losing the capability to connect to NSA starting from last last week. Again, I did tests with my working RM520N-GL in the same location with the same configuration and still the bad ones doesn’t work. Cant pinpoint the actual cause of this.

Any updates on this problem?

Have you tried issuing this command:
AT+QNWPREFCFG= “mode_pref”,LTE:NR5G

And perhaps this too:
AT+QNWPREFCFG=“rat_acq_order”,NR5G:LTE

I already tried the preferred network info command but the second one, not yet. Will try this and give an update asap.

Also it is worth noting that few weeks ago I had a similar issue where 5G could not be activated on my RM502Q-AE with whatever I did. What worked was powering off my router, taking the sim card out and put it inside a mobile phone that supports 5G. After that I put the sim card back in my 5G module and NSA 5G worked right away!

Hi, @silvia

Module: RM520N-GL
Firmware: RM520NGLAAR03A03M4G

We are trying to establish a 5G NSA connection using the RM520N-GL — which is the primary reason we chose this module. We’re
using an IoT SIM roaming on a European operator (MCC/MNC 247/05). The module finds the LTE anchor cell with good signal but
EPS Attach is consistently rejected, making 5G NSA impossible.

Confirmed by AT commands:

The LTE cell is visible and campable — signal is not the issue:

  AT+QENG="servingcell"
  +QENG: "servingcell","LIMSRV","LTE","FDD",247,05,9ED517,487,1800,3,5,5,CF,-78,-12,-45,15,15,-30,-

EPS Attach fails:

  AT+CEREG?
  +CEREG: 0,2    ← no EPS registration despite LTE cell available

  AT+CEER
  +CEER: EMM attach failed

Module is configured for LTE+5G only:

 AT+QNWPREFCFG="mode_pref"
  +QNWPREFCFG: "mode_pref",LTE:NR5G

  AT+QNWPREFCFG="nr5g_disable_mode"
  +QNWPREFCFG: "nr5g_disable_mode",0

When we insert the same SIM into an iPhone, it connects to 5G NSA on the same operator and same cell immediately with no issues. This
strongly suggests the network is discriminating based on UE capabilities advertised during Attach.

Two questions:

  1. Is there a known issue or fix for LTE Attach failures with this firmware on European operators?
  2. Is there a newer firmware that improves compatibility with European networks?

Thanks.

 ATI                                                                                                                         
  Quectel
  RM520N-GL
  Revision: RM520NGLAAR03A03M4G
  OK

  # 5G is enabled, mode restricted to LTE+NR5G only (no WCDMA fallback)
  AT+QNWPREFCFG="nr5g_disable_mode"
  +QNWPREFCFG: "nr5g_disable_mode",0
  OK

  AT+QNWPREFCFG="mode_pref"
  +QNWPREFCFG: "mode_pref",LTE:NR5G
  OK

  AT+QNWPREFCFG="rat_acq_order"
  +QNWPREFCFG: "rat_acq_order",NR5G:LTE
  OK

  # LTE cell found, signal is good (-78 dBm RSRP), but Attach is rejected
  AT+QENG="servingcell"
  +QENG: "servingcell","LIMSRV","LTE","FDD",247,05,9ED517,487,1800,3,5,5,CF,-78,-12,-45,15,15,-30,-
  OK

  # No EPS registration
  AT+CEREG?
  +CEREG: 0,2
  OK

  # Error confirmation
  AT+CEER
  +CEER: EMM attach failed
  OK

  # Manual registration attempt also fails
  AT+COPS=1,2,"24705",7
  +CME ERROR: 30

Hi, following up on my previous post.

After moving to a different location (different tracking area, TAC 204), we got a more explicit reject cause:

AT+CEER
+CEER: Requested service option not subscribed

This is 3GPP EMM Cause #33 — “EPS service option not subscribed”, meaning the network is explicitly telling the modem that
LTE/EPS data service is not available for this SIM — not a temporary congestion or coverage issue.

What makes this puzzling: we tested the same SIM in an iPhone at the exact same location, and it connected to 5G NSA on the
** same cell** (PCI 351, Band 28, RSRP −111 dBm — physically identical conditions). The modem received Cause #33 on that same
cell at the same signal level.

This suggests the network is making the LTE Attach decision based on how the device identifies itself, not the SIM
or signal quality.

What UE capabilities or device identity parameters does the RM520N-GL signal to the network during LTE Attach that
could differ from a smartphone?

Specifically:

  • Is the IMEI TAC range of these modules known to trigger stricter roaming policies on some networks?
  • Is there a way to modify the UE capability profile or device class advertised during Attach (e.g., to signal VoLTE support
    or a different UE category)?
  • Or it’s just a wrong model (Global) for our location (Latvia)?

Thanks.

[SOLVED]
The root cause turned out to be the MBN profile. The modem was configured with ROW_Commercial (AutoSel=1), which caused the UE capabilities signalled during Attach to be rejected by the visited network’s MME with EMM Cause #33.

Switching to ROW_Generic_3GPP_PTCRB_GCF resolved it immediately:

  AT+QMBNCFG="AutoSel",0
  AT+QMBNCFG="select","ROW_Generic_3GPP_PTCRB_GCF"
  AT+CFUN=1,1

After reboot — AT+CEREG? returned +CEREG: 0,5 (registered, roaming) and 5G NSA was confirmed active during data transfer:

+QENG: "NR5G-NSA",247,05,351,-101,21,-10,640320,78,7,1

Note: IMS state (AT+QCFG="ims") had no effect on the outcome — tested with both 0 and 1.

If you’re seeing ( AT+CEER) EMM Cause #33 in roaming with ROW_Commercial, try ROW_Generic_3GPP_PTCRB_GCF first.