– staff staring at walls full of screens beware
In recent years mobile operators have talked about turning their Network Operating Center (NOC) into a Service Operating Center (SOC). This was a much-needed shift, but as I see it just a small step in a chain of major changes that need to happen. Building service quality dashboards with KQI’s and trying to convert low-level alarms into service alarms is still no good in an environment where it has been humanly impossible for a long time to manually watch every graph, screen or log. So, how can we evolve further?
The way forward is for operations to become fully automated. And who will deliver this? Ericsson or Huawei? Amdocs or Netcracker? Someone else? The good news for the technical staff at the operator is that it will still be you. Because, as we know, every network is unique! But when most manual operation tasks will become automated, it will mean a big shift for the work force where staff working with operations needs to be turned into or replaced by DevOps engineers. We already see this shift happening at some operators and there are ongoing initiatives for network automation, e.g. within ONAP and OSM. As an operator it could be easy to think that someone else will fix the universal one-fit-all solution, but in the end each operator needs to be in control of its own environment. There needs to be a paradigm shift in overall culture, how an OSS stack is built, and consequently what you look for from your OSS vendors. As I see it there is still room for radio planning tools, inventory/configuration management tools, traditional alarm aggregation tools as well as probe/call-trace systems, but what will be the key things to ask for?
To step into the world of automated operations you’ll need to require a few things to get a harmonized ecosystem out of your network:
Vendors that deliver open systems, where northbound export is included and it’s close to real-time. Avoid data lock-ins; a vendor’s “on-top tools” might store things in a database and show a view in a GUI, but the data needs to be available for export to you or any other 3rd party vendor at all levels with a high level of flexibility and standardization.
Open API:s for extraction of information on-demand or issuing commands must be present. Depending on use case, these API:s need to be very responsive, with low latency, and cope with high volumes of data. Applications for automation or various types of customer interaction will require extraction of information very close to real-time.
You need fully automated alarming based on statistical or machine learning techniques. There is no room for staff to keep up with setting alarm levels or configuring thresholds. These alarms will work as input and triggers for your automation, but also as information where relevant staff can subscribe to info and act when needed, without staring at a graph all day. Some of these alarms and triggers will also be propagated all the way to your subscribers, e.g. as an information message or a notification.
Note that the above is very rarely delivered by reporting systems from OSS vendors and for many of them it requires a full system redesign. Also, they often keep the data locked in. Traditionally, RFx’s have also put more focus on the hundreds of KPI’s, reports and flexible dashboards than on defining northbound exports, open API:s, alarms and automation possibilities.
I think most of us are envisioning a future of a self-driving mobile network, but in order to get there it is high time to take the first steps in the automation journey. This will not be delivered by a single vendor and it will certainly not be delivered by data scientists swimming in your data lake, but rather by the OSS department selecting the right vendors/partners and turning themselves into innovative IT-stack designers and DevOps engineers.