Analyzing the number of variants of network slice types
Looking solely at the core network level, analyzing the functional and characteristics requirements, there may not be so many different types of network slices. However, when combined with other factors such as operational, service or business oriented, we can see that the number of variants of network slice types, and thus blueprints, or templates as we call them, may be quite high.
Slices may differ in terms of size and capacity, to what degree they share resources with others versus the need of isolation or other capabilities that are bundled such as applications also running in the slice. When combining all of these, the list of potential template and slice types can grow long. Any template can generate any number of instances. And the number of instances can for example be driven by the need of isolation per customer.
In a simple example, the capacity of a network slice could be expanded to accommodate anticipated demand created by a major sporting event. Instead of needing prior cooperation between the customer and the network operator, and re-provisioning by the network operator, the customer would be able to perform the required service changes themselves.
Through the introduction of virtualization and orchestration, customers can be offered control of the assets within their network slices, and even create network slices on demand and characterize them for their specific needs. It’s important to note that end-user services, consumed by individual devices and applications, are realized within the network slice, independently of the network operator.
The network slice may therefore contain instantiated management functions needed to supply or maintain the end user service. In some business models, a ‘Network as a Service’ (NaaS) customer may even take full operational responsibility for this service, using in-slice management functions. Although NaaS has been proved as a successful business concept, we are moving into a new era of possibilities, and use cases will regularly break new ground.
So, how many templates and slice instances will there be?
It is a question that doesn’t have simple answer. Obviously it needs to be driven from a business perspective. If creating a separate slice instance brings no value to the business in terms of new revenue, faster TTM/TTC, lower cost or lower risk, there is no reason to do it. Given that there may be limiting factors. If having a large number of slice instances but lack of automation, or cost overhead due to lack of multiplexing gains, it would drive opex and capex and kill the business case.
In other words, the better we can automate management of slices, and the more autonomous we can make them, the more of them we can have without driving cost, and the more we can realize the business potential coming with network slicing.
There may also be technical limitations, inherent to standardized architecture or implementation that prevents a wider range or number of network slices. As such limitations can go away, or be limited, over time, it is reasonable to assume that initial deployments will only have a limited number of network slices, while this can be scaled up over time as technology and solutions evolve. And how many is determined by the business need and operational efficiency.
Network slicing is often associated with 5G, but in reality it can equally well be done with 4G. Start simple, where it will make sense in 4G, learn and increase the complexity gradually. Then 5G will come with more advanced use cases.
Coming back to the crystal ball
Who would be better than Henrik Basilier, Expert Network Architecture Evolution to elaborate on where we are going in one to five years with network slicing? Listen to this podcast where he shares what’s happening in the market, the big challenges and benefits with network slicing as well as when we will reach the programmable network.
Link to Podcast
Want to know more about how to tailor services using network slicing? Download the paper "Network slicing can be a piece of cake".
Read more about how to prepare your core network.