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

[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