What Is a Multi-Protocol IoT Gateway?

If you enter a typical industrial facility, you'll see the same level of confusion always: a meter that communicates in Modbus, a SCADA panel running on a protocol that no one has modified since it was put in place, a collection of LoRa sensors in the yard, and a cloud dashboard that wouldn't want any of this data in its raw form. This is not a plan that anyone had in mind. 

It is important to understand the real role of a Multi-Protocol IoT gateway correctly before purchasing, since a simple two-protocol bridge and a genuine edge gateway would seem to be remarkably close on a spec sheet, but are quite different once installed on a live site.

Key Insights

A multi-protocol gateway does not mean a gateway with as many ports as possible, but a gateway which supports several native protocols. 

There must be a bridge between the southbound side (LoRa, Modbus TCP, GPS, Wi-Fi, cellular, digital/analog I/O) and the northbound side (cloud platforms, EMS, analytics, alerting) of the system without forcing either side to adapt to the other. 

The difference between a pass-through switch and a real gateway is the implementation of edge intelligence: aggregation, filtering, local decision-making, store-and-forward, in the protocol checklist, and it is the part that buyers don't pay as much attention to as they should. 

The clear-cut deployments all have one thing in common: legacy equipment, extreme environments, and high cost of downtime, so it's no surprise that smart grid/AMI, industrial IIoT and remote asset monitoring continue to be the biggest use cases. 

One of the least advertised specs, and one of the most significant if a network really fails in the field, is connectivity loss handling, either by buffering and forwarding, or just dropping data.

Functions of a Multi-Protocol IoT Gateway

A multi-protocol IoT gateway performs three functions: It connects with the field devices in their native language and helps to interpret the data at the gateway; it cleans the data and sends the sanitised version to the next system in the chain.

On the field side (typically the southbound interface) that involves smart meters, temperature sensors, flow meters, PLCs, SCADA terminals and LoRa-based sensors, often all within the same site. At the enterprise level, the gateway needs to send that data north to a cloud platform, an EMS or historian, an analytics dashboard, or straight into an alerting system, without all downstream systems having to learn the six different dialects.

The protocols in between are typically a mix of LoRa, Modbus TCP, GPS, Wi-Fi, cellular (4G/5G), and digital or analog I/O, and none of these was designed to communicate with each other. It is because of this boundary that the gateway was created, so it can absorb the translation work that no one else wants to deal with.

Why Multi-Protocol is NOT Multi-Device

There are many gateways to connect with many devices. That is not difficult; it's just more ports! But there are only a few who are fluent in many protocols, and this is where the rubber meets the road. If the gateway can only speak Modbus, then all non-Modbus devices on site must have their own translator box before the data can even be passed to the gateway. That's not integration. This is another layer of hardware over the original issue.
That complexity is swallowed up by a proper multi-protocol gateway, not pushed downstream by one device on the edge that understands what protocols it needs to support, not the ones a vendor would like everyone to support.

A place for the part every buyer ignores: Edge Intelligence.

It's easy to print, and it's connectivity that is getting all the attention; six protocol icons and done. More importantly, it's what's happening to the data before it exits the device that really determines whether or not a gateway becomes useful in a year. That work is usually executed on a dual-core processor at the edge and usually does a couple of things:

Data aggregation: If one packet aggregates a thousand small ones, then the gateway doesn't have to send a thousand. Protocol translation, making a Modbus or LoRa payload work for a cloud platform without having to write a custom parser specifically for it. Edge filtering of obviously bad or out-of-range readings, rather than sending them as pollution on the dashboard 3 systems downstream. Event processing, for situations where a threshold is breached and an action should take place immediately, rather than on the next batch upload. Local decision-making and secure data routing: In case the connection to the cloud fails, the gateway can still flip a relay or trigger an alert. 

Store-and-forward: Data compression, so that when the network is down, readings are not lost; the gateway stores them in offline mode and transmits them when the network is back up.

A switch moves bytes around. A gateway that has real edge intelligence determines what those bytes are, and then it determines what to do with them. That's the only difference, and typically, one only notices it when the network fails.

Use Cases for Multi - Protocol Gateways

The cleanest example in which the multi-protocol gateways can be deployed is probably the smart grid and AMI. The reason why utilities deploy smart meters over such vast geographical areas is not that they need Wi-Fi, but because they require another route of communication that's low-power, resilient, and can reach far distances. This gateway needs to connect this mesh network back to a cloud platform or EMS, and in areas where fixed-line connectivity cannot reach, it must provide GPS for asset location and cellular as a backhaul.

Industrial IIoT is the second big use case. PLCs and SCADA systems that were never designed with cloud in mind are suddenly required to provide data to a predictive maintenance model or analytics dashboard. The gateway is typically the only reasonable solution to extract that information without dismantling machines that are still functional.

Remote asset monitoring is the third. Agricultural applications, remote substations or pipelines, where running new cabling is not really a possibility, depend on LoRa or cellular, which are applications without limits on wired infrastructure.

Before purchasing, make sure you thoroughly review the following:

What protocols does the gateway support natively, compared to those that require an add-on module, which must be purchased separately? 

Why is processing needed at the edge, and is “edge intelligence” something that happens on a slide or not? 

What is done when connectivity is lost - buffered and forwarded back on restore or lost data? 

Does it have the correct rating for the environment it is being installed in, as most industrial sites are hot, dusty and cruel to consumer-grade hardware?

And how is data protected during transport, to the field devices, and to the cloud, because a gateway positioned between dozens of field devices and your enterprise systems is just the type of single point that needs to be locked down correctly.

This is important not just for the hardware, but for everything.

Conclusion

For years, industrial data has been trapped inside silos; one protocol per vendor, one dashboard per system, one engineer who, by chance, knows how the old SCADA terminal communicates with anything at all. No, a multi-protocol gateway does not remove the incompatible standards. It simply refuses to let that mess get in the way of your data.

When considering gateways for a smart grid, AMI or industrial IoT implementation, the question that should be asked is not how many protocol logos are littered across the spec sheet. Whether it can fit on the edge, whether it can fluently communicate with what's already on site, has some autonomy to make some decisions when the network drops, and give whatever's waiting at the other end something actually useful to work with.

FAQs

What's the difference between a multi-protocol gateway and a regular IoT gateway? 
A typical gateway will support one or two protocols and will expect the other devices on your network to conform to those protocols. A multi-protocol gateway is designed to be a native speaker of multiple protocols, such as LoRa, Modbus TCP, Wi-Fi, cellular, GPS, digital/analog I/O, etc., so it can be located on a mixed site without requiring additional translator boxes for any devices that do not share its native protocol.

 

Is it sufficient to connect, or do we need to add edge intelligence? 
Connectivity is only a means of transporting data from one location to another. Before that data travels anywhere, an edge intelligence system determines what it is and filters out bad readings, aggregates packets, and activates local alerts. Edge processing is not a luxury in a network that is subject to downtime, or if you're charged by the volume of cellular data traffic.

 

What if the gateway is unable to connect to the cloud? 
This depends on whether the gateway is a store-and-forward gateway. If the link comes back, a buffer is installed on a gateway that will hold readings locally in an offline mode and broadcast them once the link is restored, with no loss of readings. Without it, a gateway just loses what happened during the outage, and that's a big deal if there's a metering, compliance, or safety-monitoring application where a loss of data isn't an option.

 

Why is the use of the Wi-SUN FAN gateways for smart grid and AMI deployments so particular? 
Utility meters are deployed in large areas of geography and sometimes in locations without reliable Wi-Fi or wired connections. The protocol Wi-SUN FAN is created just for that: long range, low power, and resilience in case of the failure of one node. A gateway that is used for this use case will usually be a combination of a Wi-SUN node and a border router connected between the mesh network and the cloud platform / EMS.

 

Is it possible to have a multi-protocol gateway, rather than an existing SCADA or PLC? 
No, and that's not its job. The gateway sits alongside existing SCADA and PLC systems, and extracts data from them into a cloud platform and analytics tools in a compatible format. It's not a replacement; that's why it is a viable solution for sites that can't afford to replace the equipment that continues to work.