(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:
Post a Comment