Everyone knows that the industry has to move to fully automated problem detection and resolution. This capability is usually called “closed-loop” or “end-to-end” service orchestration and assurance. At GlobalData, however, we are increasingly seeing that there are more than just two “ends” in service orchestration. In fact, there are at least three main sets of concerns that service orchestration must address:
- Detection and remediation of problems that will affect service availability and experience
- Full lifecycle management (LCM) of services and/or network slices
- Management of not only the performance but also the cost and even greenness of underlying network resources
Service orchestration, therefore, is far more than fulfilment and assurance. It is increasingly part of the operating system of a CSP’s business.
Service creation is the essential beginning of the life cycle
To date, most of the attention in service/slice lifecycle management has focused on the operational component – monitoring Key Performance Indicators (KPIs) and fixing any issues, ideally, before they hurt the service experience. But service orchestration should also make it easier to create services, not just in the technical sense of instantiation, but in the business agility sense of quick development.
To monetize their ability to tailor network performance to a particular application’s needs, CSPs need to introduce many more services than they did before, and much more quickly. A modern service orchestration product should make this easier, ideally through both business-friendly service design and a library of service components or packaged use cases. Whether the service design is based on dropdown menus or drag-and-drop is less important than how well it enables non-engineers to participate in service design and how much it speeds up that process. Useful elements are configuration over customization, reusable components, templates, standard interfaces, and an ecosystem of service partners.
A service/use case library can further aid service agility by providing templates and examples for various services that have worked in similar contexts in other markets. This is especially useful in creating the myriad enterprise vertical-specific use cases that will be necessary to fully monetize the new cloud-native networks.
Service assurance is the traditional heart of orchestration
To date, discussions of 5G service orchestration have largely been about service assurance: Once the service has been designed and instantiated, the service orchestration platform must monitor it to ensure that it is meeting its KPIs. If not, the assurance function works with the resource orchestrators to move performance back into the target range.
What makes this process more complicated than it used to be is the fact that the KPIs are now often based on service experience and business intent rather than on strictly technical measures that do not correlate to how well the service functions for its users. This is needed to solve the older “All the indicators are green, but my users are unhappy” phenomenon. Modelling and monitoring experience and intent, of course, is more difficult than setting thresholds on probe outputs.
These changes derive from vastly improved network capabilities, but they are harder to ensure: An orchestration platform must therefore come equipped with sophisticated analytics to identify anomalies and perform root cause analysis.
Dynamic resource allocation is both a technical and business problem
For 5G service providers, the problem is even harder since each service is underpinned by at least one network slice. When the assurance function identifies a problem with a service, it must often fix it by allocating additional or even different resources to that service. Each of those resources has performance characteristics that are more or less suitable for that service, but also more or less expensive. The resource allocation function must take all such factors into account.
Take one of the most serious problems to befall a slice or service: One of the supporting resources goes down, requiring a replacement with a different resource. The orchestrator must identify and allocate a resource with sufficient performance to support the service’s SLA. As network slices multiply and are priced more granularly, the orchestrator will also have to select resources according to business intent: Not only the next best-performing resource but also the next best resource within a price range that best preserves the profitability of the service. This functionality will increasingly involve not only essential domains like the RAN but also third-party domains like interconnect or hyperscaler resources. There are also signs that this functionality will also extend to passive infrastructure in the future: An orchestration system might have to select the cheapest or greenest electricity source, for example.
Final thoughts
GlobalData recommends that any CSP that is looking at building a new service orchestration platform look at it as more than “assurance plus.” All parts of the service lifecycle, from design through operations to resource allocation, might be performed by a single, un-siloed platform. 5G network slicing makes the resource allocation function especially important for mobile service providers’ service functionality and profitability.
Ericsson’s service orchestration is designed to address these concerns. The underlying Ericsson Service Orchestration and Assurance product provides full lifecycle management for services in a multivendor environment, including a service creation platform with a library of service components and pre-packaged use cases. The solution built on top of this product, Ericsson Dynamic Network Slicing, combines those features with pre-integrated software assets specific to network slicing. It works with the company’s 5G core to orchestrate slices with tight integration into its RAN and is open to connect with alternative RAN and core as required. End-to-end network slicing demands that the IT and network work in tandem to ensure that data flows and workflows happen as and when needed to stand network slices up (and down) dynamically and assure the performance of each slice. Ericsson’s OSS/BSS Services support this network slicing journey, from inception to integration and managing platform operations to realize and operationalize network slicing at scale. Streamlining the delivery of network slicing implementation, Ericsson’s end-to-end approach with the customer-centric product at its foundation is designed to drive business outcomes and fuel innovation.
This article originally appeared on Ericsson.com
