+CEREG signals denied before being registered

[Sven Schwermer]

Hi Aleksander,

On 10/20/22 10:51, Aleksander Morgado wrote:
> Hey,
> 
>> I have another question about the Fibocom MA510-GL: When +COPS=0 is
>> issued, often the modem emits the following sequence of URC which makes
>> ModemManager abort the simple connect flow:
>>
>> +CEREG: 0 (idle)
>> +CEREG: 2 (searching)
>> +CEREG: 3 (denied)
>> +CEREG: 5,... (registered, roaming)
>>
>> I guess this might not be in accordance with the specs, but I'm not
>> sure. It also doesn't always do that but when it does it jumps from
>> denied to registered within seconds. What would be an acceptable way to
>> handle this?
>>
> 
> That's a good question, I'm not sure what to reply here. The COPS=0
> request comes from a "Register automatically" user request, or as part
> of Simple.Connect(). The outcome of that operation is one single
> result, we don't report back "several results". In this case, the
> first "final" result we get from the modem is +CEREG: 3, so "denied",
> and from my point of view, that is the result that we should probably
> return, as we don't know what else will come afterwards.
> 
> If a new "Register automatically" happens after that sequence, what
> does the modem do? i.e. if you run COPS=0 and we get the CEREG
> idle+searching+denied+registered sequence and just after that you run
> again COPS=0, does it go over all those 4 states again, or does it
> return +CEREG: 5 right away?
> 

This is the issue. After the failed automatic registration (denied), 
another +COPS=0 is issued which may again lead to the denied state. 
Eventually, the denied state is skipped and the simple connect state 
machine can move on to actually connecting. Obviously, this is 
non-optimal because we do many registration attempts and the network 
will not like this and the overall connection duration is long.

There is probably no generic way to resolve this because the current 
implementation seems correct. But do you have guidance how to fix this 
with - perhaps with a non-upstreamed patch? Perhaps, we could start a 
timer when getting the denied status update and wait some time for the 
registered state update before returning with a failed state?

Best regards,
Sven