The Port Field

The LoRaWAN specification provides a data delivery field (FRMPayload) and a Port field (FPort) to distinguish between different types of messages. FPort 0 is reserved for MAC messages. Do not use this port to transport data fields. FPort 224 is reserved for MAC compliance testing and FPorts 225-255 are reserved for future standardized application extensions1. This leaves valid port numbers between 1 and 223.

Device or Object Model and Ports

While not explicitly stated in the specification, the Port field was inspired by the IPSO Alliance’s “smart objects.”2 In that framework, smart objects are virtual functions or controls in a physical device. The idea is that a device manages the objects and exposes interfaces, such as sensor measurements and actuation controls. Object definitions, for example a temperature sensor, can be in many different devices but share characteristics such as precision, format and power consumption. By tying a port to a specific function, such as making a measurement, it is easier to abstract the underlying action.

Figure 1. IPSO device and object model

If you make two devices, say, a water meter that has a flow sensor (Object A) and a water valve with a valve actuator (Object B), both devices can use the same pressure sensor (Object C). By addressing each function individually, you can re-use the code and data-handling for the pressure sensor (Object C) in both systems, thus reducing development time when you implement an interface to the devices.

API Implementations

While all payloads could be sent with a single port identifier, it is faster and easier to write a decoder if the format is consistent from payload to payload. The payload could include a “packet type,” but that requires extra bits, or even a full byte of information, to be conveyed in the port field. With multiple ports, you can write a decoder with fewer conditional statements—and simpler checks—to validate its contents. In comparison, if the payload has variable length or different data types depending on the device state, the complexity and processing required for the decoder relative to the fixed variety are increased. This satisfies the design goal of the IPSO Alliance/OMA SpecWorks which defines functions in a device that can be expressed and managed simply.

Group Measurements

By using port definitions across functions, you logically segment the data flow and enable the designer to naturally have more “atomic” and conceptually smaller packet definitions. Some classes of sensors with multiple sensing elements have naturally synchronized measurements.

For example, a pressure and temperature sensor for liquids or gases (see Figure 2). Getting these two measurements at different times would make characterizing the system state harder than getting them both at the same time. In that case, putting the pressure and temperature reading in the same packet makes sense.

Figure 2. Example system for simultaneous sample measurement

However, another multi-measurement sensor may have data that is not necessarily related. For example, a passive-infrared motion sensor with an anti-tamper accelerometer. The purpose of the passive-infrared sensor is to determine whether someone is in a room. The purpose of the accelerometer is to determine whether the sensor has been moved. These are very different types of measurements, and are almost completely independent of one another. A single packet could be defined to provide information for both sensors together (triggered if either sensor “fires”) or separately for each measurement type. If you imagine that the typical use of this sensor would have the room occupancy triggering 10 times per day but the accelerometer trigger once a year, then every year you get 3,650 room occupancy notifications and one accelerometer notification. If the accelerometer data was included in every room occupancy update, there would be 3,649 repeated “no accelerometer trigger” messages every year. In this case, having separate ports for the passive infrared sensor and the accelerometer makes sense for data efficiency purposes. A separate port for the accelerometer could be a simple trigger for an alarm without even decoding the payload, simplifying the application implementation.

Figure 3. Example of a multi-sensor device with disparate measurements

In summary, ports allow:

• Creating “atomic” payload definitions
• Streamlining API creation and decoding
• Grouping similar or related measurements together
• Separating disparate measurements or processes into different payloads