Replies: 3 comments 6 replies
-
|
For interest, there is a related problem with downlinks - I've found that some network servers will send an empty downlink to your port number when acknowledging a confirmed uplink. So I try to avoid empty packets in either direction. |
Beta Was this translation helpful? Give feedback.
-
|
This stack implementation does support transmission/reception of empty FRMPayloads (at least it is supposed to). The LoRaWAN specification allows the following empty FRMPayload transmissions:
This stack implementation uses options 1 and 2 for the uplinks as I think it is a waste of time on air resources sending the FPort without sending as well the FRMPayload. LoRaMac-node/src/mac/LoRaMac.c Lines 1251 to 1314 in 9218d00 Maybe I don't fully understand the observed behavior description. |
Beta Was this translation helpful? Give feedback.
-
|
Something I forgot to mention is that when a transmission is not possible due to the length of a frame the application layer can try to flush the MAC commands by sending an empty FRMPayload frame. LoRaMac-node/src/apps/LoRaMac/common/LmHandler/LmHandler.c Lines 478 to 493 in 9218d00 |
Beta Was this translation helpful? Give feedback.
-
Yes, options 1 and 2 work fine. My question was primarily about whether options 3 and 4 are supported, or more precisely, whether the stack is supposed to use those when FPort is present and FRMPayload is not. Based on the following code: LoRaMac-node/src/mac/LoRaMac.c Lines 3246 to 3258 in 9218d00 I think this answer is no, but I was not sure whether this was a deliberate choice. Waste of time on air: I would argue that it is the other way around. Forcing the application to send non-empty FRMPayload when empty payload would have sufficed could be considered waste of air time. Since you cannot send application payload without FPort, it seems natural to use that field for service/functionality dispatch. And if a particular service does not accept any arguments, empty payload is the most efficient way to invoke it. But, I am actually not really concerned about time on air. I mainly raised the question because the way I read the LoRaWAN specification, FPort without FRMPayload (option 4) seems to be allowed, but it does not seem to be supported by LoRaMac-node. Since LoRaMac-node aims to be the reference implementation, I wonder if that scenario should be supported as well. This stack implementation is able to handle all 4 options when processing the downlinks as can be seen in below code excerpt
Yeah, no issues with downlinks.
Consider the following program: McpsReq_t mr;
mr.Type = MCPS_CONFIRMED;
mr.Req.Confirmed.fPort = 2;
mr.Req.Confirmed.fBufferSize = 0;
mr.Req.Confirmed.fBuffer = "";
rc = LoRaMacMcpsRequest(&mr);Question 1: Will the uplink have FPort and if yes, what value? The answer is that it depends on the internal state of LoRaMac-node and there is no way for the application to tell. You could end up with an uplink that has no FPort and MAC commands in FRMPayload, but you could also end up with an uplink with FPort 2 and empty FRMPayload. It depends on the value of macCmdSize in the following code: LoRaMac-node/src/mac/LoRaMac.c Line 3221 in 9218d00 As a user of LoRaMac-node, I would prefer an error instead of having FPort reset to 0. Or, if that does not violate the spec, the library could try to fit the MAC commands into FOpts and send my original FPort and empty FRMPayload. In other words, give the user an option to handle this case at application level. Question 2: Suppose there are are no MAC commands waiting and the above code actually sends an uplink with FPort 2 and no FRMPayload. Would you expect this uplink to be retransmitted if there is no answer from the network? I would say yes. Since this is a confirmed uplink, I would expect it to be retransmitted. But that is not what I am seeing. I see the uplink transmitted once and then the library gives up. If I modify the above code to include one byte in FRMPayload, then the uplink is retransmitted as usual. I haven't looked into this more, but unless you can think of a reason why uplinks with empty FRMPayload should not be retransmitted, I think this might be a bug. We can try to debug this more if you think this is suspicious. |
Beta Was this translation helpful? Give feedback.
-
Sometimes an uplink or downlink is used as a command or indication, and there are parameters in the payload. When you have a command that doesn't need parameters, you often want to specify an empty uplink or downlink. But it still needs to have a port number to identify the command. |
Beta Was this translation helpful? Give feedback.
-
|
I think that in such cases one should send the FPort plus 1 byte FRMPayload providing the command status. When we first specify the LoRaWAN protocol the FPort was supposed to be used like the TCP/IP port number. Meaning it would identify the meaning of the subsequent bytes. In the end this is an implementation choice and we decided to use one of the options. I believe the choice that we have made for this stack implementation is the right one. In addition so far, no argument has convinced me to change the current implementation. Nothing prevents the modification of the stack implementation to support your vision. Please feel free to do so. Good examples on how to implement application protocols over LoRaWAN can be seen on below produced LoRa-Alliance specifications |
Beta Was this translation helpful? Give feedback.
-
Indeed. This is exactly what I was trying to implement. I come from the internet protocol world where port numbers are generally used to identify processes, sockets, or logical end-points, i.e., the target of the communication, and empty payloads are not uncommon. |
Beta Was this translation helpful? Give feedback.
-
|
In TCP (and UDP), the destination port number identifies the target process or some other logical endpoint on the remote host [1]. It's usually unrelated to the payload format. In the IP world, empty payloads are valid and common. I figured FPort in LoRaWAN was inspired by TCP/IP port numbers, hence my attempt to use it with an empty payload. Also, with the exception of the possible retransmission bug, this might be an academic debate. I'm fine with non-empty payloads only. I mainly brought this corner case up since LoRaMac-node aims to be the reference implementation for LoRaWAN. The way I read the spec, this case seems allowed, but I could be wrong. [1] https://en.wikipedia.org/wiki/Port_(computer_networking) |
Beta Was this translation helpful? Give feedback.
-
|
I get and understand your arguments. I have created an issue in order to implement this enhancement. |
Beta Was this translation helpful? Give feedback.
-
I was trying to send an empty confirmed uplink the other day and realized that this is not really reliably supported by LoRaMac-node. My intended application was configuration polling. The device would send an empty uplink to a specific port number and receive configuration via the downlink.
As it turns out, LoRaMac-node would internally change the port number to 0 if it has any MAC commands waiting to be piggybacked in order to be able to put those in the message payload. The original port number is lost in this case. Another odd behavior that I ran into was that even if there were no MAC commands waiting, empty confirmed uplinks would not be retransmitted.
This makes me wonder whether empty uplinks are supported by LoRaMac-node. I quickly skimmed the LoRaWAN specification and found nothing that would prohibit those, so maybe this is an implementation limitation? If LoRaMac-node cannot reliably send empty uplinks, maybe it should report an error to the application? Or perhaps the handling of piggybacked MAC commands should be left to the application instead so that empty uplinks to non-zero port numbers could be supported?
Not a critical problem, I am just wondering what the intended behavior is in this corner case.
Beta Was this translation helpful? Give feedback.
All reactions