Looking at, more specifically, then, for three of the use cases in IoT-- narrowband IoT, and then a next generation core user in the 5G network-- we've identified some of the elements by name. And this is probably the first time that we've, in these sections, introduced some of the [INAUDIBLE] alphabet soup, if you will-- and that is the long-term evolution, mobility, user endpoint, interconnected. So now we're thinking about a connected car, in the top diagram, connected into the enhanced node B; the stuff that is at the radio and the base station of the elements; and in some of the interfaces, to both the signal end gateway and a mobility management element that are part of the evolved packet core. And this shows the separation on the S1-U plane of the data plane portion from those elements and the control plane on the S1-AP coming into those elements-- the SGW and the MME. And then finally, off of the SGW, we've got the packet gateway that allows, then, the connectivity off into the deeper core of the network. And that's the interface that we would expect this large volume of data traffic to take in the user plane route in that network slice that is the connected car, the mobility device. And then a lighter bit of functionality that takes place through the MME, the signaling aspect of it-- again, into the core of the network when appropriate. The next one, in the middle, is a narrowband IoT use case. And in this case, we're showing that the endpoints are probably stationary. And their functionality in this use case doesn't have that mobility aspect to it, again, by that nature of it. And hence, their interaction with the MME is not significant here. As a matter of fact, it's not present at all. This is primarily a high capacity data plane use case. And the narrowband indicates that those endpoint devices are probably working in a particular spectrum of the radio that doesn't require as high a throughput as you might have for a video. And then the final use case that shows us, as another slice, is implying in the medical case, maybe we've got a next-generation core functionality that has both a relatively high signaling plane and data plane that has been consolidated into that next-generation core. So this is beginning to lay the foundation for what we're going to talk about-- are the slices that exist into that network. Let's take a look, then. If we were to ask the question, well, slices are really good for 5G and these 5G use cases-- are they good for the 4G use case? Because again, when we look at what happens inside the core of the network, there's often a current generation plus previous generation deployment of devices. And it's not unusual for that separation to exist at a software level as much as it does at a hardware level. So we talked about some of the elements that are in there. The 4G LTE PC platforms are certainly capable, in some cases-- if sized correctly-- of supporting the software that transforms those functionalities into that 5G network. So it's very reasonable. Just like our handset today allows us to fall back-- if we've got a 4G handset, it will still operate in a 3G space, and we may not even know it unless we're paying really close attention to the little bars that are showing up on the top. And then similarly, as we see 5G coming forward, it's certainly reasonable that those devices, whether they're IoT devices or the UE devices, will support both the 4G and the 5G initially and as we move forward. But here, we want to look at this diagram as we work. Again, we flipped it around. So we're going to work from the right to the left in this diagram-- is that as the cell sites, the ingress-- whether it's a macro cell or some type of a small cell-- the scheduler is what's responsible for allocating this spectrum and the channels that allow that data to transition between those end devices. And it does that dynamically, so that even though while you're using it you may think that you've got complete connectivity, you're actually getting a particular segment of a time spectrum or a particular segment of a frequency spectrum allocated to you for the necessary bandwidth that's required. And that may be allocated in the next moment or the next frequency to another user. But to us human beings, or even to end devices, it appears that we've got complete utilization of it. That functionality takes place by the scheduler in those radio devices themselves. But nevertheless, these devices then being identified by that APN, accessing into that local data center allow that first layer of discrimination to take place, where we can identify that use case-- this is a mobility user, this is a connected car user, this is a smart meter type of thing-- and then allocate components from a massive collection of them specific to those types of use cases. Again, from a signaling standpoint, your smart meters are not going to require significant resources from the SGW or the PGW. So we're not going to specify a significant amount of CPU or core utilization from those types of uses as we move our way back through. But if it's a video type of device, it needs to operate in real time, we may allocate more of those slices that we work our way through the network. And for those that really want to dig down into this, there will be more sections to come about those specific elements. And let's not worry, for the moment, about the identifiers of the interfaces. Those are well defined by industry standards. You can find them in 3GPP specification that tell us about what that packet interface specification is for each of those elements.
