Service providers have been landlocked across each others’ networks due to the different architectural approaches they’ve taken, but the barriers are starting to crumble, as evinced by a recent partnership between AT&T, Orange and Colt.

Late last month, AT&T Inc. (NYSE: T), Orange Business Services , and complink Colt Technology Services Group Ltd (London: COLT) announced at Mobile World Congress that they had forged an orchestration partnership that allowed them to provision services, starting with Carrier Ethernet, across each other’s SDN architectures. (See Colt, AT&T, Orange Partner on Orchestrated Services.)

The three carriers are on familiar terms with each other. Orange and AT&T announced last year that they were teaming up on open source and standardization initiatives, which included Orange’s trial of AT&T’s ECOMP platform, which was put into open source earlier this and combined with OPEN-O last month to create ONAP, in Poland. (See Seen & Heard: AT&T, Orange Team Up on Open Source & SDN, and Orange Targets vCPE in First ECOMP Trial.) Along the same lines, AT&T and Colt conducted an API interface trial last year. (See AT&T, Colt Connect on API Interface Trial.)

The partnership between Orange, Colt and AT&T leverages open APIs from the TM Forum and the Metro Ethernet’s Lifecycle Service Orchestration (LSO) framework to enable services across the carriers’ various SDN architectures despite the differences in the service providers’ networks.

In the first installment of this Q&A, Roman Pacewicz, marketing and global strategy senior vice president for AT&T Business Solutions, provides more details on how the partnership works. The interview was edited for clarity and length. (In Part II, Pacewicz outlines AT&T’s Indigo initiative.)

Telco Transformation: What was the goal in creating this partnership with Orange and Colt?

Roman Pacewicz: In the software-enabled world, where no one carrier has all of the infrastructure, how do you create an on-demand, dynamic network? And how do you create standards that allow, as an example, AT&T, to provision services over Colt’s infrastructure, over Orange’s infrastructure, and vice-versa? We believe the transformation of networks from kind of appliance-based, static model — you know, a lot of labor involved to configure — to a dynamic, on-demand, software-centric, cloud-based (model) is opening up a window of opportunity for us.

And this is really critical as networks move from hundreds of locations — physical buildings — to potentially hundreds of thousands of endpoints. Some are physical, some are logical, some are mobile, some are fixed. So just the whole ability to be able to control a network dynamically made a lot of us think about how would you do it? So over the summer we did a trial with Colt.

And in that trial we basically controlled their infrastructure. We looked for availability of Ethernet access into a on-net site of theirs. We issued commands SDN controller to SDN controller to qualify or provision the actual service. Then we were able to, through our ECOMP, go bring the bandwidth up and down the same way our customers that buy our services in the US are able to do.

That kind of proved this model that if you have two networks with vastly different architectures you can create, or you can leverage, the dynamic nature of an SDN-enabled network to deliver different kinds of services. Services our customers have been asking us about for a while.

TT: Can you provide us with more details on how it all works?

RP: This is all about driving standards-based APIs. Now of course, you know, we’re part of the ONAP open-architecture approach to orchestrating services. We view that as kind of the operating system for the network in a way. So that’s kind of how we’re doing it. It’s an API discussion, and how do we drive standards? Because you know, we connect with networks all over the world, hundreds of networks. Right now it’s very difficult to make those networks dynamic because you have different approaches. Now that networks are being re-engineered, we want to have an opportunity to drive some standards into the ecosystem.

We talk about eight different APIs, everything from qualification to billing to, you know, provisioning services, increasing bandwidth, decreasing bandwidth.

TT: The eight APIs, which will be available later this year, that were defined included; address validation, service availability, ordering, quoting, billing, assurance, testing and change management. The initial targets are the first three. Why those three to start with?

RP: First off, you have to instantiate the service. That’s kind of a pain point, to be able to automatically qualify that the site is available, that the site can be controlled remotely to an SD-WAN controller, because we need to have an intelligent edge. So being able to query their database and see if it’s available. Then issuing orders for the service and then provisioning the service is really important to set it up. But all eight are important.

Some of those endpoints are in another country where we don’t have our own fiber into those buildings. Our master orchestration engine, ECOMP, can actually command other networks to dynamically provision endpoints so the service to the customer is seamless. The customer who uses — for example, a portal to increase the bandwidth or reconfigure the network — would be able to do that even though that endpoint is not on our own network. And we would do the same thing for other carriers where we have fiber into buildings. So it just gives you that flexibility. But it’s all about creating an orchestrated level of service on an end-to-end basis regardless of the infrastructure. So this service is seamless. That’s the first step.

TT:: And by working with MEF and the TM Forum , you want to build a set of standards to make this easier for service providers and the industry as a whole?

RP: That’s what this announcement was about. It was about driving standards. By doing these trials, by putting together real examples of how this would work, we think we can accelerate it. What we need to do is make sure we define the APIs properly; more from a functional perspective. The complexity, whatever the implementation is in each network, is abstracted so the two controlling infrastructures — the two operating systems — can talk, and the translation occurs through the APIs.

This is the foundational building block of everything that we do so we’ve got to get that right before we can build beyond it.

See more on Telco Transformation.