40 byte limit on UDP messages over NB-IoT R410/R412

#1

Hi

I am seeing problem with sending larger UDP messages than 40 bytes. If I send smaller my server receives them but larger than 40 bytes nothing comes to the server.

Ex:

[2018-10-01 11:19:46,747] DEBUG: Sent: b’AT+USOST=0,“xxx.xx.xxx.xxx”,9xxx,44,“3030303030303030303031303030303030303030313030303030303030303130303030303030303030303031”\r\n’
[2018-10-01 11:19:46,774] DEBUG: Processing URC: +USOST: 0,44
[2018-10-01 11:19:46,774] DEBUG: Unhandled urc: b’+USOST: 0,44’
[2018-10-01 11:19:46,774] DEBUG: Received: [b’+USOST: 0,44’, b’OK’]
[2018-10-01 11:19:46,774] DEBUG: AT Command response = []

Is there a way of finding out if it is a problem with the module or the network provider? I have tried with a N211 and the same operator and that works fine.

#2

The OK means that the module has a correct payload lenght.
If the payload would be incorrect size. The module will return an error.

#3

Yes. So what could be the problem of the messages not arriving to the server.

When will packets be fragmented?

#4

Did you ever find a solution to this?

I’ve seen the exact same problem with two different carriers using my R410M. Oddly, the exact same module works fine with several other carriers.

#5

Yes. There was a problem with the NAT at the MNO. After some trials we managed to make it work.

The problem is that the U-Blox SARRA R410 modul applies a default MTU size of 68 bytes when connected to
the network. This small MTU size is currently not supported for UDP when a device is using a NAT-ed IP address. My operator did manage to fix this in their NAT.

Apparently UBlox will set the default MTU size to 1500 bytes in future firmware versions, but I have not checked if they have released a new version. I have not been working with the 410 this year. I have gone back to using the 211.

maybe @Jan knows something about new firmware?

1 Like
#6

Okay, this explanation perfect makes sense. The over-the-air MTU is too low and it’s fragmenting the UDP packets coming out of the module and then the MNO’s firewall/NAT gateway is either incapable of reassembling the fragments or it just doesn’t have that feature turned on.

Do you recall if you found an AT command or something to change the MTU on the 410? I don’t see anything in the documentation, but was hoping maybe UBLOX passed along an undocumented feature.

Thanks so much for the quick reply. I’ve really been wondering why this problem has existed in our implementation and only for some carriers. I’m pretty sure that we’re NATed in all of the networks we’ve tested in, but some of them must be reassembling the fragments at their gateways.

#7

I didn’t manage to find any solution on the ublox module.

Went through my emails with the MNO again and their solution was to change some rules in the firewall/NAT.

There was one thing I never got an answer on though. As I understood it from out MNO the 211 has a High Silicon chip and the 410 has a Qualcom. I never got the answer if it was the chip provider that had made this MTU default or something that could be changed by Ublox.

I also found this test protocol a while back for KPM that highlights the same problem with promises from Ublox that it would be fixed (sometime):
https://attachments-eu-west-1.insided.com/5fe1cb1d-2572-47b8-a486-130cecabe8d5/Test%20results%20LTE-M%20devices%20v1.0.pdf

1 Like
#8

Very interesting. We’re pursuing this with UBLOX to see if they can help us to somehow set an MTU or get us a firmware fix. We’re also pursuing it with the provider to see if they can either give us a reasonable MTU in the LTE negotiation or reassemble fragments at the NAT gateway.

Thank you for the great information.

[EDITED to add a followup. I’m a new forum user so the reply limit was keeping from posting a separate comment]

We found a workaround for our particular situation that I can pass on in case someone else comes across this thread.

The default UMNOPROF is part of the problem in that it is where that default MTU of 68 bytes comes from. Other profiles have different MTUs. The tricky part is that when you change UMNOPROF settings, you blow away some other settings like your CGDCONT, URAT, etc. You can see some details for the profiles here:

So basically we switched to a UMNOPROF for a different carrier then jiggled around the other settings until it worked.

#9

No problem. Just post Ublox answers if you find anything out :slight_smile:

#10

Hello,

i have almost the same problem. But i am using the 211 module. The limit here is 236 bytes of payload for me. 512 bytes should be possible. But any message with a payload larger then 236 byte does not arrive. Since you work with the 211 without this issue: Do you have ever sent messages this large without problems? Might the error have the same source as yours? I am kind of new to the topic and i am not quite sure how to solve this. Should i contact uBlox or the MNO?

#11

I would contact the MNO. But first see if you can reproduce the problem in another environment so they don’t pin the error on you server or infrastructure and not investigating fully.

You could use the ublox echo server and see if you get responses back.