Thank you for standing by, welcome to the Arm Enterprise Networking conference call. At this time, all participants are in a listen only mode. If you require operator assistance at any time, please press star zero on your telephone keypad. I must advise that this conference is being recorded today, on Monday the 23rd of June, 2014. I will now hand the conference over to your speaker today, Mr. Ian Thornton. Please go ahead, sir.
Thanks, Tom. Good morning, good afternoon, and good evening, everybody. This is Ian Thornton, Arm's Head of Investor Relations. This is a Q&A session with Colin Alexander, Arm's Segment Marketing Manager, who is responsible for the enterprise networking market. We were going to have Andrew Dunn, the analyst who covers Arm at RBC, to quiz Colin. Unfortunately, Andrew will not be able to join us today, our own Phil Sparks, Arm's Investor Relations Manager, will be sending the questions to Colin. Hopefully, you have already had a chance to review the slides and listen to the recording of Colin's presentation. If not, both slides and webcast are available on our website at www.arm.com/ir. With that, I'll hand over to Phil.
Thanks, Ian. Thanks for joining us today, Colin. Let's kick off by referring to the final slide in your webcast, which has the familiar table of Arm's addressable market in networking in 2018. You see here we've got target penetrations ranging from 20%-60%, 60% being in mobile infrastructure, giving roughly 25%-35% target share by 2018. I think today market share is around about 5%. Why do you think there's What's changed recently that means Arm could be confident to reach these higher market shares in just a few years' time?
Sure. Thanks. A good question. I think there are a number of factors really. We start off with our processor IP that we've developed. I think the performance levels on cores for handsets are now reaching the levels that can be used in enterprise. I think the first core that we developed that was an example of that was the Cortex-A15. Now, combining that together with the interconnect we've got with the CCN, cache coherent networking line of interconnects, I think means that we've got a very good product set to meet the needs for the infrastructure. I think one of the other factors is that the expense of supporting dedicated processor architectures has encouraged many of the semiconductor companies to swap from other architectures, like for example, PowerPC and MIPS to Arm. There are a number of different examples.
I'll pick three, Freescale, Broadcom, and Cavium, because there's strength in this particular market space. I think another example that backs up the increase in market share are the challenges that are being faced by some of the companies developing new equipment. For example, let's pick up a multi-radio access base station. Where today you may have multiple boards, multiple different devices on that board, many of these are being collapsed into single system on chips for power and board savings. I think that there's a perfect storm of change within the network today. There are so many different changes happening at once. For example, I mentioned multi-standard radio base stations. There's also content delivery moving towards the edge of the network, and the advent of cloud processing as well. I think we're well placed to capitalize on these.
I think the final thing I'd like to pick up on are the devices that are today targeted towards the server network that can be targeted at the core. The announcements that have been made by Broadcom with their Vulcan device and Cavium with their Thunder, I think makes it highly possible that we can achieve these rates in the 2018 timeframe.
Why do you think it is that Arm's winning market share in mobile infrastructure first? Does it have anything to do with our heritage in mobile devices?
I think that typically, the OEMs are well aware of our architecture. They're aware of Cortex-A and Cortex-R used in mobile phone modem technology, and today also in the base station modems that are out in the radio head. I think if you look at our low power heritage, and power consumption being extremely important to target for the mobile infrastructure as well, I think that they're well aware of the benefits that we can bring in terms of lower electricity costs for powering their access network.
While we're on the subject of the access network, could you tell us roughly how many macro base stations are built each year, and how many chips would be in each base station? What the value of that semiconductor content might be?
Sure. Well, today, for the 3G and 4G network, there's around about 1 million microcell shipped. This ramps dramatically over the next few years, up to at least 1.5 million per year. The average selling prices into these equipments, they're reasonably high at around about $150 each. Now, potentially, there could be one or more devices per base station, depending on redundancy, resiliency, et cetera.
Okay. A quick bit of mental arithmetic. That gives me a silicon content of about $500 million a year coming from macro base stations. Referring back to that table, we've got a TAM of $4.5 billion from mobile infrastructure in 2018. What other types of equipment are in mobile infrastructure? It's not just macro base stations.
Sure. Well, there's the long vaunted hyped topic of small cell, which I think is certainly going to become a reality in the next couple of years for a number of reasons that I'll touch on in a second. There's radio head designs. That's basically the electronics that sits in the antenna and does some preconditioning of the traffic. Then there's equipment for the backhaul. Basically taking traffic from the base station and routing that into the core network. Why are small cells important? They're not simple devices. I think that the throughput is similar to a micro cell. They may contain or be able to service fewer users, but they contain similar chips in terms of complexity to the micro cell.
For each micro cell, it's estimated that there's going to be around between 5 to 10 small cells per micro cell, with each one costing $80-$100. The reason now for small cells is for, basically, the micro cell is being used for coverage. The small cells are being used to supply capacity into the network. The operators have been focused very much on providing coverage up until now, but now the focus is on providing the capacity, especially in LTE networks with higher frequencies.
Roughly how many small cells would we see for one macro base station?
As I said, probably between 5 to 10.
Right
Per micro.
Okay. You say similar complexity of chips. Again, we're talking about $100 each time.
Yeah. $80, $100. Yeah.
That gives us about another $1.5 billion of silicon consumption from small cells.
Sure. Yeah. Onto radio heads. The base station versus the radio head. The base station is involved with the conditioning of all the cellular traffic that basically comes from the backhaul. The base station processes all the packet traffic that comes in from the backhaul, controls and allocates the air interface bandwidth per subscriber, and is involved with the transitioning of subscribers from one base station to another. The radio head is the part of the base station system, but it's partitioned much closer to the user, so it doesn't have to be in the base station box. It can be, but it doesn't have to be. And it contains an antenna and an amplifier. The Arm subsystem is involved with the processing that's required to condition that signal for appropriate amplifier behavior.
Typically, we can see between 3 to 6 radio heads per microcell, and each one containing a chip costing, the Arm part of the subsystem, costing GBP 40 to GBP 50. Moving on to backhaul. There's roughly two backhaul links per microcell, each with an Arm subsystem chip costing GBP 80 to GBP 90.
Roughly speaking, backhaul and radio heads adds about another $1 billion to the TAM.
Which still leaves a bit of a gap. Is there anything else in there that's worth mentioning?
Well, I think these numbers are going to evolve over the next 3 to 4 years. I think that one large segment just now is carrier Wi-Fi. I think that for large suburban areas, airports, campus sites, shopping malls, et cetera, typically Wi-Fi coverage over cellular type areas. This allows users Internet access for data surfing, but not necessarily for voice calls while on the move. This is a huge market at the moment, and many OEMs are integrating carrier Wi-Fi into their next generation base station equipment. Ultimately, the function that Wi-Fi handles today may be strongly impacted by the introduction of 5G and billions of IoT devices, and the need to handle much higher bandwidth cellular voice and data traffic.
Great. Thanks for running through the sort of the market TAM. Should we move now on to the types of system-on-chips that Arm's partners are making? We've had a couple of product announcements recently. Could you give us an example of some of the things that our customers are building and what they're doing with the Arm processors? What of their own IP are they adding in as accelerators around our cores?
For an average micro BTS today, we see the OEMs utilizing eight to 16 Cortex-A15 cores. Potentially, this could be the new 64-bit cores that we've just introduced, the Arm Cortex-A53 or Cortex-A57. These run the control plane, management plane, and the data plane, so packet processing or MAC user interface scheduling. Many of these SoCs are using Arm's CCN interconnect that supports cache coherency between the cores and the IP peripheral blocks. The associated partner IP that is supported on these devices is wide and varied according to application. Generally, it's associated with logic that is more optimally hard-coded rather than programmable. For example, security crypto accelerators for the backhaul interface or for the air interface. Typically, buffer management and perhaps event queuing management. In the future, I think we'll see even higher core counts.
Examples of that was the recently announced Cavium ThunderX and Broadcom Vulcan designs that will support in excess of 30 cores. I think the Cavium device that more details were published last month supports 48 cores at around about 3.4 gigahertz. I think in the future, we'll continue to add more cores and interconnect capability to our roadmap to support the infrastructure networking space.
You mentioned interconnect just then. Could you explain in a little bit more detail what Arm's cache coherent network IP is and how it helps our partners?
Sure. Arm CCN or cache coherent network interconnect is really fundamentally important to how we support the different types of traffic on today's networking system equipment. Control plane, data plane have fundamentally different characteristics. Control plane associated with tens of thousands of instructions per packet, whereas data plane, it's in the region of hundreds to thousands of instructions per packet. The CCN interconnect must be able to accommodate these whilst balancing the CPU core partner IP and memory requirements of the system. Quite conceivably, we can see supporting in excess of 64 Arm cores on a single chip in the future.
What are the advantages of using system and chips in networking, say, compared to taking a large general purpose processor, which might have been designed for something like a high-powered server?
As I mentioned just a second ago, I think the fundamental requirements for networking is that high-performance control plane. You require, as I said, tens of thousands of instructions per packet must be combined with efficient architectures for the data plane, conversely, requiring hundreds of thousands of instructions per packet. The networking cores are required to handle high bandwidth, bursty traffic, and latency-sensitive user scheduling. The SoCs integrate different cores optimized for each type of task. They also must integrate accelerator IP, which is required for these different networking applications.
A number of Arm partners have announced significant Arm-based initiatives in servers. I'm just wondering, how does that align with our partners' strategy in networking?
I think, it's very important just now in the advent of all the different changes in the network. I think our work in executing on a strategy to support servers has led to us having an excellent position in supporting all the different software functionality and having a broad base of partner support for a range of different server platforms. I think this has led to us mass compatibility across a range of different silicon and software partners. With the inflections likely in the industry over the next few years, there's a need to ensure all the server capability and networking capability can be accommodated on the same silicon platform in order to meet all the different possible scenarios in network rollout. For example, NFV, cloud, content delivery are all examples where server capability and networking strongly interact.
Again, going back to my earlier point about Arm currently having a 5% share, can you describe where Arm has presence in networking at the moment?
Sure. I think that typically, given where we've come from with the processor architecture we've had, lower price chips into corporate networking, enterprise networking boxes. Ethernet switches, office enterprise routers, home routers, DSL modems, Wi-Fi access points, et cetera. I think, as I explained earlier, the processor capability that we now have in our portfolio, and the increase in the number of cores and high-priced chips going into, for example, macro base stations, backhaul equipment, et cetera. I think we'll see revenues continue to build from here.
Do you think that Arm's market share is likely to step up at any point, or is it going to be steady increases? Will it be felt most in particular areas to begin with?
Yeah. We'll certainly see a large market share in macro base stations. I think the public announcements are Huawei and NSN. There are others as well. I think there's five main vendors, I think we're well positioned to take a good market share in cellular base station technology. I think that will permeate out from that into backhaul into the core network. I think with the system initiatives that I described on the call last week, I think we're well positioned to capitalize on these inflections that are likely in the industry.
You mentioned earlier that the semiconductors are adopting Arm because they want to save money by really pooling their resources into one single architecture. Does that logic apply to network operators as well? Can the operator save money by standardizing around Arm instructions?
I think so, yes. I think that ISA compatibility matters because of their overall total cost of ownership, I think that code compiled for a particular processor architecture on a particular compiler or tool chain will then work across a range of cores from a particular ISA provider. If you've got multiple processor architectures or microarchitectures, then you need different tool suites and compilers. To manage two or more sets of software, it becomes very complex. You need to train your teams on these different architectures. For the large OEMs, this is a big issue because they've got to multiply different code sets, they've got to have multiple suites from different software providers, and engineers trained on these optimizations from multiple architectures.
I think, yes, the ISA compatibility does matter to the OEMs, we hear that message back from them as well very strongly.
Why do you think they're opting for Arm over, say, MIPS or PowerPC or x86?
Yeah. I think the range of cores, the series of interconnects that we've got all encompass that.
Who do you think is driving the decision? Is it the chip vendors which have licensed from Arm? Is it the OEMs that use those chips? Or is it the network operators that use the equipment?
I think depending on where you view, you could answer all three. I think for cost perspectives and what we mentioned earlier about maybe migration away from PowerPC, MIPS, et cetera, onto Arm, that's obviously a concern for the silicon providers and the OEMs. I think the OEMs, they can view the initiatives that we've got ongoing, information that we're exchanging with them. It makes them very comfortable with mixing and matching different functionality on the Arm core and interconnect IP. I think from an operator perspective, the new initiatives that are being rolled out, namely content delivery, SDN, software-defined networking, NFV, network functions virtualization, cloud, are all factors that motivate their selection of processor architecture. They want to make sure that if they select an architecture, it's got the right performance points, it's got the right power consumption points, and meets their goals longer term.
Thanks. We've just had a question emailed in which I think we should probably touch on. In the webcast presentation, you talked about data plane and control plane. Could you perhaps just recap on a bit of that, perhaps expand on exactly what data plane and control plane entails in terms of workloads, and which processors are best suited to which application task?
Sure. This is really, really important. Let's start off with control plane. Control plane's a broad term that comprises a number of different elements. Typically, again, looking at the base station environment, setting up channels, tearing down channels, running connectivity stacks that are specified through 3GPP or IEEE, measuring which bandwidth should be allocated to which subscriber, handing off cellular subscribers from one base station to another, making the decision on what base station should control which subscriber. These are all control plane tasks.
Okay.
Typically, the larger cores with high single-threaded performance are allocated for control plane. If you flip down to the other side of the network requirement and look at the data plane, typically this is involved with fast path transfers. Control plane is slow path, data plane is fast path. Really there's two different elements to the fast path. One is in handling the network data as it comes onto a particular piece of equipment. Typically you'll have hundreds of, or tens, hundreds, potentially gigabits, tens of gigabits up now in the core network, up to hundreds of gigabits of traffic on your network node. Typically today that's IP packets. They may reside in ethernet frames. They may be tagged with things called MPLS.
You have to look at the packet data, you need to extract the data from that packet, you need to buffer the data into memory, and you must be able to do that at line rates, so you're not dropping any data. That needs lots of interactions between different packets, different accelerators. Typically it's more suited to smaller cores that are able to access memory very fast and are able to access cache memory really quickly, with hundreds of instructions per packet. There's also the latency specific requirements for user interface scheduling, for example, MAC scheduling, where if you've got 2,000 users connected to your base station in a specific time interval, you have to make a decision on which of these users should be transmitted. What's the priority of these users? Is it voice, data, video? There's tremendous amounts of interaction between the different processor cores.
Typically there's maybe thousands of instructions per packet. You've got a range here of large cores, smaller cores, and really it's all interconnected through the ability of, for example, the CCN, cache coherent networking interconnect, to be able to hook these different requirements together. It is a really, really important factor, and it's one of the things that Arm, together with our partners who have got a lot of experience in pulling these architectures together, combined with the OEM knowledge, we can really, really provide an advantage here.
You mentioned that part of the control plane work is opening channels and then tearing them back down again. I guess the networks have been designed around this idea that we make voice calls for a certain length of time. How does that control plane effort change as we move to IoT with potentially tens of billions of devices connected to network?
If we look forward where IoT devices, Internet of Things, fridges, TVs, potentially, you could have safety critical applications connected to cars. You could have security services all connected in there. There's a wide range of very, very, very latency sensitive traffic. As opposed to 5G that's also targeted towards high density cellular, where you set up a channel and you stream a YouTube video for five minutes, which is very data plane centric, these IoT applications could be extremely control plane sensitive, where you set up a channel, you send 64 bytes, you pull the channel down. You set up a channel, you send 64 bytes, you pull that channel down. You've got to do that in a very, very deterministic timeframe. It's very challenging to pull together the architecture that's required for these core networking nodes.
That's something that we're working on with our roadmap developments for 5G.
Can you talk a bit about the importance of open source in networking and any initiatives that Arm is leading there?
Sure. I think that there's certainly a call for more programmability and flexibility in System on Chip solutions. This has accelerated the need for more software from open source communities. The market challenge with all these different inflections ongoing in the industry just now and how we're working with the different communities and in particular through Linaro, I think is key. Just to sum up again or summarize, Linaro is an open source software community comprising multiple Arm partners, and they're all collaborating in parallel on the development of common software functionality that will be used in both the server and networking environments. These companies collaborating dramatically reduces time to market and reduces the cost for them to develop this functionality. Really, they're focusing on the commonly used software features that are going to be needed in the network.
They still focus on their own proprietary value add and develop this themselves outwith the remit of Linaro. Linaro has this benefit of reduction of development cost and dramatically shortening time to market. I think that the use of open source in networking is more and more important, considering changes within the networking infrastructure hierarchy. Changes likely from things like Network Function Virtualization, Software-Defined Networking, content delivery, highlight the need to be able to partition different elements within different boxes. The OEMs and the network operators being able to do that, the need for more open source software availability. Again, I think that that's an element that I'd like to explore in the follow-up webinar that is scheduled for some time in the next quarter.
Great. Okay, well, I won't steal your thunder for that one by asking lots of detailed questions about Network Function Virtualization now. I have to learn to speak at the right time we do that call. I'll guess we'll wrap up here by going back to the first question. We asked then why Arm was now ready for networking industry. Perhaps you could tell us why the networking industry is now ready for Arm.
Sure. I think that highlighting what I mentioned on the presentation that was recorded, there are multiple reasons, but I guess the main ones are the fact that our partners can provide a series of heterogeneous architectures, mixing large and small cores together with DSP blocks, together with their own proprietary functionality on system-on-chip designs, allows them to target the needs of specific elements very carefully. I think that having this Arm-based instruction set architecture scaling across multiple network elements and the ability for multiple Arm-based chips to provide highly optimized solutions so our partners can integrate their value add and differentiate with that value add. I think another key reason for why Arm now is the software environment that we've put in place and are continuing to put in place, our investment in Arm Linux and open source initiatives like the one I mentioned from Linaro.
I think that the final point is in providing competition, choice, and innovation for our partners to really provide a wide range of solutions, and ultimately lowering our networking OEM partners' total cost of ownership.
Great. Well, thanks, Colin. I look forward to hearing more in part two. Appreciate it.
Okay. Well, thank you, Colin. Thank you, Phil, thank you everybody for dialing in. As you're probably aware, this was only the part one of two. The second of these calls and webcasts we're planning for probably for September. We look forward to hosting you on one of those in a