The Autonomous Network Is the Endgame for Telecom

Who you gonna call?
So the big question for service providers is: Who can they trust to design and help build their autonomous network? Options range from traditional to mold-breaking.

At the "trad" end of the scale they can go with one of the incumbent vendors (Huawei Technologies Co. Ltd. , Nokia Corp. (NYSE: NOK), Ericsson AB (Nasdaq: ERIC), etc.), which in turn are competing head-on with the incumbent OSS vendors ( Amdocs Ltd. (NYSE: DOX), Oracle Corp. (Nasdaq: ORCL), Netcracker Technology Corp. -- all of which have their own NFV and multi-domain orchestration platforms) and the heavy-duty IT vendors ( Hewlett Packard Enterprise , IBM Corp. (NYSE: IBM), Dell Technologies (Nasdaq: DELL)).

"Each type of company brings its own strengths to the party, and some of them play in more than one camp, notably Ericsson, which is strong in network operating software, as a network equipment provider and as an integrator," comments James Crawshaw, analyst at Heavy Reading, who recently published a report on this market called Intent-Based Networking, Automating Next-Generation Networks.

On the more disruptive end of the scale, carriers can opt to use code from one of the new carrier-driven industry organizations, such as ONAP or OSM; do it themselves using an automation programming framework and a lot of hard work; or go with one of the new and disruptive "God code" middleware solutions now entering the fray (more on these later).

Whichever path they take, for service providers this is a decision fraught with much more anxiety today than it was four or five years ago when they were considering suppliers for NFV.

Back then, service providers were optimistic that deploying software-based virtualization (SDN and NFV) would buy them two benefits: cost savings, plus a way to escape from being locked into one vendor's end-to-end communications portfolio. At the same time, those same service providers were also predisposed to continue to work with the incumbent vendors they knew and trusted.

For the incumbent vendors, this situation presented a serious quandary. How could they continue to lock in their biggest customers while also showing that they were fully committed to the bold new, open and interoperable world of software-based virtualization? Their answer, basically, was to slap some open source lipstick on a proprietary pig, by continuing to sell their own technology while also joining a slew of open source virtualization organizations. This effectively sent their service provider customers (and analysts and the media, who all fell for this line) the strong impression -- not guarantee, mind -- that their products would seamlessly interwork with products from other open source supporters.

Today, of course, we know that "support" for open source code doesn't mean that a vendor's products will interoperate with anyone else's, at all. Mostly they won't, without a lot of hard systems integration and/or lab work. Now add in the fact that the incumbents' early NFV products were mostly hard to implement (buggy, overly complicated, expensive to get running) and the result, four years on, is a lot of very big incumbent equipment companies with a lot of very frustrated carrier customers.

Next page: Making sense of the vendor marketectures

Previous Page
2 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