fPort for ACK of an confirmed uplink

Recently we did a test with the Actility Network server and found 1 minor discrepancy between Actility and Chirpstack.

We noticed that for a confirmed uplink, Actility sends ACK on the same port as the application uplink while Chirpstack uses null. This is just ACK without any additional MAC payload.

I checked the specification document of LoRaWAN v1.0.2 however, it does not specify which port to be used for ACK of confirmed uplink.

Is there a reason why Chirpstack uses fport null for ACK of a confirmed uplink? or it is something that is free to interpret?

Note, we are using LoRaWAN v1.0.2, region EU868, class A in both situations.

Best Regards,

Confirmed traffic is ack’d with a header bit, the port is irrelevant, but the port has to be one that is legal for the packet as a whole. An ack is only contextually tied to the uplink it is acking by time, nothing else is necessarily going to match.

An application port number should really only be used if the packet contains an application payload to be delivered to that port.

Network housekeeping messages that don’t have an application payload are sent on port 0, which may show as null in some places that are either expecting an application port, or falling victim to protocol buffer’s habit of omitting default values, which tend to leave them re-parsed as null.

An end device should recognize an ack delivered in any legal packet. The same goes for MAC command traffic, which can be in the fopts of a packet containing application traffic, or be in the payload of a port 0 network management packet.


Added to @cstratton his comment, ChirpStack could combine the ACK with a downlink payload, in which case the fPort relates to the downlink payload, not to the ACK.

1 Like