What could cause CREG status: "Registration denied"?


We are having a issue with modems (WS6318) going from roaming status (5) to registration denied (3) (verified using AT+CREG? command). It seems like the modem stops searching for new operators whenever this happens causing a stop in communications, but it seems to be fixed by a normal modem reset.

What could be the cause for a modem to be denied registration by the operator?




There are alot of things that can happen especially when roaming that can cause the unit to be rejected from the network.

The process that occurs when attaching whilst roaming is as follows (in simplistic terms).

  1. Unit searches for a network as per the constraints it has i.e. preferred roaming list, last used network, etc.
  2. When it find the network it wants attach to it sends an attach request out as it would do on any network (home or roaming).
  3. On reception of the request to attach the network will see the Mobile Network/Country Code (MNC/MCC) and request authentication from the SIM’s home network HLR (Home Location Reigster), this link is setup when networks create roaming agreements between each other and is a permanent link which should be continuously monitored.
  4. All being well the SIM has roaming rights and the authentication procedure will be completed successfully.

If the above procedure fails at any point the unit will be unable to register, the critical link being the one mentioned in 3. In addition to this if the link in 3 fails at any point while the unit is attached to the roaming network it could be kicked off with the registration denied cause, this is because the roaming network is unable to verify any transactions you are carrying out or link back to the APN (for PS traffic) that you might want to use. How fast the unit gets kicked off depends how fast the network notices the link is down, if it is a quick temporary outage then the unit might not lose the network and it will be none the wiser.

Re the network reselection, the ‘Registration denied’ is a bit of a catch all for a number of different specific reject values sent to the unit, each of the values cause different behaviour as per the specs but without getting into too much detail if you get rejected the unit will just fall back to its normal search routine which is not constant to save power and the longer it is unable to find a network the less frequently it tries to search.

As you have stated a reset resolves everything because the history of the session the unit has been in is erased and starts from scratch i.e. all of the timers that it has to adhere to between retries, searches, etc are reset and it tries everything again immediately i.e. the link outage could have been resolved at this point.

Hopefully that answers the question.



Would AT+COPS=0 also fix it :question:

See: https://forum.sierrawireless.com/t/undocumented-side-effect-of-at-cops-0/4871/1


It might fix it but as mentiond in the apps note it can have side effects which make everything a bit more unpredictable. Probably the best way to handle it is to

  1. Perform a manual network search (seting at+cmee=1 before hand).
  2. If it sees the network you want manually select it (using at+cops=1,2,"xxx"then set it back to automatic mode (at+cops=0).
  3. if it does not see the network you want (or any networks) reset the unit to be sure.

Alternatively you could just go for the big red button straight away. Obviously you need to build some timers into the above to avoid performing continual resets.

I have attached an algorithm that I developed with another customer to ensure the timely recovery of a unit in exceptional circumstances i.e. to take into account, no network coverage, module problem, network problem, avoid resetting the unit too often to allow it to do its job, network timers, unit timers, etc. Note this was specific to them i.e. it had to also include provision for 32KHz mode, but could be implemented generically.


Network recovery algorithm.docx (53.8 KB)

I guess the problem then becomes how to define what network(s) you “want”… :question:

Hi Matt,

I’m having troubles with Network (Roaming) Registration abroad. In my country my embedded WS6318 application works very well. It only has to send an SMS with some status in the message body. But it is attached to a bird thus flying over many countries.
After initialization of the WS6318 (automatic Registration) I go into a loop sending +CREG and parsing it’s answere. 1(home) or 5(roaming) are allowed. On 0 or 4 I remain in the loop until a overall timeout (60-90 seconds) stops the whole circuit.
Access denied (3) does also stop this sending session.

And that is exactly what happens until now. I only get access denied.

My questions are:

  • if, in automatic register mode, +CREG? returns 3 has the WS6318 then checked all available PLMN’s for registration? Or is it just the result of one single entry in the list?
  • If not when or how do I know it has done all available ? My application has very limited energy resource so if I can’t register at all the module needs to be powered down.
  • Why does the +COPS? command take 40 seconds to answer? I don’t see any transceiver activity (by scoping line TX_CTRL)
  • Would my application prefere (=less time to send an SMS) by clearing one or all of the PLMN list (if possible because I can’t find how)

I’m quite shocked by the time in your network recovery algorithm minutes, 5 minutes up to an hour? :open_mouth:

Any help very appreciated


I would primarily rely ion the unsolicited events coming out of the unit with at+creg=1, this will allow the application to reduce traffic on the serial port for other things and also be notified immediately when there is a status change.

Re the CREG : 3, this will be returned when the unit has performed a scan and tried to attach to each of the networks in turn and been rejected by all of them. Assuming the unit works like some of the others the maximum time between radio power scans (i.e. just looking on each of the GSM radio channels for power and not decoding the information) will be 2 minutes when it is not attached to a network.

Since it is on a bird the cellular environment is very dynamic so its difficult for me to say why you are taking 5 minutes to an hour to get an attach back. However, since you are power limited (as I gues its not an albatross you are strapping this to) with a small battery and dependent on your application requirements, if you get a CREG : 3 I would suggest powering down for an hour, that way the environment will have changed and also alot of the parameters will have timed out on the unit and the network allowing for a clean attach.

Why COPS? is taking 40 seconds to return, no idea, that requires a detailed log file.



Hi Matt,

Thanx for you swift answer.
In the mean while, we did get some results. I think it has to do with signal quality. Our antenna on the device is far from perfect. Any whips sticking out will be ripped of by the bird. :cry:

Could it be possible that an accessible roaming PLMN gets on the forbidden list during registration because some data gets garbled or not received on which the PLMN returns “acces denied” ?

Imagine this is the only possible roaming PLMN. The this work against us. So I really would like to be able to clear this forbidden list. No idea how…

What do you think?



The forbidden list (generally) can only easily be managed by the unit, there might be a series of AT commands using CSIM and CRSIM which can clear it but I am not sure of them right now. The FPLMN elementary file is defined as having 3 fields and is FIFO based i.e. one gets written to the top of the file the one at the bottom drops out.

Re the signalling and writing erroneous networks to it, the unit will only write to the field if it receives a specific rejection cause from the network, if the attach attempt is incomplete due to interruption’s, BER, etc this would not result in a rejection with a specific cause but be written off as failed hence the field will not be written to.