The Autonomous Network Is the Endgame for Telecom

The telecom industry has spent decades wandering in a technology desert. The trek isn't over by any stretch -- but at least the destination is now clearly marked.

Journey's end is a place we are calling The Autonomous Network. Right now, it's pretty much a mythical gleaming city on a hill. But the road to that city is now under construction, and it's just a matter of time before this truly massive project is completed. That time will be marked in years, which means there's a lot of hard work ahead.

Figuring out the endgame is not so much an "aha!" moment as a "duh!" moment. It starts with the latest industry buzzword: automation. Automation isn't actually a new concept at all -- it's been a part of just about every communications innovation since the advent of the rotary phone. But we are now at the point where all the bits and pieces of automation will start coming together to form one great superstructure.

The immediate goal of automation is to create "autonomous processes" -- in which the network does what it needs to do without human intervention. That's been an aspiration of telecom architects and solution providers for literally decades.

But now, the vast array of related technology ingredients that are essential to make automation possible -- virtualization, AI, machine learning, telemetry, robotics, analytics, et al -- are all reaching various degrees of maturity (though, just like people, some are a lot more grown up than others). And as these discrete elements of automation come together, the path to The Autonomous Network is taking shape. Carriers are now contemplating building networks that could run themselves for days or even weeks at a time, without any human interaction whatsoever.

When we talk about The Autonomous Network in this context, we are talking about communications processes in their entirety -- not just the connections but also the services, applications, underlying processes and everything else that is part of the giant virtual machine that powers the global economy.

For carriers and CSPs still grappling with the problem of getting NFV to work, the thought of tackling automation, with all of its science-fiction-like components, probably looks like a job too far. Making sure they can reap the benefits of automation (staff reductions; better performance; greater reliability) without falling into the same traps that have plagued NFV and other great leaps forward (vendor lock-ins, over-complicated open source non-standards, hard-to-prove business cases) requires our industry to take a long hard look at the mistakes that continue to make virtualization such a painful experience for carriers, and to learn from them.

It's complicated
Let's get one thing clear up front: Automation is really f***ing complicated. In fact, the word "automation" is a generic catch-all for all the separate elements that need to be in place to get to The Autonomous Network, and each step in the process will be more complicated than the previous one. Step 1 is the automation of specific management functions (generally sitting in the carriers' existing, clunky IT infrastructure). Step 2 is the automation of the updates of those processes, so they don't have to be handled manually (automating the automation, basically). Beyond that, service providers will want to make the scripts more intelligent by adding AI and machine learning to not only automate the processes but to improve their efficiency, "automagically," over time.

For carriers, most of whom are still operating in super manual mode, using thousands of human admins and operators, this stuff is pretty much pie in the sky right now.

Next page: Who you gonna call?

1 of 5
Next Page
Page 1 / 2   >   >>
Joe Stanganelli 9/22/2017 | 11:13:03 PM
Far off "this stuff is pretty much pie in the sky right now"

Indeed, most of the telecom execs I speak to about SONs and similar areas (1) have and/or acknowledge vastly different definitions for SONs and "intelligent networks" in the industry, (2) note that we're quite far away from this vision, and/or (3) seem to have little idea what I'm talking about.
mendyk 9/15/2017 | 4:11:13 PM
Re: Componentry? Don't go away mad ...
PaulERainford 9/15/2017 | 4:09:27 PM
Re: Componentry? This conversation is getting silly. I'm off to nail some jelly to the wall.
mendyk 9/15/2017 | 1:51:14 PM
Re: Componentry? As a wise old copy editor (as if there were any other kind) once advised, know the language of the tribe. Virtualized functions run on components, but referring to those functions as componentry does not comply with the idiom of this particular tribe.
PaulERainford 9/15/2017 | 12:40:10 PM
Re: Componentry?

Componentry | Definition of Componentry by Merriam-Webster

Define componentry: the parts that make up a system or device.
PaulERainford 9/15/2017 | 12:33:14 PM
Re: Componentry? Plus: it didn't strike me as wrong. It's hard copy editing in a foreign language, you know.
mendyk 9/15/2017 | 12:29:25 PM
Re: Componentry? As an emeritus member of the Copy Desk Academy, I take issue with your hand-washing in this matter. I remember getting the most pleasure out of thankless tasks by correcting things that came from on high.
PaulERainford 9/15/2017 | 11:23:00 AM
Re: Componentry? Oi, leave the copy desk out of it. This came to us from on high and is no sillier than many other words we assured are common parlance on Planet Telecom.
IS-dg 9/7/2017 | 10:42:54 AM
Re: Testify! I meant http://platonicrealms.com/encyclopedia/zenos-paradox-of-the-tortoise-and-achilles

Zeno, Xeno, ya know.
Steve Saunders 9/7/2017 | 10:38:45 AM
Re: Componentry? possibly worried about being downsized by automation? 
Page 1 / 2   >   >>
Sign In