From the LoRaWAN v1.0.3 specification (v1.0.4 and v1.1 will show similar information):
4.3.2 Port field (FPort)
If the frame payload field is not empty, the port field MUST be present. If present, an FPort > value of 0 indicates that the FRMPayload contains MAC commands only; see Chapter 4.4 for > a list of valid MAC commands. FPort values 1…223 (0x01…0xDF) are application-specific. > FPort value 224 is dedicated to LoRaWAN Mac layer test protocol
However in the “FUOTA Process Summary Technical Recommendation TR002 v1.0.0” document on page 6, additional reserved ports are listed:
The document links in the table are no longer valid. The v1.0.0 documents can be downloaded from the following pages:
- FUOTA Process Summary Technical Recommendation TR002 v1.0.0
- LoRaWAN® Application Layer Clock Synchronization Specification v1.0.0 - LoRa Alliance®
- LoRaWAN® Remote Multicast Setup Specification v1.0.0 - LoRa Alliance®
- LoRaWAN® Fragmented Data Block Transport Specification v1.0.0 - LoRa Alliance®
For each of the ports 200, 201, 202, 203 and 225 a separate document is listed in the table, where each port is further described (in the listed documents search for port instead of fport).
Does this imply that FPort values 1…223 (0x01…0xDF) can be used by applications, except for ports 200…203?
Does this mean that FPort information in the LoRaWAN 1.x specification documents is outdated?
If so that would break backwards compatibility, which will probably not be the case here. Can you explain where/when these additional FPort numbers are used and whether this impacts any regular application traffic for applications that currently use FPorts 200…203?