Showing posts with label Google Fi MVNO. Show all posts
Showing posts with label Google Fi MVNO. Show all posts

Monday 11 May 2015

NFV cloud MVNO conference 2015

Cloud NFV MVNO MVNE round table #MVNOIS 2015

As the first on some hopefully more views from the #MVNOIS conference 2015 in Nice, here is a quick note on the round table I was dragged onto by Informa due to having being building a fully cloud based NFV MVNE platform for the last few months. Google's project Fi has brought a lot of this to the forefront as global MVNOs and multi-national roaming require NFV and cloud MVNO.

NFV MVNOs and MVNEs making way for more disruptive, flexible, global / local mobile services
The round table was interestingly represented by HP (whose servers we incidentally used for our cloud NFV MVNE) Oracle (think Tekelec, ACME), Syniverse and Yaana, which gave us a very good panel of people in the industry in the security, law enforcement, hardware, software and cloud services space.

The most interesting outcomes were as follows:

NFV Cloud MVNO makes it easier and good for Global

One of the key take aways was the fact that NFV and Cloud makes it easier to roll-out and scale MVNOs and MVNEs nationally, and internationally. I can relate to having built international MVNOs and MVNEs - having to chose, MVNA / MVNE, full MVNO or Build Transfer Operate MVNO model from the beginning, possibly having to throw away one or more of the platforms and re-issue MVNO SIMs if you get it wrong is a big challenge. Similarly, so is global expansion: having to use one platform in one territory (e.g big/full) and another in another (e.g. small/MVNA) is just not good.  

NFV cloud essentially brings IT plus Telco together: good for LTE & WiFi

In the good old days you had to buy lost of boxes to run a mobile network, then lots of boxes to run a wi-fi network - if you wanted to make them work together, you needed more boxes, more integration... NFV Cloud lets and MVNO or MVNE run all / mots of its services on a virtual machine, as well as the wi-fi management. In pure LTE terms this means an radius and diameter on the same boxes, same network: think lower latency

NFV cloud MVNOs and the eSIM

Previously a lot of MVNOs got into trouble, if they were ill-advised, by not putting the right provisioning, activation, and SIM management processes in place from the start, which can be very costly as the MVNO grows: many believe a SIM costs less than a dollar, which it does in terms of the 'plastic', but the association of this SIM with a mobile core, OSS / BSS, CRM, BI, etc systems is at least ten fold if not more. An MVNO usually only orders a few hundred thousand SIMs max up front; eSIMs however, due to the large up-front volume, mean next generation MVNOs and MVNEs are having to look NFV and cloud based to be cost effective. Period.

NFV is more disruptive

NFV essentially separates out the hardware from the software, meaning that costs are contained, distributed, transparent and delivery / transition is simpler, quicker and as local / global as required

NFV is not pure cloud and still needs localisation

The biggest misconception that brings walls and heads together is the concept that you can run this anywhere: the truth is that a lot of it you can, and as we move to LTE and away from legacy signalling and media we will - but the truth of the matter is that certain services mean locality is essential: HLRs and HSSs often need to keep data protected in a certain area and GGSNs  / PG-Ws need localisation to avoid latency, then there are security, government intervention and other issues to consider. 

NFV is about standardised hardware

a common view / misconception about NFV is that its all virtual machine and cloud, but a key component is the ability to break out from the virtual environment on standardised hardware when necessary. A great example was from Oracle where they have had to break-out voice encoding into a standard non virtualised machine. We have found this with certain media drivers as well. The key here is that: you have all that is possible on a, for example HP server(s) but the voice encoding needs to go native: then you add another, in this case, HP box of similar specs, with more or less known specification, most likely the same drives, memory, SAN, etc. and have it running voice outside of NFV.