Are current 5G requirements and the cloud telco incompatible?

So here is a bit of more expanded thinking (and I hasten to add this is my thinking rather than GSMA’s at this point).

The 1ms delay requirement that a bunch of organisations quote for 5G requires some pretty fundamental changes. Two use cases are quoted as driving it:-
– Vehicle (to network) to vehicle communications for accident avoidance.
– AR, VR and Immersive Internet delay budget for prevention of cyber sickness.

The first I think is a bit bogus – I can’t see how, or indeed why the network should be included in V2V comms for preventing accidents, although I do also have a small issue with ‘backwards compatibility’ in V2V scenarios if I happen to be driving an unconnected car and the cars either side of me start autonomously braking.

VR and Immersive are not necessarily that ‘mobile’ in the way they will be delivered, since VR is fully ‘virtual’ in that it has no reference to actual relaity (else it is augmented reality, right?) and so it requires a user to be in actuality somewhere where they aren’t going to bump in to things. Immersive Internet is displacement experience to another location (although that location, and the images conveyed from it still have to meet and react to gesture within that 1ms delay).

AR is the real challenge because the content to be served has to keep up with the user’s movements, and also is contextualised by the local environment. That means the content has to be served dynamically and reactively from a source within 1ms of the consumer, which in turn says, at the bottom of the mast, or at worst within a small number of metres (which I think is larger that the number of metres for BBU hosting in C-RAN). That is why the Saguna/Akamai CDN-at-the-base station work is interesting.

The problem with content close to the user is handover. Not only does the RAN need to take account of the shift from one cell to another, but the content needs to move across too. This is not an issue right now because the bearer is uninterrupted, but if the bearer terminates at a cell, and the customer moves to another cell, then the bearer has to shift too, and take the content context with it.

It is worth noting that 1ms delay does not apply to every service identified in association with 5G, so when it comes to things like content cahcing and Zipf law (I spotted Kit’s tweet), because the content delivered for AR is local in context, it’s not such an issue.

It also strikes me that for most of these use-cases, having “content” at the base station is the least of your worries. It’s the application logic which is going to have to be somewhere else – you’re not going to host a full copy of SAP, sensor data-analysis algorithms, a VR game, or advert-insertion in a local Akamai node, presumably.

… as otherwise we would have already seen those functions replicated in every DSL or fibre broadband distribution point.

A couple of points:

1) 5G seems to be an interesting collection of very different applications and mutually incompatible wish lists. Unless we can actually say “what problem are we trying to solve?” then quoting a requirement in isolation seems daft.

2) The LTE 8ms HARQ turnaround is pretty challenging and complicates / precludes a lot of deployment architectures. For example cloud RAN might require dark fibre to meet this timing. So anything that makes it 8X harder had better have some really good rationale.

3) I can’t see the logic for 1ms – even from Dan’s example.
Two cars colliding with closing speed 0f 200mph (which is quite extreme!) is 89m/s – so 89mm in one millisecond. Do we really need to specify a technology in order to make that precision? Let alone the point it should be local, not cellular. And for AR or VR we would be even slower.

Keith, thanks for kicking off a fascinating discussion. I’m seldom tempted to join online debates but I’ll make an exception here. To Keith’s point that “nobody’s going to invest in all that just to enable some AR apps are they[?]”, no, clearly this would be an example of the double-headed killer app fallacy i.e. don’t expect to find one and if you think you’ve found one you are almost certainly wrong. The reason I agree with Dan about the Saguna/Akamai approach being shrewd is that it is a multi-faceted, multi-phased platform approach – by no means a one-trick pony for one specific use case. Phased rollout strategies involving a bridgehead based on the cost saving dimension of transparent caching and the side-benefit of QoE improvements for the most popular content are a logical first step. Even within this first step, the devolved functions are multifarious. Take the most simple one of all: the enablement of caching for DNS lookups at the eNodeB. This alone eliminates many, many TCP roundtrips for a typical page download and bucks the received wisdom of those citing Zipf Law. The fact is it works beautifully on reasonably modest served user populations. A second phase involving managed content (aka Akamai and…) is a natural progression that can (if Akamai is considered to be representative) enable the elusive “host the OTT” revenue opportunity. The third phase is the ability to run any server-side application in the eNodeB. To Kit’s point about Lawful Interception and security, Saguna have defined an architecture and set of mechanisms complementary to 3GPP that solves the tricky LI and mobility management issues without wholesale devolution of the entire EPC to the edge. Elsewhere in the ecosystem, Intel is doing some interesting things to ensure the secure “bubble” Meanwhile, to Dean’s skepticism about functional distribution to the edge of networks, the analogy drawn between mobile and fixed is debatable. What is the fixed equivalent of an AR app? What is the mobile equivalent of a set top box? How do latencies compare in FBB vs MBB? How do unit cost structures compare? The differences outweigh the similarities. So, how can you conclude that access-side hosting of latency-intolerant and/or repetitious viral content won’t happen in mobile because it didn’t happen yet in fixed?

Dean, thanks for clarifying. In fact it seems we are pretty much aligned. I do concur that it is not a binary edge vs cloud debate. No way does every AWS service start to spin up in a base station! I see the definite need for a selective smorgasbord of content and web services that yield benefits (in 3 dimensions of cost, quality and revenues) from edge-hosting. In other words the smorgasbord menu consists of a subset of Akamai’s services plus a subset of AWS plus a subset of de facto and proprietary CDN and OTT clouds’ services/distribution layers. Multi-tenancy (to extend the virtualised edge for multiple cloud partners) is key here, as is cooperation with hosted 3rd parties to ensure that the orchestration logic exists to extend selectively certain services/layers to the edge. The latter will no doubt involve direct engagement with the big players (e.g. Akamai etc) and this is where the current energy is being focused but as things pan out, more of a “development kit” approach will emerge for the long tail. Such cooperation is already bearing fruit: take the Saguna/Akamai case for example. By extending Akamai right to the service provider access edge, suddenly the growing volumes of HTTPS traffic managed by Akamai becomes cacheable on the user’s side of the key bottlenecks. This has become possible because of a new synthesis of CDN and access network. Disruptive, huh?