search

u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
287 stars 82 forks source link

Reject Cause Information #188

Closed eeFLis closed 5 months ago

eeFLis commented 5 months ago

Hi

Is there a way to read the reject cause if the network registration is not successful? The only option I've seen is to read the information from the URC +CREG, but ubxlib seems to skip this information.

RobMeades commented 5 months ago

Hi @eeFLis; not at the moment but you're right that there should be, I'll look into it.

RobMeades commented 5 months ago

Had a quick look and the reason why the reject cause is not passed back is because we set the +CEREG type to be 4; the reject cause is only returned if the +CEREG type is 3 or 5. We need at least 4, since 3 doesn't return the power-saving parameters, but the problem with 5 (which would return everything) is that we then can't tell the difference between a +CEREG URC and a +CEREG response (see summary and detailed information for why) since 5 represents a "registered" state (registered, roaming).

At the moment I can't see a way around this but I will continue thinking...

EDIT: it looks like the bit you read in the comment, and the skipping of the two parameters, is a bug, which I will fix.

eeFLis commented 5 months ago

I see. Without taking a deeper look, can't a distinction be made based on the number of parameters returned?

RobMeades commented 5 months ago

That might be a possibility, let me see if there's a way to do it. Will require quite a log of re-jiggering/re-testing, so might be a while.

RobMeades commented 5 months ago

I've had a look at the logic to make a retrieval of the EMM reject cause work within all of the other dodges and workarounds we have to do for the way registration commands work across all supported module types and I can't make a solution fit into my head.

However, this is for SARA-R5 only and so find here:

https://github.com/u-blox/ubxlib/tree/preview_cell_reject_cause_rmea

...an alternative solution: in uCellNetGetLastEmmRejectCause() we temporarily switch to AT+CEREG=5, ignoring URCs while we do so, read the registration status and then switch back to AT+CEREG=4 and re-read the registration status in the normal way in case it changed while we were "away".

This seems to work, in that it doesn't break anything, however in my testing I have not been able to make SARA-R5 actually return an EMM reject cause.

Do you have a scenario in which there is an EMM reject cause which you could try this code out on?

eeFLis commented 5 months ago

Thank you I will try to force an reject cause.

eeFLis commented 5 months ago

It was also not possible for me to create a reject cause. What's a bit strange is that with mode 4 the module returns +CEREG: 4,3 which means "registration denied". when the reject cause is read and the module switches to mode 5 +CEREG: 5,0 is returned.

RobMeades commented 5 months ago

Hmph. Let me find out how this is meant to work...

RobMeades commented 5 months ago

OK, turns out that the reject cause isn't captured when in +CEREG mode 4, which is why we don't see it. However, there is an AT command that I hadn't come across, AT+CEER, which allows network cause values to be read. I have updated the branch:

https://github.com/u-blox/ubxlib/tree/preview_cell_reject_cause_rmea

...to use this and have confirmed that it does return an error value when an incorrect APN is used, resulting in the network denying service; it is not a very specific error code in this case (19, "ESM failure") but it is, at least, an error code.

Could you give this a try, see if it works for you?

eeFLis commented 5 months ago

hmm. in our test case it doesn't seem to work. We get:

AT+CREG?

+CREG: 2,3

OK
-1: Deny
AT+CGREG?

+CGREG: 2,4

OK
-1: OoC
AT+CEREG?

+CEREG: 4,3

OK
-1: Deny

AT+CEER

+CEER: "EMM cause",0,"No cause information available"

we expect an error " PLMN not allowed".

But with your test case "incorrect APN" we also get the error code (19, "ESM failure").

RobMeades commented 5 months ago

I wonder if this is something to do with it being a circuit-switched (AT+CREG) reject? Let me go ask...

eeFLis commented 5 months ago

Sorry I have cut off too much of the debug output. I have edited the message.

RobMeades commented 5 months ago

Thanks: can you indicate which network this is on, in case it is relevant?

RobMeades commented 5 months ago

IIRC "PLMN not allowed" is not a "final" error message, in that, assuming you are running in automatic selection mode (AT+COPS=0) [please confirm], the module should put the PLMN in the forbidden list and continue looking for other PLMNs it can roam onto. But I might be wrong about this, so I will check.

EDIT: in case this turns out to be a bug in SARA-R5, can you indicate the current FW version you are using (the response to ATI9 near boot)?

eeFLis commented 5 months ago

In our test case we use manual registration mode on network 22802 to force the error AT+COPS=1,2,"22802" Since we use the manual registration mode I think that the forbidden PLMN list should not play a role. But since you mention this I have another question: is there a way to delete the forbidden PLMN list in the ubxlib?

we use the following firmware version: 03.30,A00.01

RobMeades commented 5 months ago

Since we use the manual registration mode I think that the forbidden PLMN list should not play a role.

Ah, understood, yes, you're correct.

is there a way to delete the forbidden PLMN list in the ubxlib?

No, we haven't added any SIM functionality at all so far, not something anyone had asked for. Are there other SIM-related things you might need, or just that? We could certainly start with that.

eeFLis commented 5 months ago

A way to delete the forbidden PLMN list would be very useful for us.

RobMeades commented 5 months ago

A way to delete the forbidden PLMN list would be very useful for us.

OK, will add that.

eeFLis commented 5 months ago

after further testing, i realized that we used an wrong mnc "22812" instead of "22802". So we tried to register on the wrong network. This was not noticed because the +CME ERROR returned by the module seems to be ignored in registerNetwork(). The deviceErrorDetected is set to true but the "Wait for registration" loop is still called and only returned after the timeout.

Shouldn't the process be aborted immediately after the ERROR?

RobMeades commented 5 months ago

Interesting: from the comments in the code (this was written a long time ago), my intention was that the registration outcome should be driven by the URCs, so the bit where the manual registration is carried out, if it returned an error, would result in a URC that echoes that error and hence the "wait for registration" loop below that would exit pretty much immediately, when it saw that error.

Can you paste in here a bit more of the AT sequence so that I can see the pattern?

eeFLis commented 5 months ago

Here is the AT sequence starting with manual registration:

AT+CGDCONT=1,"IP","shared.m2m.ch"

OK
AT+UAUTHREQ=1,0,"",""

OK
AT+CFUN=1

OK
U_CELL_NET: registering on 22812...
AT+COPS=1,2,"22812"

+CME ERROR: not found

+CREG: 3

+CEREG: 3
AT

OK
AT+CREG?

+CREG: 2,3

OK
-1: Deny
AT+CGREG?

+CGREG: 2,4

OK
-1: OoC
AT+CEREG?

+CEREG: 4,3

OK
-1: Deny
AT+CREG?

+CREG: 2,3

OK
-1: Deny
AT+CGREG?

and after the timeout:

AT+CEREG?

+CEREG: 4,3

OK
-1: Deny
AT+CREG?

+CREG: 2,3

OK
-1: Deny
AT+CGREG?

+CGREG: 2,4

OK
-1: OoC
U_CELL_NET: unable to register with the network, is APN "shared.m2m.ch" correct and is an antenna connected?
AT+CEER

+CEER: "No report available",0,"No cause information available"

OK
AT+CFUN=4

OK

+CREG: 0

+CEREG: 0

+CGREG: 0
U_CELL_NET: connection attempt stopped after 240 second(s).
RobMeades commented 5 months ago

Hmm, OK, we have to be quite careful with this particular bit of code.

I recall that when I originally wrote it I had the "wait for registration" loop exit if a "deny" came back, since that seemed pretty final, but there were situations, possibly only with automatic network selection, where "deny" would be a transient state and giving up registration at that point would be the wrong thing to do.

EDIT: or possibly one could receive "deny" from CREG but not from CGREG/CEREG, depending how the network is wired.

So we could exit the "wait for registration" loop if "deny" came back and we were in manual selection, but that is a more complicated solution than simply, as you say, setting errorCode to, say, U_ERROR_COMMON_NOT_FOUND if deviceErrorDetected is true.

For the purposes of this experiment, would you be able to try hacking:

https://github.com/u-blox/ubxlib/blob/cd03192c93ea7fa4edd50168965d24160040f71f/cell/src/u_cell_net.c#L1129

...to be:

            deviceErrorDetected = (deviceError.type != U_AT_CLIENT_DEVICE_ERROR_TYPE_NO_ERROR);
            if (deviceErrorDetected) {
                errorCode = (int32_t) U_ERROR_COMMON_NOT_FOUND;
            }
            uAtClientClearError(atHandle);

...and see if that (a) causes an exit if the wrong wrong manual network is applied and (b) gets us the desired AT+CEER if the correct wrong manual network is applied?

eeFLis commented 5 months ago

with the modification

a) causes an exit if the wrong wrong manual network is applied. (manual selection mode) b) causes an exit and return "EMM cause",15,"No suitable cells in tracking area" if the correct wrong manual network is applied (manual selection mode) c) do not cause an exit and return "EMM cause",19,"ESM failure" if an incorrect APN is used. (automatic selection mode)

RobMeades commented 5 months ago

That's good, I think, except that the "correct wrong manual network" (which I guess is MCC/MNC 22802?) is returning "EMM cause",15,"No suitable cells in tracking area" whereas you were expecting it to return "PLMN not allowed" (11)? How sure are you of that EMM cause? If memory serves, "no suitable cells in tracking area" is the "softer" reject cause which is used specifically to stop networks ending up in an FPLMN list that no user knows how to delete.

eeFLis commented 5 months ago

Yes "correct wrong manual network" is 22802. The EMM cause "PLMN not allowed" was only an assumption. For me it's fine like this.

Thank you for your great support

RobMeades commented 5 months ago

Phew, that's good. The changes discussed here have now passed internal testing, need to get them reviewed and they should land here soonish, will update this issue when done.

RobMeades commented 5 months ago

Hokay, various commits to master, I hope, fix the issues raised here:

I will close this issue now and will delete the preview_cell_reject_cause_rmea branch sometime next week; please feel free to re-open this issue, or open another, should there be a problem

eeFLis commented 5 months ago

@RobMeades I don't understand the commit https://github.com/u-blox/ubxlib/commit/2018c62239763bafae0e7c35f44be729fabf8550 This has the opposite effect: Active time and periodic TAU were reported correctly before and no longer after the change.

eeFLis commented 5 months ago

reject type and cause seems to be present but empty +CEREG: 1,"025e","01083403",7,,,"00001000","00111111"

RobMeades commented 5 months ago

Gah, you're right, I'd misread the AT manual, where it says:

image

...I'd read it as the reject type and cause not being present for +CEREG type 4, but of course the two commas are present. Silly me, will revert.

RobMeades commented 5 months ago

Commit 2018c62 now reverted by commit https://github.com/u-blox/ubxlib/commit/140134b52047bd8d50d63e615cc1a1c13a8390fa.

eeFLis commented 5 months ago

Thanks. Another question about uCellSimFplmnListDelete(). Sometimes reading the length of the FPLMN field on the SIM fails with the CME ERROR: SIM not inserted. (Don't know why, as the writing afterwards is successful) No error is returned either, as it appears that no distinction is made between the various CME ERRORs and U_CELL_CSIM_FPLMN_SIZE_BYTES_2G is returned in all cases.

AT+CRSM=176,28539,0,0,20

+CME ERROR: SIM not inserted
AT+CRSM=214,28539,0,0,12,"FFFFFFFFFFFFFFFFFFFFFFFF"

+CRSM: 144,0
RobMeades commented 5 months ago

Sometimes reading the length of the FPLMN field on the SIM fails with CME ERROR: SIM not inserted.

Oh! That's a bit unexpected. The reason I had to assume the 2G length when there is an error is because one of our module types (LENA-R8) sends back a CME ERROR if you try to read something that is longer than what it has (i.e. if you try to read the 3G length).

Let me see if I can think of a different dodge for the LENA-R8 case...

eeFLis commented 5 months ago

ok. any idea why we get a CME ERROR: SIM not inserted ?

RobMeades commented 5 months ago

ok. any idea why we get a CME ERROR: SIM not inserted ?

No, it is quite baffling: could you maybe post a slightly longer AT sequence here, including the bit where AT+CIMI and registration succeeds, then I can point it at someone who knows the insides of SARA-R5?

eeFLis commented 5 months ago

I have moved the deletion of the fplmn lists to a different position in the registration sequence. So far, the error no longer occur. I will post the AT output here as soon as the error reappears.