IoT gateway: what it does and how to choose one

An IoT gateway is a device that sits between connected devices and the network above them, and does the work the devices cannot do for themselves. A power meter that only speaks Modbus RTU over a serial cable, a temperature sensor that only has a Zigbee or Bluetooth radio, or a soil probe that sends a few bytes over LoRa cannot publish to a cloud platform or a plant historian directly. The gateway talks to them in their own protocol, turns what they report into named, timestamped readings, and sends those upward over an IP network, usually as MQTT or through an OPC UA server. It is one of the building blocks described in what an industrial IoT system is made of, and the industrial IoT hub collects the other parts. This article explains what a gateway does, how it differs from a router and an edge computer, the kinds you will meet, and what to check when choosing one.

Why gateways exist

Most sensors and field devices are built for a narrow job at the lowest cost and power. Giving each one an Ethernet port, a full IP stack, encryption and a cloud client would make it larger, more expensive and, if it runs on a battery, much shorter lived. So the devices use whatever suits their situation: a serial bus in a plant, a low-power mesh in a house, a long-range radio across a farm. The gateway is where those many local networks meet the one IP network.

There is a second reason. Even where a device could connect directly, you may not want it to. A plant full of controllers and drives connected individually to the internet is a plant with hundreds of things to patch and protect. One gateway per line or per building, with the field devices behind it, gives a single place to apply security and a single connection to watch.

The four jobs a gateway does

Protocol translation. On the field side the gateway acts as a master or coordinator: it polls Modbus devices over RS-485, forms a Zigbee network, scans for Bluetooth Low Energy advertisements, or reads a PLC over its own industrial protocol. It then maps what it reads into the protocol the upper systems expect. For Modbus that means knowing which registers hold which values, their data types and scaling, which is configuration rather than anything the device announces. The Modbus RTU article explains what the gateway is reading.

Data handling. Field devices often report far more than anyone needs to store. A gateway can filter, average, convert units, attach timestamps and names, and send only changes or summaries. This is the simplest form of edge processing, and the edge computing against cloud computing article covers when to do more of it locally.

Buffering. When the uplink fails, a gateway with local storage keeps collecting and sends the backlog, in order and with the original timestamps, when the link returns. This is called store-and-forward and is covered below.

Security and management. The gateway holds the credentials and certificates for the upstream connection, encrypts traffic with TLS, and keeps the field devices off the wider network entirely. It is also the thing that gets monitored and updated remotely, and it often relays configuration or firmware to the devices behind it.

Gateway, router or edge computer?

The words overlap, and vendors use them loosely.

A router forwards IP packets between networks without looking at what they mean. Your home router connects the house network to the internet; it does not know what a Zigbee sensor is. A gateway, in the IoT sense, understands at least one non-IP protocol or one application protocol and converts between them. A device can be both, and many industrial gateways include a cellular router.

A Thread border router is a useful edge case. Thread devices already speak IPv6, so the border router forwards packets between the Thread mesh and the home’s Wi-Fi or Ethernet without translating them; the Thread border router article explains the difference. A Zigbee coordinator, by contrast, has to translate, because Zigbee devices do not use IP at all.

An edge computer runs applications close to the machines: analytics, a local dashboard, a machine-learning model. An edge gateway is a gateway with enough computing power to do some of that as well, often by running containers or a flow tool such as Node-RED. The line between the two is a matter of how much software runs on the box.

The kinds of IoT gateway

Smart home hubs are gateways for the house: they form a Zigbee or Z-Wave network, pair devices, and expose them to apps and voice assistants. Whether that hub works without the internet is a separate question, covered in the local-only smart home guide.

LoRaWAN gateways are the odd ones out. They do not decode the data. A LoRaWAN gateway receives every LoRa packet it can hear on its channels and forwards it, unchanged and still encrypted, to a network server, which removes duplicates, checks it and passes it to the application. The device’s data is encrypted end to end between the device and the application, so the gateway cannot read it. The LoRaWAN article covers the network structure.

Industrial edge gateways are built for control cabinets: DIN-rail mounting, a 24 volt DC supply, a wide operating temperature range, isolated serial ports, and often digital and analog inputs, including 4-20 mA loops, for signals that come straight from sensors. They usually poll Modbus devices and read PLCs, then publish over MQTT or serve the values through OPC UA, as described in OPC UA and MQTT in factories.

Cellular gateways connect equipment at sites with no wired internet, using a SIM and a mobile network. For low-data devices, LTE-M and NB-IoT modems are common; the NB-IoT vs LTE-M article and the IoT SIM card guide cover those choices. For gateways that move more data, such as video or a site’s whole internet link, 5G RedCap modules are the newer mid-range option.

Store-and-forward: what happens when the link drops

Every uplink fails sometimes: a cellular signal fades, a firewall rule changes, a cloud service has an outage. A gateway that simply forwards readings loses everything until the link returns. A gateway with store-and-forward keeps polling, writes each reading with its original timestamp to local storage, and when the connection comes back sends the backlog in order before resuming live data.

Three details decide whether this works in practice. The gateway’s clock must be right, set from NTP or a GPS receiver, or the buffered timestamps are wrong. The storage must be large enough for the longest outage you expect at your data rate, and you should know what the gateway does when it fills: drop the oldest data or stop collecting. And the receiving side must accept late data with old timestamps; some dashboards and databases treat a reading as arriving when it is received rather than when it was taken. MQTT’s QoS levels help with delivery once the link is up, as the MQTT explainer describes, but they do not replace a local buffer.

How to choose an IoT gateway

Start from the devices and the site, not the gateway catalog.

1. Field interfaces. List every device it must talk to and how: RS-485 with Modbus RTU, Ethernet with Modbus TCP or a PLC protocol, Zigbee, Bluetooth LE, LoRa, digital or analog inputs. Count the serial ports and check whether they are isolated.
2. Protocol support in the software. A physical port is not enough. Check that the gateway’s software has drivers for the specific protocols and, for a PLC, the specific controller family, or that you can add them.
3. Uplink. Ethernet, Wi-Fi, cellular, or two of them with automatic failover. For cellular, check the bands and technologies against the carriers at the site.
4. Upstream protocols. MQTT with TLS is the common choice; check whether you also need OPC UA, HTTP, or a specific cloud platform’s connector, and how topics and payloads are formatted.
5. Buffering. How much local storage, how long that lasts at your data rate, and what happens when it is full.
6. Environment and power. Operating temperature, mounting (DIN rail, wall, pole), ingress protection for outdoor or wash-down areas, and supply (24 V DC in a cabinet, Power over Ethernet, mains).
7. Security. Secure boot, signed firmware updates, storage for keys or a TPM, a firewall, and how long the maker promises security updates. The firmware update article explains what to ask.
8. Management. How a fleet of gateways is monitored, configured and updated remotely, and whether that depends on the maker’s cloud service continuing to exist.
9. Openness. Whether you can run your own software on it, such as containers or Node-RED, or are limited to the maker’s configuration screens.

Common mistakes

Forgetting it is a single point of failure. Every device behind the gateway goes quiet when it does. Monitor it, keep a spare configured, and decide what the plant does if it stops.

Adding a second master to a bus. A Modbus RTU bus expects one master. Wiring a gateway onto a bus that a PLC or building management system already polls, without agreement from whoever owns it, causes collisions and intermittent faults. Read the values from the existing controller instead, as described in what a PLC is.

Polling too fast. Serial devices are slow. Asking every device for every register once a second can saturate a bus at 9,600 baud. Poll each value at the rate it actually changes.

Leaving the gateway on the office network. A gateway bridges the plant floor to an IP network, so it deserves the same separation as any other IoT device; the separate VLAN guide applies to plants as well as homes.

For where the gateway fits among sensors, controllers, brokers and dashboards, read what an industrial IoT system is made of, and browse the rest of the industrial IoT guides for the protocols on either side of it.