Inter-carrier aspect of CaaS and NaaS pt. 1
Introduction
I'd like to take you through the inter-carrier aspect of CaaS (Carrier as a Service) and NaaS (Network as a Service), explaining the following key points:- What is the motivation for providers to interoperate - The Driving Force
- How do theoretical models and standard’s specifications developed by MEF and TMF address the problem? Are MEF and TMF conceptually aligned or misaligned? Is intercarrier API interoperability enough to marry those two or does differences reach much deeper? - The Enablement
- How does automated inter-carrier solutions work infield - The Life as We Know It
- What is the future of inter-carrier solutions? - The Weather Forecast
It may turn into a usual pattern to start my articles with an attempt to align vocabulary and definitions. I noticed that lack of it leads to confusion and blocks interesting discussions.
In my past job we were trying to promote the term inter-partner automation. The idea was to suggest a larger scale (not only carriers) of MEF LSO APIs adoption. To some extent it was marketing driven motivation. Here, I want to present an engineering point of view, supported by sufficient explanation of the business drivers behind. Therefore I will go with the term inter-carrier rather than anything else. It is a term commonly used in the industry and usually understood by most. By inter-carrier I mean all the bi-lateral interaction taking place between carriers, with a special focus on those leading to trading telecommunication services (Carrier Ethernet, N/W slices and other). Those may be subject to automation and provide requirements for domain modeling, APIs’ specifications, etc.
Once we have this basic vocabulary aligned I believe is the great moment to jump to the first topic from the list above, to understand the motivation and specifics of inter-carrier operations.
The driving force
What is the motivation for providers to interoperate?
In the globalized world we live in, end customers increasingly demand network services that span wide geographic areas, often extending beyond standard connectivity. Thanks to hyperscalers, customer expectations have evolved, and telcos are now required to provide their offerings quickly, seamlessly, and efficiently—mimicking the ease of cloud services. In fact, it's thanks to hyperscalers that we can discuss concepts like CaaS and NaaS!To illustrate the challenges in this context, consider the following example.
Example
Imagine you work for a car manufacturer (although there are many other relevant business examples, I'll stick with one that I found useful in my past work). You decide to establish a new factory in a cost-efficient location, let's say Kiev, Ukraine, while your headquarters are in the US. To connect this new site to your private network, you need private connectivity, like Carrier Ethernet E-Line (CE EPL), from the US to Ukraine. To achieve this, you approach your local Service Provider (SP), such as AT&T, for assistance. To meet your requirements, they must collaborate with suppliers to reach locations not covered by their network. This scenario aligns well with a question posed by Roman Pacewicz, SVP Business Solutions at AT&T:“In the software-enabled world, where no one carrier has all of the infrastructure, how do you create an on-demand, dynamic network?”
The answer to that question is simple: "Through engaging partners."
Returning to our example, the global network comprises interconnected autonomous networks, often referred to as Autonomous Systems (AS) operated by different providers. Each provider operates within its specific geographical area. These networks can be interconnected globally through protocols like BGP, providing the foundation for a global infrastructure. To illustrate this, I've included a simplified visualization below:
Services like previously mentioned Carrier Ethernet E-Line (CE EPL) use this underlying infrastructure for providing desired private connectivity (for more information on MEF CE standard please study MEF materials: https://www.mef.net/resources/mef-6-3-subscriber-ethernet-service-definitions/ and https://www.mef.net/resources/mef-51-1-operator-ethernet-service-definitions/)
At this point for the sake of the presented example it is enough to mention that CE services start and terminate at so called UNIs and may traverse through multiple provider networks that connect through so called ENNIs (this is enabled by those previously mentioned AS’ interconnections). In order to do it a respective virtual channels need to be established between mentioned points.
It looks something like:
(picture borrowed from publicly available MEF resources)
In the above picture there are only two carriers involved, but it is quite easy to extrapolate that to more than that. It happens when suppliers need to engage their suppliers. At the end of the day, using business terms, we may say that a supply chain got formed. In our example it could consist of the following:
AT&T(US) → Colt(GB) → T-Mobile(GER) → Orange(PL) → Kyivstar (UKR)
It is important to say that details of the “downstream” chain of suppliers is “invisible” to “upstream” partner. It is very important to decompose this statement and explain in detail. Using common language situation can be described in the following way: Customer/Enterprise asks Service Provider for an end-to-end (UNIUS-to-UNIUKR) service. This forms the first bi-lateral relation and the only one that the end customer is really interested in. AT&T finds a supplier - Colt - and asks for help with providing ENNIAT&T-Colt to UNIUKR. This forms the second bi-lateral relation (and a first in the inter-carrier space) within the end-to-end supply chain. Colt turns to T-Mobile, T-Mobile to Orange and this is how it goes until the last one is reached.
To wrap up the above example: in order to provide long range connectivity it may be required that carriers enter respective bi-lateral arrangements, within which the processes of service negotiation and ordering will take place.
(I really hope I was clear when describing the high level service topology and business relations needed to establish it. If by some reason I was not, please let me know so I can fix it.)
This is how the supply chain gets established. The golden grail is to make it happen seamlessly. And this is “The Driving Force” for inter-carrier automation, mentioned earlier.
I think it is very important to explain at this point, how such a process of business negotiation between carriers may work. Before I do it I have to explain one more thing. Within a bi-lateral relation explained earlier, there are very specific roles that parties involved enter: Buyer and Seller. Buyer, requests a particular service from a Seller. Seller provides what the buyer wants.
In the previously outlined supply chain example, AT&T is a seller to the end customer but a buyer to the own supplier (Colt). Independently on the role they play there is always a particular sequence of events that takes place between carriers. Here it goes:
It is crucial to clarify how the process of business negotiation between carriers operates at this point. But before diving into that, let's address one more important aspect. In the bilateral relationship we discussed earlier, there are specific roles that the parties involved assume: Buyer and Seller. The Buyer requests a particular service from the Seller, and the Seller provides what the Buyer needs. In the supply chain example we previously outlined, AT&T serves as a Seller to the end customer, but they also act as a Buyer when dealing with their own supplier, Colt. Regardless of the role they play, there is always a distinct sequence of events that unfolds between carriers. Here's how it works:
As you can see, these business negotiations follow a well-established pattern. I'll jump ahead a bit here, but I want to share that the above described process looks nearly identical whether executed manually or automated through APIs.
I believe it's a good point to conclude this section. I hope I've successfully described the 'Why' and 'How' of the inter-carrier market. If I fell short in any way, please let me know so I can make the necessary adjustments.
In the next segment (or segments), I will guide you through how MEF and TMF approach the challenge of inter-carrier automation. I'll delve into the underlying models, reference architectures, and APIs, providing insights into the open dialogue approach enabled by MEF's suite of APIs known as LSO Sonata and a catalog-based TMF approach.
At the end I will try to answer the question on MEF/TMF alignment, that goes much deeper than just simple API interoperability. I plan to transition from a business focus to a more technical one at this stage. It all will be covered in the article called “The Enablement” which I hope to publish very soon. So stay tuned!
Komentarze
Prześlij komentarz