Pathways to Network Capex Reduction: Do Any Lead to a Good Place?

Everyone is talking about carrier capex, in some sense or another.  If you’re a vendor you know that your buyers have been pinching pennies, and if you’re an operator you know that return on infrastructure is threatening your capital plans.  The Street has worried about it too, though more for vendors’ profit impact than for operators, since the traditional EBIDTA model discounts capital spending by operators.  The problem with all these discussions is that they don’t really address the critical question of balancing the chances of capex reduction with the risks of transformation.

Capex reduction is the most commonly stated goal for new technologies too, so I wondered how much capex could actually be saved, and pushed some numbers through my market model to find out.  My goal was to test some possible capex-controlling approaches to see how they might do.  I focused on electrical-layer devices only, and looked at the US and international markets.

The most obvious way to control capex is to put price pressure on vendors.  Operators say that’s been done for years, and that they believe that Huawei in particular is a good way of pushing prices down.  In the US, where operators can’t buy from Huawei, equipment prices seem to be about 14% higher, and operators believe that Huawei could be hit for an additional 20% and other vendors by 25% or even 30%.

My model says that current network technology pricing could decline by about 17% outside the US and 24% in the US under optimum price pressure, which in the US would include releasing Huawei to sell here.  Enterprise data is a bit harder to get, but the model suggests that enterprises could reduce their capex by about 19% through pricing pressure, and this is fairly consistent across the market segments.

The next approach is to substitute “white-box” technology for traditional electrical-layer devices.  There is at present no direct white-box alternative for all the electrical-layer devices in use; generally, it’s available for the mid-range and below products but not for the terabit-level stuff.  Where you can get white-box stuff, direct 1:1 substitution without a technology shift (to OpenFlow, for example), the savings potential is slightly better, meaning 19% internationally and 27% in the US.

We now enter the gray area, because the other options for capex reduction have to be considered with some skepticism.  SDN and NFV create a different network model, one that would have to be assumed would impact operations costs as well.  There are no really good ways of estimating the impact because we don’t have many vendors who even tell a complete story, and in any case I’m trying to look at capex here.  So for the stuff below, I’m making a critical assumption, which is that SDN and NFV opex impact is neglected.  Service automation creates most of the opex benefit in any case, and you don’t need SDN or NFV to employ that.

Moving up, the “hosted-router-switch model” would substitute software instances of L2/L3 devices for the physical appliances.  The software would be hosted on “commercial off the shelf” or COTS servers.  This isn’t NFV yet, it’s a static model of software switch/routing.  Like white-box products, this approach isn’t extensible to the very top end of the range of devices, but where it’s linked with SD-WAN edge technology to create overlay networks, the model says it saves 21% of capex internationally and 29% in the US.

True, OpenFlow, SDN is next.  This model combines white-box and central controller logic and generates a lower capex not only because the devices are cheaper but because the stuff is less complex.  However, server cost and complexity for the controller has to be considered.  If we stay with traditional network applications and forego cloud multi-tenancy for the moment, the model says that this approach would save 23% of capex internationally and just under 30% in the US (US data center switch prices are lower, even not considering Huawei).

NFV comes next.  Here, the challenge is that NFV even more than OpenFlow SDN should really be considered not box for box but on an alternative-architecture approach, and the benefits will vary considerably depending on the mission.  I’ve modeled only two for this blog.  The first is “vCPE” or “service chaining” where software features substitute for premises equipment.  In the model, a premises-device-hosted vCPE approach showed only a 15% capex savings, with little variation by market area.  Cloud-hosting the software features proved impossible to model because it’s impossible to assess the cloud cost without knowing the volume of deployed servers, and vCPE can’t drive mass deployment alone.

In the mobile application and CDN area, the model says that NFV could save almost 20% of mobile-or-CDN-specific capex internationally and 25% in the US.  This benefit, I think, understates the value of NFV in mobile and CDN applications; much of the benefit would come from creating more agile deployments that (without NFV) would cost more than today’s mobile infrastructure.  If you try to factor that in, the savings jump to 29%, but these numbers are softer because of the difficulty in establishing a model census for data center resources.

What’s the best case?  This is really a modeling stretch because of the host of assumptions you have to make, not the least of which is that because there’s no vendor offering this solution, you kind of have to make up a product set.  However, if you assume that white-box OpenFlow SDN is used as an overlay on agile optics, and that this segments networks to the point where hosted router/switch technology can be applied throughout, and that NFV then redefines metro and feature hosting, you get an international savings of 33% of capex and a US savings of 38%.

The important point here is that L2/L3 boxes don’t make all of network capex; the actual percentage for L2/L3 varies by operator type, but a good benchmark is that access makes up about 40% of capex (and isn’t impacted by L2/L3 changes) and fiber makes up about 30%.  That means roughly 30% of total capex is impacted by these measures.  Since globally, capex makes up about 18 cents of every revenue dollar on the average, optimum capex measures could save about 7 cents of each revenue dollar.

My model had previously shown that service automation techniques, applied to all services in an optimum way, would save 7.7 cents of every revenue dollar by 2020 without changing capital equipment spending or practices.  Projecting further (and obviously with less confidence!) into the future, the service automation approach appears to plateau at approximately 12 cents per revenue dollar, which could be achieved in 2024.

You can draw a lot of interesting stuff from this.  First, it would be relatively easy for vendors to secure greater savings for operators through service automation than the operators could get by “saving money” on equipment.  In fact, the potential savings is nearly double.  The ROI on this savings is considerably better too.  But the second point is also critical; capex reduction savings and opex savings are additive.  Operators could totally transform themselves by harnessing both, and by 2024 could hope to have saved a total of 22 cents of every revenue dollar, which means they’ve cut costs overall by more than a quarter.

The best ROI could be achieved by combining service automation with the hosted router-switch model and SD-WAN principles, which would generate a significant capex savings and could easily be paid forward through savings from the opex side.  The model suggests that short of SDN virtual wire underlay and SD-WAN overlay, there aren’t many other capital-focused steps that could really pay a big dividend.

It’s essential to realize that these pathways to transformation aren’t accumulative in savings, though.  The same model says that the most you could achieve in capex reduction would be from my “optimum” model that forecasts 33%/38%, so all the others are going to be optimal only to the extent that they lead to this happy place.  That shows that you have to understand your transformation goal before you start chasing it.