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 your network has been built out over a couple of decades, your monitoring probably didn't arrive all at once. A microwave site here, a batch of generators there, an optical ring from one project and a set of substation gear from another. Each piece came with its own way of reporting alarms, and somewhere along the way you ended up watching several monitoring systems instead of one.
Protocol mediation is a translation layer that converts alarm and telemetry data from one monitoring protocol into another, so equipment that speaks different, incompatible protocols can all report into a single system. Protocols are the languages your equipment uses to report status, and a mediation device takes alarms coming in on one language, maps them to another, and forwards them so gear that could never talk to each other before shows up on the same screen. The practical payoff is that you keep the equipment that still works, you escape the vendor lock-in that comes with proprietary protocols, and you control your own upgrade timeline instead of a manufacturer controlling it for you.
At DPS Telecom, protocol mediation has been part of how we build monitoring since 1986, and we've shipped more than 172,800 devices into the field over that time. We build it at both ends of the network, on the remote-site hardware and on the central master, and our T/Mon platform now supports more than 30 protocols, most of which we added because a client asked us to. This guide walks through what mediation is, when you need it, and how to choose a solution you won't outgrow.
Every alarm message has two parts. There's a header that says where the message came from and how to route it, and a payload that carries the actual status, which includes things like a door contact that opened, a rectifier that dropped, or a fuel level that fell below a threshold. A protocol is the agreed-on format for arranging those parts. Simple Network Management Protocol (SNMP) formats them one way. Distributed Network Protocol 3 (DNP3), Modbus, and Transaction Language 1 (TL1) each format them differently.
A mediation device reads a message in one protocol, pulls the alarm points out of the payload, and rebuilds them in the format a second protocol expects. It knows which point maps to which because you tell it once, in the device's database. After that, a contact closure on an older generator panel can arrive at your Network Operations Center (NOC) as a clean SNMP trap, tagged with exactly what it means.
Bringing those different languages into one system is the whole point of mediation.
When your gear can't all report to one place, you end up running two or more monitoring systems side by side. That splits your technicians' attention across different screens, different alarm logic, and different ways of describing the same event. When something fails at 2 a.m., the odds of a real alarm getting lost in the shuffle can go up.
It gets harder during a big event. A single failure at a core site can set off a cascade of downstream alarms as everything that depends on it loses its connection. If those alarms are scattered across separate systems that don't talk to each other, your team is left correlating them by hand while the clock runs. That time is expensive. Research from Cisco and Splunk put the average cost of enterprise downtime at $15,000 per minute in 2026.
Proprietary protocols make the problem stickier. In 100% Uptime, DPS co-founder Bob Berry writes, "Fractured systems are a great way to build confusion and drive up costs." As he explains, "Many manufacturers also develop their own protocols as a way of 'encouraging' you to buy from them exclusively." Mediation is what breaks that hold.
When a network gets messy, one common response is a forklift upgrade, meaning you pull out the working gear and replace it with new equipment that all speaks the same protocol natively. It's clean on paper. In practice it can mean paying twice, once for the new hardware and again for the labor to remove the old equipment, rewire, reprogram, and cut everything over, typically inside a maintenance window that takes planning and coordination to get right.
Mediation takes the other path. You leave the field wiring in place and add a translation layer, so equipment that still does its job keeps doing it. The upfront cost is usually lower, there's less to coordinate, and you decide when older gear comes out.
| Consideration | Forklift Upgrade | Protocol Mediation |
|---|---|---|
| Up-front hardware cost | New Remote Telemetry Units (RTUs), sensors, cabling, and master licenses | A remote-site gateway or a central master, and little else |
| Installation labor | Rewiring, re-terminating, reprogramming, and drafting a new topology | Database configuration, with field wiring left in place |
| Operational impact | A cutover window and dependency mapping before go-live | Runs alongside the current system, so a fallback stays available |
| Timeline control | Set by the project schedule | Set by you, with older gear coming out when it's ready |
Mediation can happen in two places, and a well-built network often uses both.
At the site itself, the mediator is usually an RTU acting as a smart gateway. A lot of the equipment you need to watch doesn't speak a network protocol at all. Standby generators, batteries and rectifiers, uninterruptible power supply (UPS) systems, and heating, ventilation, and air conditioning (HVAC) units often signal through analog voltages or dry contact closures, where a relay opens or closes to say "door open" or "power lost."
Our NetGuardian RTUs sense those physical signals and turn them into SNMP traps that any standard SNMP manager can read. The same class of device can take in older serial data, whether that's Telemetry Byte-Oriented Serial (TBOS), Telemetry Asynchronous Block Serial (TABS), TL1, or any number of other serial formats, and forward it over your Ethernet network. That last part quietly saves money, because it lets you retire the dedicated serial circuits those formats used to require. Where the job is purely translation, a NetMediator is purpose-built to do it. Our page on converting contact closures and serial data to SNMP covers the discrete and analog side in more detail.
At the core, the mediator is your master station. Our T/Mon alarm master collects alarms from many different equipment types and protocols at once, including SNMP, DNP3, Modbus, TL1, and American Standard Code for Information Interchange (ASCII) text, normalizes them into one common format, and presents them as a single standing alarm list.
From there it can forward alarms in whatever protocol your existing masters already use. Bringing many protocols in and sending one clear picture out is the core of multiprotocol alarm aggregation.
That forwarding works in both directions, which matters more than it sounds. If the master you already own doesn't speak SNMP, you don't have to replace it. T/Mon can take SNMP traps from newer gear and hand them to that master in the protocol it expects. Mediating into the master is almost always cheaper and less disruptive than swapping the master out.
Mediation runs in more than one direction. Most often it's bringing older or proprietary gear up to SNMP, but it works the other way too, from SNMP out to another protocol, and it can even move you from older SNMP to newer SNMP. Translating SNMP version 1 or version 2c traps into SNMP version 3 adds authentication and encryption to alarm traffic that didn't have it, which can help you meet stricter security requirements without touching the field sensors.
Modbus to SNMP is a good example of the translation work involved. Modbus only speaks when spoken to, so a master has to poll a device to get a reading. SNMP works the opposite way, built around devices pushing alerts on their own when something changes. To bridge them, the mediator polls the Modbus device on a schedule, watches the values against thresholds you set, and fires an SNMP trap only when a value actually crosses a line. You get the alert without flooding the network with constant polling traffic. Our Modbus to SNMP converter handles exactly this, and if you're deciding which device on your site to convert first, our guide to choosing the right Modbus device for SNMP conversion covers the key decision points. Modbus and DNP3 come up together often enough that our DNP3 vs Modbus comparison sorts out where each one fits.
The inputs a mediation device can take in cover most of what sits at a remote site:
Once those inputs are translated, equipment that used to sit in a blind spot shows up on the same screen as everything else. Standby generators, batteries and rectifiers, UPS systems, HVAC and cooling equipment, and door and environmental sensors all become things you can actually watch. Anything that keeps your revenue-generating equipment online becomes visible.
Mediation pays off over time because it separates your field hardware from your management software. Once a mediator is in place, you can modernize in stages instead of all at once.
You stand the mediator up next to your current system and let it translate live alarms into the new format, so you can check everything against a working reference before you trust it. Then you move regions or equipment types over in waves.
Because the old path is still there, a surprise means an easy rollback rather than an outage. Older gear comes out only when it genuinely fails or when normal network expansion makes replacing it the sensible move, not because a protocol went out of style. When a unit really has reached the end of its service life, our guide to finding a compatible replacement for a discontinued RTU can help you match it to a current equivalent.
A few things separate a mediation solution you'll grow into from one you'll fight with:
For central-office equipment, it's also worth looking for Network Equipment-Building System (NEBS) compliance, which tells you the hardware has been tested to survive the physical conditions of a telecom central office.
Mediation can mean selling less new hardware, so a vendor whose business is built around replacement cycles has less reason to lead with it. We've built our business the other way. We would rather keep your equipment running and earn the next project than sell you a replacement you don't need, and that has been our approach from the start. It's why mediation is something we design toward rather than around.
Our clients tend to take that path too. Dominion used T/Mon to bring three separate legacy alarm systems into a single platform without replacing the underlying field equipment.
Yes. A mediation gateway polls the Modbus device, checks the readings against the thresholds you set, and sends an SNMP trap when a value crosses one. It's one of the most common conversions we set up.
In most cases, no. You can add a mediation layer that translates your existing equipment into a standard protocol, keep the gear in service, and replace individual units only as they reach the end of their service life.
Both are common in industrial and utility monitoring. Modbus is simpler and widely used on generators and site equipment, while DNP3 was designed for reliable reporting over the long, sometimes unreliable links that utilities depend on.
It can help. Translating older SNMP version 1 or version 2c traps into SNMP version 3 adds authentication and encryption to alarm traffic, which can support stricter security requirements without replacing the field sensors themselves.
If your network has quietly turned into several monitoring systems, we can help you bring it back to one. Tell us what you're trying to accomplish and what equipment you're working with, and we'll help you map out a mediation approach that keeps your working gear in service. Everything we build is designed and manufactured at our facility in Fresno, California, and backed by direct access to the engineers who built it.
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...
