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]

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 :)