The Mobile World Congress event is arguably the most important carrier show, in no small part because mobile services are about the last bastion of profitability for operators globally. This year, we had for the first time quite a bit of NFV stuff presented at the show, and that’s important for the same reason the show is important. NFV has to be invested in to be successful, and it’s reasonable to assume that the investment would be easier in services where profits were still decent—like mobile.
The challenge with NFV and mobile is that NFV is already getting more hype than substantive announcements, and in the mobile space NFV substance is even harder to deliver. So…you won’t be surprised if I’m unimpressed in general by what happened at MWC.
Networks have traditionally been built from specialized appliances or devices, both for the data-plane handling and for control and higher-layer service features. When NFV came along, it was aimed at substituting COTS hosting for appliances, mostly in areas where data-plane traffic levels were modest enough to make commercial servers a viable way of creating the necessary features. Mobile service elements like IMS and EPC were targets for NFV from the first, and that’s likely why we see NFV promotion at a show like MWC.
The challenge is that we’ve always had hosted versions of both EPC and IMS, long before NFV came along. You could rightfully argue that many or even most of these were really “hosted” on specialized server configurations with specialized OS and middleware tools, but they were hosted nevertheless. One immediate question this raises is whether migrating IMS and EPC to COTS would really save all that much money. Another is whether “NFV” adds anything to the mobile picture overall, other than media cachet.
NFV so far is focusing its attention on software component orchestration, or the deployment of cooperative software-based components of functionality to create a cohesive network service experience. Obviously an experience that has to be created a bunch of times, ad hoc, for a bunch of people would benefit from automated orchestration, but you don’t instantiate IMS or EPC every time someone makes a mobile call. These are infrastructure components, things that are run and sustained for macro periods of time to serve multiple tenants. In my personal view, NFV adds little to IMS or EPC unless you presume that NFV’s mission goes far beyond simple component orchestration.
Let’s now address my first question. The value of COTS versus specialized platform for mobile components would depend, in my view, on one or both of two things. First, can you say that a COTS version of the component would be significantly cheaper? Second, can you gain some value from the ability of COTS to form virtual resource pools that can provide dynamic capacity for variable load and to respond to failures? If we look at these questions in combination with my NFV point, we arrive at what I think is the first of two central issues of NFV in mobile. That is mobile components are most likely to benefit from an NFV deployment if the components are cloud-optimized and if NFV is capable of exploiting all the cloud-related features in support of mobile components.
If that’s the “first of two” central issues for NFV/mobile, what’s the second? The answer is metro integration. Mobile isn’t a service in a vacuum, it’s an access alternative to wireline. Users of mobile devices still make calls and access online services, and these services have to be coordinated with mobility in order to be stable and consumable. Content delivery, in particular, is an important element of “mobile service” and yet content delivery networks aren’t traditionally part of mobile infrastructure. While CDN is another NFV target, the explicit integration of CDN, EPC, IMS, MRF, etc. is what the real target should be. We had some EPC stories at MWC but they weren’t anything more than hosting of components—back to the old part-of-the-story thing. We need more than that.
It’s my view that you can’t assert that you have an NFV strategy for mobile unless you can provide integration between the mobility-specific elements (IMS, EPC) and the rest of the service layer—especially the CDN. I also believe that SDN integration with mobility is essential unless you don’t believe that SDN will ever be used in the metro. If that’s the case, you don’t believe in any meaningful carrier SDN at all. So a good NFV story for mobile would also involve EPC and CDN based on SDN. Where were those stories?
Then there’s implementation. Nearly all the “NFV deployment” stories these days are OpenStack stories, and I’ve noted many times that OpenStack is not sufficient as the basis for NFV for the simple reason that it doesn’t effectively address the control of network connectivity outside the data center or the management of deployed/connected elements. I believe that OpenStack is one of the things that a good NFV implementation has to embrace because it is valuable in the data center, but it’s not NFV in and of itself. Come on, people! We’ve had OpenStack for years before NFV came along; if all you needed for NFV was OpenStack we’d not have needed an ETSI ISG. If your NFV strategy consists only of OpenStack, don’t bother to tell me about it. If somebody tells you about such a strategy, my recommendation is that you don’t bother to listen.
Taking IMS and EPC components out of appliances and sticking them in servers isn’t enough to make something NFV either. An obvious example is the notion of horizontal scaling. Stand next to an EPC or IMS appliance and yell “Scale Out!” Nothing will happen, for the obvious reason that physical devices can’t just be commanded to appear and disappear. Given that, taking code from an appliance and running it on a server doesn’t change the fact that it’s appliance code and no more likely to respond to your shouted commands than the original appliances were. If you want the implementation to do more, the code has to be more.
I offer the comparison of Metaswitch’s Project Clearwater stuff and the classic IMS as an example. Metaswitch’s approach was to treat IMS as a “black box” and replicate its external interfaces while at the same time implementing its functionality in a cloud-friendly way. That’s why you can scale it horizontally, for example. Metaswitch was named as a vendor partner in helping AT&T migrate to SDN/NFV, and in fact I think they’re the strongest partner that was named. They prove that what we need to see from “IMS-in-NFV-form” claimants is an implementation of IMS designed for the cloud, first and foremost. Absent that, vendors are just blowing smoke.
Management remains the big issue in “NFV” claims, but to be fair I don’t think the NFV ISG has gotten management right yet either. Virtualization of service elements and resources requires a different view of things, because the relationships among elements are elastic. This is what I’ve been calling a “Binding Domain” in parallel with the TMF Product, Service, Resource domains. I’m hoping that the TMF will step up and define binding formally, as well as model service functionality and resource capabilities in terms suitable for virtualization. Till something like that happens, we have no “M” in NFV’s MANO that is both sanctioned and effective.
We have a serious, growing, disconnect between NFV announcements and carrier goals for NFV, a divide created not by the fact that the standards aren’t ready or that there are issues with what’s covered, but by the fact that nobody wants to do anything hard, they just want good PR. A network revolution has to be funded by revolutionary benefits, and in the mobile NFV space in particular we’re just not seeing them. In two or three years, mobile infrastructure will be more ossified architecturally than it is today, and it will be too late to make major changes. We’ll have lost NFV’s best opportunity.