IP & Non-IP Protocols in Industrial IoT
Why rural and industrial IoT deployments often need a gateway layer that speaks both IP and non-IP protocols, and how to design one.
Most IoT tutorials assume every device can reach the internet directly over Wi-Fi or LTE. In practice, industrial and rural deployments rarely look like that. A sensor bolted onto machinery in a plantation or a remote facility often has no cellular signal, no Ethernet drop, and no budget for satellite links.
The connectivity gap
When standard IP connectivity isn't available, the usual options are:
- Long-range radio (LoRa, licensed VHF/UHF, or even handy-talky-based links) for low-bandwidth telemetry over long distances.
- Mesh networking between nearby nodes to relay data back to a point with better connectivity.
- Store-and-forward patterns, where a device buffers data locally until connectivity is intermittently available.
None of these are "just TCP/IP." They're non-IP or IP-adjacent transports that need translation before the data is useful to a cloud platform.
Where the gateway fits
An IoT gateway's job in this setup is translation, not just relaying:
- Ingest — receive readings over the non-IP transport (radio, mesh, serial).
- Normalize — convert vendor- or protocol-specific payloads into a consistent schema.
- Publish — forward normalized data upstream over MQTT once IP connectivity is available, buffering locally when it isn't.
[Field Sensor] --(non-IP radio link)--> [IoT Gateway] --(MQTT over IP)--> [Cloud Platform]This pattern is what makes it possible to treat a plantation full of radio-connected sensors the same way you'd treat a rack of Wi-Fi-connected ones from the cloud platform's perspective — the gateway absorbs the messiness underneath.
Design considerations
- Buffering strategy matters more than throughput. A gateway that loses data during a connectivity gap is worse than a slow one.
- Protocol versioning should live at the gateway, not the sensor firmware, since gateways are easier to update in the field.
- Backpressure: cloud platforms should tolerate bursts of buffered data arriving all at once when connectivity returns.
None of this is exotic engineering — it's mostly about accepting that "always connected" is a design assumption, not a given, and building the gateway layer accordingly.