+CGEV: APNRATECTRL STAT - Not reported with pdn_event_handler_t

[Achim Kraus]

mfw 1.3.5, NCS 2.4.1

I received a

+CGEV: APNRATECTRL STAT 0,1,86307

from the modem.

I'm wondering, if that is processed by a pdn_event_handler_t.

If not, how does the application know that?

[emdi]

Hello Achim Kraus 

currently there is no support for APN rate control notifications in the PDN library.
I will check if that can be added there and open a PR for that if possible.

Regardless, the application can subscribe to any AT notifications using the AT monitor library, which will also let you parse the AT command as necessary in your application to extract all the information you want from it.

[Achim Kraus]

Thanks!

One additional comment:

Using

AT%APNRATECTRL=0,0

helps also to read that. Once the rate limit is triggered, that's indicated there. The pain is unfortunately, if the modem is switched off CFUN=0 and one CFUN=1 again, that AT cmd reports inactive rate limit, but the modem continues to fail sending the data. If the device gets rebooted, it's able to send data again.

Not sure, what the nature of that "rate limit" should be. For now I only saw that from one SIM card provider. Maybe Nordic checks, what the right behavior for switching off and on would be. I guess either the modem should then continue to send data or the modem should continue to report, that the rate limit is triggered.

[Achim Kraus]

I use

fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

sendto(fd, data, len, MSG_DONTWAIT, &session->addr.sa, session->size);

I consider that as non-blocking.

[emdi]

Indeed, that's non-blocking; this seems like a bug to me (in libmodem).

I have a tentative fix which I would like to share with you, it would be very helpful if you could give it a go. Can you please create a private ticket for this?

[Achim Kraus]

Yes. I will do that in 2h.

[Achim Kraus]

I opened that private ticket.

[Achim Kraus]

In the meantime, my device is able to "overcome" the triggered rate-limit.

Assuming the idea behind that is to prevent devices from "flushing too much unintended data", in my case it's simply triggered by a FOTA. That results in two questions for me:

- if the device (or the device owner) should decide, if the traffic is intended or unintended, I would consider to be able to "delegate" that to a server. But with the current API, the app will mainly get noticed, when the limit is already reached. If the app get noticed "short before", server communication will still be possible and with that it will easier to make usage of that "rate limit / cost limiting" feature. I see therefore two extension, a "pre limit warning" event, and to report more details in %APNRATECTRL when the status is "0". Adding the remaining "number of packets" and remaining time of the period will help to improve such application specific usage.

- if this "rate limit" isn't a "hard limit", is it really required to switch the modem off and on? Or are other implementations also possible, e.g. a reset command for the "rate limit" state?

[Amanda Hsieh]

It will be fixed in NCS v2.5.0. 

[Achim Kraus]

Thanks!

Please also try to forward my questions to the modem team. With the current API / implementation of the AT cmds, the "rate-limit" is more painful than helpful.

[Amanda Hsieh]

Thanks for the feedback. I have forwarded it to the team. 

[emdi]

Hello Achim Kraus ,

the APN rate control feature is controlled by the network and not the device itself.
It is the network that toggles this feature to control how much data the device is allowed to send.

[Achim Kraus]

So the modem off/on will be required by the network spec?

OK, I guess, it's just an other "very useful" GSMA feature.

Hopefully is not used by too many SIM card-provider.