No, not by increasing the payload itself, but improving the payload/overhead ratio.
If you need to transmit 100 bytes payload, it’s a better approach (for the RF channel usage) to send it in one packet of 113bytes than to send it on 10 packets of 23 bytes each, 230bytes total!
It’s obvious much better to use the channel to transmit the app’s data than overhead!
By fragmentation I mean the process of breaking a big payload in smaller packets that can fit the protocol’s payload size (MTU).
Yes, you are correct. By now, over LoRaWAN, it has to be solved at the app layer. But in other protocols (like TCP) it is solved at the network layer. I didn’t tested yet, but LinkLabs claims that their Symphony Link (alternative to LoRaWAN, based on the LoRa PHY layer) also solves the fragmentation at the network layer.
I am implementing this at my app, but I would be much more comfortable to rely on a network layer fragmentation solution. And, as I told before, I belive it would lead to a better use of the RF channel and standardized solutions.
LoRaWAN is not build for ‘big’ payloads, bigger payloads means (even for the suggested ‘fragmentation’) that rf channels are longer occupied
Sure it’s not for big payloads…
But 100bytes isn’t big, is it? I don’t think so, based on the fact that some LoRaWAN DR can support 243 bytes payloads.
So, imagine an application that may need to evantually send a (100 - 150) bytes message. And can take many advantages of LoRaWAN network (long range, low cost, low power). Wiithout fragmentation on the network layer it will have to implement a quite complex algorithm at it’s app layer, or make a bad usage of the RF channel, flooding it with almost 2x the necessary bytes to be transmited.
yes it is 
can you explain what kind of sensors/data you use that require big (> 100) payloads ?
1 Like
Actually it isn’t a ordinary sensor.
There are some equipments and they use a legacy communication protocol based on some ‘big’ messages.
I am developping a remote connectivity solution to them, but it’s mandatory to keep using this legacy protocol, end-to-end. The LoRa/LoRaWAN data rate and traffic limitations can be accepted and we’re deploying the whole network infrastructure (gateways, network servers…).
Ok, so let’s consider that 100bytes is indeed a big payload. But 11bytes is really a tiny payload, right?
This way, what would be a good solution to send, let’s say some (25 - 50)bytes ordinary sensor messages, considering that the lowest maximum payload can be as low as 11 bytes?
Having the LoRaWAN stack provide it would solve your issue, however it would encourage people to send larger packets as the network stack takes care of it anyway.
Also, keep in mind EU868 at SF12 does not allow another transmission for minutes (time on air restrictions) when a large packet has been sent. So the LoRaWAN stack would have to stay awake for minutes to handle the next transmission wasting battery power all that time.
also, it will be very complicated because you must be 100 % sure that the second fragment reached the backend, to accomplish that it must use ACK or a form of CrC where the node must resend everything when not 100% received.
- very fast you’ll hit duty cycle restrictions/fair use policy
Yes, I’m aware of it.
AU915, which is also used here in Brazil, also has some time on air restrictions. This particular application use case won’t have battery power limitation and probably will be implemented at class C.
Anyway, I just think that fragmentation would play an important role, maximizing the efficiency of RF channel and avoiding poor solution like limiting application payload to the lowest maximum possible.
Unfortunatelly this is the aproach that I have seen being recommended almost everywhere I look for.
Yes, it must be reassembled at the other end and this requires all the fragments to reach. It might increase the communication errors, but for my particular app, as I told you before, there aren’t messages that needs to be transmitted very often. Just imagine that we’ll send about 3 - 5 times per day and receiving correctly more than once would be Ok.
Thinking about a general fragmentation feature at network layer I believe it must provide both confirmed (ACK based) and unconfirmed version of it.
maybe you could use different ports
Hmmm… How, exactly?
If not limited by battery, you could use WiFi or GSM depending on distance needed.
WiFi is being used where possible, this is the main reason we should keep using the legacy protocol.
But for some remote regions it will be almost impossible. Long Range is a must and there’s no GSM/LTE coverage.
By our current analysis, LoRa is the best PHY option.
1 Like