In this installment of Network Slicing 101, we’ll examine the basics of what is meant by end-to-end as applied to network slicing.
When we hear about network slicing, one of the most common attributes associated with the concept is the notion that the slices will need to be enabled on an “end-to-end” basis. Along with “ecosystem”, end-to-end might be one of the most over used terms in the telecom lexicon. At the same time, it is one of the most crucial to creating proper network slices.
End-to-end means network layers and devices
At its most basic level, end-to-end means exactly what it says. It is a soup-to-nuts approach to being able to create a network slice that cleaves through all network domains. In a wireless setting, this means being able to slice resources in the radio access network, edge/core, and transport network domains. This is not a simple task, as it essentially involves virtualizing nearly every aspect of these network domains.
It also means being able to provision any and all applicable devices (which in a network slicing context are commonly referred to as User Equipment, or “UEs”) to interact with one slice, or a combination of slices that might be created to satisfy a particular use case. In practice, this could mean setting corporate bring-your-own-device policies so that only a subset of employees can access the services running over a particular network slice. It could also mean an array of vehicle types (e.g., public safety vehicles vs. fleet vehicles vs. mass transit vehicles) being able to access certain slices in a V2X-type use case.
End-to-end also means service layer automation
Beyond networks and devices, end-to-end also means a comprehensive approach to network management and operations. While often times taken for granted, this coordination at the service layer is arguably the most complex. For network slicing to work, the OSS and BSS systems must be able to fully partition all service parameters with in a particular network slice. This means, among other things, the ability to have unique service-level agreements and security requirements for each slice. Eventually, it could require the ability to allow slices to interact with each other in a setting where multiple slices are needed to satisfy a particular use case (e.g., a “factory automation slice” which might actually be made up of multiple slices to satisfy a range of requirements).
Further on, the network operations and management slice it will also mean movement toward enabling closed-loop operations through-out the entire service lifecycle. In practical terms, this will involve providing end users with the ability to order network slices on demand, have all the necessary network resources and service layer requirements orchestrated to support fulfillment and assurance of the service, and, of course, billing for the service largely without the need for human intervention in the process.
Taking the concept a step further still, it will also mean the ability for network operators to adopt profound organization change in the way services are designed, brought to market in maintained. Often this requirement is explained under the umbrella term of “digital transformation.” One key aspect of this transformation will be the ability to adopt agile design processes (e.g. DevOps) as opposed to the more static waterfall design processes that are overwhelmingly more common in operator development organizations today.
