What a gateway does
Some connected devices cannot reach the internet on their own. A soil sensor on a LoRa radio, a door sensor on Thread, or a controller on a factory network has no Wi-Fi or cellular link, or is deliberately kept off one. An IoT gateway is the device that connects them to an IP network, and from there to a service such as a cloud platform.
To do that, it sits on two networks at once and does some combination of these jobs:
- Bridging radios. The LoRa Alliance describes LoRaWAN gateways as converting radio packets to IP packets and back, connected to a network server over standard IP. OpenThread says a Thread Border Router minimally provides two-way IP connectivity between a Thread network and Wi-Fi or Ethernet, along with service discovery in both directions.
- Translating protocols. Devices that do not speak the cloud’s protocol need their messages converted.
- Processing locally. AWS describes IoT Greengrass as letting devices act locally on the data they generate, run machine learning predictions, and filter and aggregate device data.
- Buffering. When the uplink fails, a gateway can hold data instead of dropping it.
- Isolating. Devices behind a gateway need not be exposed to the internet themselves.
A gateway inside a mesh, linking the mesh to the outside, is a narrower case covered in what is a gateway in a mesh network.
Radio gateways and edge runtimes
It helps to separate two kinds of gateway, though one box can be both.
A radio gateway exists mainly to bridge a low-power radio that IP networks cannot hear. LoRaWAN gateways and Thread Border Routers are examples. Their main job is moving data across that boundary. BLE vs Thread vs Zigbee vs LoRa covers the radios they bridge.
An edge runtime turns a computer near the devices into a programmable gateway. AWS IoT Greengrass is an open source edge runtime and cloud service; local client devices connect to a Greengrass core device over MQTT, and the core can process their messages and relay them to AWS IoT Core. Azure IoT Edge is a runtime that deploys and runs containerised modules on a device, and Microsoft documents how an IoT Edge device can act as a gateway for other devices on the network.
Transparent and translation gateways
Microsoft’s documentation for Azure IoT Edge names three gateway patterns. The names are specific to that product, but the distinction is useful for any gateway, because it answers a basic question: who does the cloud think it is talking to?
| Pattern | Who has a cloud identity | What the cloud sees |
|---|---|---|
| Transparent | Each downstream device | Each device, as if no gateway were there |
| Protocol translation | Only the gateway | One device, the gateway; per-device detail must be inside the messages |
| Identity translation | The gateway provides one for each downstream device | Each device as a first-class device, with the gateway hidden |
A transparent gateway suits devices that could connect to the cloud directly. They keep their own identities and connect over MQTT or AMQP; the gateway passes traffic through. Microsoft notes that by default a parent can have up to 100 children, and gateways can be nested up to five generations deep.
A translation gateway suits devices that cannot. In protocol translation, a module on the gateway converts their messages and sends them as the gateway, which Microsoft calls opaque because the downstream devices’ identities are hidden. In identity translation, the gateway also gives each downstream device its own cloud identity, so it can be managed individually. Microsoft adds that its runtime does not include either translation itself; these patterns need custom or third-party modules specific to the device’s hardware and protocol.
What a gateway adds, and what it costs
Microsoft lists the benefits of the gateway pattern: analytics at the edge, so only a subset of data goes to the cloud; isolation of devices on an operational network from the internet; multiplexing devices over one cloud connection, which needs AMQP; exponential backoff with local persistence when the cloud throttles traffic; and storing messages that cannot yet be delivered.
That last point is store-and-forward in practice. The same position brings costs. Every device behind a gateway depends on one box. If it fails, everything behind it loses its route to the cloud, unless there is a second gateway. If it is compromised, everything that crosses it is exposed to inspection or tampering, unless the data is protected end to end. And an acknowledgment from the gateway means the gateway has the message, not that the backend has stored it.
Choosing and trusting a gateway
Treat a gateway as a security boundary, not a pipe.
- Authenticate in both directions. In Azure’s transparent pattern, child devices use a shared root CA certificate to verify that they are connecting to the right gateway, and the gateway authenticates to the cloud.
- Decide which devices may be gateways. Offline Protocol’s networking docs, for example, state that a gateway is provisioned against a defined contract including identity, delivery verdicts and recovery, and that a device with internet access does not automatically become a trusted upload destination.
- Plan for the uplink to fail. Buffer locally, set a limit on what is kept, and confirm end to end that the backend accepted the data.