"Network Slicing" in 5G usually refers separation of the forwarding elements in the current EPC and their placement "closer" to the UE.   Why?   Because today's mobile networks are not actually mobile.

If you look at most (all?) of the sliced proposals, what you normally see is placement of the S/P functions and Internet ingress/egress (and MMTel services - more about those in a minute unless you get bored by the end of this email) adjacent to the eNB rather than in the current pre-aggregation/aggregation/core architecture.

Andrew's point - "error ... centralised/semi-centralised."  Yes.  30+ years of mobile networks shows that to be the case and that is what 5G slicing thinks it is addressing.

The problem that we have today is that the packet-core architecture is built around a single anchor-point on the P-GW.  Services such as VoLTE (actually VoIPoLTE) run totally over-the-top - the bearer binding is the IP address anchored above the P-GW.  If I'm on the same cell as you and we talk to each other over VoLTE, control plane for SIP is anchored above the EPC in the IMS and media flows between us above the P-GW.  The benefit is that if you (or I) move cells, chances are the additional RF and transport latency will be  << the packetisation period of the VoIP call (usually 20ms).  Add this to the typical EPC transit of 40-60ms, and you can see that you moving one cell and maybe adding 0.5 - 1ms of latency is going to have no impact on the packet ordering.

But, let's say you and I were on the same cell and media went direct and now you move to a cell homed on a different S (aggregation) gateway.  All of a sudden, you've added maybe 60ms of latency to the equation - 3 frames could be lost or (worse) re-ordered  which would break the VoLTE SLA (typical eNB handover ~10ms of interruption so no VoLTE packet loss).  So it is simpler to leave everything anchored.

There are other good reasons to hold everything on a central anchor; charging, LI and circuit-switched fallback on loss of LTE.

The problem we have in 5G is that to-date, VoLTE has really been the highest demand service in terms of quality requirements and, quite frankly, it is an adjunct service to LTE because the IMS and the MMTel services are disjointed from the EPC and are just a.n.other IP service (except in ONE important way which is that MMTel is linked to PCRF is linked to LTE modulation scheme selection via a dedicated bearer {specific APN} which means that from UE to MMTel I can guarantee QoS including over-the-air).

Now try and deliver the 5G Mythical One Millisecond service over this infrastructure.   You can't. 

So theory is we slice the network and place the forwarding elements and the packet treatment (e.g. MMTel VoLTE or the latest IoT app from the Sirrius Cybernetics Corp) on some kind of hosting thingy close to the eNB and we force traffic that matches some kind of rule to that service.   We do it for services which "need" low-latency, high-bandwidth because we recognise that we some services we don't care that much about.  Result?   We've just pulled out 40-60 ms of latency and we probably can deliver Mythical One Millisecond.  Woohoo!  5G!

BUT.

On what basis do we steer the traffic?  HOW do we steer the traffic (remembering that traffic across the EPC is in multiple GTP/IP tunnels and possibly encrypted).  

How about LI?   I can't tap at every base-station....  I don't have the bandwidth (plus that would make a tap potentially detectable).

How about mobility - I have the same issue as before and now I have to move and update a whole heap of state between adjacent base-stations and apps on hosting thingys.

How about HOW to disseminate all those policies and the Sirrius Cybernetics Corp's applications, etc?   How about the OTT apps (WhatsApp, etc) - are we going to insist those are "modularised" in some way so that portions run close to the UE?

This only works if UE and application terminating are within the same domain.  Doesn't help at-all if the application is at some distance from the UE across the EPC. 

No proposals to move away from GTP in 5G - how does that work then?  We stay anchored AND we have local services???  LIPA (Local IP Access) and SIPTO (Selected IP Traffic Offload) have existed for years in LTE and have been rarely use because of the LI/Charing/Mobility issues.   What changes here?


Does SDN and/or NFV "solve" these problems?   Nope.   

Could they be PART of a solution?   Mebee.

Highly personal and Sunday afternoon G&T inspired response.

David




-----Original Message-----
From: Next Generation Networking [mailto:[log in to unmask]] On Behalf Of Andrew Moore
Sent: 05 March 2017 14:09
To: [log in to unmask]
Subject: Re: Idle speculation

I'm not sufficiently familiar with the " 5G network slicing solution" to talk to john's point; honestly, I think the implementatin strategy is just that, but its still hard graft and sometimes heroic engineering - no matter how people slide it.

just observing the note about SDN tending to centralization

Id' always considered it an error to consider that SDN must be centralised or semi-centralised or ...

While most of the pictures of such structures indicate this, they actually tell a lie; most any (SDN) switch has a local processor etc etc, practically (from my own experience) SDN is about API definitions being open, extensible, and useful; thus, there is the ability to get into the control-plane data-plane interface - and in recent times we have seen the control plane - API plane (north bound interfaces in SDN nomenclature) have been where every Tom, Dick and Harriet have rerolled their own bad form of centralization etc.

The open/extensible/useable/useful API between controller and switch fabric (where I spend most of my care) does not preclude decentralization, nor does it preclude sensible 'core infrastructure' designs - it is only that so many of the first instance of (recent) SDN work seemed to also proclaim they had discovered (Ha!) the advantage of centralised administration as well.

I'd also suggest and wonder if there is a burden for each of these northbound API people (it might be 5g it might be 'funky new CDN' it might be 'some resiliance thingo') is they don't have much awareness of each others efforts and successes. Of course, building upon solid past success rather than rolling-your-own, gets fewer, so-called, Hot publications..... better stop there before my fingers are burnt.


My thoughts of this second.

cheers,
Andrew.



> On 5 Mar 2017, at 13:01, Jon Crowcroft <[log in to unmask]> wrote:
> 
>> I'm dubious about 5G network slicing solutions. Why make it a story 
>> about SDN and NFV? A solution in search of a problem?
> 
> John
> 
> indeed - the scale and resilience requirements for such a crucial 
> dimension of the service argue strngly against semi-centralised 
> solutions - i know of one massive data center failure which was down 
> to the SDN controller&vlan management, and that was a much simpler 
> (and
> localized) problem, which still needed very complex manual access to get the system up again.
> 
> the idea that we'd predicate a core critical infrastructure like 5G on 
> the same design mistake is daft. - I suppose we could replicate the 
> SDN controllers to every cell tower and then run some state machine 
> replica management algorithm, but why not just run some decentralised 
> dice&slice scheme in the first place...? what it would look like is 
> actually an interesting problem - another bad idea (I've seen in the 
> IETF) is something based on BGP:)
> 
> j.

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7998 / Virus Database: 4756/14051 - Release Date: 03/03/17