Building an MQTT IoT Gateway with LoRa and Wi-Fi Modules: Architecture Guide

Most IoT architectures follow the same pattern: sensors in the field generate data, a gateway aggregates it, and a cloud platform stores, analyses, and visualises it. MQTT (Message Queuing Telemetry Transport) has become the standard protocol for the gateway-to-cloud link because of its lightweight publish/subscribe model, persistent sessions, and quality-of-service levels that handle unreliable network connections gracefully. This guide walks through the architecture of an IoT gateway that bridges Reyax LoRa sensor nodes to an MQTT cloud platform.

System Architecture

The gateway sits at the boundary between two wireless domains:

Field side (LoRa): Sensor nodes equipped with Reyax RYLR998 or RYLR498 modules transmit readings over LoRa. The gateway receives these transmissions through its own LoRa module connected via UART.

Cloud side (Wi-Fi/Ethernet/Cellular): The gateway publishes received sensor data to an MQTT broker (Mosquitto, HiveMQ, AWS IoT Core, or Azure IoT Hub) over a TCP/TLS connection. The Reyax RYBW Series provides Wi-Fi connectivity for the cloud uplink, or the gateway can use Ethernet or a cellular modem.

The gateway processor, a Raspberry Pi, ESP32, STM32 + Linux SBC, or any platform with two UART ports and a network stack, runs the bridging logic: receive LoRa packets, parse sensor data, format MQTT messages, and publish to the broker.

Hardware Configuration

A minimal gateway uses two Reyax modules:

1. RYLR998 or RYLR498 on UART1, receives LoRa data from field sensors
2. RYBW Series on UART2, provides Wi-Fi for MQTT cloud connectivity

Both modules use AT commands over UART, keeping the gateway firmware simple. The LoRa module operates in continuous receive mode, and incoming data appears on UART1 as +RCV=<address>,<length>,<data>,<RSSI>,<SNR> messages. The gateway parses each received message, extracts the sensor payload, and formats it for MQTT publishing.

For gateways using an ESP32 as the main processor, the ESP32’s built-in Wi-Fi can serve as the cloud uplink, and only the LoRa module is needed as an external Reyax module. For gateways using STM32 or other MCUs without built-in Wi-Fi, the RYBW Series provides the wireless network connection.

MQTT Topic Structure

A well-designed MQTT topic hierarchy makes data organisation and access control straightforward:

gsas/site/{site-id}/sensor/{node-id}/telemetry
gsas/site/{site-id}/sensor/{node-id}/status
gsas/site/{site-id}/gateway/{gw-id}/health

Each sensor node publishes telemetry to its dedicated topic. The gateway publishes its own health metrics (uptime, LoRa packet count, error count, RSSI statistics) to a separate topic. This structure allows the cloud platform to subscribe to all sensors at a site with a wildcard (gsas/site/pune-factory-1/sensor/#) or to a specific sensor (gsas/site/pune-factory-1/sensor/node-042/telemetry).

Message Format

JSON payloads are the standard for MQTT IoT messages. A typical sensor telemetry message:

{
  "node_id": "N042",
  "timestamp": 1743850200,
  "temperature": 34.2,
  "humidity": 67.5,
  "battery_v": 3.42,
  "rssi": -68,
  "snr": 11
}

Including RSSI and SNR from the LoRa reception in the MQTT payload gives the cloud platform visibility into wireless link quality, useful for detecting sensor nodes with degrading antennas or changing environments.

Quality of Service and Reliability

MQTT defines three QoS levels:

• QoS 0 (at most once): Fire and forget. The message may be lost if the network drops. Suitable for high-frequency telemetry where an occasional missed reading is acceptable.
• QoS 1 (at least once): The broker acknowledges receipt. The message may be delivered more than once. Suitable for most sensor data where idempotent processing handles duplicates.
• QoS 2 (exactly once): Guaranteed single delivery with a four-step handshake. Higher overhead, used for critical commands and alerts.

For sensor telemetry from LoRa nodes, QoS 1 provides a good balance between reliability and overhead. The gateway should implement a local message queue that buffers MQTT messages when the cloud connection is temporarily unavailable and publishes them when connectivity is restored. This store-and-forward capability is essential for deployments in Hyderabad, Chennai, and Pune where internet connectivity may be intermittent.

Security Considerations

MQTT brokers support TLS encryption for the transport layer and username/password or certificate-based authentication for access control. For production deployments:

• Use TLS 1.2 or later for all MQTT connections
• Use per-gateway client certificates rather than shared credentials
• Implement access control lists (ACLs) on the broker so each gateway can only publish to its own topic tree
• Encrypt sensitive payloads at the application layer if the data transits through a shared broker

The LoRa link between sensor nodes and the gateway is inherently difficult to intercept due to spread-spectrum modulation and the need for matching LoRa parameters (frequency, SF, bandwidth, network ID) to decode transmissions. For applications requiring stronger security on the LoRa link, AES-128 encryption can be implemented in the sensor node firmware before passing the encrypted payload to the Reyax module for transmission.

Cloud Platform Integration

MQTT is natively supported by major IoT cloud platforms:

• AWS IoT Core: managed MQTT broker with device shadows, rules engine, and integration with Lambda, S3, and DynamoDB
• Azure IoT Hub: MQTT support with device twins, message routing, and integration with Azure Functions and Time Series Insights
• Self-hosted: Mosquitto MQTT broker + InfluxDB + Grafana is a popular open-source stack for teams in Bengaluru and Delhi NCR that prefer on-premises data sovereignty

The gateway firmware is the same regardless of the cloud platform, only the MQTT broker endpoint, port, and authentication credentials change.

Why Buy from GSAS

GSAS Micro Systems provides Reyax LoRa modules (RYLR998, RYLR498) and Wi-Fi/BLE modules (RYBW Series) from Indian inventory with INR invoicing for IoT gateway projects. Our engineering team supports gateway architecture review, module selection, and MQTT integration guidance. Teams across Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR can access local support. Contact GSAS to discuss your IoT gateway requirements.