We've undergone transformations in the network-operator business model before, so you might expect those seismic shifts of the past to guide the current transformation effort. That's turning out to be difficult, however, because past telecom transformations, like universal dialing and consumer internet, were clear technology shifts. While there is no shortage of telecom network technology candidates to lead today's charge to the future, operators are wondering if technology change is enough -- and if it is, what technology they should choose.

Gain best practices for optical network design including access, metro and core network issues affecting fiber deployment as well as 3-part overview of DWDM optical network transport.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Operators know future networks will have to offer better return on investment for infrastructure and better profit per bit. They also know this goal can be met by a combination of reducing costs and increasing revenues. For example, the technology transformation to stored-program switching that enabled telecom operators to control telephone exchanges with programs stored in switching systems was a major step in terms of lowering cost, because it eliminated the need for both operators and patch panels. Much later, the transition to consumer internet and mobile broadband were transformations in terms of revenue. So, will the next transformation address operators' cost or revenue, and what technologies will get them there?

If there is any technology truth that operators can agree on, it's that automating service processes needs to be a big part of transformation -- or by making the service lifecycle run under software control, with minimal manual intervention. This type of automation would reduce costs and radically shorten the delay in getting new services from planning to generating revenue.

Given the virtual unanimity of interest in service lifecycle automation, you'd think that we'd be leaping forward. We are moving forward, but on opposite fronts.

The dominant view in the current operator market is the existing infrastructure is inherently dependent on human-driven processes. Due to this, a service lifecycle management transformation would mean a network technology transformation from current network technology to something more suitable for automation -- primarily software-defined networking (SDN) and network functions virtualization (NFV).

If there is any technology truth that operators can agree on, it's that automating service processes needs to be a big part of transformation.

The promise of SDN and NFV is that centralized, planned and orderly deployments can be achieved by replacing traditional devices with white box OpenFlow switches in SDN's case and with virtual network functions in the case of NFV.

SDN's northbound APIs would allow software to directly configure forwarding paths that create services, respond to service changes and recover from faults. NFV's management and orchestration would drive deployment of virtual functions as software elements hosted on a pool of cloud servers, or even on edge routers and customer premises equipment. If these changes were made and automation's potential was fully realized in both cases, operations costs could unquestionably be reduced by as much as 70% and time to revenue reduced by perhaps as much as 98%.

The problem with this happy outcome is we don't have proven cases of SDN or NFV results to speak of, so current services must still be built from legacy elements. Furthermore, even a decade from now, it's unlikely that networks will be 100% SDN and NFV.

As long as SDN and NFV services have legacy components, the automated tools designed to deploy them would also have to deploy legacy network services. An NFV firewall will still likely need a carrier Ethernet connection, for example. If you can automate carrier Ethernet legacy equipment with SDN or NFV service automation to create an end-to-end service, why do you need to transition the infrastructure at all?

We see two examples of this thinking today: first, an operational support system/business support system (OSS/BSS) transformation; and second, software-defined WAN, which is similar to the Metro Ethernet Forum's Third Network. The former applies software orchestration techniques to current devices, thus reducing Opex and improving service agility. The latter builds services by overlaying them on any mixture of Level 1 (optical or SDN tunnels), Level 2 (Ethernet) and Level 3 (IP) infrastructure. The infrastructure is then decoupled from the service, and infrastructure changes don't have to affect services at all.

As a result, we have three competing technology models for transformation. The differences are stark in their effect, so it's no wonder operators are struggling with their choices. The choices are as follows:

What will -- or should -- they choose? One thing that appears clear is SDN and NFV cannot be deployed quickly or far enough to create a major effect in the next three years. The depreciation rate for operator infrastructure constrains sudden forklift network transformation technology changes, not to mention operator fears of massive problems with new technology never tied at scale. This doesn't mean SDN and NFV won't happen, but that other technology options must lead them there.

Where operators have a strong set of APIs or policy management tools to control their legacy networks and facilitate the whole service lifecycle, a service modeling and automation strategy that operates either within or underneath the OSS/BSS could realize fast and substantial rewards. This approach could generate 10 times the cost reduction as renewing infrastructure using SDN or NFV in 2017, and over 18% more cost benefit even by 2020.

Only by adding in other technology changes can costs be further reduced, however, and revenue gains from this approach are difficult to prove.

The SD-WAN approach simplifies software automation and increases agility through the use of an easily controlled overlay model, one popularized by Nicira Inc. -- later bought by VMware and relabeled NSX -- and also supported by Nokia Networks with Nuage Networks and other vendors. This overlay model requires little capital investment compared with forklift infrastructure upgrades, and it is easier to automate. This strategy, in combination with service modeling and automation, could boost cost reduction in 2017. And by 2020, the combination could reduce current Opex by 50%.

SDN and NFV can then play, and play decisively. By introducing SDN as a virtual wire below the SD-WAN and adding features with NFV, SDN and NFV could combine with other approaches to generate a 70% reduction in Opex. This combination could unite network feature hosting and carrier cloud computing services to increase operator revenues by about $100 billion per year globally by 2020. They may not lead the transformation wave, but SDN and NFV can bring it home.

SDN and NFV drive telecom changes

NFV propels changes with network management

How SD-WAN and NFV can lower costs

Read the rest here:

Telecom operators navigate three technology transformation options - TechTarget