Not long ago, operating a telecommunications network was a static, slow-changing process. Networks were built using physical functions, configured to provide a stable set of services and, once rolled out, to operate for many years without significant changes. This also reflected upon the operations and business support systems, the OSS/BSS, which would unavoidably acquire legacy status after several years in operation. Today, changes that were previously done manually via CLI are now fully automated and replicated at scale for increasingly faster deployment times, better SLAs, and an enhanced customer experience. Any legacy OSS/BSS will most likely not have the flexibility and the automation capabilities to support it, therefore digital transformation initiatives are actively targeting this crucial set of systems that need to be brought up to speed with the new trends.
'Any legacy OSS/BSS will most likely not have the flexibility and the automation capabilities to support digital transformation, therefore initiatives are actively targeting this crucial set of systems.' -WaylayClick To TweetOSS/BSS
The complexity that inherently accompanies the new approach reflects upon all layers, from infrastructure to the OSS/BSS. There is, however, a catch. Changing the OSS/BSS layer is often a multi-million dollar project that spans over several years, touches on all active parts of the network, and usually begins with the migration of all legacy inventories to the new system before a single new service can be rolled out. It creates a dependency on specific vendors and is not something most CSPs or MNOs are looking forward to.
So, is there an equally reliable, less intrusive, and more pragmatic alternative? Everything is ultimately possible in software, and I believe there is a way, loosely inspired by two concepts borrowed from the field of software architecture: the service mesh and the sidecar.
Introducing a Companion Automation Layer
Enter the brown-field scenario of a CSP that has made a huge investment over the years and manages a heterogeneous, multi-vendor OSS/BSS ecosystem. The challenge of new product introduction is to avoid the bespoke development and integration effort associated with adapting each of the OSS/BSS components and with adding the glue logic that allows them to support the new use cases end-to-end.
What if, instead of touching upon all these systems or replacing them with a new one, we keep their existing functionality and federated inventories? We can do this by introducing a companion automation layer to the existing OSS/BSS stack, effectively creating a mesh between these systems and enabling them to participate in fully automated end-to-end transactions and accelerating digital transformation.
How will the Automation Layer Work?
This approach would bring all the digital transformation benefits to CSPs and allow them to start innovating immediately, without first going through an expensive OSS/BSS replacement exercise. Here is how.
- It bypasses the inventory migration conundrum, keeping the sources of truth with the systems that own them and consuming data directly from the source.
- An automation layer can centralize the automation flows for all the domains covered by the CSP’s network into a reusable, easy-to-extend catalog that spans from SDN and data center automation to 5G slicing and eSIM connectivity.
- It can easily bring in new and existing systems into the mesh by exposing their APIs and data to the automation layer, continuously expanding the automation scope towards new use cases. The automation layer acts as a sidecar to all these systems, enabling them to participate in automation scenarios even if they were not initially designed for it. Arguably, this is better than the initiative taken by many CSPs to expose all OSS/BSS APIs under a unified API gateway, which consolidates access but still lacks any automation capabilities.
- Coupled with concepts like low-code and no-code, an automation layer enables the CSP’s subject matter experts to define new services as end-to-end automation templates that seamlessly consume the APIs published by the different OSS/BSS components and apply NetOps principles to them.
- It provides a central point for operationalizing the AI/ML models used in assurance scenarios across all domains, enabling advanced assurance and closed-loop automation even across legacy systems.
- And last, it allows the CSP to expose the automation layer to their own MVNO customers in a controlled way, providing them with the means to customize the standard offerings or define new services on top of it.
CSPs and the Digital Transformation Journey
While introducing the new layer and new products, existing systems and services are kept running, allowing the CSP to determine exactly if, when, and how they will be migrated, with zero risk of downtime. Similarly, it is sufficient to expose the APIs of newly introduced components to the automation layer to have them included in the automation spectrum.
Tweet
Share
Share
- Artificial Intelligence
- Automation
- Digital Transformation
- Machine Learning
- Telecommunications
- Artificial Intelligence
- Automation
- Digital Transformation
- Machine Learning
- Telecommunications