Silvano Rebai - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Why network operations efficiency should drive technology change

If the systems responsible for network operations efficiency and automation were driving telecom technology upgrades, the savings might just pay for SDN and NFV deployments.

Every industry vertical has a core or mission-critical set of applications that normally drive its technology evolution. The CIO of a bank would never plan for technology change without considering demand deposit accounting -- which, in banking, is savings, checking and teller support. In telecommunications, the core application set is operations support systems/business support systems, or OSS/BSS. But in this critical time of telecom change, it's not clear whether telecom's core applications are driving the change or being driven by it.

The original mission of operations systems was to manage people, rather than networks or services. But, as networks evolved and relied more on autonomous behavior, OSS/BSS became focused on billing and other noninfrastructure issues. In many cases, the CIOs of network operators head activities that are not directly related to either service or infrastructure evolution. And with SDN and network functions virtualization (NFV), for example, CIOs as recently as last year were saying they were largely unengaged in those technologies.

What's changing this is the need to prove that network technology like SDN and NFV have tangible business benefits. Operators quickly agreed the Capex reduction was a goal unlikely to drive enough change and moved to a broader benefits justification that included operations efficiency and service agility. Now, there's the question of whether operations efficiency and agility can be brought to existing networks through changes in operations systems, or whether new infrastructure offers a better hope of significant gains. And that is what will determine whether OSS/BSS will drive, or be driven.

Putting network operations efficiency first

The case for an operations-first approach is compelling. For every dollar in earned revenue, operators currently spend an average of about 20 cents on Capex. Operating costs attributable to service and network support and related activities make up about 27 cents. Few operators believe there is any credible way to reduce Capex by even 25%, so Capex reduction could contribute only a 5-cent-per-revenue-dollar savings in a best-case scenario.

Operators believe they could reduce Opex by as much as 75% through software automation and orchestration.

In contrast, operators believe they could reduce operations expense by as much as 75% through software automation and orchestration. That would produce savings comparable to an operator's entire capital budget. Those savings could be achieved with little investment in new technology, so risk and return on investment would be favorable.

If operators' savings in operations costs -- driven by operations software changes -- were applied to fund new infrastructure, like SDN and NFV, the cost burden of early deployment could be reduced, and software automation would magnify the operations savings that infrastructure could generate. This could almost make next-generation network transformation self-funding.

On the service agility side, operators point out that creating self-service portals for customers' services, combined with service automation software in operations systems, could significantly reduce order-to-billing time for services and reduce operations costs at the same time. Just adding agile customer premises equipment to host virtual functions, or virtual CPE, would allow new service features to be added on premises, further enhancing revenue and shortening the provisioning cycle.

The problem with the network OSS everybody-wins scenario

The challenge to this apparent everybody-wins outcome is operations systems and their vendors haven't embraced this approach. Even network operators tend to frame their orchestration, operations efficiency and service agility missions in terms of devices, and have pursued these device-driven goals through SDN and NFV tests and trials. This has fostered an infrastructure-driven vision, where new technology creates virtual devices that interface with operations software just as the physical devices did. While that simplifies integration at one level, it insulates operations software from network technology trends.

The virtual-device model breaks the operations efficiency and service agility benefits in half, with the operations part of the picture left to evolve without specific drivers of change. The break means lacking a common driver would not only make it difficult to secure the full range of operations efficiency and agility benefits, but the lack of new OSS for technology hidden inside virtual devices would make it difficult to realize agility and efficiency benefits there.

Another complication is the fact that transformation has long been seen as meaning infrastructure transformation, driven by changes in standards and technologies under network operator CTO organizations. Initiatives like SDN and NFV have created enormous visibility for CTO organizations, and tests and trials aimed at transformation have targeted SDN and NFV. As a result, operations changes have been excluded from the scope of trials, and that has cemented the limited virtual-device model into place.

OSS, emerging technology separation affects next-gen architectures

The organizational separation of operations systems and emerging technologies has even colored emerging operator architectures for next-gen networks, notably those from Verizon and AT&T. Both have codified the operations and infrastructure separation by supporting multiple layers of orchestration. It is feasible to combine these layers into one, but the fact that operators look at operations and infrastructure orchestration separately will likely perpetuate divisions on the issue vendors. Few vendor sales reps call on both the operations and infrastructure sides of the business.

Economics should be the deciding factor in whether operations drive or are driven by transformation, but operators and vendors have struggled with network transformation for a decade without success. With SDN and NFV, the trend seems to take a narrow service-specific leap, rather than a broad migration. If SDN and NFV initiatives drive the change, a narrow infrastructure-driven shift is emphasized, and that risks the classic service-silo problem. But, most importantly, since SDN and NFV don't define operations automation and orchestration, the service-driven transformations seem to force operations into follow-me missions.

It could take five years longer to achieve service agility and operations efficiency if technology evolution at the infrastructure level is separated from the evolution of operations systems into an event-driven, service-automation model. Arguably, we might never fully realize the goals because SDN and NFV present more potential complexity, and that could raise costs, rather than lower them. Right now, we're on an "operations is driven" path, and we need to shift policy to make operations the driver.

Next Steps

Automated network OSS needed for SDN and NFV

Survey links next-gen OSS to faster service deployment

OSS not glamorous, but necessary for network changes

This was last published in August 2016

Dig Deeper on Telecom OSS and BSS

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What would drive operators to focus on network OSS automation and updates, rather than infrastructure-only upgrades?
Cancel
The rate and scale of NFV savings in the near term depends heavily on the type of service or network function being migrated. 
1. Simplification of hardware appliances shipped to customers
2. Reduced complexity of customer driven overlay services
3. Infrastructure economies of scale and procurement for large shared underlay services
The most obvious business case today is simplification of equipment sent to customer premises. Virtual CPE cases where a simplified “dumb” box is shipped instead of an expensive box that can run services directly or multiple complex appliances that need to be chained together by the customer. There are savings for the Service Provider from the cost and number of the boxes shipped. Virtual versions of appliances such as firewalls that are hosted in the network can more easily be pre-tested and pre-chained together delivering simplified configuration and automation benefits. The vCPE business case really shines when new compute intensive IOT/set top box/networking features can be consumed by customers without needing any new equipment to be shipped.
In fact, any network overlay service created in response to a customer order will achieve higher levels of operational automation with NFV. Feature rich service bundles have complex network lifecycle tasks often need manual intervention to fix fulfilment errors or diagnose operational problems. tested up front more comprehensively than can be done today, reducing the fulfilment errors assurance complexity that requires manual intervention today.
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchDataCenter

SearchCloudComputing

SearchCloudProvider

Close