LTE Link Controller: RAI_UPDATE behaviour

[JordanYates]

I have a nRF9151 based device, modem firmware version v2.0.3, with `CONFIG_LTE_LC_RAI_MODULE=y`, registered on LTE-M.

Using `NRF_RAI_LAST` is working, but I am seeing odd behaviour of the `LTE_LC_EVT_RAI_UPDATE` event.
Each time the modem comes out of PSM, I receive an event reporting that neither AS-RAI nor CP-RAI are supported, followed a few milliseconds later by a second report saying AS-RAI is supported. For example, the following logs:

[00:01:00.044,281] <dbg> modem_monitor: lte_reg_handler: MODEM_SLEEP_EXIT
[00:01:00.044,281] <dbg> modem_monitor: lte_reg_handler:     Type: 1
[00:01:00.103,240] <dbg> modem_monitor: lte_reg_handler: MODEM_EVENT
[00:01:00.103,240] <dbg> modem_monitor: lte_reg_handler:    Event: 1
[00:01:00.512,634] <dbg> modem_monitor: lte_reg_handler: MODEM_EVENT
[00:01:00.512,634] <dbg> modem_monitor: lte_reg_handler:    Event: 6
[00:01:00.657,714] <wrn> modem_monitor: RAI_UPDATE
[00:01:00.657,745] <wrn> modem_monitor:     INFO: 147045644 505 1
[00:01:00.657,745] <wrn> modem_monitor:   AS-RAI: 0
[00:01:00.657,745] <wrn> modem_monitor:   CP-RAI: 0
[00:01:00.657,867] <dbg> modem_monitor: lte_reg_handler: RRC_UPDATE
[00:01:00.657,897] <dbg> modem_monitor: lte_reg_handler:    State: Active
[00:01:00.882,263] <wrn> modem_monitor: RAI_UPDATE
[00:01:00.882,293] <wrn> modem_monitor:     INFO: 147045644 505 1
[00:01:00.882,293] <wrn> modem_monitor:   AS-RAI: 1
[00:01:00.882,293] <wrn> modem_monitor:   CP-RAI: 0
[00:01:06.266,876] <dbg> modem_monitor: lte_reg_handler: RRC_UPDATE
[00:01:06.266,906] <dbg> modem_monitor: lte_reg_handler:    State: Idle
[00:01:22.291,900] <dbg> modem_monitor: lte_reg_handler: MODEM_SLEEP_ENTER
[00:01:22.291,931] <dbg> modem_monitor: lte_reg_handler:     Type: 1
[00:01:22.291,931] <dbg> modem_monitor: lte_reg_handler:      Dur: 46783975

This happens every time the modem comes out of PSM, not occasionally. Is this the expected behaviour?
It seems unlikely that the AS-RAI support is truly switching, seeing as the attached tower is never changing.

[Michal]

Hello,

I will check that internally and get back to you.

In the meantime, please also tell me your NCS version.

Best regards,

Michal

[JordanYates]

I am not using NCS. The `nrfxlib` version is the v3.1.0 tag: github.com/.../v3.1.0

[Michal]

Are you using upstream Zephyr or some other kind of setup with just the nrfxlib?

[JordanYates]

My own fork of upstream Zephyr. I'm not sure why its relevant though, the events come directly from the modem library, its not like they are generated by the integration layer.

[Michal]

Sorry, just wanted to be on the same page.

I am checking internally for more information on that behavior.

Best regards,

Michal

[Michal]

Hello again,

I have an update for you:

When modem wakes up from PSM, it selects a cell. When the cell has been selected, modem sends a RAI update with RAI not supported, because network communicates the support only in RRC connection establishment. At this point, modem does not know whether RAI is supported or not. When RRC connection has been established and RAI is supported, modem sends a new RAI update with RAI supported.

The extra RAI update with RAI not supported is not very useful, but that’s how the modem currently behaves. The RAI update is intended to be used for information/debug purposes, so this should not affect application behavior anyway. The application should always set the RAI socket options, regardless of what the RAI update indicates. Modem then uses RAI if it is supported by the network.

Best regards,

Michal

[JordanYates]

> When modem wakes up from PSM, it selects a cell. When the cell has been selected, modem sends a RAI update with RAI not supported, because network communicates the support only in RRC connection establishment.

It seems odd that this behaviour occurs only for RAI, but no other information that could presumably change coming out of PSM. It seems like all other information is cached in the modem and only sent if it has actually changed, as indicated by the lack of other duplicate events notifying the cell tower, PSM parameters, etc.

I agree that this has minimal impact on the functioning of an application. But as it currently stands, using it for information/debug purposes will return the wrong value if the application is caching the support status and a query happens to arrive at the wrong time.