Verizon Communications Inc. (VZ) Earnings Call Transcript & Summary

Okay. Good afternoon. My name is Colby Synesael. I'm the communications infrastructure and telco services analyst here at Cowen. Welcome to day 1 of Cowen's Communications Infrastructure Summit. This one being brought to you virtually, unfortunately, opposed to our typical Boulder surroundings. For this presentation, we have Verizon. It's structured as a fireside chat. And from Verizon, we have Adam Koeppe, who's the company's SVP of Technology, Architecture, Strategy, and Planning. This is going to go for 40 minutes. I have a bunch of questions prepared, but there's also a way for you to ask questions through your screen and those will pop up and certainly I'll try to get to as many of those as I can. Before I go into my questions, I'm going to turn it over to Adam. I think he has a little bit of safe harbor commentary.

Yes. Thanks, Colby. It's great to be here and if you know, everybody's favorite disclaimer. We would like to draw attention to our safe harbor slide on the screen, which I think you should be able to see now. Comments may include some forward-looking statements which are subject to risks, and actual results may differ materially, and details can be found in our SEC filings or on the verizon.com Investor Relations page. So thank you for letting me say that.

All right. Always my favorite part. So I wanted to just start off like we did last year. Can you tell us what it is you do at Verizon? And what your responsibilities entail? And I guess, I'll just add this in there right now. What are some of the -- where are you spending most of your time?

Yes, it's great. And the title is a bit of a long one because we're really broken out into a couple of different functions here in the planning team. And we have our overall technology strategy, which we pair closely with our overall corporate strategy and our business units. We have our architecture, so the architecture for all of Verizon's networks is defined by our team. And then we have the traditional planning process, which is everything from hardware-software road maps for our technology partners to our device technology landscape, working closely with our device teams and the capital planning process that we use to build out our networks. So it's a pretty large set of activity across our group. If you think of it in this regard, every piece of wireless and wired equipment that is in service in Verizon at some point flows through our planning team. So when there's a technology shift like we're seeing today with the intelligent edge network, 4G to 5G, edge compute, all of those things kind of originate within our planning organization. So we're spending most of our time on that. For us, for -- as a group, first and foremost, here, our focus right now is certainly on the health and safety of our employees. So that does take a lot of time these days. We're all working remotely. It's been a bit of an adjustment, but really happy to say that we've been moving the business forward quite well given the circumstances.

Okay. Great. I guess, sticking with that topic of COVID-19 in the network, a lot has changed since we spoke with you last year, namely the pandemic, the subsequent lockdown, a shift in work-from-home, increasing OTT video demand and a change in wireless patterns. Hans has also noted accelerating certain priorities in the company's strategy as a result of the pandemic. As it relates to your world, how has COVID-19 changed? Where it is you're focusing?

Yes. It has been -- it seems like a long year so far, but most of our work, like from a pure tactical standpoint, has been business as usual. Obviously, we're all working differently. And we're spending a lot of time on collaboration tools like this, but the actual projects and the deliverables are largely consistent. And in the beginning of this pandemic response, we had lot of network traffic assessment going on, looking at hotspots in both the voice network, our collaboration tools. One thing that really stuck out in the beginning was our voice network profile was very consistent for many years. And then when work-from-home started, we had a dramatic increase in voice usage, collaboration tool, the usage of those solutions went through the roof. And our planning, engineering and operations teams, they really -- they knocked it out of the park on that front and just adapting to those shifting usage patterns on the voice networks and addressing them. It's fantastic to see. And on the wireless network, also uses pattern shifts. When states were more or less kind of quarantined, less mobility on the network. You saw a bit of a decrease in urban usage, a bit of an increase in suburban and rural usage that fit with people working from home more and really just less travel going on. So we responded to those, accordingly adjusted where we had to, kept the business running. There's been also great response on that front. And I would just say whether it's a pandemic response, natural disasters like we saw last week, our response to societal injustices, our employees across the globe have gone above and beyond to help their colleagues and our customers. And I just couldn't be more proud of how we've answered the call this year.

On the wireless side, you mentioned you had seen a slowdown, which what we had seen in data that we looked at as well. Has that come back up? I mean, are you back to what you'd perceive as normal levels or are you still somewhere below that?

It's a little bit below and mainly focused again on the mobility. So not so much the overall usage, but there's been a -- still that shift where you see a little bit less in the urban centers, a little bit more in the suburban and rural. Naturally, there's been a lot of kind of reopening around the country for certain states. So we've seen that usage get a little bit closer to normal, not totally to pre-COVID levels, but closer to normal. And these shifts have been -- it's been an active process of addressing them because each state has been a little bit different and depending on how they've approached their response to the pandemic. So we've had to be fairly flexible in what we look at and how we adjust the network accordingly. The team has done a phenomenal job, really seamlessly working to provide a best-in-class customer experience, and you can see that in our 25th consecutive set of J.D. Power wins for network quality, that's really just a result of the fantastic engineering our teams do.

As a result of the pandemic, what changes are you seeing on the enterprises making to their networks?

Yes. We -- so I mean, like we did here at Verizon, big shift for major -- our major enterprise customers going to a work-from-home or a remote model in some way, shape or form. So a lot of that workforce shifted to a home-based model. That increased the use of collaboration tools, increased demand for VPN circuits, increased capacity across the voice networks and the collaboration suites, like I mentioned before. Call center products have been critical for enterprises. So they adapt to these new work environments. There are small, medium businesses using solutions like One Talk to allow for call routing that they would have to adjust on-the-fly based on what stores are open, what stores are closed, where employees are housed. So that's a really good solution for flexibility in the small, medium business front. And then obviously, we have our acquisition of BlueJeans. It's fantastic to have them as part of the portfolio, obviously, geared towards the enterprise communication suite. And that's been already a great partnership and we've got some very well-aligned technical road maps working with the BlueJeans company.

Those technical road maps that you're referencing, I mean, the company has said that you'll incorporate BlueJeans into your portfolio and your strategy. My impression was you won't just leave BlueJeans by itself as a stand-alone product, you could still have that as a customer, but there's going to be other ways to utilize that technology. Can you give us some more examples of that?

Yes. So there's work to do here, obviously, but we've already had the teams basically sitting together and going through the, call it, the traditional Verizon product portfolio and how that can align with the BlueJeans' capabilities. There's a tremendous amount of synergy. That's not a new concept. We've been active in the collaboration space for many years, and that's a product we provide to our enterprise partners around the globe. And if you think of use cases that parallel with 5G and video collaboration, telemedicine, distance learning, field service work, training resources, there's a really great fit there. So we already see that. We've known that to be the case with these types of video solutions. Now we have it as part of our portfolio to integrate directly. And we see really good promising capabilities there.

Sounds like you vertically aligned products, and is that fair?

Absolutely, yes, for sure.

Then switching over, I just want to talk about the edge and ownership. Has your definition of the edge evolved in the past year since we last spoke?

I don't know it's evolved, per se. And again, edge can have a lot of different definitions based on what you're doing. But our plan has been the same. So our edge compute strategy allows us to actually be pretty flexible with where we deploy compute resources. That's the beauty of it. So...

It feels like -- I'm sorry to cut you off but I just need to get this in there. But like it feels like a year ago, there's a lot of talk about focus on the C-RAN hubs. And now it feels like there's a lot more talk about focus on the MEC, so it feels like you moved the edge a bit further into the network versus your thinking a year ago? I guess that's the premise behind it.

I got you. Yes. So I would think of it this way, Colby. Think of edge compute as a function that you can put at any part of your network, based on the latency needs that you're trying to meet. And so let's start with edge compute in our owned LTE architecture locations or SAP locations. That provides a latency that can meet use cases A through Z. And when you need to decrease that latency even further, you're going to push that edge compute out past the SAP locations to a central office location, a fiber POP, a C-RAN hub location, whatever it might be, to decrease the latency for that particular part of the network. So edge compute is actually meant to be agile positioned into the network-based on the use case you're trying to meet. All of those locations become fair game, if you will, for edge compute resources.

Okay. And then this is my criticism, and you could -- I'm going to put you on the defense. But I have a hard time understanding why, over the long term, it would make sense for someone like AWS, which I know you're working with, to deploy in 1 region in your MEC pack but also in AT&T and T-Mobile's MECs, opposed to a neutral host MEC or edge location. I guess, what am I missing in my thinking?

Well, I mean, probably what you may be missing there is, I mean, AWS partnered with us for a reason. And so there's really 3 important pieces of that edge compute equation. So you've got the compute resources. And in our historic partnership with AWS, it's their Wavelength platform which is designed specifically for small footprint, edge compute capabilities. You have then the space to operate it in. So we talk about edge compute being placed in our owned locations. And our distributed architecture is an enabler for those resources to be put in locations that we own and operate. They're already on the network and that provides the third layer or the third advantage, if you will. So you got the Wavelength platform. In the case of AWS, you've got our locations, and you've got our network connectivity. That's fiber, wireless, backbone. Those 3 things position us very strongly in an advantageous position here. And when you take that package and then what you're doing is you're creating a capability for developers, like those in the AWS community, to now build applications on top of this low-latency distributed network. So that package there is it's really compelling. There's a network function that we're providing better than anybody. We've got the AWS platform and the development on...

You have the first-mover advantage. That's how I...

Absolutely. Yes.

And my question then is if you have the dominant position, you're building off of that first-mover advantage, you're taking share, at some point AWS is going to say, well I want to offer these same services to AT&T or T-Mobile or whomever else type customers on their network. Will they be able to do that from your MEC?

I wouldn't comment on the structure of our relationship with AWS, but what we're focused on now, since we have that first-mover advantage, is showing them that this is the best possible partnership that they can have in the business. What they choose to do beyond that is their call, obviously, but we've been thrilled with the technical relationship and partnership that we have. We've got great technical leaders running this. And actually, we just launched those services in Boston and the Bay Area. We announced that last week. So we're making tremendous progress working closely with AWS and have been really pleased with the partnership there.

So talking about MECs, Verizon plans to build 10 public MECs at SAP locations or SAPs, this year with the goal to have about 55, I think, SAP locations that are MEC-enabled in the next few years. So a lot of -- lots to unpack there. But first off, I guess, what is a SAP for those who might not know? And can you help us understand what goes into standing up a public MEC at an SAP location?

Yes. So we'll come to the acronyms in a second. But I mentioned a second ago, we just saw us launch Boston and Bay Area edge compute zones. And the way to think of that is basically a piece of geography that's now capable of providing low latency services based on that edge compute capability. And I do want to extend a huge thanks to the Verizon and AWS teams that worked their tails off to bring this to life following our successful trials in Chicago, which we announced earlier. But a SAP location, it is really just a -- it's a distribution point based on LTE architecture. So without going too far into a rabbit hole, the LTE architecture is based on IMS locations, which were core, and then you have had SAP locations, which were considered edge. And the lower latency needs and the LTE architecture relied on the SAP locations. Things that didn't care so much about latency, relied on the more traditional centrally located core locations. The reason these locations, in general, are meaningful is that they're distributed. And domestically, for us, they're distributed throughout the country to provide a certain level of latency that LTE relies upon when you put edge compute capabilities into those distributed locations that have space, power, cooling, availability for that equipment. You then create these edge compute zones that are then available to all of the cell sites and end points, if you will, that are homed back to that distributed SAP location. So it's really a distributed network location that we already own and operate. It's already got network connectivity. We've already got space, power, cooling to accommodate additional equipment, in this case from AWS with the Wavelength platform. So that's how those when we referenced the Boston and Bay Area edge compute zones, that's how those are configured. We've already got their locations.

That's Great explanation. And SAP, I don't know if you mentioned, but it stands for signaling access point, correct?

Yes.

And the 55 number, that we've referenced. That's the total number of S-A-P, SAPs that you have across the United States today and the thought is they all become MEC-enabled, is that correct?

The actual number is irrelevant because if you look at LTE architecture, there's a pairing aspect, which provides geographic redundancy. So the SAP location architecture, it usually functions in native pairs. And that's specific to LTE and failover capabilities. The important point is that we have distributed locations throughout the country that can then provide those low latency zones for the entire footprint that we serve today. So whether that's 50 or some other number doesn't really matter in the sense that we're creating an architecture that's geographically-based, and it has the ability to then provide low latency zones with edge compute across our entire footprint.

Got it. And I guess you mentioned AWS a few times. What are the early learnings of your partnership with AWS as it relates to AWS Wavelength including the work you've done with Bethesda gaming and the NFL in Chicago and I guess more recently, you just mentioned in the press release last week, Avesha, if I'm pronouncing that correctly, that does help [indiscernible] ShotTracker as it relates to sports. I mean, what are we learning here?

Yes. So the biggest thing was the goal with us and the partnership with AWS was to have this edge compute infrastructure, but then really simplify the developer experience. So that massive AWS development community, how do we create a really simple way for them to put applications that require low latency services onto the network and then in front of customers. The partnerships with -- we had Bethesda Softworks, we had Avesha, ShotTracker and the NFL. The biggest thing we saw there was their applications could be quickly deployed where we have to rearchitect their code. And that's a big deal for all of these partners. They don't have to basically recreate their entire code base to have their applications run in an edge compute environment. Now they can write their applications. They take advantage of the low latency zones that are being built, and they're getting significant improvements in latency as compared to public cloud. From an AWS standpoint, if you're a developer for AWS, you've got -- basically, you've got a set of API capabilities with expanded tool sets, same ones that you're using today. So you take advantage of Wavelength. It shows up in its availability zone, and they can start consuming resources based on the applications they write through the traditional AWS development process.

Beautiful.

So it's a very -- it was geared towards really just efficient development of applications that can then take advantage of low latency architecture.

When you think about that and then what you're doing with IBM, as you also mentioned, you've also announced a partnership with IBM to drive that "Industry 4.0" in the industrial environment with IBM's Watson data analytics. I mean when you think about what you're doing with AWS and what you're doing with IBM, part of this is just understanding functionally what is capable. But also a part of it is like, what's the business model? How does Verizon make money doing these things? Can you give us some color on that aspect and how that maybe has evolved?

Yes. So on the IBM front, that's -- we're basically integrating IBM's Watson, and they have an asset management platform called Masimo Visual Insights. That gets integrated with our -- the Verizon ThingSpace platform for IoT. That's been a product we've had in the market for quite some time now and it's an IoT platform. We're putting these applications on edge compute for latency-sensitive things to help drive things like assembly line productivity. So one of the most compelling things when you look at IBM, they have got platforms for industrial innovation. Putting that into an enterprise location with edge compute is how you help transform some of those enterprises. So whether it's logistics or manufacturing processes, those things paired together are a really compelling solution for the Enterprise that's done in partnership with IBM. So when we're approaching our joint or unique enterprise customers, we've got a compelling story that accommodates their software needs, the edge compute platform that's coming through our services. And then they're putting locations specific to things like industrial manufacturing on top of that platform. So much like the rest of the enterprise model, there's a partnership revenue opportunity there, in this case, working with IBM.

And I mean, the concern, I think, for investors, just to kind of put you outside your comfort zone and talk more investor and finance stuff than technology stuff is that with 5G, there's a risk that the value creation is going to kind of move away from Verizon. Akin to what some people would argue, happened with 4G, when you think of the app layer and the value creation at an Apple or just about any other app company like Facebook or something. When you start working with an AWS, when you start working with an IBM, are we seeing the beginning signs of that happening again? I mean, are you approaching this differently than you did with 4G to ensure that you get your just due, if you will, relative to the investments which you're making?

Yes, absolutely. And I think it's -- when you look at the value that was created with 4G LTE, just using that example, as a data mechanism, yes, we had incredible partnerships that helped generate a tremendous amount of revenue. But that's -- there are model improvements that we want to make there in the context of 5G. And when you look at the -- I know Hans has talked and we've all talked quite often about the Eight Currencies of 5G, as an example, they extend through consumer and enterprise and small medium business sectors very seamlessly. And the goal there is to have strong technical and business partnerships that create value on both sides of the equation for the end customer, be it any 1 of those 3 that I mentioned. And it doesn't mean we have to build everything ourselves. It doesn't mean we have to not build things. There's -- we're going to look at that very strategically and figure out where we can add value directly and create solutions ourselves and where we can partner most effectively to either create a larger addressable market or to take advantage of innovation that's occurring outside of our walls. Pairing it, though, with the 5G and MEC capabilities that we have uniquely in the market. That's the most important piece there. So I think you'll see great partnerships come out of this and increase the value that we're getting out of that equation.

Okay. Shifting to public -- first, private MECs. So we said in an edge white paper we did back in May that we think it's likely the first edge deployments will be private edge deployments and thus leverage private MECs, like what you're doing with Walmart, given a lack of third-party edge infrastructure available at scale. So how do you see customer utilization of the edge evolving?

So I think maybe a couple of things. If you kind of ignore private and public just for a minute, the purpose of the edge compute platform as a whole is to provide low latency solutions. So that processing that would normally have to occur, we're pushing that out closer and closer to the customer to create opportunities for them to do things differently than they do today. So whether it's immersive mobile gaming, industrial automation, there are tons of use cases in the funnel that take advantage of edge compute, whether it's private or public, okay? So then you peel that back a little bit and you say, all right, well, let's stick with mobile gaming as a public edge compute use case. And you can -- all right, that's fair. What is a private counterpart to that, if you will? So in the case of private edge compute, right, look at stadiums and venues, look at enterprise locations, look at companies that have a manufacturing plant that they want to completely transform, they don't necessarily need that edge compute capability exposed beyond their walls, right? They want to use that capability within their facility within their campus, within their manufacturing plant. So the use cases have some overlap between the 2, things like VR and AR. There's public use cases for that, and there's private use cases for that. And so how that solution gets solution gets delivered, will be slightly different based on the end customer. But think of it as public becomes available on every device that's being sold as an example. Private focused on specific locations or specific sets of locations for a customer that aren't necessarily shared with the public. And there are tons of overlap with use cases in that regard.

Yes. I think implied in your response is we really, to your point, shouldn't be focused on what comes first, public or private? Or what's the big -- your view is that they're both going to be kind of moving at an equal pacing, if you will, and both should be contributing, and it's not clear to you that one is going to be dominant over the other, at least I...

Yes, it's a good way to look at it for sure. And just look at the partnerships that we've set from the beginning here, with edge compute, right? So our partnership with AWS is geared towards public consumption of edge compute resources. So there's going to be applications written for the general public, if you will. That's not to say specific enterprise solutions can't take advantage of that same infrastructure. And we could set it up so that their specific unique need on the enterprise side available for their location can run through that same type of infrastructure with really no challenge to how it's architected or built. And then we already have enterprises that we're partnering with to build that same type of installation onto their campus. So take -- you're placing edge compute resources at their location for their specific needs and you're pairing that with a private network solution. Now you've got really what fully 5G, 4G, edge compute, private solution for a given enterprise. So there's a lot of flexibility, and there's a lot of adaptability that these solutions can then provide to the enterprise or the private consumer.

Bringing all this together, Verizon has spoken about edge in 5G becoming material to revenue starting in 2022. What are the milestones we should be looking for, for the remainder of this year and then into next that should give us some indication that the company remains on track towards what's been stated.

Yes. So you kind of -- so you say you have the bread and butter, which is the continued network performance dominance across our wire to wireless networks. You'll see throughout the year and through next year, for that matter, a series of launches of new markets for 5G mobility, for 5G home, for edge compute zones. We publically talked about our commitments and targets for all of those and then you are just going to see basically a running cadence of launches that are associated with expanding the footprint of all those solutions. Like we've seen with BlueJeans here, there's going to be solutions that we bring together, 5G, edge compute, BlueJeans, that will create a compelling product and we'll talk about that when we get to launching those types of things. So I would focus on this like market launches 5G home, 5G mobility, edge compute zones and then really partnerships in the industry that are going to create value for end consumers.

Okay. And 1 question I got from the audience, which I think is appropriate at this point, is as more infrastructure has moved to the edge of the network, is security increasing in many of the facilities that house that equipment?

So in some cases, yes, depending on where physical equipment is being placed. But one thing to keep in mind is that between physical and logical security, that is something that is really part of our core tenets for operating a network. So it's not like, oh, well, we've got an edge compute now. We have to do something completely different. That's been a staple in the way we design and run and operate our networks from day 1. We've worked extremely closely with AWS on things like physical security, how things get racked up in our locations. It's -- it's really been a great experience on both ends of the equation. But that -- our focus on physical and logical security for all of our network access does not change. That is part and parcel to everything we do.

Okay. Shifting over more specifically to 5G post to edge, but what are the most compelling near-term use cases for network slicing. We've heard about this. We have a general understanding of what it is, still not quite sure exactly how it's going to be used or quite frankly, like everything else in life how are you going to make money on this? Can you just kind of give us some more color or context a year later?

There is slicing done on networks today, and they are really driven by operator efficiency if you will, so I absolutely think the first use cases, if you will, for network slicing are going to be driven by the operator. So how do I create a highly efficient path based on the capabilities I have on the device and the requirements of a network session for said device, and instead of doing that manually like today, we set a lot of those rules and parameters manually meaning certain class of device gets a certain treatment, certain path through the network, if you will. How do I do that at a more granular level and with more autonomy and automation. So when you take the scale that's expected in 5G capabilities in devices, any -- a lot of flexibility and a lot of programmability in the network to accommodate what's expected to be billions of devices over time that are 5G capable. Let's take an example of a VR session. So if I have a VR-capable device and I have to specify that it gets 20 milliseconds or less in latency and 10 megabits per second or more in throughput, we'll be able to slice the network accordingly based on that session for that device when it's needed as opposed to today. If I wanted to do that same thing, I would have to say, all right, any device that meets this portfolio, I will create a permanent slice through the network for it. That could be largely inefficient, right? If you have a capable device that doesn't need those resources at that time but you reserved a slice for them, that's really inefficient. So from a operator perspective, we want to use network slicing and say, all right, in our VR device when it starts up a VR session, I want to create that slice in real time. And all the other millions of devices that are asking for that same type of slice are going to get theirs on demand as well. Those are the types of use cases that will come with network slicing as you would imagine. That's complex. It requires a lot of work and a lot of, really, network function support. But those are the types of use cases that are going to emerge with slicing in mind.

You also want to be able to turn that functionality which has historically been looked at internally and kind of like face it back out to the customer and allow them to have that dashboard, if you will, that allows them to kind of choose what they want, that specific level of latency, that specific level of throughput because ultimately, by giving them that functionality control, it allows you to charge for it in a way, you historically haven't been able to as opposed to just giving it away, which I think obviously, Verizon will not be wanting to do.

It's certainly possible. I would say, right now, even the standards bodies are focused on a kind of a collection of slices. So if you start at -- I don't know, it's just an arbitrary number, 10 different types of slices that you would put into the network, whether it's for low latency, whether it's for ultra-reliable, whether it's for IoT, whether it's for a sensor or what have you, there's -- there'll be like basically a set of slices that are standardized, if you will, within 3GPP.

That hasn't happened yet?

Most of it's -- I mean, it's a work in progress. Most of it's defined, but the...

What figure would that be? Like 17 or something?

You'll see some of it in 16. Some of that's available now. Some of it's in 16, and it will progress. But you want to take those as the base layer and then figure out, all right, well, what else can I do to create additional slices that are specific to my customers or specific to a product I'm selling, and you build off of that framework.

Got it. Okay. And then shifting over, talking about fiber and small cell build-out, is Verizon still averaging 1,400 fiber route miles per month as we spoke last year? Or are you pivoting to other projects?

So the monthly run-rate actually varies depending on the month that you're in because as we're building out our fiber footprint, we're pairing that with our 4G and 5G node needs. So yes, there's some peaks and valleys to the averages, but the fiber build plan itself has actually progressed really well, especially during the pandemic, which has been interesting. Some markets have been a bit harder to build, all others have been easier. But overall, our fiber route miles are ahead of where we wanted them to be for the year. So that's a good story. That's -- so that's actually moving along quite well. And I say even now, the vast majority of 4G and 5G nodes that we activate inside of our fiber markets are served by our own fiber. So -- and if you remember, when we talked about this initially, the goal was to pair our node needs with our fiber deployment and have kind of a very tightly integrated engineering process for those end locations. So we could capitalize on the owner's economics of that fiber. And we're doing that exceptionally well today. So our teams have been cranking up the fiber build and they're pairing it with our 4G and 5G node needs, and it's going exceptionally well.

I mean don't you get to a point though where like you've blanketed enough of the U.S. with fiber. And it's no longer about building the fiber and the strategy does kind of transition to other areas of the build-out, maybe it's MECs, for example? I mean, where are we in that?

Yes. So if you think -- I mean we had 60-plus markets that are in some phase of fiber build-out, right? But the goal isn't every square foot of the country. So it is very targeted to the more dense areas, our hottest markets, if you will, for 4G and 5G growth. That's where -- that's the sweet spot for where we're putting our fiber resources. That's -- there's still 2 to 3 years left in that build program for those core markets. So each year, though, we have an aggressive capital management process that looks at projects that have a greater need versus ones that don't and shift resources accordingly. But right now, we are full steam ahead on the fiber build and pairing that with our 4G and 5G node deployments and it's been going exceptionally well.

Can you give us a sense how many small cells you have today? Or how many you would anticipate having in the next 3 to 5 years?

Yes. We don't really release any stats around the number of cells we're building or the number of small cell nodes we're putting in service.

Why not?

It's really not relevant. The end result isn't -- the goal isn't a specified number of nodes. It's how many people am I covering, what type of network experience I'm putting in front of them, and that's a byproduct of our design. And you see it reflected in the awards we win in the market every year.

And then shifting to CapEx a little bit. Verizon raised its CapEx guidance in the first quarter of '20. What buckets have you accelerated with that incremental capital?

So that was -- a lot of it was focused on, again, tried and true 5G and fiber. And those programs, these are multiyear programs, our 5G ultra-wideband millimeter wave deployment, the fiber build, those are multiyear programs. And when we can increase guidance on those, and also at a time of this pandemic where there's societal good to that, if you will, we're able to build through these challenges and advance those programs and put more weight behind them. That was really the purpose of the guidance. It was -- we're going to do more of these things that we know are successful, and we know we're doing well. We're going to basically increase the pace and cadence and guide some additional capital towards those projects.

Okay. We're running out of time. So we're in the lightning round now. I want to talk about DSS real quickly. On the 2Q call, Hans noted DSS testing is going well. When will we see a market launch? And what is required for that to occur?

Yes. So DSS has actually been going quite well. The way we -- and if you recall, the way we've positioned DSS is the network capabilities, the device capabilities, the chipset capabilities. We're going to develop all of that together and that's what's basically being put through its paces in the field right now. And we're basically turning that over to our commercial teams, Tami and Ronan and [ saying this ] when you -- when we feel that there's a viable commercial need based on customer demand, handset availability, market conditions, whatever it is, we're ready to flip the switch and provide a 5G nationwide experience using...

And you're ready now? If Hans came to you and said, in some reasonable period of time, for you to get your ducks in a row, we need to go, you could do it?

Yes. And like we've said previously, any time in the second half of the year here, we're able to take advantage of that capability and put that type of solution in place, yes.

Okay. And then the company has recently started messaging a goal to deploy a portion of the C-band spectrum. You, in theory, will win at auction as early as the second half of 2021. What will be required from a network upgrade perspective to enable this?

Yes. So first, we have tremendous amount of confidence in the FCC to meet the time lines that they've laid out. And you've probably been following that in the market and everything that's come out through that process for the C-band auction. Targeted for December -- December of this year, has been positive. So that's good news. Assuming success at that, the first chunk of spectrum, if you will, that's made available is expected to be free and clear for use by December of 2021. And so there's several things you can do ahead of that, and this is not unique to C-band. In fact, anytime new spectrum comes to market, you can always do some work ahead of time, whether it's real estate and permitting, whether it's baseband upgrades within your cell site, there's a lot you can do ahead of time. You're going to manage that effectively and accordingly based on your capital envelope, but there are things you can do ahead of time to be prepared for that.

And if you got C-band, though, from the Verizon specific perspective, recognizing all the other bands that you already have in your portfolio, can you leverage antennas and radios and so forth that are already out there, but now could be kind of tuned in, to use a nontechnical term, to support C-band? Or do you actually need to put new physical infrastructure up on these towers to support it? I know nothing is -- I'm just talking...

Yes. Yes. No, I'm with you. Yes. In the case of C-band because this is the new band that's being deployed, there's new antennas, new radios, things like that are required for use of that band.

Got it. So you will be assuming you win, assuming you build-out for that, there is new physical hardware that has to -- or equipment that has to go up on these cell sites to support that?

Yes. Correct.

Okay. Well, with that, Adam, we are out of time. Thank you so much for joining us again. Really appreciate and hope to see you.

Yes. Live next time, right? Colby.

Absolutely.

Thank you very much. I appreciate it.

Thank you so much and enjoy the rest of your summer.

Thank you very much. Always a pleasure.