Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Thursday, July 14, 2022

Network Slicing is a huge error for the 5G industry

(Initially posted on LinkedIn, here. Probably best to use LI for comments & discussion)

I've started calling myself a "Slice Denier" or "Slicing Skeptic" on client calls and conference speeches on #5G.

Increasingly, I believe that #NetworkSlicing is one of the worst strategic errors made by the #mobile industry, since the catastrophic choice of IMS for communications applications. The latter has led to the fiascos of #VoLTE and #RCS, and loss of relevance of telcos in communications more broadly.

At best, slicing is an internal toolset that might allow telco operations or product teams (or their vendors) to manage their network resources. For instance, it could be used to separate part of a cell's capacity for FWA, and dynamically adjust that according to demand. It might be used as an "ingredient" to create a higher class of service for enterprise customers, for instance for trucks on a highway, or as part of an "IoT service" sold by MNOs. Public safety users might have an expensive, artisanal "hand-carved" slice which is almost a separate network. Maybe next-gen MVNOs.

(I'm talking proper 3GPP slicing here - not rebranded QoS QCI classes, private APNs, or something that looks like a VLAN, which will probably get marketed as "slices")

But the idea that slicing is itself a *product*, or that application developers or enterprises will "buy a slice" is delusional.

Firstly, slices will be dependent on [good] coverage and network control. A URLLC slice likely won't work reliably indoors, underground, in remote areas, on a train, on a neutral-host network, or while roaming. This has been a basic failure of every differentiated-QoS monetisation concept for many years, and 5G's often-higher frequencies make it worse, not better.

Secondly, there is no mature machinery for buying, selling, testing, supporting. price, monitoring slices. No, the 5G Network Exposure Function won't do it all. I haven't met a Slice salesperson yet, or a Slice-procurement team.

Thirdly, a "local slice" of a national 5G network will run headlong into a battle with the desire for separate private/dedicated local 5G networks, which may well be cheaper and easier. It also won't work well with the enterprise's IT/OT/IP domains, out of the box.

Also there's many challenges getting multi-operator slices, device OS links to slice APIs, slice "boundary controllers" between operators, aligning RAN and core slices, regulatory questionmarks and much more.

To use an appropriate analogy, consider an actual toaster, with settings for different timing, or a setting for bagels. Now imagine Toaster 5.0 with extra software smarts, perhaps cloud-native. Nobody wants to buy a single slice of toast, or a software profile. They'll just buy a toaster for their kitchen, or or get an "integrated breakfast solution" including toast in a cafe. They won't care about the slicing software. The chef might, but it's doubtful.

If you see 5G Network Slicing as a centrepiece of future "monetisation", you're in for an unpleasant smell of burning, and probably a blaring smoke alarm too.


 

No comments: