By Mika Skarp
Is Net Neutrality the fly in the ointment of Network Slicing? It depends on who you ask, and more to the point, what use case happens to fall under their microscope. The EU’s BEREC regulations on net neutrality go perhaps further than anyone has to draw out the discussion of where network slicing, (or “traffic management for special services” as they call it) finds its happy place on the free and open internet. Still we are only at the beginning of its ascent.
This has come into pretty clear focus for me over the past few weeks amid discussion with several leading European carriers, and as witness to others at the recent IEEE 5G-IoT Summit here in Helsinki. Partly as an update to some of my earlier blogs on the subject, and partly to sound the bell on this critical technology in the countdown to 5G, I’ll be pulling out my own microscope to yield what I hope to be a balanced view.
While Network Slicing has enjoyed an increasing amount of ink and attention of late, and particularly in the technical press, I guess it’s no surprise that most of the discussion happens at the conceptual or network platform level. This has been a pretty consistent theme since MWC last year when Network Slicing first began garnering attention amoung powers and influencers in our industry. If the elephant in the room is Net Neutrality, then the mice scurrying around under its feet are definitely mobile users and user experience. Unfortunately for both the debate and the advancement of Network Slicing, the lack of focus on user experience has been a considerable impediment. This was part of the inspiration behind our recent Cloudstreet whitepaper The User-Defined Network – Network Slicing in Practice, and the companion webinar series on the subject.
And though one might have been encouraged at all the star gazing at last month’s IEEE 5G-IoT Summit in the hopes of spotting Network Slicing’s “killer app”, it’s exactly the wrong end of the telescope to be looking through. Sure there will be IPTV and Public Safety, but the idea that one dominant app, experience or business model will rule them all is to fundamentally misunderstand the opportunity. I remember these very same discussions taking place in back in the late 90s and early 2000s with all of the excitement around the arrival of 3G. Of course Telecom was quite a different world back then, and it only made sense that 3G would be spoken of with the same limiting vocabulary as that of the dot com boom, but certainly we should now know better. Of course eventually we all figured out that there was no one killer app that would drive 3G business, but rather a cocktail of apps. Plus ca change…
But Network Slicing is different, and its very arrival will change the telecom business model forever. The ability to freely generate and manage virtualized slice-as-a-service clusters within a unified network is truly revolutionary. Cloudstreet is fortunate to have had a front row seat to this as we have been discussing the Network Slicing concept with dozens of mobile operators and experimenting with and deploying the technology for at least 4 years now. And though we don’t like to think in terms of a single, killer app, we often do get asked what application we think will be the first to utilize Network Slicing technology. And aside from the obvious use cases, that are already in the works like public safety (with FirstNet and AT&T) and IPTV with several carriers here in Europe, we prefer to talk about Bandwidth-on-Demand and specifically the Application-Aware Network framework delivered to users via the Cloudstreet Mobile App and Dynamic Profile Controller™ (DPC™).
This not only helps to illustrate the “what and why” of Network Slicing, but opens up the dialogue on “how and for whom”. We’ve developed over 10 specific use cases with one common, critical feature; They will all be supported by rock solid SLAs provided by the MNO. Some of these will enjoy the very widest market reach, while others will serve very niche customer segments. The main point is precisely that there will be no one big use case for network slicing, but rather a multitude serving their own unique market needs. As a Canadian colleague often quotes his country’s unofficial self-reflection, that of being “a nation defined by its diversity” - I see this a good metaphor for network slicing. And just as the democratic principles of transparency, fair treatment and equal opportunity are the basis of any healthy diverse society, Net Neutrality must come early to the conversation. I am happy to report that after presenting various use cases, it is almost always the very next point of discussion.
The Elephant in the Ointment
While there may be countless ways to open this topic, it never hurts to ask the very toughest question right out of the gate. Is Network Slicing at odds with Net Neutrality? The simple answer is no, and fortunately so it the more complicated one. But there are a number of key factors that need to be taken into consideration when moving toward any implementation, including:
- Net Neutrality means that everybody has similar access to Internet and the Internet can be used freely without blocking, throttling or slowing down access to certain sites or functions. So while it would be strictly forbidden to drop packets of, say, an OTT VoIP service, It’s ok to pay your carrier more money to get more bandwidth.
- Network Slicing flips the status quo of networks and devices on its head. While its first mission is to improve customer experience by differentiating traffic based on application need, this itself amounts to a paradigm shift. Whereas in today’s networks, applications adapt their performance to the network actually providing the capacity, in a sliced world, the network is adapting its performance to requesting application's need.
- The more resources that can be shared, the more affordable a service will be. So dedicating a lot of resources to serve only one slice, means that the price of that slice or service will be very high, just as it would be in a proprietary network.
- Fourth, the EU’s BEREC Net Neutrality guidelines define two high-level policies; The first policy is around “Traffic management” and the second governs “Special Services”. Both are acceptable with certain conditions attached. We should note, that though that ball is in the air in the US with the FCC's very future at stake, this is practically the same provision in that country.
According to the EU the “Special Service” class is defined as those applications that in order work as expected actually require special treatment, and this would need to be objectively verifiable. While this clearly opens the door to Network Slicing on a case-by-case basis, in practice, this means that we can’t do any significant buffering. Good examples of special services are voice (that is already prioritized), as well as linear TV and services requiring real-time monitoring in areas such as healthcare or IoT. But to make these services meaningful for end users, iron-clad SLAs needs to be in place and enforced. In our paradigm of a massive dynamic slicing, an SLA means first and foremost that admission to enter a slice needs to be granted even in the case where the slice is used by only one organization.
The Special Service must also be distinct from any generic Internet service, and does not provide access to the Internet according to the BEREC Net Neutrality Guidelines. They state, however, that a “logically separated connection” from any generic Internet services would be a suitable way to deliver such a service. And what, precisely is a Network Slice, if not a logically separated connection? A Network Slice can be configured to only have access to a certain percentage of overall network capacity, and access to the slice is granted only to the Special Service. The BEREC Guidelines further elaborate the requirement stating that the operator providing any Special Service must guarantee enough bandwidth for generic Internet traffic. Together, these requirements mean that Network Slicing is not only the optimal solution for delivering Special Services and Traffic Management, but the only way to ensure these initiatives fall within the principles and practices of Net Neutrality as laid out by regulators.
But lets take a deeper dive into the details with some pretty straight forward cases. “Traffic Management” means that Network capacity can be tailored for certain application classes or categories, but only if all of the applications within that category are treated equally. We should remember that the goal(s) should be both to improve the performance of the given traffic class, but also to increase the general performance of the Network. A good example is Video-on-Demand (VoD) services. With an extremely large buffer, you can make VoD work under almost any network conditions. However, with Network Slicing we can make it work better, and actually provide the kind of user experience that most customers expect today. By “better” we mean that videos will start faster, that the picture quality will be consistent and that network resources won’t be wasted on dropped buffers, or re-transmissions.
The BEREC guidelines again provide some insights here, and specifically into how Traffic Management must be implemented. First, it must only occur be when necessary, it cannot rely on investigating the IP traffic streams or packets, and instead must rely only on information sent to the network by the applications themselves. Yet more set solid confirmations of Network Slicing as the correct approach. Another important requirement is the measure that requires that any traffic management schemes must be proportionate, and they should never be allowed to hog the entire network.
All of these conditions lead for us to an indisputable conclusion that Application-Aware, Dynamic Network Slicing is the only way to meet the regulation. Not only is Network Slicing as a concept already accepted by EU regulators, but the specific manner in which it may be done, under the heading of Exceptions, Justifications and Special Services, places Network Slicing in the catbird seat as the only model that can deliver on these requirements. if implemented correctly all admission control to any slice will be upheld, while upper limits to how much total network capacity can be consumed by the slice will be orchestrated accordingly. And again, the only way to trigger the slice will be via application awareness and never by inspecting traffic flows. It seems we have a clear winner.
Cloudstreet – The Network Slicing Company