lte network rate limits

[paul_tanner]

Normally when we send data via UDP we get a +CEREG: 5 response.

We use this to generate a signal &lte_ready which in turn allows the next message to be sent.

(As per the SUPL_CLIENT code in the AGPS example)

We have noticed that this strategy fails after sending 14 messages of 71 bytes at 2 minute intervals.

I think this may reflect a UK (O2) network limit (or something standard for LTE).

I have not found any document to support this theory or otherwise shed light on this.

Suggestions please.

[Didrik Rokhaug]

Hi,

Could you explain what you mean with "Normally when we send data via UDP we get a +CEREG: 5 response"?

Is the device moving? And are you using NB-IoT?

There isn't really a direct connection between data transfers and CEREG notifications.

Or are you waiting for CEREG notifications before you send data? Do you disconnect from the network afterwards?

Best regards,

Didrik

[paul_tanner]

Hi Didrik,

This happens whether device is moving or not.  We are using LTE/M.

The code is from the gps example.  I'm re-using that, calling activate before sending each message:

static void wait_for_lte(void *context, const char *response)
{
  if (!memcmp(status1, response, AT_CMD_SIZE(status1)) ||
    !memcmp(status2, response, AT_CMD_SIZE(status2)) ||
    !memcmp(status3, response, AT_CMD_SIZE(status3)) ||
    !memcmp(status4, response, AT_CMD_SIZE(status4))) {
    k_sem_give(&lte_ready);
  }
}

static int activate_lte(bool activate)
{
  if (activate) {
    if (at_cmd_write(AT_ACTIVATE_LTE, NULL, 0, NULL) != 0) {
    return -1;
  }
  at_notif_register_handler(NULL, wait_for_lte);
  if (at_cmd_write("AT+CEREG=2", NULL, 0, NULL) != 0) {
    return -1;
  }
  printk("waiting for lte_ready\n"); // gets stuck here after 14 x 71 - 2 secs
  if (k_sem_take(&lte_ready, K_MSEC(600000)) != 0) { //10 mins
    printk("timeout waiting for lte_ready\n");
    while (true) {};
  }
  at_notif_deregister_handler(NULL, wait_for_lte);
  if (at_cmd_write("AT+CEREG=0", NULL, 0, NULL) != 0) {
    return -1;
  }
} else {
  if (at_cmd_write(AT_DEACTIVATE_LTE, NULL, 0, NULL) != 0) {
    return -1;
  }
}
return 0;
}

You'll notice I added something to detect the timeout I'm getting.  What I don't know is why this happens after exactly 14 messages.  The question is what to do about it.  Ignoring it seems like a bad idea.

PS. I changed the message size from 71 to 47 bytes.  This had no effect on the number of messages that could be sent.

[Didrik Rokhaug]

Hi, and sorry for the late reply.

I don't think the problem is the amount of data that you are sending. However, the frequent disconnects and reconnects might be.

There is a feature in the LTE network where devices that reconnect frequently gets blocked from the network for a while. However, if I remember correctly, that limit is 30 connection attempts in 30 minutes, not 14.

However, it might be an idea to increase the time between the messages, or use eDRX or PSM to give the GPS enough runtime, while still staying connected to the network.

[paul_tanner]

Yes.  It seems that there is a limit to "activations".  When I reduced those the problem went away

(AT+CFUN=21 ... AT+CFUN=20)

I had thought these necessary to allow the GPS to operate properly.  Not so.