Skip to main content

Broker Requirements

The broker needs to fulfill the following requirements:

Why QoS 0?

The gateway uses QoS 0 (fire-and-forget) for all MQTT messages. This is intentional:

  • TCP already guarantees delivery within an active connection — retransmission and ordering are handled at the transport layer, so QoS 1/2 would add overhead without meaningful benefit.
  • Sensor data is periodic — if a connection drops mid-transmission, the gateway reconnects and sends fresh readings at the next scheduled interval. A missed packet leaves a gap in the time series, but does not cause permanent data loss.
  • Simpler broker setup — QoS 1/2 require the broker to maintain persistent sessions and send acknowledgements for every message, which increases infrastructure complexity unnecessarily for this use case.

If your application requires guaranteed delivery of every individual reading (e.g. billing-critical data), consider buffering on the backend side rather than relying on MQTT QoS levels.

  • Authentication: None, Username+Password, Client-Certificate.
  • Security: None, TLS 1.2.

The list of supported TLS ciphers can be found here: Security → Device Certificates.

RSA Key Length limitation

We recommend using elliptic curve certificates due to their compact size. If you prefer using RSA, please note that the gateway’s crypto hardware (Arm® TrustZone® CryptoCell 310 (CRYPTOCELL)) is limited to 2048-bit key lengths.

MQTT topics used by the device​

The default topic prefix is LOB, and can be changed via the Host parameter.

The device subscribes to the following MQTT topics:

  • [topic prefix]/[DevEUI]/down/#

The device publishes to the following MQTT topics:

  • [topic prefix]/[DevEUI]/up/+
  • [topic prefix]/[DevEUI]/req/+