AT&T Exec Puts Access Space in Open Source Spotlight

When AT&T released VOLTHA 1.0 this month, the optical access system architecture marked a new approach for the service provider. Not only did AT&T partner with Open Networking Foundation, but the SDN/NFV-based technology also incorporated disaggregation, open interfaces and abstract APIs to support a vendor-neutral, software ecosystem.

Eddy Barker, assistant vice president of technology design and architecture, led the charge at AT&T, as part of his role overseeing the service provider's fixed access broadband platforms. The release of VOLTHA -- or Virtual Optical Line Termination Hardware Abstraction -- marks one of many steps in a long voyage Barker and his team are taking toward a cloud-based, highly automated and orchestrated network that puts services in the hands of users and dramatically cuts costs and inefficiencies, even as the network's power continues to grow.

UBB2020 Editor Alison Diana spoke recently to Barker, soon after he wrote a blog celebrating the release of VOLTHA 1.0. The 25-year veteran of wireless and wireline communications enthusiastically shared his insight into the project, what it means to AT&T and the industry, and why VOLTHA may allow AT&T to skip NG-PON2. Read on for an edited version of the interview.

UBB2020: How did AT&T and Open Networking Foundation work together?

Eddy Barker: We had been participating somewhat with their CORD effort -- central office rearchitected as a data center. We started engaging with them to try to push them into some new areas that just had really not taken advantage yet of looking at SDN from a controller perspective, and we wanted to help drive them into the access area. They had a number of efforts -- residential CORD, enterprise CORD -- and then they had a mobile CORD. We were looking to expand that into access and start focusing on how we could start expanding the domain for SDN control so eventually we could have it end-to-end.

UBB2020: And on the software side?

EB: What we started doing on the software side was standardizing with the SDN control mechanism. We talked to different equipment with different technologies and then, simultaneously, we started working with the open compute groups to develop white box solutions for access. We're trying to create standardized, commodity based solutions for hardware … and we try to commercialize as many functions as we can into that box so we can reduce the cost as much as possible. The hardware is an important part, but most of the effort to make this ecosystem work is really dependent on making that software ecosystem work, and it's essential to control this thing.

Once we've built that hardware abstraction interface to anybody's silicon, then the commands from our systems, our orchestration, is basically the same, and that's what makes it nice because it becomes as easy as taking one box or one virtual application from one vendor and substituting it with another. If done correctly it should work the same way, without changing anything upstream, which helps us innovate more quickly and reduces our capital cost, because the barriers to change are easier and our operations organization doesn't have to learn as many unique pieces of equipment and how to control and manage them because, essentially, it's the same. That's critical to putting this all together as we move forward.

UBB2020: This is no longer new to vendors, so how has response changed?

EB: When we started this effort, we had to solicit community involvement. The key thing to open source is community involvement. Early on in the process, we worked with other global service providers to sign them up and see who was interested to develop some of these applications. Simultaneously, we worked with some of the low-level suppliers like silicon vendors, which are developing a lot of technology in these areas, and ultimately OEMs and ODMs, some of which are legacy incumbents and some of which weren't in that business already. The goal was to get incumbents on board and interested, and at first it's difficult because they've got revenue growth in those areas, it's change for them and they have to rework their business models and figure out how to remonetize.

Over time, as the industry gains consensus on the direction they're heading and when the incumbent sees it's a serious move by the industry and large customers, then the incumbents get on board. I think we've gotten to that point now with this program where all interested parties -- we probably have 14, 15, 16 companies working on it -- have come together and everybody is contributing to advance and to continue evolving the software in the access space.

UBB2020: You're planning to perform XGS-PON trials before year-end. Could you walk us through that a little, please?

EB: We started an RFP -- and pretty much any request for proposal that AT&T puts out nowadays, regardless of what technology it is, all have a foundation built upon SDN and NFV -- we did that for XGS-PON about 18 months ago. The goal was to see how we could drive these new technologies into these new, higher capacity PON technologies.

We started working on a lot of aspects of XGS. The first was the creation of white box with OCP [the Open Compute Project]. We actually have multiple vendors that built white boxes and have them for sale now. We've gotten four or five vendors that are commercializing the ONF VOLTHA software. We're trying to mix and match and make sure everybody works with everybody else. We're pretty close to selecting two vendors to field-trial by the end of this year: One of those will be in Dallas and one will be in Atlanta, so there'll be two different vendors and we'll be trialing out different services with them by the end of the year and probably a little bit into next year. Ultimately, a big part of it isn't just the open software. A lot of it is making sure the technology scales and the technology is economical relative to the optics and the silicon.

UBB2020: And what comes after that? Any other technologies beyond XGS?

EB: We are rapidly evolving it to other technology areas. For example, Gfast -- we are already standardized some of the Netconf/YANG models to control that technology, which will be in the next generation of VOLTHE. (We'll probably rename it to a little bit better name.) Also, we're working with ONF in that same software package to integrate it into ONAP. Ultimately instead of going out and deploying islands of technology that have SDN control, we want to get the whole end-to-end network working and be able to orchestrate it through ONAP.

UBB2020: What happens if you don't make a move, operationally?

EB: Our operational support systems have gotten pretty heavy. It takes us, without updating it periodically, a lot of development effort any time we have to roll something new into the infrastructure. How many operational support systems do we have to deal with? How many separate vendors do we have if we're doing sourcing? Each one of those vendors may be its own development program.

The goal is to get away from that and tie it all together in a more robust and a more flexible orchestration platform that really drives our operational costs down over time. I think once we do that, that's where you'll see a lot of that network programmability be offered out to consumers where they have more visibility and more ability to self-change the characteristics of the services, so customers get access and can program parts of the network relative to their desires.

UBB2020: And a lot more automation as well...

EB: Automation is obviously a huge part of orchestration. That's got to happen for us to right-size our company relative to operating a big network. We can't just keep growing people. It's unsustainable. The more hands you have in the network, the more problems you self-create. All of that automation and orchestration is critical to managing and running and changing it more quickly. It's going to be absolutely vital.

UBB2020: You plan to deploy XGS-PON initially, so does that create a good foundation for NG-PON2 and future technologies?

EB: You look at XGS-PON, some of the systems we put out there, are very much the same and won't need to change to support NG-PON2. We're looking at some of the designs we've got that'll have to be future-proof and go straight to 25-Gbit/s PON, which will be the next step. We may even jump over NG-PON2 and go to 25 Gbit/s based on the economics of the optics. All that becomes easier to do because we can develop through that for deployment much, much faster than we have been able to previously.

UBB2020: How do you juggle serving customers and upgrading a network?

EB: We've got a huge amount of legacy infrastructure and we're always trying to shift things, and that's probably one of the hardest things that we're going through right now: You can't stop the network while you change it. You've got these networks with huge amounts of legacy equipment and then you're trying to come in and introduce new things that are NFV-based, SDN-controlled, and you've got to make those things work together and you've got to determine whether you're going to cap the old one and put the new one in place separately or try to interwork them. In any case, you've got to maintain existing service and take something new and scale it very quickly and make it stable and practical to deploy.

Related posts:  

• ADTRAN 10G-EPON Virtual R-OLTs Bridge Old & New Worlds
• 10 Tech Transformation Challenges Operators Face
• In Days, Calix Integrates AXOS With OpenDaylight Carbon

  — Alison Diana, Editor, UBB2020. Follow us on Twitter @UBB2020 or @alisoncdiana.