How We View the Future of Telecom Site Automation (IOT, Automation, Big Data)

Telecom Network and Data System

In today’s post, I’m going to talk about how we view the future usage of data generated by a modern telecom site automation solution in a modern telecom network. By future, I mean possible now, but only currently being done by a smaller set of future looking telecom operators. Before I can talk about future usages of this data, a review is needed to explain what central challenges are to collecting this type of data from large numbers of telecom sites.

In a previous blog post, I was writing about how Asentria’s SiteBoss unit can be used to gather data from the wide variety of makes and models of equipment that can be found at a telecom site. Before you can consider what, you will do with the data collected, you have to address the challenges involved in “data normalization” across all of the different data collected from your sites. Here is a snippet of that previous post:

There are vast differences between different telecom networks, and even within a single telecom network. If we were just to use power as an example. It would be likely that within a single telecom network you might have on-grid and off-grid sites. In an off-grid site you might have a solar-array, one or two generators (or none), different makes and models of equipment, fuel types, rectifiers, etc. Different customers could have different business purposes. A public-safety network would likely focus solely on reliability. A tower company might focus on reliability, but also in being able to do power billing to different customers at a site.

One of the most common failures of remote monitoring systems (RMS) is not successfully accounting for all the differences at various sites, and not bringing back all the data produced by the sites reliably and accurately and in a normalized format. This is the failing of many IoT type solutions for monitoring at telecom sites. Failing solutions may try and just collect data from many different element management software systems and piece it together once it is centrally collected. This is not ideal due to the fact that this almost inevitably leaves sites not monitored that don’t have the most modern equipment, and also creates a large management task trying to massage all the data into a usable format in a centralized database.

But what if you DO manage to bring back normalized data across all makes and models of equipment, and different site types? What do you do with this data in a successful implementation? In a simple form, Asentria would recommend centralizing alarm or fault data from remote sites as faults occur, but also collecting telemetry data on systems on a regular interval. This can vary considerably, but for an example we might consider faults on 30-40 variables being pushed as they occur, and another 50 variables being brought back from each site on a five-minute time interval.

Data is King

Traditionally in telecom operators, there is software based on the Simple Network Management Protocol (SNMP) to receive fault data. Asentria is very happy to work with existing SNMP software if it is present already in a customer’s network.  Often there are already processes built to take fault or alarms into that SNMP software and create tickets for cell technicians or other corrective actions. Asentria has worked for ~20 years with SNMP and working with SNMP has convinced us of the advantages of working with open protocols.

For processes outside of fault management, it is particularly clear that there are advantages to viewing the data itself as having value and using non-proprietary tools to work with it.  In the past Asentria has worked with many more proprietary software to enable some function to occur. To enable a proprietary software to control our SiteBoss units for generator exercising, for example.   What is becoming clear to us is that more open consolidation of the data our units produce and more standardized ways of using commands to control our SiteBoss devices is superior to silo-ing data into a proprietary system.

Collecting the data from our SiteBoss units and combining that with other data from other systems into more of a “data lake” architecture has a number of cost and functional benefits. We can see parallels between the best way for our solutions to function and the goals of Open RAN systems, which borrow many ideas from data center management. This runs counter to even newer IoT vendors whose systems are designed to get users to adopt a particular IoT software platform and be “locked in” to the use of that system.

We believe that creation of data in open structures is inherently better and offers greater future flexibility. If you build up a database of data from your sites, it is just data, it isn’t walled off in proprietary software. If you want to use an open-source software to work with the data today, there is nothing preventing you from working with the data in the future with a different software. We believe the value is in the data itself, not the software that is used to work with the data.

What you do with the data is then up to you.

telecom data dashboard
Example - CO2 emissions dashboard in an open source data analytics tool.

Asentria can help with data visualization and analysis, but it is possible these are skills your organization are already developing. It is YOUR data after all. Data is king and gathering and analyzing the data within your organization should be a part of any telecom network operator’s future strategy.

Need help visualizing the data across your telecom sites? Asentria is a 40-year-old telecom equipment and engineering company based in Seattle, WA USA that can help you get started by contacting

remote site monitoring system
telecom tower equipment
Recent Posts

Leave a Comment

Start typing and press Enter to search