Hi,
How does message port number work on the network ?
Any efficiency to better heading of message/node collision except that RF?
According to;
Single node, nodes in application, all nodes I own.
Should I use a port number when sending messages like;
a single static for all ?
as different as possble by sequential or randomize ?
dynamic ?
Thank you
The port number does not affect the radio transmission or handling on a gateway in any way.
If your application does not use it, I’d set it to 1. But only as using another value might make it look like it is actually important somehow; just a matter of taste.
Aside: you might even argue that it’s a waste to include that byte in the protocol, and could instead have been added to the application payload (FRMPayload) by whoever explicitly wanted to use something like that. However, a few port numbers are reserved:
FPort value 224 is dedicated to LoRaWAN Mac layer test protocol.
Note: The purpose of Fport value 224 is to provide a dedicated Fport to run Mac compliance test scenarios over-the-air on final versions of devices, without having to rely on specific test versions of devices for practical aspects. The test is not supposed to be simultaneous with live operations, but the Mac layer implementation of the device shall be exactly the one used for the normal application. The test protocol is normally encrypted using the AppSKey. This ensures that the network cannot enable the device‘s test mode without involving the device’s owner. If the test runs on a live network connected device, the way the test application on the network side learns the AppSkey is outside of the scope of the LoRaWAN specification. If the test runs using OTAA on a dedicated test bench (not a live network), the way the Appkey is communicated to the test bench, for secured JOIN process, is also outside of the scope of the specification. The test protocol, running at application layer, is defined outside of the LoRaWAN spec, as it is an application layer protocol.
FPort values 225…255 (0xE1…0xFF) are reserved for future standardized application extensions.
Without that port number being present in each LoRaWAN payload, the above might have needed some specific bit in the message anway.
Also, for downlinks, a zero value for FPort indicates that MAC commands are included in FRMPayload (rather than in FOpts). Again, this could have been designed differently, but that would probably have needed yet another special bit.
Another aside, apparently:
All said, as FPort is part of the protocol anyway (at least when FRMPayload is not empty), use it for your application any way you want. Like, see Multiple sensors with different payload decoding TTN.