What is an IoT gateway?
An IoT gateway is a device that connects non-IP field equipment to a platform or cloud, and in doing so turns raw field data into structured, contextualised data. It carries its own connectivity – Ethernet, fibre or a cellular modem – and it runs a small operating system, which is what makes the translation and the local logic possible.
The formal definition is shorter than the confusion around it: the gateway is the boundary. Everything below it speaks a device protocol with no security model and no naming convention. Everything above it speaks a message protocol with authentication, topics and time stamps. Someone has to stand at that line, and that someone is the gateway.
Three layers, and what lives in each
| Layer | What lives there | The protocol it speaks | What it knows about the data |
|---|---|---|---|
| Device layer | Sensors, transmitters, meters, PLCs, RTUs, drives, cameras | 4-20 mA, thermocouple, Modbus RTU over RS-485, Modbus TCP, CAN, DI and DO | Everything. It is the measurement |
| Gateway layer | The gateway, and the protocol converter or edge computer beside it | Southbound the field protocols, northbound MQTT, HTTPS or OPC UA | Everything that matters: tag name, scale, unit, byte order, freshness |
| Cloud and platform layer | Broker, time-series database, dashboards, SCADA, EMS, billing | MQTT, HTTPS, OPC UA | Only what the gateway decided to send it |
Notice what is not in that table: the industrial switch. A managed switch is essential – it carries the uplink, forms the ring and isolates the segments – but it moves frames without reading values. On a typical site the gateway hangs off a managed industrial switch, and the switch in turn uplinks over fibre. The gateway translates; the switch transports. Keeping those two jobs separate is how you avoid buying a switch to solve a data problem.
The word already means something else
In TCP/IP, the “default gateway” is the address a host sends traffic to when the destination is not on its own subnet. That gateway is a router, and its job is entirely about addresses. This is why a network engineer who has never touched a PLC may reasonably tell you that a gateway and a router are the same thing. In industrial IoT the term was borrowed for a device that is not doing routing at all: it is doing application-layer translation.
The practical consequence is a specification problem. “We need a gateway” tells a supplier almost nothing. “We need to read 14 Modbus RTU meters on two RS-485 buses, buffer three days locally and publish change-of-value to an MQTT broker over 4G” tells them everything, and the box they quote for it is not the box they would quote for a cellular router.
Figure 1 — A fieldbus on the south side, a message protocol on the north side, and one layer that translates between them. The gateway is also the trust boundary, which is why the fieldbus stays on its own segment.
IoT gateway vs router: the three differences that matter
The two boxes can be the same size, the same shape, the same DIN rail and the same price band. The difference is what runs inside, and it shows up in exactly three places.
1. Protocol translation
A gateway reads a Modbus register, applies a scale factor and a byte order, gives the result a name and publishes it on a topic. A router cannot do any part of that, and it is not supposed to: it moves packets between networks and never opens the payload. This is why a router will happily carry an unauthenticated fieldbus protocol across your cellular link – it has no idea what it just forwarded.
What protocol coverage actually means in practice is worth being concrete about. A utility gateway has to read the protocols that the equipment in front of it already speaks – and those are not the protocols of consumer IoT. State-grid and energy-storage projects in particular run IEC 60870-5-101 and 104 telecontrol, IEC 61850 MMS toward station-level equipment, DNP3 in distribution, and metering protocols such as DL-T 645 on the electricity meter side. If a candidate gateway does not list the protocol your meter speaks, nothing else about it matters.
2. Edge processing
A gateway can decide not to send something. That is the whole value of local processing: thresholds, de-duplication, change-of-value reporting, and continuing to collect while the uplink is down. On a site with 400 tags polled every five seconds, publishing everything unconditionally is roughly 7 million messages a day; publishing only what changed is often two orders of magnitude less. A router has no opinion about any of this.
Where a device runs an open operating system, the same hardware can also carry your own logic – which is the honest boundary between “gateway” and “edge computer”. A gateway that runs embedded Linux and exposes a documented interface is a lightweight edge node; the moment you need containers, a local database or local analytics, you are in edge-computer territory and should specify it as such.
3. Device management
Devices are the gateway’s assets. That means a maintained tag map, firmware that can be updated remotely, a heartbeat that distinguishes “the value is zero” from “the device is gone”, and backfill for data collected while the link was down. None of it belongs to a router. In practice this is the difference an operations team feels at 2 a.m.: one architecture tells them which meter stopped answering, the other tells them the link is up.
| Question | Router | IoT gateway |
|---|---|---|
| Primary job | Forward IP packets between networks | Connect devices to systems, and read the data |
| Working layer | Network layer – addresses | Application layer – values |
| Field protocols | None | Modbus RTU and TCP, IEC 60870-5-101 and 104, IEC 61850 MMS, DNP3, CAN, metering protocols |
| Southbound physical | Ethernet or Wi-Fi | RS-232, RS-485, CAN, DI and DO, plus Ethernet |
| Northbound | The internet, over a VPN if configured | MQTT with TLS, HTTPS, OPC UA |
| Local buffering when the link drops | No – packets are dropped | Yes – store and forward, then backfill |
| Change-of-value reporting | Not applicable | Standard practice, and usually the setting that saves the bandwidth |
| Device identity on the network | Shared credential typical | Per-device certificate, which is the correct model |
| Can run your application | No | On Linux-based models, yes – this is where edge computing starts |
| Right answer when | The equipment already speaks IP and just needs to be online | The equipment does not speak IP, or the data has to reach a platform |
Figure 2 — The three differences, and the four roles they split into. Most site confusion disappears once the job is matched to the box rather than the label on the box.
When a router is the right answer
Buying a gateway to solve a connectivity problem is as common a mistake as buying a router to solve a data problem. A router is the correct and cheapest answer when the thing you need to reach already speaks IP: an IP camera, a switch, a controller with an Ethernet port and an HTTP interface, a small office network inside a plant. All of them need to be reachable over LTE or 5G, and none of them needs translation.
Because a capable gateway often contains a router, the two roles can collapse into one box – open Linux gateway with a cellular modem, doing protocol translation and carrying the wide-area link. That is usually the economical choice on a remote site. Keep them separate when network management and data handling are owned by different teams, when you need a vendor-certified router in front of a regulated control network, or when the gateway must be replaced without touching the route to the internet.
| Role | What it is for | Use it when | Do not use it when |
|---|---|---|---|
| Router (industrial cellular) | Move IP traffic between networks, carry the WAN link, run the VPN and the firewall | The device already speaks IP and only has to be reachable | The device speaks Modbus, CAN or a serial protocol – a router will forward it without ever checking it |
| Protocol gateway (converter) | Make one protocol speak another: Modbus RTU to Modbus TCP, serial to fibre, fieldbus to MQTT | Two systems on site must exchange data and neither will change | You also need the wide-area link and the tag model – that is a gateway, not a converter |
| IoT gateway | Poll field devices, model the tags, buffer, and publish northbound | Sensor, PLC or meter data has to reach a platform, a broker, SCADA or a billing system | The equipment is already IP-native and no data transformation is required |
| Edge computer | Run real applications locally: containers, a local database, analytics, closed-loop control | The logic is too heavy for a gateway, or the site must keep working with no link at all | A tag map and a publish path are all you need – you would be paying for compute you never use |
One more case is worth naming, because it is common in the security and infrastructure projects running across Southeast Asia, the Middle East and Latin America: a camera or access-control network that already speaks IP and needs nothing translated, but sits 3 km from the nearest fibre. That is a transport problem, not a gateway problem. It is solved with an industrial fibre media converter or a short fibre run, and a router only if the site needs its own cellular uplink. The security and protection solution is laid out this way.
What a Modbus-to-MQTT gateway actually does
This is the single most requested gateway function, and the one most often described as if it were a cable. It is not a cable. Five things happen in sequence, and each one has a detail that decides whether the project works.
| Step | What happens | The detail that decides success |
|---|---|---|
| 1. Poll | The gateway is the Modbus master. It issues read requests on a schedule and receives raw register values | RS-485 is half duplex: one request is on the bus at a time. Group registers by device so one request reads twenty consecutive values, and make sure a dead device cannot stall the bus – timeout at 200 to 500 ms, retry twice, then move on |
| 2. Normalise | Raw 16-bit registers become engineering values with names, units and time stamps | Byte and word order. A 32-bit float split across two registers can arrive as ABCD, CDAB, BADC or DCBA, and the Modbus specification does not pin it down. This is per device model, and it is the most common cause of a “working” link reading nonsense |
| 3. Buffer | Samples are appended to local storage whether the uplink is up or not | Size the buffer for the realistic worst-case outage at the real sample rate, and time-stamp each sample at capture, not at transmission – otherwise backfilled data lands at the wrong point on the chart |
| 4. Publish | Values go out as MQTT payloads on mapped topics, or as OPC UA nodes | Report by exception with a deadband, rather than publishing everything every cycle. Keep the poll rate and the publish rate as two separate numbers |
| 5. Commands down | The gateway subscribes to command topics and writes the value back into a register with function code 06 or 16 | Separate command topics from data topics, so a setpoint can never be mistaken for a reading, and publish commands at QoS 1 rather than 0 – a dropped telemetry sample is a gap, a dropped setpoint is a fault |
Four MQTT mechanics an operations team will ask about
· QoS. QoS 0 for high-rate telemetry that will be replaced in a second; QoS 1 for events and for anything a person has to act on. Choose by the cost of losing the message, not by habit.
· Retained messages. Publishing each value with the retain flag leaves the broker holding the last known value, so a dashboard that connects later shows the current state instead of an empty panel.
· Last will and testament. The gateway registers a will message on a status topic. If it dies or loses the link, the broker publishes it, and consumers can tell “the value is zero” from “the gateway is gone”. A polled protocol cannot express that distinction on its own.
· Certificates. One identity per device, not one password for the fleet. Sharing a credential to save time turns a single leaked unit into a site-wide replacement.
Where this pays off: water, power and city infrastructure
The three application families below share a shape: field equipment that predates IP, a site that is often unattended, and a platform that needs reliable history rather than instant perfection. What changes between them is the protocol set and what “unattended” means for the hardware.
Water and utilities
Pump stations, reservoirs, pressure-reducing valves, flow meters and energy meters are the classic gateway case. Level and pressure often arrive as 4-20 mA loops; flow and energy meters usually sit on an RS-485 bus speaking Modbus RTU, sometimes with the meter protocol of the local utility. The platform wants trends and alarms, and the regulator or the finance department wants the history to have no holes – which is exactly what the local buffer is for. On a remote site with no fibre, the uplink is cellular, and the specification that matters is wide input voltage because the supply is often a battery or a small solar array.
Power and energy storage
This is where protocol coverage stops being an abstract question. Substation and storage sites run IEC 60870-5-101 and 104 telecontrol, IEC 61850 MMS toward station equipment, DNP3 in distribution, and DL-T 645 on the electricity meter side. Our published design for an energy storage station uses the wsCom/TX-2T-16C communication manager for direct IEC 61850 communication between the station control layer, the PCS and the BMS, with televiewing, telemetering, remote control, remote regulation and remote signalling processed and then carried on the industrial Ethernet or uploaded over 4G or 5G. That architecture is described on the energy storage solution page, and the same design family is behind the national power grid solution.
Two hardware requirements follow from the site rather than the protocol list. First, isolation and surge protection: an RS-485 line running between buildings picks up transients, and the standard protective practice is an isolated transceiver plus surge protection at the entry point. Second, wide temperature with no fan – a cabinet on a substation platform sees sun, frost and dust, and a moving part is the first thing to fail.
City infrastructure
Utility tunnels, pipe galleries and street infrastructure combine several of the earlier cases in one contract. A gallery monitoring system collects wind speed, air pressure, hazardous gas concentration, structural health data and fire early warning across tens of cabinets; lighting control, access control and CCTV share the route. The pattern that works is one gateway or converter per zone, feeding a redundant ring back to the monitoring centre, with cellular as the fallback for the sections where nobody wants to dig. The underground pipe gallery solution and the intelligent manufacturing solution describe the ring and monitoring layers in more detail.
| Application | On the southbound side | Protocols the gateway must read | What to specify first |
|---|---|---|---|
| Water pumping and distribution | Level and pressure transmitters, flow meters, energy meters, pump status | Modbus RTU, Modbus TCP, pulse and 4-20 mA inputs | Isolated RS-485 inputs, local buffer sized for the worst outage, wide DC input |
| Substation and energy storage | Protection and measurement units, PCS, BMS, electricity meters | IEC 61850 MMS, IEC 60870-5-101 and 104, DNP3, DL-T 645 | Protocol list in writing, and the exact model that covers it |
| Utility tunnel and pipe gallery | Gas, wind, pressure and structural sensors, fire alarm panels, cameras | Modbus RTU or TCP, dry contacts, digital inputs for alarm circuits | Zone-based architecture, ring topology, per-device certificate management |
| Street infrastructure and security | Lighting controllers, access control, cameras, intercoms | Modbus, dry contacts, and IP for anything already native | Whether translation is needed at all – if not, a converter or a router is the cheaper answer |
What to ask a supplier before you buy
The failure mode in this product category is not a bad box. It is a box that is technically fine and cannot read the one protocol, or reach the one temperature, that the site needs. Six questions separate the two.
| Question | What a good answer looks like | What should make you slow down |
|---|---|---|
| Which field protocols does it read, and which does it publish? | A named list, including the utility protocols if the site is a substation or a meter network | “It supports all protocols” with no list, or a list that omits the protocol your meter uses |
| How much data can it buffer, and for how long? | A figure in samples or days at a stated sample rate, with time-stamping at capture | “It stores the data” with no number, or a buffer that only fills while the link is up |
| Can it report by exception, with a deadband per tag? | Yes, configurable per tag – this is what makes a cellular tariff survivable | Publish-everything-every-cycle and no deadband setting |
| How is it secured northbound | TLS 1.2 or higher with one certificate per device, and a documented way to rotate it | A shared password, or plain 1883 with no TLS option |
| What is the temperature range, and is it fanless? | Stated operating range, natural convection cooling, IP-rated metal housing for outdoor cabinets | A temperature range quoted for the office model, or a fan in an unattended cabinet |
| What happens when the device model or firmware changes? | A documented way to edit the register map on site, and support for updating it after a firmware revision | Register maps that only the vendor can change, and no answer about firmware drift |
The Winsure range, by role
We build all three boxes, which is why the roles can be kept distinct instead of forced into one product. The gateway line is the wsCom/TX family; the serial-to-Ethernet bridge line is the wsCom/3CK family; the cellular line is the 4GYL and 5GYL routers.
| Role | Models | Ports and protocol coverage | Environment |
|---|---|---|---|
| IoT gateway (protocol translation and northbound publishing) | wsCom/TX-2T-4CwsCom/TX-2T-8CwsCom/TX-6T-16C | 2 to 4 Ethernet ports plus 4, 8 or 16 RS-232 or RS-485 serial ports, digital inputs and outputs, and 2 CAN 2.0B channels on the 16-port model. Published protocol set: OPC UA client and server, Modbus, IEC 101 to 104 telecontrol, IEC 61850 MMS client and server, CDT, DNP3.0, DL-T 645, GB103, SC1801 | IP40 metal housing, fanless, -40 to +85 C, MTBF 100,000 hours; DIN-rail for the two smaller models, 19-inch rack for the 16-port model |
| Protocol converter (serial to Ethernet, Modbus TCP to RTU) | wsCom/3CK-1T-4CwsCom/3CK-2T-16R | 1 or 2 Ethernet ports with 4, 8, 16 or 32 serial ports; Modbus TCP to RTU conversion, virtual serial port, Modbus TCP client and server; MQTT and SNMP on the high-density model; per-channel DIP switches for bias and 120 ohm termination | IP40 metal housing, fanless, -40 to +85 C, MTBF 100,000 hours; IEC 61000-4-5 level 3 surge protection and reverse polarity protection |
| Industrial cellular router (the WAN link, VPN and firewall) | wsCom/4GYL-1C-1WDwsCom/5GYL-1C-4L | 4G and 5G models, two or four Ethernet ports with WAN and LAN auto-sensing, one RS-232 or RS-485 port, Wi-Fi, SIM slot, VPN client and port mapping; optional GNSS with RTK | IP40 metal housing, DIN-rail or wall mounting, -40 to +85 C, MTBF 100,000 hours, 0.3 kg |
Send us the point list and the site conditions – device models, protocols, tag count, sample interval, the uplink you have, the temperature and the supply – and an engineer will come back with the role that fits, the model, and a written quote within 24 hours. If you are choosing the transport layer at the same time, the industrial switch that most deployments put between the gateway and the fibre is the wsCom3010G-2GSFP-8G/DC-INT, and for larger rings the wsCom3028G-4GSFP-8G/DC-INT; where a longer run needs a converter at each end, the wsCom3010-2GST-8G/DC-INT takes pluggable SFP modules. Winsure has been building industrial communication hardware since 2016 as part of the Hansun group, with ISO 9001, ISO 14001 and ISO 45001 covering the factory and every unit tested before it ships.
Frequently asked questions
1.What is an IoT gateway in one sentence?
A device that connects non-IP field equipment to a platform or cloud by reading the field protocol on one side and publishing structured data – typically MQTT, HTTPS or OPC UA – on the other, while carrying its own Ethernet or cellular connectivity.
2.What is the difference between an IoT gateway and a router?
A router moves IP packets between networks and never reads the payload. A gateway reads registers and values, scales them into engineering units, buffers them when the link is down and publishes them upward. A router is the right answer when the equipment already speaks IP; a gateway is the right answer when it does not, or when the data has to reach a platform.
3.Do I need both a router and a gateway?
Often not. Most capable gateways contain a router, so one box can carry the wide-area link and do the translation. Keep them separate when network management and data handling belong to different teams, when a certified router has to sit in front of a regulated control network, or when the gateway should be replaceable without touching the route to the internet.
4.What does a Modbus to MQTT gateway actually do?
It polls Modbus registers as the master, converts raw 16-bit values into engineering units with tag names and time stamps, buffers samples locally when the uplink drops, publishes them on MQTT topics – usually only when a value changes – and subscribes to command topics so a setpoint can be written back into a register. It is a master, a translator and a client in one device, not a transparent pipe.
5.When does a gateway become an edge computer?
When the logic no longer fits in a tag map. Reporting by exception, thresholds and local buffering belong to a gateway. Containers, a local database, local analytics or closed-loop control belong to an edge computer, or to a gateway that runs an open operating system and is specified to host your application.
6.Is it safe to expose a Modbus device to the internet?
No, and the question usually means the design is missing its gateway. Modbus RTU and Modbus TCP have no authentication and no encryption, so the fieldbus must stay on its own segment and the only route out should be an authenticated, encrypted link from the gateway – TLS with a separate certificate per device.