re: Clouding Up the NFV TransitionI believe the 2c/sub applies to only SOME of the solution. No SBC, no media gateway, no carrier services, no provisioning solutions or back-office management systems. All that still requires investment and ongoing OPEX and dedicated internal resources. While an impressive figure, it's an incomplete. The true cost is much higher.
And yes, I use gear here to hardware and software. It does indeed conjure up images of boxes with many wires.
re: Clouding Up the NFV TransitionHey, Kevin - by 'gear', in this case (re. your fist sentence), you are, of course, talking about software. The word has such a 'hardware' connotation! :-) Re. your other observation, you are right. Naturally this multi-tiered model (wholesale / retail) is dependent on getting the cost out of the service. A cloud-based IMS core, app servers and session border controllers will enable that. There is a simple worksheet on the Project Clearwater web site that enables anyone to calculate the cost of an IR-92 VoLTE service in a cloud environment. With current AWS it's under 2c per sub per year - and the way Amazon are slashing their prices, that'll only decrease over time.
re: Clouding Up the NFV TransitionThe ETSI NFV ISG is all about deploying functions within a cloud environment. Indeed, a lot of the work-in-progress is around management and orchestration (MANO) in such environments. CloudNFV can be seen as the 'plugfest' arm of the ISG, IMO. They will work closely with the (new-ish) proof-of-concept' (POC) arm of the NFV ISG. We will hear about the 6-founding members in September, I believe. Although we already know that the one non-founding member is Metaswitch, as the group is looking at Project Clearwater as the first POC.
re: Clouding Up the NFV TransitionThere's not really a disconnect - I think the Cloud NFV folks are looking to add some greater clarity on how delivering network functions virtualization through a cloud ecosystem delivers additional advantages. Cloud was initially part of NFV's charter, as I recall. CloudNFV will disclose its membership this fall, I believe. I don't think they were necessarily ready to start talking publicly but they were discovered by an eager reporter and have been gracious enough to share some basics.
re: Clouding Up the NFV TransitionCorrect me if I'm wrong, but I not sure whether there is necessarily a disconnect between the NFV group and the CloudNFV project. My understanding is that NFV wants to get away from proprietary boxes--thus the software providing the services can run on COTS servers or in the cloud. In other words, NFV is not saying the service cannot or should not be in the cloud--it just does not want to buy boxes.
One thing I do find puzzling is that CloudNFV has not disclosed its membership, because typically when a group like this is formed, one of the first things they do is disclose the membership.
re: Clouding Up the NFV TransitionCloudifying the network still means the providers buy and operate gear even if they put it on someone else's servers "in the cloud". That's not the only choice and, for some services, we think the time has past where all providers must each run their own network. Cloudsourcing VoIP makes a ton of sense given the voice market dynamics, next gen network costs, and the importance of focusing limited resources on broadband, mobile, video and other strategic initiatives.
Cloud voice platforms enable the outsourcing ALL the aspects of the voice network to the cloud lets service providers stay in the triple-play game without the hefty bill or resource drain.
re: Clouding Up the NFV TransitionCouldn't agree more, Carol. While there will be some value in NFV on COTS, the long term play for Telcos has to be in the scalable, fault-tolerant, highly elastic cloud. Metaswitch first showed our Perimeta SBC working on AWS last year. Project Clearwater (open source IMS core) also runs on AWS - although the community has shown it spin-up in Azure as well. Of course, the software has to be designed with the cloud in mind (which does require some smarts to deliver real time comms in a traditionally async environment). I actually think the conversation is also going to tilt towards the public end of public/private clouds. Sure I get the desire/legacy that says Telcos "must own it themselves" but the cost benefits of public clouds are going to be compelling. And with Amazon co-locating in data centers around the world, there won't be performance trade-offs. The software telco will happen.
And yes, I use gear here to hardware and software. It does indeed conjure up images of boxes with many wires.