Let's continue with the decomposition of the NFV workloads that we've got. To begin with, we often like to create some separation, at least conceptually, between what some of us like to call the operational technology network and the IT network inside the communication service provider arena. The operational network or the OT network is typically the part that makes money-- it's the revenue generating aspect of it. Sometimes we like to say if you turn this stuff off, bad things happen immediately. And then the IT network, while certainly very critical to the business operations, belongs to that back office a bit of functionality where you may not be able to do some of the things that you want to do and necessary to do to support that business operation, but if you turn things off, you're not instantaneously necessarily going to have a bad reaction. That's a pretty coarse discrimination, but it's not unusual to find an operational network and an IT Network inside that comm service provider area. That vision of NFV, going back to the 2012 ETSI Work, really focused on the operational network. Now certainly there are plenty of opportunities to look at virtualizing other aspects in a variety of networks, but the main thrust of that NFV effort continues today and that disaggregation of the purpose-built platforms that we talked about, is because of the nature of the way that's purpose-built platforms have gone into the OT network. Well if we look at the IT network maybe in some of those comm service providers, they already had a disaggregated concept in some cases for a very long time, and their transition to a virtualized environment is not quite as challenging. It's not that it's not interesting, it's not that it's not important, but it's not as challenging. It's not as challenging because it doesn't require them to change an ecosystem that exists as a supplier to them. It's not as challenging possibly because they've already got the infrastructure from a staffing perspective in place that understands how to operationalize those elements that are in there. So we're going to focus more on the functionality of the OT network as we start decomposing these types of elements, only because that's where the heavy lift is, if you will, inside this network on that revenue-generating side of the functionality. And again, it's because of that ever-increasing demand of the burden that's on that network that's non-linear, and that we can't continue to invest in a linear way. So in order to meet that ever-increasing demand, we've got to transform the way we build these networks, and the way to do that is through this decomposition so that we've enabled that ecosystem to be more agile and to allow us to adapt more rapidly to that ever-increasing demand. So this applies not only to the fixed network, but also to the mobile network. We talked a little bit about mobility and 5G and how there's a big driver that comes into it from the IoT burden that we expect to see, the large number of connected devices, that 20 to 50 billion connected devices that are going to be there and the amount of data that they're going to place on it. But it's also in the fixed network when we looked at-- through the network. The simple consumption of videos, the streaming videos, the through-the-network type services that are placing additional demand onto that network. And many times in the OT network, we find that there is consolidation that's taking place. Is that while certainly at the edge we can discriminate between fixed and wireless access, as we get closer to the internals of that network, those two networks actually start merging together and some of the functionalities that we see will be common from that standpoint. Again, that's done because of economic concerns, manageability concerns, and communality of the simple functionality that takes-- I don't mean trivial, but the functionality inside these networks is very common, so there's no reason not to have those unified. There are other comm service providers who may have both of the service who haven't yet unified their elements, and maybe it's because of the heavy lift that's necessary in consolidating things like their MPLS network because of a variety of interface issues that exist from a numbering plan standpoint. But nevertheless, it's all primed for transformation into a virtualized environment. We also see that there's motivation to look at some of the enterprise-level functionality that takes place, and maybe even to a lesser extent the residential or the home user. And in that area, we talk about the customer premises equipment. We divide that again into two sections-- the enterprise and the consumer side of it. And on the enterprise level, some of that equipment may in fact be under control of the comm service provider, and the functionality in some cases can be distributed. Some of it will be functionality that resides on the enterprise level itself, and other bits of that functionality may be homogenized into the comm service provider. And their business model drivers, it's not just technology. Their business model drivers that can come into play allow us to offer services that provide both of those bits of functionality. Oftentimes when we talk about CPE, Customer Premises Equipment, particularly in the scope of the enterprise level, we overload it with software-defined wide-area networking. And just like we talked about SDN as being that control plane management aspect of things on top of virtualizing the network from these platforms in the past, SDN is similar in that it's a control aspect of it. There are enterprise functions that maybe can take advantage of direct access to the internet, and there are other types of enterprise-level where you really want all of that traffic either to be secured very tightly and flow over a particular managed interface like an MPLS network, and also maybe into a corporate VPN because of the nature of that information. So you can have economies of scale that come into play if you've got a platform, an enterprise CPE platform that allows you to discriminate between traffic patterns and route that traffic appropriate either over an interface that is a lower cost IP broadband interface versus a managed MPLS type interface that's in there. Some of the services then come into play, we still have to support VoIP. Enterprises and people still use phone calls, and the voice over IP is a very popular way of doing that. And we want that service to reside, to co-exist inside that same network infrastructure that we have today that provides all the rest of the services of the through-the-network type of capabilities or the enhanced services that a comm service provider might provide, whether those are IP or video or any of the other ones. And then on the mobility side of the network, obviously we've got RAN itself. There's efforts underway to virtualize the RAN. They go by a variety of names. There's a cloud-RAN, there's a virtualization RAN itself, and sometimes we just eliminate the confusion by calling that the xRAN. Inside the core of the network, we talked a little bit about the evolved packet core that's a significant and active target for being virtualized. As we continue to place more traffic onto that network, we need more resources on the EPC and virtualizing that certainly has shown significant enhancements to the operational aspect in the capex model that's there in some of the comm service providers who have done that. We expect to see that continue to grow as we move into the 5G world. The provider edge. We've got to spend a lot of time talking about this, but it's another target that is well understood at this point for virtualization. And again, we talked a little bit about session border controllers. Haven't spent much time on the provider edge, but it's another area that is certainly active. And then emerging area into the network that is complemented by the video process, the volume of data that's coming in, and that's the content delivery network and virtualizing that element. And the content delivery network allows us to buffer bits of content-- certainly not entirely the video that's being streamed, but bits of that stream ahead of time so that we can manage any congestion that would otherwise present into the network by pulling those things a priori to their need into elements near the edge of the network prior to their expected consumption by that end device that's streaming video. So, when you think about that model, these are all excellent targets for NFV. [INTEL JINGLE]
