Modern business depends on fast connectivity for time to market, quality customer experience delivery and competitive advantage.
Whether you’re a consumer or manage a quick service restaurant, a bank or a large hospital, you expect reliable connectivity and low latency when you interact with business applications. That is directly tied to the quality and reliability of a telecommunications (telco) service provider’s capabilities.
Providing consistent, high quality connectivity for customers in diverse locations has long been a telco business challenge―there are areas where it is not economically or even physically feasible to provide the last mile of network that brings a signal to the customer’s facility; tall buildings and sometimes bad weather can disrupt signal propagation; and network congestion in densely populated areas is common.
Some telcos turn to satellite communications (SATCOM) to help fill the service gap. In recent years, the proliferation of low Earth orbit (LEO) SATCOM is proving to be particularly helpful, providing additional low latency bandwidth to anywhere coverage is needed worldwide and greatly improving network performance.
Still, ready integration between SATCOM and terrestrial networks is not always guaranteed. The current LEO inflection point illustrates why it is now crucial for every service provider to embrace two separate but complementary standards that enable ready interoperability.
Established almost 25 years ago, the Mplify (formerly Metro Ethernet Forum) MEF 3.0 Carrier Ethernet standard is already widely used by telcos and cloud services providers for interconnection of their terrestrial networks and for lifecycle service orchestration. LEO satellite constellations that are certified as MEF 3.0 Carrier Ethernet networks can seamlessly integrate low latency backhaul connectivity with terrestrial networks – at a lower cost than deploying fibre to remote locations. Plus, it seamlessly integrates into a carrier’s Business Support Systems (BSS).
The more recent TM Forum Open Digital Architecture (ODA) standard aims to support universal plug-and-play services with a blueprint to build flexible, cloud-based telecom and enterprise IT systems that allow users “to simplify enterprise architecture designs, modernize software build for a plug-and-play ecosystem and automate IT and network operations.”
The goal is to replace monolithic Operations Support Systems (OSS) managing the telco’s network infrastructure and BSS’s handling customer-facing activities like billing and order management with a flexible, component-based cloud-native architecture for digital platforms and services using the ODA framework.
The TM Forum has had great success over the last 10 years around the adoption of open standard application programming interfaces (APIs) within the telecoms industry. The ODA incorporates those APIs and a lot more.
Those APIs are essential for B2B companies like SATCOM providers or telcos, where exemplary customer service is enabled by integrated back-office BSS with OSS running underneath them. These systems are integral to all aspects of the customer experience, from taking orders from consumers, businesses or even other service providers to billing and opening service tickets if something goes wrong.
Think about the case of a remotely located business ordering services from a telecom service provider that does not have fibre or Carrier Ethernet in that location. The provider will need to collaborate with a local carrier or satellite operator to provide last-mile connectivity to the customer’s specific location. MEF 3.0 provides the APIs that allow the two companies’ BSS and OSS to interface with each other in a way that is invisible to that end customer.
ODA standards work alongside the MEF APIs by packaging that order information into a uniform format so that it flows much more easily, with no translation needed inside a company’s business or operational support systems. Without ODA, the structure of the orders might differ in every single company’s database.
While this may sound like a very technical and perhaps esoteric process, it really equates to faster and more efficient business processes. For instance, it could take a company up to a year to develop interfaces to modify a third-party solution across multiple internal systems within a large corporation. That means a year of missed revenue. Without ODA, all of the involved back office work is bespoke. But with ODA, consistency in the interfaces eliminates the tedious, time consuming integration work, so go to market and revenue generation happen faster. This is particularly helpful in the telecommunications industry, where massive companies have operated hundreds of stitched-together systems for decades.
Still, it’s a huge (and unrealistic) step to say, “Stop the train, throw all that out, and spend whatever it takes for the digital transformation needed to go to a full ODA compliance stack.”
Telecom companies should instead take small steps to ODA adoption and integrate it over time. As they bring LEO SATCOM into their network environments, it will help to leverage satellite operators that already follow a telco standards-based approach for Carrier Ethernet services, and that have adopted ODA.
After all, telcos’ adoption of APIs took some time to mature, yet APIs are now deeply embedded into their business processes and have become a way of life. We can expect the same evolutionary path for ODA.
Companies should not view adopting these standards as a purely technical issue, but as one critical to the success of their businesses. Those that truly conform to the MEF and ODA standards of interoperability will be able to improve existing service, go to market with new and better services faster, earn and retain happier customers and have a leg up over their competitors.
Learn more about seamless terrestrial and non-terrestrial integration in this free guide.
