Slicing was one of the greatest promises of 5G: one physical infrastructure, many logical networks, each adapted to a different customer or operational need.
Its simplicity was deceptive. Network was already complex and slicing was multiplying this complexity. And it added on top separated configurations, policies, monitoring, assurance, and lifecycle management.
Slicing promised:
-
Privacy and separation. But privacy from whom? If the goal is separation from other customers, the operator is already expected to provide trusted separation. If the goal is deeper isolation, then it should probably be treated as a separate deployment, almost a parallel network, not as a slice of a shared one.
-
Different functionality. DECOR already provided a form of core-network slicing based on UE classes or UE characteristics. What 5G slicing added was a broader slicing model, where slices could be associated beyond device classes, with services, customers, or use cases. That distinction matters, because a customer slice may still contain many UE classes and therefore may reproduce the same internal complexity as the operator network.
-
Differentiated Quality of Service. Put bluntly: QoS differentiation is available without slicing. Priority, latency, throughput, and reliability differentiation already existed in different forms. Slicing often repackaged this into a broader architectural story.
-
Customer self-management. This sounded attractive in diagrams, but it is questionable in real deployments. Operators operate networks, not customers. Most customers just want a service that works and with clear guarantees, not more responsibility.
-
New operational models. Mobile networks are strong when they are built and operated at scale: bulk infrastructure for bulk services. Slicing looks towards a long-tail model, with many smaller cases, each needing specific integration, assurance, support, and operational treatment. That does not scale in the same way. It needs another operational model.
The issue was not that slicing was technically wrong. The issue was that slicing multiplied functionality, responsibility, and operational surface before the industry had a simple model for operating that complexity.
This is one of the half-truths about software-based networks. More software can create more flexibility. But it can also multiply the number of things that must be configured, assured, monitored, and explained. How to achieve this flexibility in 6G, will come in a next post.
If 6G again promises customized, programmable, intent-based, or customer-specific network services, then it must be clear what is truly slicing, what is a separate deployment, what is only repackaged QoS, what the operator still manages, and what the customer actually wants to control.
LinkedIn: 