Every major natural disaster causes problems for telecom networks. The people who have managed networks through those events know the quality of passive infrastructure — generators, DC plant, HVAC, batteries — is critical.  What is less understood is the accompanying data problem associated with this passive infrastructure.

During any natural disaster, what an operator actually needs to see looks something like this: which sites are on generator right now, what are actual fuel levels and estimated runtime at each one, which sites have already failed and why, whether cooling is holding at sites still running, battery state of charge at sites where generator hasn't yet kicked in, and which sites are trending toward failure in the next few hours versus which ones are stable. That's a triage and prioritization picture across potentially thousands of sites in real time, during the event itself.

What most operators have had access to, historically, is much closer to a low-fuel alarm. A single contact closure. Not a dataset.

One response to that gap has been to spend heavily on RTU infrastructure. The intent was sound. The result was limited. What an RTU delivered, even at significant cost per site, was still fundamentally alarm-level visibility. An as needed SNMP get of a single OID representing fuel level. A contact closure that triggered when a threshold was crossed. Not actual fuel quantities across the network. Not system-generated metrics that are truly useful like network-wide estimated run times.

 
The equipment was capable of reporting detailed telemetry for decades. The problem was that nothing could collect it all, standardize it, and deliver it in a usable form across a mixed-vendor, multi-site network. The tooling to do that reliably didn't exist yet. So the expectation of solving it faded over time.

Data streaming changed that. Not as a vendor category someone invented to sell — as a set of open tools that matured to the point where the problem is truly addressable. What is now possible is 50 to 100 standardized variables per site per minute. Power draw, fuel level, battery state, HVAC status, access events, life safety alerts — continuously, across the entire network, from whatever equipment is already deployed. That is a categorically different class of information than an SNMP alarm. 

We found this through years of working the problem directly, across telecom networks and data centers. It did not begin as a planned strategy. It was where years of work finally led us.

The Input Side: Why Normalization Across Equipment Is the Foundation

The first half of the data standardization problem is the one that occasionally gets discussed. A brownfield telecom network or data center built over decades does not have uniform equipment. It has generators from one vendor, DC plant or PDUs from another, HVAC and cooling from several more, RTUs from whoever was preferred at the time of each deployment, smart meters added later, legacy equipment with no remote interface at all. Each of these has a different management interface, using different protocols, naming conventions, scales, and units.

Unless something normalizes all of that into a coherent dataset, you do not have network-level visibility. You have islands. An energy manager can see one vendor's equipment in one platform, another vendor's in a separate system, and a significant portion of the network can't be seen at all. Cross-site comparison is impossible. Trending is impossible. The kind of operational picture described above — fuel levels, generator status, and site life estimates across your entire network simultaneously — is impossible.

Input standardization is the prerequisite for everything else. The equipment has been capable of producing this data all along. What was missing was the layer that asked for it consistently, normalized it across every equipment type, and delivered it in a single coherent format.

This is not a general data engineering problem. The telecom power and data center environment is deeply specialized — protocols, equipment classes, edge cases, and failure modes accumulated across decades of heterogeneous deployments. Building and maintaining that normalization layer correctly is the work. The open-source tools that make it possible — Kafka, InfluxDB, MQTT, Grafana — are the infrastructure that carries it, but they are not the expertise.

The Output Side: The Half Nobody Talks About

Input standardization is becoming understood, at least in principle, as a problem worth solving, but the output side is just as important.

Consider what exists in a mature telecom network or data center before a new data layer arrives. A Network Management System (NMS) with an alarm scheme the NOC has worked from for years. 24, 32, or 64 contact closures feeding into that NMS, mapped to specific alarm categories, tied to trouble ticketing systems, driving workflows that have been established and refined over time. In a data center, a Data Center Infrastructure Management (DCIM) system with naming conventions and alarm hierarchies the operations team knows cold, as well as requirements for meeting certain regulatory standards.

These legacy systems are non-negotiable. The alarm output to the NMS is not a preference — it is the operational spine of how the network is managed. Thousands of sites, associated ticketing, established escalation paths. Nobody is going to adopt something that puts any of that at risk. Nor should they.

The output standardization problem is this: a new data layer that speaks a different language — even a better one — creates friction that stalls adoption. If the alarms, events, and telemetry produced by the new system don't map to what the NOC already knows, someone has to reconcile the two. That reconciliation is a financial cost, an operational risk, and a change management problem. It is exactly the kind of friction that causes good technology to sit unused.

The answer is to standardize the output too. Deliver alarms, telemetry, and events in the format, naming conventions, and hierarchy the operator's existing systems already use. Don't alter the existing systems already in use at all. Just provide new, additional data in a form that matches the existing data. The NOC sees what it has always seen. Trouble ticketing works the way it always has. Nobody retrains. Nothing breaks.

Standardization has to happen at both ends. What comes in needs to be normalized across every equipment type and vendor. What goes out needs to speak the language of wherever it's going — whether that's an NMS, a DCIM, or a downstream analytics platform.

It is the same normalization discipline applied in both directions. The capability to do the output side was always present in the work we were doing on the input side. A customer surfaced the use case and we recognized it as the obvious extension of a principle we were already applying.

What This Looks Like in Practice

In a data center environment, this means FOCUS alarm output can match the naming conventions and hierarchy used in an existing DCIM. A data center might have four standard categories — Power & Energy, Cooling, Life Safety, Security — mapped to whatever scheme is already in use. The escalation structure — equipment level, subsystem level, category level, facility headline — mirrors what the operations team already works from. An alarm visible in Grafana is consistent with what the team sees in their existing DCIM.

In a cell network, the same principle applies to the NMS. An operator with an established alarm taxonomy — however that system categorizes power, security, and environmental issues — receives standardized FOCUS output in that format. The NOC works the way it always has, but the dataset available underneath that workflow is now 50 to 100 variables per site per minute instead of a handful of threshold alarms.

In both cases, FOCUS runs alongside the existing system. It does not replace the NMS. It does not displace the DCIM. Over time, as the granular dataset grows and the coverage extends to equipment and sites that were previously dark, it becomes the more trusted source of operational truth. What operators choose to do with their legacy systems at renewal time is their decision to make. The data layer makes itself indispensable first.

Why This Matters Now

The arrival of data streaming tools has unlocked something that was technically impossible to do at reasonable cost even a few years ago. The ability to collect 50 to 100 variables per cell site per minute, or thousands per minute in a data center, standardize them across every equipment vendor in a heterogeneous network, and deliver them in a format that feeds or works alongside existing operational workflows — that capability is new. The layer that could collect, normalize, and deliver this data at scale simply did not exist.

Traditional hardware vendors cannot lead this transition. Their business models depend on proprietary hardware at each site. Standardized data streaming makes hardware interchangeable — which works directly against how those businesses make money. Traditional software vendors get closer, but even the best of them solve only the input side, creating proprietary output formats that produce a new version of the same lock-in problem.

The operators who recognize this earliest are building a data asset that compounds in value. Every month of continuous, granular, normalized energy telemetry is a dataset that improves with age — as AI tooling matures, as benchmarking across larger site populations becomes possible, as cross-site pattern recognition surfaces things that single-site analysis never could. The operators who keep solving this with monitoring hardware additions and software licenses are paying more, accumulating less, and narrowing their options for what comes next.

The two sides of standardization are not separate problems. They are two requirements of the same solution. Getting the input right without getting the output right produces a dataset that never reaches its potential — blocked by the operational friction of a system that doesn't speak the language of the people who would use it. Getting the output right without getting the input right produces a well-formatted stream of incomplete information.

Both sides have to work. Let us know if you'd like to know more. We believe this approach, which is significantly better AND less expensive, will be in use in every network in the near future.

[email protected]