bug: lte_link_control: Cell-ID check leads to false UNKNOWN event (#5353)

[mrks115]

Hello

I found a possible bug in NCS 1.7.0 which was introduced in PR #5353.

1) False UNKNOWN event when disconnecting

The "invalid cell id" check leads to an false UNKNOWN event when you disconnect the modem.
The disconnect itself will emit a cell id update with an "invalid" (read: valid in the case of disconnection) cell id.
Since there is no further DISCONNECT event this leads the application to an error state instead of a graceful disconnect.

2) Modem Event Manipulation

Furthermore I didn't expect the library to actually change the registration status from the modem.
This is also what the library documentation says ("maps directly").

Kind regards,
Markus

[Charlie]

Hi Markus,

Sorry for the late reply, I have submitted an internal bug report to our R&D team, but the code owner is on vacation now, so there might be some delay.

You can also comment on the original pull request, so you can get feedback once there is some action to it.

Thanks for your feedback!

Best regards,

Charlie

[Charlie]

Hi Markus,

Please check if this fix addressed the issue you metioned. The commit moves the guard to only be called if the incoming registration status is either roaming or home.

https://github.com/simensrostad/fw-nrfconnect-nrf/commit/0ca961b1a0eddd9bba6da392e54f32416bdfda3f

Best regards,

Charlie

[Charlie]

Hi Markus,

Here are the comments from our expert:

AFAIK loosing the cell ID does not directly translate to being unregistered from the LTE network. However, from an application standpoint, attempting to send data while when the modem has returned an invalid cell ID does not work. Its possible that the modem still accepts data being sent to its internal TCP/IP buffers and that the data will be when sent when the modem obtains a valid cell, at a later point. This is not known. It will at least be strong indications that the UE is in quite poor network conditions.

To simplify, the link controller simply checks if the cell ID is invalid and propagates the UNKNOWN event upon such an occurrence, giving the application more concrete control over whether to send data or not.

This was reported to be an issue in several cases including https://devzone.nordicsemi.com/f/nordic-q-a/77155/asset-tracker-v2-failed_data-buffer-not-filling/323632#323632 and https://devzone.nordicsemi.com/f/nordic-q-a/63267/getting-cereg-5-fffe-ffffffff-while-disconnected-from-the-network

If the modem at a later point succeeds in obtaining the Cell ID it will notify the application with its current registration status.

mrks115 said:

So the modem is online and the application doesn't know that and (probably) will never request the modem to disconnect. Is this assumption right?

This is not entirely true. If the link controller has configured and inited the modem it should not be necessary to take explicit action in the case of a disconnect. This will happen automatically, the modem will simply notify the application when a valid cell ID / registration status has been obtained. Which in turn will be propagated via the corresponding event in the link controller callback handler.

Best regards,

Charlie

[mrks115]

Hello

Thanks for this update, I understood.

But, just to be sure, what exactly is the meaning of the event LTE_LC_NW_REG_UNKNOWN and when does this occur (except in case of an invalid cellid)?

Or in other words, how exactly do we need to react to an UNKNOWN event in the application (e.g. treat as error)?

Kind regards,
Markus

[mrks115]

Open question:

When is this fix planned to be released?

[Charlie]

mrks115 said:

But, just to be sure, what exactly is the meaning of the event LTE_LC_NW_REG_UNKNOWN and when does this occur (except in case of an invalid cellid)?

Or in other words, how exactly do we need to react to an UNKNOWN event in the application (e.g. treat as error)?

You can find its definition from comments and source codes logic.

The application side reaction could be varied depending on your needs, for example, our assert tracker v2 has a ring buffer, when one failure data transfer happens, it will buffer data with a timestamp and try to update on the next transfer window. When more serious issues happen, like the base station stopping work, there are limited reactions you can take on the device side.

mrks115 said:

When is this fix planned to be released?

We target to add this fix to release NCS 1.8.0, proximity end of November.

Best regards,

Charlie

[Charlie]

mrks115 said:

But, just to be sure, what exactly is the meaning of the event LTE_LC_NW_REG_UNKNOWN and when does this occur (except in case of an invalid cellid)?

Or in other words, how exactly do we need to react to an UNKNOWN event in the application (e.g. treat as error)?

You can find its definition from comments and source codes logic.

The application side reaction could be varied depending on your needs, for example, our assert tracker v2 has a ring buffer, when one failure data transfer happens, it will buffer data with a timestamp and try to update on the next transfer window. When more serious issues happen, like the base station stopping work, there are limited reactions you can take on the device side.

mrks115 said:

When is this fix planned to be released?

We target to add this fix to release NCS 1.8.0, proximity end of November.

Best regards,

Charlie

[mrks115]

Hey!

I'm aware of the definition in the source code. But since it originally comes from the modem I wanted to know if there is any (further) documentation about that?

The AT documentation only says:
"4 – Unknown (for example, out of E-UTRAN coverage)"

Unknown can mean literally anything to me, so I'm not sure if we have to treat this e.g. as an error and thus disconnect (application needs to save power) or e.g. this is an temporary error that can simply be ignored.

Kind regard,
Markus

[Charlie]

Hi Markus,

The reason for defining the "Unknow" state is that they are unpredictable or hard to find reasons just from the device side and also if they happen, there might be no reaction you can take to solve the issue on application firmware directly. Please refer to assert tracker v2 for application-level solutions to different kinds of lte connection conditions.

Best regards,

Charlie

[mrks115]

Ok, thank you for your help :)