Hello, ladies and gentlemen. My name is Colin Alexander. I work for the Segment Marketing Group within Arm, with a specific focus on the carrier infrastructure. This is the second event targeted at giving an overview of the networking market, and this presentation will specifically highlight how Arm and partners are developing products to target changes in the carrier infrastructure market. Networking and specifically carrier infrastructure is a specific focus area for Arm, where we wish to target many of our new silicon software and system technologies that we're developing. I think you'll have seen many announcements over the last few months, where partners have been targeting products in this particular area.
Traditional networking silicon partners like Broadcom, Cavium, Marvell, et cetera, but also big players like AMD and others who are initially targeting the data center market, but with specific extensions and requirements for these carrier-grade networks as well. This is the second presentation in a series of events looking at networking and infrastructure. In these series of presentations, hopefully we can explain what networking infrastructure is, convey the relevance of this particular market opportunity, and try and illustrate why we are aligned with the changes that are happening in the market, and back this up with some evidence that we are heading in the right direction to meet industry needs. In the first presentation I gave back in June of this year, where we really covered topics associated with introduction to networking. We looked at the different types of equipment that were required to make up the network.
We looked at the types of tasks the processors had to undertake within the network. We looked at the motivations that have led the industry to adopt Arm for new designs, and why we expected the pace of adoption to ramp as more and more new designs were required to meet tomorrow's architecture. In this presentation, we will take a more in-depth look at some of the macro trends and challenges that are facing the industry in supporting the expected data deluge, and how we hope to support the higher and higher data rates through the network and the latency targets that are required. We will look at some of the inflection points and technologies that are driving the industry, and we'll look at the broad Arm strategy to accommodate some of these new designs.
In this slide, we look at some of the challenges that the network operators are facing and look at how these equate to the technical challenges that are being faced by some of our silicon partners and by the OEMs supplying equipment into this marketplace. Today, the network operators face a huge increase in traffic in their networks. This has really been driven by two things. The first off is in the ramp in the number of cellular subscribers that are using new cellular technologies like 4G, and in the future 5G. Specifically in meeting the requirements for the control signaling plane and the data plane through the network. With the increase in huge data rates, revenue per user is not increasing at the same rate. Really the network operators face two options to remain profitable.
The first off, they can shuffle more bits for less GBP, and look for greater efficiencies in their network. Efficiency really means cost, which really means power. We need to provide the industry with new silicon technologies that provide this efficiency. Now, the vast majority of power is spent just running the network. The efficiencies that the operators need to meet really don't meet the gap in revenue that they need to find. The second off is to look at new business models. Rather than shuffling bits, they need to look at how they can deploy new services into an intelligent network. How they can introduce new techniques like Network Functions Virtualization to get new feature velocity. How they can deploy new services without deploying new equipment, if that's possible.
This slide summarizes these challenges leading to deploying these new cloud technologies in a pictorial way. You can see in the center of the cloud network, there are a number of companies that are using the cloud to deploy their services. Companies like, for example, Google, Amazon, LinkedIn, Facebook, et cetera. Around the edge of the network, we can see all the different medium that are connecting into these cloud services, from the mobile infrastructure, through enterprise networks broadband access networks all the way through to the emerging need for connectivity of these potentially billions of connected devices through the Internet of Things. Really what Arm are driving towards is in providing higher data rates at the same time as really managing the end-to-end latency through these networks.
Looking at how we can support higher and higher connection densities, while at the same time ensuring that these networks are very malleable in that new software and applications technology can be deployed on these boxes in the cloud network. We've looked at some of the business and technical challenges, but how does the market segment, and what is the business opportunity for each of these different sub-segments? Looking at this foil, we can see really that we've broken the market down into three subcategories. On the left, we see wireless access. This really covers the different cellular technologies, 2G, 3G, 4G, in terms of base station technologies. Carrier Wi-Fi, the different antenna systems that are required for each of these base station technologies, wireless relays and microwave backhaul radios.
Looking at the right-hand side of the diagram, we look at the core cloud and enterprise networking sub-segment. Really this is, in the future, really driven by a lot of the data center requirements and for server technology. Also in here, we can look at things like Ethernet switches, network attached storage, security appliances, and some of the enterprise requirements in terms of routers, data center network switches, et cetera, and wireless LAN access points for the enterprise. In the middle, there's the core wireless and wireline connectivity elements in terms of the backhaul. Really we see a lot of the technology that's being developed for the core network migrating down towards the wireline and wireless connectivity space. In the center portion, there's a large need to maintain end-to-end latency through the network.
There's not just a need for high-performance programmable processors, but there's a need to support offload accelerators, so that we can meet the throughput requirements of multiple 10 gig Ethernet or 40 gig or 100 gig Ethernet data rates. There's a question mark what happens longer term in these segments. If we look at an example, for example, like C-RAN, Cloud RAN, where multiple elements may collapse into a single platform to support cellular connectivity. You could see some of the baseband processing elements, the evolved packet core from the core of the network, and some of the storage content delivery elements all being deployed in a single box. In terms of what we know today, we've represented the equipment TAM for each sub-segment, and this is derived from a number of sources.
We're adding this up, we're somewhere over $100 billion worth of equipment TAM, and really that translates down to the target that we've previously disclosed of approximately $20 billion silicon TAM for this particular overall segment. What challenges do Arm and partners face in delivering optimal system-level technology for this market? I think we've recognized that we can't just focus on silicon and interconnect technology with our silicon partners. For this market, we need to take a broader system-level view of the requirements and then address what are the particular needs for each of these sub-segments. We then need to map these into specific focus areas for Arm and the ecosystem moving forward.
If you look at this foil, if you look at the different market trends that are challenging us, we see exponential data growth in terms of subscriber traffic, and also the need to be able to support connectivity of these billions of different devices in the infrastructure. We need to look at the different operator CapEx and OpEx pressures and how we can alleviate these or help alleviate these. We need to look at the advent of new, more scalable technologies that allow the network to be more scalable, like SDN and NFV. We need to look at some of the new standards that have been developed and will be introduced over the next four to five years. Like, for example, 4G, LTE Advanced, and 5G, and look at the transition between each of these different technologies.
We need to look at some of the financial and industry consolidation that's occurring, the different market players that are entering the market, and we need to look at data privacy, which is really an end-to-end problem over the network. We need to replicate these onto the different sub-segments, which we covered before. We need to look at each of the focus areas and map these on top of the different sub-segments. We're known for our processor interconnect and IP technology that we've developed and licensed to our silicon partners. I think we need to look at infrastructure subsystems. How do we design our processor interconnect IP? How do we validate and quantify the performance? We need to come up with a plan with our ecosystem on how to deliver on some of these new NFV and SDN technologies.
How we map some of the new Arm-based driven standards like OpenDataPlane on top of that. How we optimize some of the OS and virtualization capability on top of our devices. Overall, we also need to look at the security aspects that we need to apply end-to-end over these different technologies. I'd like to take a look in a little bit more detail at some of these focus areas. First off, processors and interconnect IP, and looking at some of the system-on-chip level challenges that we face. What does this mean in reality in terms of meeting the network infrastructure inflection points? We see a need for many new heterogeneous, many core, many type platforms to address the needs of these different access networks, whether that be cellular, passive optical networking, DSL, et cetera.
Also for many of the new core networking requirements, acceleration offload to some of the data centers so that we can meet the latency end-to-end requirements. Some of the new C-RAN implementations where some of the baseband modules need to be combined with storage array capability for content delivery and some of the new core control functions. Many of the new cloud services require network acceleration capability as well. We need to bear in mind the need to support IoT capabilities. The billions of new connected devices that potentially only send 64 bytes or so maybe once an hour. We need to design these devices to be extremely efficient, but also to meet the throughput requirements in the network.
In delivery towards these technologies, we need to pull together with our ecosystem partners silicon cores, interconnect memory and storage capabilities to meet the throughput power and latency needs of these different equipment types. As we pull together our core intellectual property, we need to look at the requirements for the slow path, the control plane, and also the fast path. Really we see a move in the industry towards general purpose C programmable devices away from the more hard-coded network processors and ASICs that might have been used in the past. What do these platforms have to support? If you look at the foil that we're showing here, we've segmented the requirements into four.
If you look at the top part of this diagram, this really represents the classic networking data plane packet processing requirements, where typically we're handling maybe hundreds of instructions per packet before we have to stall a packet, offload it to a bulk accelerator, or wait for the result from an adjacent packet to be received. Typically, this needs a number of threads. It's very IO-intensive, and we need to be able to handle higher packet rates with more complex processing. It's hard to parallelize. There's a big issue with legacy and how we have to meet code that's already available within either the silicon partners or the OEMs. The overall problem is becoming more and more complex. If you look at the other data plane application that's shown on this foil, MAC scheduling, this is extremely latency sensitive.
We need real-time control between the different cores on our systems. Again, multiple threads can be an advantage here. It's very compute-intensive in terms of the processing that's required. As the new cellular technologies are introduced, more and more complexity is required for the MAC scheduling. In terms, which maybe I should say, MAC scheduling is basically scheduling from the base station out towards the handset. Potentially you could have thousands of different handsets connected or IoT devices, each with multiple different sessions. You may have video sessions, voice sessions, data sessions, each with different latency requirements. This all has to be accommodated potentially over multiple different cores that have to work in parallel. We've got the control plane requirements for these designs. The control plane typically is handling tens of thousands of instructions per packet. It's highly single-threaded.
Basically, applications can be handled with highly single-threaded architectures. There's a large legacy code base, and it's quite complex processing that's required. Again, as the new cellular technologies are introduced, we expect the control plane requirements really to ramp quite significantly. There's the other element that's shown in the bottom right of this diagram, which is basically all the specialized processing. In terms of base stations, for example, the layer one air interface processing is pretty key. It needs a diverse set of requirements, typically applied in banks of accelerators or DSPs. Also into this bucket here falls things like security offload processing, bulk security processing. All of these different requirements need to be supported over an interconnect.
This interconnect needs to be able to handle all the different latency requirements of these different blocks, and needs to be able to handle the different requirements in terms of accessing internal cache and external memory requirements. I'd like to take a further look at the SoC building blocks and apply this to the second focus area, which is basically the subsystem requirements. I've got three different subsystems that I'd like to illustrate. The first off is a cellular infrastructure application. Looking at a base station implementation and looking at what components need to be integrated at the system-on-chip level to meet the requirements of these different platforms. In the previous presentation, the one in June that I gave, I introduced some of the block-level concepts that Arm had been working on with some of our partners.
I introduced the CCN range of cache coherent interconnect that we'd been working on. I introduced some of the cores that we had introduced. Shown here is the Cortex-A57, which is the highest performance of our 64-bit Armv8 implementations. I talked a little bit about the memory controller functions that we had on offer, so in this case, the DMC 520 memory controllers. I talked about the ability of the cache coherent network interconnect to be able to support different cores connected in over a common interconnect. Basically allowing these different cores to share the same memory interfaces, whether that be cache memory, L1, L2, or L3 internal cache or external memory. In the case of the CCN-508, we have the ability to manage cache coherency to the level 3 cache.
Each one of the processor cores has its own L1 cache at a cluster level. In this diagram, we show quad clusters. There's 4 cores share an L2 cache, and then all 16 cores, or sorry, all 16 Cortex-A57 cores share an L3. What we're showing in this diagram is that our system partners can utilize, in this case, we've shown the CEVA-XC4500 DSP vector processing cores in the same architecture. In this case, the CoreLink CCN-508 interconnect is maintaining cache coherency over the Arm cores and also the CEVA cores. Also what we're showing in this diagram is, and it's particularly for small or medium-sized small cell Pico or micro base stations, the antenna processing or the digital front-end processing can also be either accommodated on-chip or can have off-chip interfaces.
On the right of this diagram, I'm showing some of the requirements for the evolution in the base station, and particularly for baseband processing. Really what we can see is that the level of complexity is increasing dramatically. We would expect in the region of a 30X increase in terms of baseband control and signaling. We'd expect in the order of maybe 10X increase in packet processing. This is the data that's channeled back into the core network. We'd see for technologies like LTE Advanced and 5G, we'd see in the region of 10X increase in latency. It becomes a very key factor in scheduling user traffic out over the antenna. Certainly, we'd see the need for 64-bit processing in terms of increased memory range.
Also we'd see potentially the need for even more control processors on these sorts of devices to handle things like local content caching and application processing on the base station itself. Finally, on this foil, the subsystem approach. We need to be able to quantify results on this type of architecture in terms of the control plane and the data plane elements, and how that all interacts with the layer 1 subsystem and any accelerator blocks that we would have on these system-on-chip technologies. The second example of a subsystem and the SoC building blocks required for that subsystem is C-RAN, Cloud RAN. I've picked this example to illustrate how multiple different elements can be extended on a similar system-on-chip architecture to the previous example of the base station. In this example, we see an extra 16 Cortex-A57s being integrated.
We go from 16 up to 32 core. Really this shows consolidated compute for server processing, and potentially for something like MAC scheduling as well. Potentially on this device, these cores could be used for a range of different functions, from control processing for the baseband capability, or for some content delivery capabilities where data may be cached locally to this particular node. Once again, I've chosen CEVA-XC4500. We've just written a white paper with CEVA, which looks at some of these applications. I've reused the diagram. Typically, this could be CEVA cores, or it could be custom vector processing engines that are used in this type of architecture. Again, the CoreLink CCN interconnect is showing that coherency can be managed at multiple different cache levels, either L1, L2 or L3 in this case. We show an extra 2 channels of memory being integrated.
In this case, we're showing some Cortex-A series, smaller cores being used in this case for maybe some packet processing or some user interface scheduling processing. These could be Cortex-A53 cores. These could be some other sort of smaller cores with some appropriate accelerators also being used on the CCN fabric as well. This is just a representation of a different subsystem, a higher processing capability, more functions being integrated on a SoC. But from a subsystem viewpoint, we're looking at this type of architecture to validate the performance of these type of system-on-chip devices. The third example of a SoC architecture would be for example, infrastructure and analytics or media processing. Again, scaling the architecture using multiple clusters of quad Cortex-A cores for the server processing. Potentially this could be a data center device using interconnect with vector engines.
Again, I've chosen CEVA in this case. Could be proprietary vector engines, all utilizing the CCN interconnect to manage the L3 coherency. What we'd envisage in this case would be that the vector engines were maybe doing some codec task. It could be doing some voice or video coding. It may be processing some analytics tasks. The Cortex-A cores would be handling some maybe compute server functions. Could be handling, again, some scheduling capabilities. Typically these would be using some virtualization capabilities as well. Again, the idea here with a subsystem approach would be to validate some of the functionality and quantify some of the performance for this particular application.
I'd like to choose this foil to illustrate how our partners have to be able to target the appropriate functions in the appropriate system-on-chip devices, and then be able to allow the OEM equipment manufacturers to package these for appropriate geographies. I've chosen the radio access network as an example. I think this is a good example that illustrates how Arm and our partners need to consider the processing, software, and system requirements for many of these new designs. CRAN in some geographies makes a lot of business sense. In the Far East, where we have lots of massive urban conurbations of 10, 20 million subscribers, and fiber is owned by the same operator that manages the wireless network, CRAN makes a lot of sense.
In many of the other geographies where the operators don't have access or such readily access to fiber technology, it may not make sense to centralize a lot of the RAN capability in a single box. This really shows why we need to provide the flexibility and the ability to move functionality between different locations and adapt to the network case and the best option for each network case. Using off-the-shelf hardware and software may help this to be a reality, using virtualized capability, using some of the NFV and SDN techniques. The solution must be cost-effective when compared with specialized equipment that's used today. Really, there's no single solution that could be considered optimal for all these different scenarios. If you look at this slide and the picture that we're showing here, really, there are two main options for RAN deployments moving forward.
First off is the eNodeB, the base station functionality. Should that be centralized or distributed? There's the CRAN-like case where a lot of the baseband capability is centralized, and what new antenna schemes should be used? Looking at the core network, the evolved packet core functionality, again, can be located centrally or could be distributed. These architectures use a lot of carrier cloud and server-type capabilities with some acceleration offload. The main question here is, where are the functions located? Are they located centrally? Are they distributed? The main options are Cloud RAN, where eNodeB functions are centralized in a massive box, where IT data center technology is reused. The other option is to use heterogeneous-based architectures for small cell base stations. Small cell base stations are overlaid on top of the macro network.
There's the base station hotel concept, which really covers everything in between. One of the crux arguments and decisions that has to be made in the network is where is the MAC layer processing populated and where does the layer one processing reside? In many cases, the layer one processing actually has to be located much closer to the antenna, the remote radio head. This diagram illustrates how functions may be moved from different boxes across the network, depending on the network requirement, whether we be in the Far East, whether it be in Europe, North America, wherever we be. Again, this has got a large bearing on the type of system technologies, software technologies, and silicon technologies that are developed for each one of these different applications.
Another example that shows how our partners are having to adopt to target the appropriate functions into the appropriate SoC devices is shown here in terms of the network infrastructure evolution. Historically, the data center core networking equipment and the access network equipment have had a degree of intelligence in terms of processing storage capabilities for content delivery, acceleration, and networking. The backhaul equipment has been fixed function. Effectively, the traffic is routed across that network without much intelligence being applied to the packets as they transition. Tomorrow's cloud infrastructure sees a convergence of access and core network technology, excuse me, where intelligence is distributed in the network. Processing, storage, acceleration may actually be accommodated in the gateways and switches in the network. In this case, the processing is moved closer to the client devices. There's an argument that this actually reduces network latency.
The choices that are made on routing a packet can be made much closer to the client device, and it allows for much more scalable deployment of technologies across the network. It allows new technologies like, for example, software-defined networking and NFV, to be introduced, and features to be used more flexibly from within the OEM hardware. The operators have direct access to configure their network once it's in place. From an Arm perspective, we're enabling these solutions with much more scalable Armv8, Cortex-v8-based cores with interconnect. We're provisioning much more cost-effective, efficient designs for this intelligent, flexible cloud. We've looked already at the silicon IP and subsystems requirements for the networking market. Now switching and looking at the software requirements, and the need for Arm to work with the ecosystem partners to try and bring some standardization to the requirements of networking.
The foil that we're showing here really illustrates the three different market sector requirements. If we look at access market, backhaul, and core, really we see two different needs emerging. On the left-hand side of this diagram, we see a typical server application. Really, the server platforms are reasonably easy to enumerate. They've got really standardized CPU capabilities, and the number of peripheral functions on a data center or server application are reasonably limited. We need to configure at boot time things like the generic interrupt controller, any timers, UARTs on the board. Really, it can be enumerated into a standardized API. Arm have been working with a range of our partners, including the main OS vendors, to specify something called SBSA, which is the Server Base System Architecture. This sits below the OS or hypervisor with the server application running on top.
If you look at the requirements for the networking market, you see that the range of functions on a networking blade typically is a lot wider than in server applications. It's much more difficult to come up with a standardized interface to configure functions like, for example, the scheduler, any buffer management that's required into memory, any encryption or crypto-type features, or any networking IO capability or any other particular offload for that matter. What we see in this case is that, typically our silicon partners are coming up with a series of proprietary drivers.
What Arm and the ecosystem have done is we've come up with an additional API that sits on top of that to allow our partners to configure this networking blade, but our silicon partners to layer on a proprietary driver underneath this API that configures their potentially proprietary hardware underneath that relies on their specific hardware. Looking at the software approach in a little more detail. This foil represents an example of how Arm and partners are working to enable the market with a series of proof of concepts for Network Functions Virtualization capabilities. Arm have worked with several silicon partners like Avago and AMD, with several software partners like Tieto and Aricent, utilizing core software capability that has been developed under the Linaro umbrella to develop a number of POCs that have been submitted with network operator sponsorship to the ETSI NFV community.
The intention of each of these PoCs is that certain network functions are configured to run on Arm-based silicon from our partners, and then the performance and functional requirements are tested and then documented and published on the ETSI NFV portal for all the interested parties to use. Examples that have been submitted to date include service chaining, and virtual evolved packet core applications. Each of these require a mix of compute and offload capabilities. All have been configured to run virtual functions under Linux with the silicon chips configured appropriately. Hopefully now, after taking time to listen to this presentation, you've got more of an understanding of the complexities and often conflicting technical and business challenges that are facing the industry today.
We've covered many of the inflections that are playing out in the market, including the introduction of new radio access technologies and how these might be deployed in the radio access network. We've looked at how different delivery mechanisms may be supported for content delivery, whether these be hosted in the cloud or hosted much closer to the edge of the network. We've looked at how these new services can be deployed in the core of the network by decoupling hardware and services, whether they be hosted on overlay networks or on dedicated boxes that are owned by the operator. Whether they use dedicated implementations, network processing techniques, ASICs, et cetera, or whether they utilize more malleable NFV-ready equipment.
Looking at this foil, really what we've done is summarized Arm's approach to the market and looked at the specific requirements for the access market, backhaul, wireless, wireline, and the cloud enterprise networking and core markets. You can see that for the access market, there's a need to target very specific functionality, target the specific cost, power, and form factor constraint requirements for these dedicated pieces of equipment, such as base stations, passive optical networking nodes, et cetera. These platforms use mainly heterogeneous architectures, mixes of different cores, different sizes to target the control plane, data plane requirements, and potentially any additional accelerator IP that's needed. There's a need for Arm and partners to support not only the processor and interconnect IP, but to supplement the market with a series of platforms that can be used for performance evaluation, proving efficiency, et cetera.
The other two elements, the cloud, enterprise and core networking, is very horizontally aligned. Basically, this is looking at data center and server-based technology that's feeding into this right-hand box. It's got a high reliance on these new software technologies, SDN and NFV, and potentially can run on top of commodity compute platforms, making use of things like the SBSA that we talked of earlier. The element in the middle really aligns many of the requirements of the access market in meeting the latency requirements across end-to-end in the network, together with the elements from the right-hand box, this commodity compute capability. In conclusion, why is the industry moving towards adoption of Arm-based technology? Why does the industry care whether it uses technology from Arm rather than competitive offerings? I've listed here five main reasons why I think this is the case.
Going through these one by one, really Arm and partners are targeting heterogeneous architectures, mixing small and large cores to meet the specific needs of access, backhaul, and core, and really targeting the cost, power, and latency requirements of each. We're offering a single processor and instruction set architecture that can stretch across multiple different network elements. Leading into the third point, this is available through a number of our different partners, leading to increased choice. There are multiple different providers of Arm-based chips for this particular market. Arm are enabling the market with a very flexible and rich software environment. We're working with our ecosystem partners, with many of the open source initiatives. We've talked about a few in this presentation, like NFV, SDN, Linaro, et cetera. We're investing a lot in the Arm Linux open source community.
We believe that the choice of Arm-based designs offers networking OEMs lower total cost of ownership, reuse of platforms, and extending capability with software programmability over a range of their different equipment types. I think that these five points considered together with a strong roadmap that intends to continue the development of products for networking equipment all combine to present Arm-based technology as a very attractive proposition for OEMs and network operators alike. I'd like to take this opportunity to thank you for listening to this presentation. Hopefully, you found it useful, and I'd just like to conclude there. Thank you.
Good.
Hello, operator. What's going on here?
Sir Thornton, you are now in the main room. You may begin.
Okay. Thank you, operator. Thank you, everybody, for joining. Good morning, good afternoon, and good evening, everyone. This is Ian Thornton. I'm the Head of Investor Relations at Arm. Welcome to this call, where we'll be discussing Arm's opportunity in enterprise networking. This is actually part 2 of the discussion. Part 1 is available on our investor relations website at www.arm.com/ir. Hopefully, you will also have had time to view the presentation by Colin Alexander, which gives some more background to this discussion. If you have not, then that is also available on our website. On this call today, we're joined by Charlene Marini, who is the VP of Segment Marketing at Arm, and she is responsible for our strategy in enterprise networking. Also we have Pierre Ferragu, who is the global telecoms equipment and European semiconductor analyst for Bernstein.
I'll now hand over to Pierre to lead the discussion. Over to you, Pierre.
Thank you, Ian, and thank you, Charlene, to offer me the opportunity to have this time with you, and thank you for the presentation Colin made available on your website. I thought it was extremely useful. I'd like to kick off this Q&A. First of all, if you could take us through, in terms of time, how the networking initiative developed at Arm. When did you get started? What was the first kind of products you've been targeting? When did you sign your first licensing agreements?
Thanks, Pierre. Happy to have the discussion here today. To answer your question, of course, everything within this space has been an evolution, and the chips that are shipping today are Cortex-A9 and Cortex-A15. HiSilicon, which is part of Huawei, made one of the first announcements that they were going to use Cortex-A15 in base station equipment in 2011, August of 2011, to be specific. Shortly thereafter, there were announcements from other partners like LSI and TI that they would use Cortex-A15 in networking equipment as well. 2011 was really that beginning in terms of this part of the market in networking. Looking forward, of course, the main opportunity is going to be for the Armv8 processors, which enable 64-bit with the Arm instruction set. We started working on that in about 2007.
We started licensing that architecture in 2009, we saw first announcements of partners showing their intent to use Armv8 in networking in 2013, and Broadcom was the first one to make that announcement. Since then, we've seen continued momentum with other partners like HiSilicon, Freescale, Altera, Xilinx, and others announcing their intent to use Armv8 processors for networking. As we go through, you can also look at some of the partners in addressing the server space. As we go through this discussion, I think we'll see that a lot of the attributes in the server space are being applied to networking as well. Partners like Applied Micro, AMD, and Cavium, while their chips are focused on server, we'll see that they can also be used for some networking applications given the types of IP and market engagements they have.
Okay. If we look at a snapshot of the situation today, what is already shipping and how does the ramp-up, in terms of shipments, look like for the next 12 months? Well, first of all, what can you tell us about specific products that are shipping, you think, in volumes already today, and what do you think ships in volume in 12 months from now? I think that would be my first question, and then I have a quick follow-up.
Certainly. We see Cortex-A9 and Cortex-A15 shipping in volume in things like intelligent switches today, Wi-Fi access points, and certainly in things like cable or DSL modems, so on the access side of wireline network. Of course, in terms of wireless access with base stations, that's just beginning to ramp. We'll see more and more, of course, with the Armv8 platforms coming out in 2015 and shipping in 2015, that that pipeline will continue to deepen.
Okay. That's very clear. If now, a follow-up question on where, like a snapshot on where we stand today, could you give us a very rough idea of how much of the market have you licensed already? I started looking at it, and I kind of came to the conclusion that virtually everybody doing networking equipment has already at least taken a license from you guys. Is that a fair assessment?
That is a fair assessment. The past two years, I think we've seen virtually every networking equip silicon maker, and certainly all of the major networking silicon providers, taking and announcing Arm licenses. Of course, when Intel completes the acquisition of the Axxia product line from Avago, they also will be shipping Arm-based chips.
Okay. In terms of the trajectory of Arm getting into actual shipped silicon, how can we think about that? It's a fairly long product cycle industry, I would assume. That's one thing, like getting Arm into the product cycle may take a few years. If you look at your most advanced licensees, how do you see their approaches? Is that like a ground zero kind of approach? We just forget about all our other processor architecture, and we migrate all our product lines to Arm, or is it actually a more progressive kind of penetration?
Yeah. As you state, the product cycles are longer in networking than, say, in mobile. They'll vary by the space as well. For instance, right now we're seeing incredible momentum around new Wi-Fi 802.11ac standards, a replacement cycle going on there. Of course, with SDN and other trends in the enterprise side, we're seeing maybe a quicker uptake of some new designs there. There will be pockets where the market will evolve faster and the replacement cycle will take place faster. I think those are areas that you'll see Arm-based designs. Also because those tend to be areas of newer software, where legacy is not an issue. You have, as you mentioned, portions of the market that have been based on other architectures for a number of years.
We're working with the ecosystem to ensure a smooth transition. Really what's happening is a lot of the OEMs and carriers do not want to maintain multiple code bases. It's really in the interest of our silicon partners to transition their product lines as quickly as they can to the newer Arm architecture, such that OEMs can meet their goals to simplify their product development and their maintenance support.
Okay. Very clear. That's very clear. You touched on ecosystem migration, I actually remember a chat with one of your licenses in the space. I think it was with Freescale. They were actually telling me about how challenging it is actually for them to migrate a product line to Arm, that once you do that, all the software that has been developed by themselves, software that has been developed by their clients, needs to be actually recompiled or adjusted. That the magnitude of that work was probably more than what they had initially anticipated. Also that the visibility on how is it going to be, when it is going to be completed, basically, was quite challenging.
They, of course, absolutely didn't see that as a showstopper or something that could challenge their decision to migrate to Arm, but it seems that in moving ecosystem, moving legacy is fairly challenging. Would you agree with that assessment? Is that what you see at the moment in the market? Or do you think maybe there are pockets of specific players where this is challenging, but you see other places where it's much easier? I think you say that in Wi-Fi, enterprise, it's easier because there is less legacy. Maybe if you could tell us where you think it's going to be the most challenging and how it's going to impact the ramp-up of your penetration in the space.
Yeah. I think whenever a new architecture enters a new market, there is, of course, the transition of an ecosystem, that's quite natural. I think there are a few dynamics working in our favor, in addition to the OEM consolidation around their platforms wanting to minimize the number and different types of code bases they have. Certainly, another one is the transition to 64-bit. As Colin mentioned in the webcast that was done, significant pressures on networks in terms of bandwidth today, both from the cloud side on the enterprise, but also on the edge side from subscriber usage. With that, we are seeing these replacement cycles, as you mentioned, and new ways of structuring the software across networks. The increased need for 64-bit, to my previous point.
If you look where the market is, it's having to transition in terms of software code base throughout most of the market, just because of these trends. Starting to rely more and more on open source and some of the other things that Colin talked about. Certainly, there will be pockets where everyone who designed the software has been gone for 20 years, and no one knows what the software does. There are technologies to enable that in terms of binary translation and compile technologies. I think we have everything the ecosystem needs to transition, and we certainly accounted for that phasing of transition and replacement cycles in our forecasts.
Okay. Maybe it's a good point in time maybe to remind us what sort of long-term guidance you've given on your expectations. I think your estimate of your addressable market in networking is in the high teens, close to $20 billion, and you've given some kind of 25%-30% penetration targets. Can you remind us on what sort of time horizon do you feel comfortable you can get there? Maybe how much this ecosystem transition dynamics could actually happen faster? There is an upside risk to that number, or how much it could be delayed if ecosystem transition is taking longer than what you're expecting today.
Okay. Yeah, certainly. We feel that in 2018, we've given a 25%-35% target penetration number across this broad range of networking. In terms of your question on ecosystem evolution and the assumptions in those numbers. This is certainly on the wireless access side, mobile infrastructure side. We're seeing the ecosystem for base station software, et cetera, move over. We feel good about that ecosystem, and we think that's on progress. In terms of more of the core part of wireless and wireline networking, a lot of this is moving to Linux. Optimized carrier-grade Linux is of use in that market and will continue to grow in that market. The adoption of Linux in that market is something driving this market penetration.
In the enterprise networking space, that target number is based on the fact that, again, move to open source software, and also things like needing higher levels of orchestration and optimization at higher levels in the networking stack. We see things like OpenDaylight, Open vSwitch, a lot of these forums and open source platforms evolving to address that market.
Mm-hmm. Okay. That's very clear. Thank you. Maybe one last question on just making sure we set the lay of the land and we have all a full picture on what this networking opportunity looks like. If I think about this $18 billion, that's the number I have in mind, or maybe you communicated 20 or anyway, I don't think we are at a stage where this exact number matters a lot. I've tried to slice it the way we analysts like to do it all the time, and I thought it was actually a very varied, I would say, market. You have a lot of sub-segments, you have processors in there, you have FPGAs, you have very specialized chips. You have a lot of players. It's a very fragmented market.
If you take Broadcom and Texas Instruments, they are probably both above 10% market share or close to 10% market share for Texas Instruments. All players tend to evolve between the $300 million and $800 million kind of revenue in networking. As I couldn't figure out how to segment properly this market, I'm actually returning the question to you. How do you guys think about segmenting the market for you? Maybe the hint I would give you is an easy way for us analysts and industry observers to think about it, would be in networking, you can have a small chip with just one processor. You can have a very big chip with a lot of processors, with a lot of parallel computing.
you also have big chips with just one small processor or a small number of processors and a lot of other things with very specialized architecture like for instance, FPGAs or arrays of DSPs, et cetera. If I think about these three categories of chips, first of all, is that a relevant way to think about it for you guys? Second, what would be your rough idea of how the market splits between these three? Of course, how it's going to evolve over time, because as you mentioned, things are changing a lot in the industry.
Very complex question, I'll try not to make the answer too complex, in that, as you say, the most important thing here is this is a very diverse market. I think your breakout is fair. I think I'd add some context around that. I think you said low ASP single processor. I think moving forward, there will be very few single processor designs. I think dual core and maybe even quad core could be the norm, even for what you might consider lower performance, lower ASP designs because of these trends we're seeing. Something just like a Wi-Fi access point that seems quite simple once you get into the enterprise space, once you get into increasingly maybe even carrier access space with the combination of cellular technologies and Wi-Fi handoff, a lot more control processing is taking place. That's driving up the complexity there.
In terms of the other end of the spectrum, you could have lower processor density on bigger chips. As you mentioned, this might be a switch fabric, where the switch fabric is taking up billions of transistors, excuse me, the processors are a small portion of that chip. Of course, chips that have tens, maybe even hundreds of cores, and those types of designs certainly increasing in terms of the penetration across the spectrum. I think, as you know, our business model is highly scalable. We look to address this entire market, in general terms. The simple side, that first tend to have lower royalty per chip because they have fewer processors, and the processors might not be as complex.
As we get to the chips that have more processors, have 64-bit processors, those chips will tend to have higher royalty, they'll tend to have higher ASPs, as you pointed out, underlying that higher royalty. We do look at it across the spectrum, can break it out in those general categories. In general, we do see that the processing requirements are lifting across that spectrum, even from the low end, moving up.
Okay. If you think about this very high processing type of architecture versus architectures where you have a much lower processor count, do you think the latter is going to actually let more and more room for the high processor count because that's where the market is going? Do you see places where you would have just one processor and a gigantic FPGA array being replaced by actually application-specific processors, application-specific chips with a lot of processors? How do you see that evolving?
Yeah. That is a trend in some places, not necessarily the FPGA replacement, but a simple chip being replaced by maybe a more complex chip, and a lot of that's due to integration. In many cases, it's actually multiple chips being replaced by a single chip that will integrate more of the intelligence onto a single die or a multi-die package. We will see more of that, and we are seeing that today. At the same time, we're seeing intelligence being put into places that previously there was no intelligence. Switches are a good example. Traditionally, they've been no processing capability. There are now places where switches increasingly have processing capability. Trends like SDN, which require the termination of some protocols on the switch itself, add more complexity in the need for processing in some switch fabrics.
We're seeing both higher integration of existing platforms and a base station, base band platform is a good example of that, but we're also seeing intelligence now popping up in other parts of the network, processing capability being added there.
Okay. More processing capabilities, more raw processing volume, and more integration would be-
Yeah
the two trends. Okay.
Yes.
Very clear. Thank you. One thing, just jumping from my memory, I remember reading stuff about, I wonder if it's not Microsoft looking into that, but who are looking at actually a kind of opposite movement where they would actually use, especially for search, processors combined with FPGAs, and kind of like non-processing logic to accelerate the processing of their search engine. I don't know how much this is already tangible and like a trend that could emerge on the server side, on the pure processing side. I was wondering if in networking, this is also something you could see, like places where there's a very high level of compute requirements could see emerging actually alternatives to pure raw processing power and being replaced by processors being mixed up with faster, more dedicated type of elements like an FPGA.
Yeah, Pierre, you bring out a really good point. Certainly, the underpinnings of networking have always relied on acceleration. The architectures that have evolved because of where technology has been and et cetera, have been kind of separation of that compute part of the code of the equipment with the acceleration technology and scheduling and other things that need to happen in networking for latency and throughput reasons. With this increasing integration, what's happening is those are being combined onto single chips.
Whether that is FPGAs that are adding compute subsystems, as Altera and Xilinx have done, to address certain parts of the market that still need a lot of flexibility in the acceleration portion, so they want to be able to have a fast path in the FPGA logic that they can program, or whether it be a chip that has a combination of the general-purpose Arm processors, but also some more programmable types of processing and accelerators with a software development kit on top that an end user can then program in a generic way, but not as generic as, say, the general purpose processors. Enabling, again, that fast throughput, and lower latency than you would get just using a high single-threaded general purpose processor. We definitely see the market moving more and more towards that.
Some of the initiatives that Colin mentioned in the presentation are really enabling for that. One primary one is an API called OpenDataPlane. This is all about abstracting that logic I mentioned, that kind of acceleration, fast path logic out. Now OEMs will have a common interface to program that type of logic, whether it is a chip from vendor X or a chip from vendor Y, and they won't need to pay attention to what the specific hardware components are on that chip.
Okay, that's very clear. A lot of things could move from where we stand today. Maybe if we move on to the second batch of questions I had in mind, which were more about how you see the market structure evolving over time. If I try and take a snapshot of where we stand today, we know that Intel, with maybe 30% of the processor, like discrete processor market in networking, maybe has between 5% and clearly less than 10% share of this $18 billion kind of market. The footprint of Intel is actually very, of x86, is actually relatively small. Then I think MIPS and PowerPC are kind of like the other legacy architectures we find in networking. Is that fair to say that in the long run, it's going to be Arm and Intel and that's it?
Other architectures are likely to disappear over time based on the comments you made earlier about your clients not being willing to maintain multiple architectures?
I think it's fair to say that there's a consolidation of architectures, as you mentioned, and given the licensing momentum we've seen in the announcements of PowerPC and MIPS silicon users transitioning to Arm, that the market is moving to two architectures, as you mentioned.
Okay. Is it going to be Intel keeping its kind of 5%-7% footprint I just estimated, and you guys taking the 93%-95% remaining footprint, or do you think Intel has also an opportunity to increase its presence in networking? If we listen to what the company says, if we look at what the company is doing, they seem to be fairly active in the space. How do you read their behavior at the moment?
I would step back and say there's a huge opportunity in networking for silicon providers today, for all the reasons we've mentioned, a great amount of innovation and investment going on in the market. Clearly everyone is trying to meet the needs of this market and address this market. We generally view the types of discrete processors that you mentioned as the primary market for x86 today as being in points in the network that are most like a server in terms of the processing capabilities. The Arm ecosystem providing the operational parts of the network that really require the high throughput and lower latency, which is the highest proportion of the types of workload and processing that go on. We think our ecosystem is very well poised in terms of engagements with the end users, the existing ecosystem, and certainly the ecosystem that's transitioning.
Of course, my team is working very hard on what we feel the future ecosystem will need to be around the software-defined types of networking technologies. I think Intel and x86, they'll need to make similar types of investments and look where the market is going. It's hard to say how successful any one player will be as they address this kind of rapidly evolving market.
Okay. Let me maybe give you the simplified long-term perspective with which I like to think about that question. With this whole SDN story, everybody, I would be tempted to say almost my kids, would know what a data plane is and what a control plane is. You have this idea that the data plane components have to basically do the heavy lifting and forwarding at a very high speed packets of information through the network. Then you have the control plane that is basically trying to think through the process and give instruction to these data planes components. That's where we want to see the network evolving. A control plane that has a very open and normalized and codified and, I would say, open source kind of communicating with the data plane.
I think the next step of the thinking would be, today, any sort of processing is being run on the cloud. We see every single equipment vendor offering their core product, like an evolved packet core. Even the edge product, like edge routers, actually running on the cloud, running from distant data centers. The most amazing example of that we see is that the first networking, I would say, components that are going to run on a cloud environment are going to be set-top boxes. Like the set-top box you have at home, from which you get all your service, et cetera, is going to become like a pure packet forwarding kind of box. Then all the intelligence of the service you're going to be delivered is going to be coming from a cloud somewhere in the country, if not somewhere else on the planet.
If I think about the evolution of networks along these lines, all the control plane is going to end up in the cloud, and all the packet forwarding, all the data plane, is going to stick to the box. Then maybe that's a way to think about how the world is going to split between Intel and Arm, because Intel will have the upper hand in a cloud environment, in the large data center environment, and Arm will have the upper hand on the high integrated data plane chips. What would be your reaction to that kind of conceptual vision of the world? Is that the right direction? Is that where we are going, or am I missing something?
Well, I think when people talk about cloud, and I'm glad you bring up the set-top box one because that's one we're actively working on. I'll kind of draw that into this answer. They think of, as you say, a massive large data center somewhere very far away, and then you're thinking of the endpoint. In reality, what we're seeing is instead of that intelligent endpoint and the intelligent cloud, and a dumb network in between, we're actually starting to see a more intelligent network. Then on top of that, what I'd call dispersed cloud. In things like set-top box and cloud, we're actually seeing more experiments where cloud-based systems are sitting in the network, for the set-top box offload. People looking at workload-optimized types of deployment.
They're not looking at what has been kind of the traditional legacy server of a high single-thread general purpose processor. They're actually looking at systems that are SoC based that allow workload optimization for very high density, and over the lifespan then, very low, or I should say, lower operating costs. Our view is that you're actually going to see more of this intelligent network. Think of the cloud as actually dispersed cloud. With that, both of those elements looking at workload optimization and flexibility. Optimized for certain types of tasks that have the orchestration and the software such that you can evolve services very quickly, change services, and deploy new services very quickly, but still with an optimized underlying infrastructure.
That's very interesting. I actually wish my good friend John Chambers were on the call with us today, because he's been trying to convince and to evangelize the planet about his concept of fog computing, this idea that you would need compute and processing power and intelligence at every level of the network, and that just like the very centralized cloud, and no intelligence in the rest of the network is not the best option. Is that fair to say that you would agree with that view? You may think whatever you want about the wording fog computing, but this idea that compute is going to be actually very distributed in the network is the future.
I think we're aligned with that view. We're obviously starting to see parts of that today. Certainly as you look at IoT and the discussions that are happening around IoT, and the different types of requirements for control of billions of nodes, the tendency is to really see how we can solve some of those problems in the edge of the network, so that you're not creating more and more pressures back at the data center, in highly condensed cloud environment.
There was one way to think about it, which is cloud environment versus distributed. The idea that all processing would go to the cloud, all the control plane could go to the cloud, and only the data plane would stick to the distributed network is probably not the right way to think about it. There is another conceptual divide in the market, and I think some of Colin's slides touched very well on that. There are places where you need super high power, super high performance, single-threaded processing. There are places where actually you need a lot of parallel and multithread processing and where you need also, I think, a lot of integration. If I recall, one of Colin's slides, MAC scheduling is a place where high processing, single threading is important.
The control plane, of course, is where raw processing and single-threaded processing is very important. Then I think you have the data plane where integration and multithreaded, highly parallel architectures is probably what matters the most. There was a fourth box on that slide, but I have to admit, I can't remember what the fourth box was. The way I think about it is, without making any comment on who wins where, et cetera, not thinking about it on a relative basis between Arm and Intel, but more thinking about where Intel is more at ease and when Arm is more at ease. Is that fair to say that Intel will feel more comfortable where this very high performance requirement is, which would be the control plane and maybe MAC scheduling, and then places highly parallel architectures and multithread and integration is important.
Of course, the beautiful flexibility of the Arm model would be the most successful. Is that a fair way to think about it, at least directionally?
I guess I would add the context that with increasing levels of integration, you're not going to have as many separate applications that are just a control plane box. The balance between control plane and data plane and the tight coupling of control and data plane becoming more important, is something that's lending towards SoC, certainly, capabilities. Where the Arm roadmap is going and even where our architecture partners are going. I don't think moving forward, you can assume that x86 will have the single high-threaded performance advantage that you might see or might have seen in the past.
Okay. Very clear. I'd love to continue on these very technical topics, but I'm conscious of time. Maybe I would move on to a broader perspective, and I'd love to hear your thoughts on how you think you guys are impacting the value chain. My first question would be very simply and maybe very candidly, could you tell us who were your biggest sponsors when you got into networking? Who were all excited about talking to you amongst chip manufacturers, of course, and one level above amongst equipment vendors and then among service providers? Of course, there's a flip side of that question. Who was kind of resisting, and who perceived you, at least initially, as a threat?
Interesting question. I think in general, the resistance to Arm or to change, is usually in pockets of the market where there is legacy, and people do not want to invest. As we've mentioned, the transformation going on in infrastructures created real pressures, for carriers, for OEMs and then for the silicon partners that supply them. I think it's fair to say that the market has really been looking towards a way to provide more efficient solutions. That is everything from the physical solution, the higher density, better performance, and power optimized to, as we mentioned earlier, a consolidation on code bases, being able to use more open source software, et cetera. That all has really been positive in terms of the reception that we've gotten from the various parts of the value chain.
I think you just need to look to things like Linaro, which is a nonprofit foundation that is dedicated to providing optimized Linux upstream to the Linux kernel around Arm-based platforms. In that group, we have a networking group, and members of that networking group include pretty much the broad spectrum of our silicon partners. Broadcom, Applied Micro, and Freescale, TI. I'm going to leave probably some off, but the broad spectrum, as well as OEMs like NSN and Cisco. We've had really, I think, positive momentum and a good reception from the value chain.
Okay. Great. I think I'll probably just limit myself to just one last question, and that will be my concluding question. A lot of observers looking at this evolution and looking at a consolidation, a concentration of processor architectures in networking will immediately think about commoditization. If everybody's selling chips with Arm architectures on them, this is going to be a commodity market. Some will argue doing networking chips is going to become a commodity business. Some would argue doing networking equipment is going to become a commodity business. Then the conclusion of that whole line of thought would be, well, Arm is actually going to increase efficiency, reduce price of equipment, et cetera. It also means Arm is going to badly hurt the profit pools of the value chain. What would be your reaction to that?
I think broadly, Arm is enabling innovation in the right places. I think it's really up to the carriers and the OEMs, and their strategies on how this market evolves and what parts of the market are commoditized and which aren't. I think the Arm business model enables the flexibility for these new types of networks. We have to remember that networking chips are some of the most, I would say they are the most complex chips across markets. These types of things, Broadcom just announced a new switch chip, for instance, with trillions of transistors. They're very complex. That I think is going to keep the value up in the networking silicon market because there are many more components that go into it, in addition to the general purpose compute.
Thank you very much. I say it was my last question, I'll refrain myself from asking the many more I would have. Thank you very much for taking the time to do this call. I learned a lot. Thank you all for taking the time also to listen to us. I'll hand over to Ian for closing remarks.
Thank you, Pierre. Thank you, Charlene. I know that we've taken lots of notes at this end, and I think you've asked and answered most of the questions that certainly I've been asked over the last few months about our opportunity in enterprise networking. Thank you for everybody who's dialed into the call. We hope you've also found this useful. We are planning a call in Q4 about Armv8 potential penetration into smart mobile devices going forward. There'll be more information about that coming up on our website later. Hopefully we'll be seeing some of you next week at our technology conference. There is an investor event associated with that on Thursday, the 2nd of October. This is based in Santa Clara. Information on how to get involved with that is also on the website.
Finally, we have our Q2 results on the 21st of October, and we'll be on the road immediately after that. Hopefully we'll be seeing most of you all there. Thank you very much indeed, and good evening, good afternoon, good morning to you all. Thank you.