Let's get started with one of the buzzwords that some of you may have heard of already, but if you haven't, no problems here is where we'll look at a few more details about it and that is network slicing. Before we understand network slicing, let's visualize how the traditional cellular networks or core network specifically were deployed. In traditional technologies such as lt your core network components, how many ever they maybe were treated more or less as one homogeneous black box. If you had to serve more users or different applications, you will simply pick up a few additional resources from that homogeneous black box. And you will facilitate that additional service or additional users. So in terms of 5G if we went with that homogeneous approach, so to speak, then as always. If you focus on AMF, SMF and UPF you would have just a homogeneous box containing all these components. And you would simply assign those components for different users or different purposes. However, this homogeneous approach doesn't work very well when our applications or use cases are becoming as diverse and as aggressive as they are becoming in 5G. We saw earlier, we have eMBB, we have massive IOT, we have URLLC all with desperately different requirements with respect to support latency and connection density. And as it turns out that serving such disparate applications or service classes using this homogeneous network approach isn't optimal anymore and I can give you a couple of examples reasons as to why. For example, if a certain group of components, let's say a few AMFs go down, then you don't know what service was using those AMFs. Because you had allocated them in a homogeneous manner or a black box manner. So chances are all the services that your network was offering, let's say IoT or URLLC or eMBB those services will be affected. And that would ultimately mean that some of the stringent requirements of those services will not be met. So that is one reason why this homogeneous approach doesn't make sense anymore. Another reason is that for example, as you know, eMBB would require a lot of user plane resources whereas IOT for example would require very few user plane resources. But because it would handle millions of devices in a square kilometer, it would require many more SMFs and AMFs as compared to UPF. So applications have widely different requirements and hence they are also going to require widely different amount and types of resources inside the core network. So these are a couple of salient reasons for which this homogeneous black box approach of allocating network resources doesn't work or isn't optimal anymore in 5G terminologies. That is where network slicing makes its entrance. What is a network slice? Well, network slice is a subset of the available network components that can provide an end to end service. So instead of this homogeneous network wherein resources are just a bundle altogether. Imagine you had those resources logically partitioned to different services precisely depending upon their individual needs. Keep in mind that every slice so to speak will contain at least one instance of every network components so that you can promise this intelligence service. But beyond that you can customize the deployment of a slice precisely depending upon the needs of the application you are going to serve. For example, as I mentioned, IoT will require more SMFs than UPFs. So the network slice or the logical subset of the network components that you have a portion for providing IOT service. You can have that slice contain many more SMFs than UPFs at the other end of the spectrum for an eMBB slice where emphasis is on throughput. You can have many more UPFs as compared to SMFs or AMFs and by separating the resources logically at least into different slices, you will have made sure that. You will have the ability to precisely meet all the aggressive and diverse requirements of different applications. And this will allow you to serve different applications within the confines of the same broader network but by creating logical subsets of different network components. Precisely depending upon the news of the applications that they are ultimately going to serve. So the second problem that I mentioned about the black box or homogeneous networking is already solved here. The first problem about component false, so to speak. So for example, let's say that in this new example your AMF related to IoT service goes down sure, a part of your IoT service will be affected. But because that IMF was responsible only for IoT service, you're URLLC and eMBB service can continue operating as if nothing happened. So you have isolated the points of failure and thereby you have contained any possible failures to a single service rather than those failures. Magnifying and percolating across different services of your network as the otherwise would homogeneous or black box network approach. So those are some of the benefits of network slicing in that not only can you allocate resources in a slice precisely depending upon the needs of the application or service class, it is going to serve. Which is the first point here, but resource isolation among services allows you to contain your possible failures to a limited number of services, letting all the other services operate without any problems. Not only that, it allows you as a network operator, it allows you to offer flexible subscription model. For example, what if there is a certain company that only wants its devices subscription to IoT like services. Then at a more reasonable and affordable price, you can give that customer access only to the IoT slice. On the other hand, if there is another customer that needs access to eMBB resources, you can sell that customer only for the eMBB sliced subscription. And the users of those customers will not interfere with your other slices. So flexible subscription model is another commercial benefit of network slicing. If this technical discussion kind of happened to throw you for a loop, that's okay. Let me give you a simpler example, in order to understand network slicing in everyday terminologies. Let's say that you are hosting a dinner party, everybody has had their dinner and it's time for you to serve desserts. Let's say that you have baked a nice chocolate cake for everybody to enjoy for somebody with a sweet tooth. For somebody who likes a chocolate cake, they'll definitely ask for a bigger portion. Whereas for somebody who's trying to cut down on sugar or somebody who's already full with dinner, they'll probably ask for a little piece of the cake. But because you have the whole cake before you and you have a tool or the knife to cut the cake, you can give a bigger slice of the cake to the first person. And to the second person, you can take a slice out of the same cake, but you can give them a narrower or a smaller slice. If somebody wants to go for a second round, you can cut them an additional slice from the same cake. If it turns out that you happen to cut more slices than there were guests, you can safely keep the extra slices back into the same cake. And they'll appear as if they are part of the same cake because they in the end came from the same cake. So in this example, cake is your common bucket of network resources, whereas different slices of cakes that are cut precisely according to the tastes and requirements of individual guests. Those different slices would be the slices of the network that are commissioned and implemented specifically, depending upon the needs of different applications. So that is the concept of network slicing and those are some of the fundamental benefits that it offers.
