Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat Today
If you've inherited a network where the new equipment won't talk to the old equipment, and neither one reports cleanly to a single screen, you already understand the problem protocol mediation solves. Protocol mediation is the job of translating data from one communication protocol into another, so that devices and management systems that "speak" different protocols can still exchange information. In plain terms, it's a real-time interpreter that sits between your field gear and your master station and lets them understand each other.
We've been doing this work at DPS Telecom for nearly 40 years. Across the more than 172,000 devices we've built, the request that comes back to us again and again is the same one. Bring a pile of mismatched, multi-vendor equipment under a single monitoring umbrella, and don't rip any of it out. That's what mediation makes possible.
A protocol is the language a device uses to communicate. SNMP (Simple Network Management Protocol), DNP3 (Distributed Network Protocol 3), Modbus, and TL1 (Transaction Language 1) are all common ones, and each structures its data differently. In our book 100% Uptime, our co-founder and Chief Executive Officer Bob Berry writes that protocols are "languages" that devices use to communicate with each other.
A typical network carries equipment from several generations, and that equipment rarely shares one language. That happens for a few reasons.
What you end up with is a fragmented monitoring picture, and fragmented systems build confusion and drive up costs. Plenty of field equipment can't help you here either. Contact closure alarms, serial devices, older Remote Telemetry Units (RTUs), and any number of other older technologies have no native modern protocol support at all, so they can't report to an SNMP manager on their own.
Protocol mediation translates and normalizes data so that incompatible systems can work together. A device speaking Modbus and a manager expecting SNMP have no common ground until something in the middle maps one to the other and re-presents the data in a form the receiving system can read.
The idea is old enough to be written into formal standards. The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) describes a mediation function that acts on information passing between network elements and the systems that manage them. That function can store, adapt, filter, and convert the information along the way.
In everyday use, you'll hear a few different terms for roughly the same idea.
People use these terms interchangeably, and that's fine. When we talk about them internally, we tend to separate them by scale. A "gateway" suggests a centralized, multi-protocol role, while a "converter" usually handles one specific translation at a single site.
A mediation device sits between your existing field equipment and your management system, and it works in three steps.
Timing matters underneath all of that. With polling, the master asks each device for its current values on a schedule. With unsolicited, or trap-based, reporting, the device speaks up on its own the moment something changes.
A mediation platform also plays two roles at once. To the equipment below it, it acts as a master, gathering data in each device's own language. To the master above it, it presents itself as a single agent forwarding standard SNMP. That collection can happen out at the remote site or back at the master station, depending on how you design the system.
The protocols below were built for completely different worlds, which is exactly why they can't understand each other on their own. SNMP grew out of Information Technology (IT) network management. DNP3 and Modbus came from industrial and utility Supervisory Control and Data Acquisition (SCADA) systems. The table compares the three you're most likely to run into together.
| Attribute | SNMP | DNP3 | Modbus |
|---|---|---|---|
| Primary domain | IT and network management | Electric and water utility SCADA | Industrial automation |
| Communication model | Manager and agent | Master and outstation | Master and slave |
| Unsolicited reporting | Yes (traps) | Yes (report by exception) | No (poll only) |
| Timestamps and events | Limited | Yes | No |
| Data structure | Management Information Base, OID | Object groups | Registers and coils |
| Standards body | Internet Engineering Task Force (IETF) | Institute of Electrical and Electronics Engineers (IEEE) | Modbus Organization |
| Origin year | 1990 | 1990 to 1993 | 1979 |
SNMP was first defined in 1990 by request for comments (RFC) 1157, one of the documents that set internet standards, and it now runs in three versions, with SNMPv3 adding authentication and encryption. DNP3 and Modbus were designed for something else entirely, namely field telemetry over noisy, wide-area links. If you want a closer look at where those two diverge, our breakdown of DNP3 versus Modbus covers the differences in detail. Alongside these, you'll also run into TL1 in optical telecom networks, plus plain contact closures and proprietary serial outputs from older gear.
A lot of the installed base is genuinely old. Federal energy data shows that 70% of U.S. power transformers are 25 years or older, and the broader picture across industrial control systems is that many older devices and protocols still lack encryption or authentication entirely. Ripping out field equipment that still works is expensive and slow, so most of it stays where it is. Translating its data is usually the smarter path.
Dominion had this problem at scale. Their monitoring equipment was spread across 150 sites in a seven-state coverage area, with several different types of remotes from Badger, Larse, and NEC. Because the existing remotes used different communications methods, Dominion was maintaining multiple master stations and wanted a way to bring the systems together without replacing its installed equipment.
We designed a monitoring system around the remotes Dominion already had instead of a forklift replacement. A T/Mon master station collected and mediated the Badger, Larse, and NEC remotes into one platform, with a path to add native Internet Protocol (IP) remotes over time. Their lead telecommunications technician, Dan Jackson, described it this way.
"The thing I liked was that DPS was going to make it fit our needs. They weren't going to try to make our stuff fit their stuff. They were going to make their stuff fit ours."
Every existing remote stayed in place. Dominion used T/Mon to bring three incompatible alarm systems into a single platform that could grow with whatever they needed next.
Inside DPS, mediation happens at two levels. At the master station, our T/Mon LNX supports more than 25 protocols, including SNMP, DNP3, Modbus, TL1, and American Standard Code for Information Interchange (ASCII). That list grew over the years as clients brought us equipment they needed to integrate. Older RTUs and proprietary equipment report to T/Mon in their own languages, T/Mon normalizes all of it, and it forwards alarms upstream as SNMP to any standard SNMP manager. Many inputs feeding one consistent view is what multiprotocol alarm aggregation means in practice.
Out at the remote site, our NetGuardian RTUs can convert non-SNMP equipment to SNMP. They accept discrete alarms, analog inputs, and serial data, then report via SNMP v1, v2c, and v3. For sites built around Modbus gear like generators and intelligent power equipment, a dedicated Modbus to SNMP converter reads the registers and presents them as SNMP objects your manager can read.
Mediation extends the useful life of equipment you already own. When your existing gear still works reliably, integrating it usually gives you a better return than replacing it, and it lets you move to modern monitoring gradually, as budget allows.
They overlap, and people use the two words interchangeably. Conversion usually refers to the specific step of translating one protocol into another. Mediation is the broader function that can also filter, condense, and normalize data from a lot of different sources at once.
Usually not. If your field equipment still works, mediation can translate its data into a modern protocol so it reports to a current management system. That saves you the cost and downtime of a full replacement.
Either one. An RTU at the remote site can convert local non-SNMP inputs into SNMP, and a master station can mediate many protocols at once and forward a single, unified stream upstream.
With polling, the master asks each device for its values on a schedule. With unsolicited reporting, the device sends an alert on its own the moment something changes. Our explainer on SNMP poll versus trap breaks down how each one behaves.
It depends on the platform. T/Mon supports more than 25 protocols today, and that number only grew because clients kept bringing us equipment they wanted integrated rather than discarded.
If you're staring at a mix of SNMP, DNP3, Modbus, proprietary gear, and who knows what else that won't report to one screen, you really only need to tell us what you're trying to accomplish. We'll work with you to map out what mediation looks like across your specific sites. You can also email us at sales@dpstele.com.
Talk to an Engineer | 800-693-0351
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 19 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
