As CSPs deploy network virtualization, cost accounting will become more difficult. This post looks at why accurate cost attribution is essential in the telecoms sector and explores NFV-specific accounting challenges. 

Network Virtualization: Implications for Cost Accounting

By Michael Dargue  

Cost attribution in the telecoms sector is anything but simple. Years of investment in successive generations of technology have created a complex web of networks supporting scores of services.

Yet the ability to accurately attribute costs to products and services is essential, for both commercial and regulatory purposes. On the commercial side, network operators need a means of understanding costs – by service, customer and location – to determine the profitability and plan accordingly.

From a regulatory perspective, accounting obligations are commonly applied to firms with market power to facilitate activities such as:

  • Setting charge controls;
  • Monitoring compliance with cost-orientation obligations; and,
  • Detecting anti-competitive behaviour (e.g. margin squeeze).

Given the importance for both commercial and regulatory purposes, it is critical that cost accounting accurately captures the underlying relationships between assets and services. Whilst never simple, assuring the quality of accounting frameworks is becoming more difficult as operators virtualize and ‘cloudify’ their networks with NFV (Network Functions Virtualization). This viewpoint discusses some of the challenges posed by network virtualization on cost modelling and cost allocation.

Network Virtualization

Network Operators are embracing NFV and SDN (Software Defined Networking) to achieve a step change in the flexibility and agility of the networks. This change is so profound, that 69% of respondents to Cartesian’s NFV survey said that operators that did not virtualize their networks would struggle to compete.

In the traditional mode of telecoms networking, operators assemble their networks from an array of proprietary hardware appliances, each tailored to a specific network function. In the new world, the function of these hardware appliances is virtualised as software applications that can run on a generic, off-the-shelf server using merchant x86 processors. By virtualising the network functions, network operators are no longer constrained by the physical boxes and can set-up, tear-down and relocate virtual network functions (VNFs) throughout their network using just software commands.

Sharing compute and storage infrastructure across multiple VNFs is inherently more efficient as dedicated appliances are no longer required; resources can be redistributed between VNFs based on demand – either to a predefined schedule or on-demand using automated feedback loops.

 

7300-virtualization-figure-1.jpg

Source: Cartesian

This use of common resources to deliver multiple network services drives the need for new accounting methodologies which are beyond the simplistic approach of counting boxes and circuits.

Implications for Cost Accounting

As network operators transform their networks, it is essential that the cost accounting framework keeps pace with the changes. In this section, we focus on two specific issues: the attribution of costs incurred in network transformation, and the impact on cost allocation methodologies of virtualized networks.

The first of these issues concerns the investment in NFV transformation. The challenge here is reconciling the costs incurred and benefits delivered, with the added complication of a relatively long (and potentially uncertain) implementation schedule.

Figure 2 below depicts an illustrative cost curve for an operator when transitioning to a virtualized network. The chart shows that costs increase during the NFV deployment phase, and then fall back to a level above the initial baseline during a period of parallel running of both infrastructures. Eventually, once the legacy assets are decommissioned the total costs decline to a level below that of operating the legacy networks.

 

7300-virtualization-figure-2.jpg

Source: Cartesian

 

During such network transformations, accountants face two main challenges:

In the build phase, costs are incurred but benefits are not realised immediately. As shown in the figure, the full benefits are only achieved later once the legacy network is decommissioned.

Once built, there will be a period of parallel running during which services are migrated to the VNFs. The temporary reduction in economies of scope for each network may cause unit costs to rise.

These challenges are compounded by the uncertainty of realising expected benefits in the long run, as the operator’s strategy may change in-flight due to market pressures or technical feasibility. The sheer length of time over which the investment is made and recovered is also problematic. In extreme cases, some of the physical servers supporting a virtual network may be fully depreciated before services are migrated onto it.

All the above issues can be reflected in a single overarching question: How should networks costs be attributed to services during the phases of a network transformation programme?

In answering this question, accountants will need to consider:

  • What are the primary drivers for the transformation?
  • What are the benefits to each of the services in the operator’s portfolio?
  • At what point in time do benefits accrue to the individual services?

The second issue to consider arises once multiple services are being delivered on the virtual network infrastructure: namely, how to fairly apportion the shared costs between these services. For legacy networks, cost attribution has been a relatively straightforward affair. Legacy networks consist of static circuits of fixed capacities connected to physical boxes which lend themselves to simple counting and arithmetic. In contrast, the utilisation of virtual network infrastructure is dynamic, with resources assigned to services dynamically. To account for this fluid nature, a new approach is required.

The challenge can be decomposed into two separate questions: (i) How can you measure the amount and type of resources that are used by a service? and (ii), how should you account for the cost of capacity that is not fully utilised?

Conceptually, the first of these questions is the easiest to answer. A well-designed SDN will include comprehensive Fault Configuration Accounting Performance Security (FCAPS) functionality that will enable collection of usage data. For example, within the ONAP framework, FCAPS is provided in the Data Collection, Analytics and Events (DCAE) framework. By collecting empirical usage data, resource costs can be allocated to network functions and then on to services. Cost allocation then becomes akin to billing in arrears, and where forecasting future costs is necessary this could be based on historic trends.

The second question is more of a policy question for which there are several possible answers. For example, unallocated costs could be treated broadly as a general business overhead, or specifically allocated to the services that consume similar resources on a equi-proportional basis. Special treatment may be required where servers are over-dimensioned to provide redundancy to cope with failure conditions, and the priority that services are given to access this excess resource.

Conclusion

Operators are embracing network virtualization to increase the flexibility and agility of their networks and services. In doing so, the shift to virtualized infrastructure creates challenges for cost accounting.

Accountants and regulators need to carefully think through how to attribute costs within this new paradigm, both in terms of the basis for apportionment and the data and methods that are required to support this. Additional policies may be required during the transformation programme to cope with costs incurred ahead of benefits, and temporary inefficiencies created by parallel running.

Finance teams should factor in these changes during the planning of the network transformation. A proactive assessment of the full implications will avoid the need for a change of approach later on. <>