Verizon’s comments about capex and generally better visibility from vendors has helped the telecom equipment space look a bit better, and of course that’s been our forecast since the spring. My model shows general telecom spending will increase through 2015, with spending in all equipment areas showing some gain. This represents the “last-gasp” modernization funded by mobile revenues and unfazed by SDN and NFV. Beyond that point we’ll see gradual erosion in spending on network equipment, first in the core where the long-term effects of a shift to optics will be felt. The core, recall, is the least profitable part of the network for operators.
You can see in AT&T’s earnings that they are expecting to have to do some creative framing of new fees and services if they’re to sustain profit and revenue growth going forward. The capex increases will likely put all of the major operators near zero profit growth if they don’t cut other costs, and many are concerned about further cuts in OAM&P for fear of creating service issues that would drive churn.
Operators I talk to have three touchstones for future profit growth. First, they believe that initiatives like SDN and NFV can lower overall costs, though some now admit that they believe the early estimates of savings are generally too high. Second, they believe that the prepay mobile market can, with the proper programs and handsets, translate either to postpay at a higher ARPU or translate to featurephones with a la carte feature pricing. Finally, they believe that there is a service-layer framework for profitable cloud-based services and features out there somewhere.
Readers of my blog know that I’m not a big fan of technology changes driven by cost management goals. Historically operators have underrealized in this kind of investment, and in nearly all cases the problem is that they’ve been unable to create a reduction in operations cost corresponding to the capex reduction. In fact, Tier Ones tell me that opex as a percentage of total cost has increased more than capex has been reduced by new technology. Even operators who report higher profits on services like VoIP admit that part of the equation is limiting customer interaction. They could have done that with the old stuff. So while I think that SDN and NFV cost-savings won’t create a steady stream of profits, I do think they can help prime the pump.
The “a la carte” feature stuff is linked to operator views that the majority of wireless users will pay for some special features (like international roaming for mobile) on an episodic basis but not in monthly-subscription form. Today we tend to see two classes of wireless service—prepay and postpay. The latter, in the US in particular, trends toward unlimited usage and complete feature support and is aimed at customers who rely totally on mobile communications, especially for social reasons. The former is for those who tend to use only basic services and are trying to control costs. Operators tell me that their modeling shows that prepay revenues could be raised by as much as a third by introducing special-service packages on a shorter-term basis. Some of this is already visible in calling packages for Mexico or data packages for prepay customers.
The “featurephone” notion is an offshoot of the a la carte model. European operators and many in emerging markets are interested in the Firefox OS framework which would allow hosting of features on-network and a cheaper phone. AT&T’s profits were hit a bit by smartphone subsidies, so you can see why the latter point would be interesting. But inside the whole featurephone notion is the fact that operators recognize that ad revenues will be an unattractive profit strategy for them. For the most part the ads are linked to social or other portals already in existence, and competing with them is probably unrealistic. In addition, total available online ad revenue isn’t enormous. A pay-for market is better, and if people will pay for apps on a phone they’d pay for network-hosted apps. Most likely wouldn’t even know the difference.
The service-layer and management stuff is at the heart of this, of course. Operators are already spending on cloud data centers (F5’s gains in the SP space were linked to that, IMHO) and they’re eager to leverage them (as the NFV stuff shows), but the model of an agile service layer is still illusive. You need to define a “PaaS” platform for applications, you need a deployment model, and you need operations. It’s not clear how long any of those will take to mature, but one factor that may help things along is the increased interest of network and other vendors in what could be called “VNF authoring”. NFV is helpful to the extent that there are properly designed virtual network functions to deploy, and Alcatel-Lucent for example has just established a program, its “CloudBand Ecosystem” to encourage virtual function development.
A VNF authoring framework is a bit of a fuzzy concept. At the minimum, you need to have an application structure that can be deployed by NFV for hosting, and it’s not clear yet from the state of the ISG work just what the requirements for that would be. It might be necessary, or helpful, to include some platform APIs for integration with deployment and management services, but this area is even more fuzzy. We don’t know yet whether things like horizontal scalability are expected to be application-controlled or controlled by a platform deployment or management system, and we don’t know much of anything about NFV management in an official sense. I don’t have information on the program yet, and I don’t know if these details are revealed and can be made public. I do think that most vendor NFV strategies are likely to include a program to support VNF authoring at some level.
VNF authoring is a natural step toward service-layer deployment because unless you do a very bad job at defining the hosting framework for VNFs, you should be able to use that same framework to deploy SaaS elements or components of cloud computing services. That would make a VNF authoring strategy a natural step toward service-layer development programs and the de facto definition of a service-layer architecture. I do want to stress, though, that it’s the management of virtual functions or cloud service elements that’s hard, not the deployment. Otherwise we’re back to my early point; operations costs overwhelm capital benefits and the service price is too high to sustain market interest.