Automated Assurance for Managing 5G SA Complexities
Learn why Automated Assurance is key to cross-domain monitoring of 5G SA services and how it aligns with TMF ‘s Autonomous Networks Model.
5G SA monitoring and network assurance is essential, but presents new challenges that change deployment and operational models. Learn more in this article
Cloudification
– Monitoring in a Containerized World
Let’s look at a couple of examples, to give you a flavor of the insights you will gain from Jonas in the webinar:
First, cloudification. We’re all used to the physical approach to network monitoring, in which passive taps were inserted into control and user plane links, allowing the requisite data to be siphoned from the network and presented to processing engines that could filter and parse the data.
With the passive tap approach, it didn’t really matter what the source was - signaling flows, user plan data, whatever - you just needed the ability to decode and interpret the captured data, so you could then track KPIs, follow service sessions and so on. The fundamental element, from the perspective of the mobile network, was the IMSI, so that all the data could be correlated to an individual user (or, with the IMEI, the specific device). With that, service assurance could be scaled down to events that impact a single session, or up to cover the entirety of the customer base.
The IMSI remains fundamental, of course, and it’s still there – in the case of 5G, as the SUPI. But the challenge is now to extract this from the cloud. That’s because 5G SA builds on the virtualization trajectory we have been following in recent years to realize a fully cloudified, software-based network architecture. Here, the entities of the new mobile core as containerized micro services that are not physically interconnected, but which communicate and exchange information in a cloud environment.
Changing Deployment Models
As such, you can’t simply tap into entities in the 5G SA core as you might, say, between components of the IMS, or a physically deployed PCRF solution. Instead, you need a radically new approach – inserting new processes into the heart of this cloud environment to extract the relevant signaling – and to uncover those crucial IMSIs.
And that’s not all. Much of the necessary information is encrypted — ciphered — so, before you can find that to which the session or service information relates, you need to decode it. To get round this, solution vendors provide an output to authorized software monitoring processes, allowing access to the requisite data.
5G SA Monitoring Must Be Adapted for Different Formats
But, guess what? Different vendors have chosen different formats for this necessary output, which means software-based monitoring for 5G SA must be adapted for different formats to obtain the same key information. Creating a framework that allows you to securely and accurately monitor all of the relevant information flows is, then, somewhat more of a challenge than we’ve been used to.
It requires, not just support for the specific interfaces in question, but a completely different deployment model, in which monitoring processes live alongside the active components from which they capture information. It’s almost invasive, with passive, non-disruptive monitoring co-existing with the processes that deliver services to subscribers.
But What About Slicing in 5G SA?
Does that complicate matters?
That’s one thing – but there’s much more to consider. For example, one of the great promises of 5G SA networks is network slicing. This is supposed to usher in a new era of agile, dynamic high-performance and low-latency services, supporting offers targeted to the needs of a wide range of verticals, industries and new business partners. It’s key to monetizing your investments.
However, as Jonas notes, slicing is, ephemeral. Put simply, this means that slices may be instantiated for a short period, they may change during that period and then they may be retired. Sure, some will be long-lasting, but many others will be of fixed duration, and applied to a specific location.
Once upon a time, to deliver dedicated QoS-assured connectivity, you would need to secure the relevant hardware, deploy it, connect it and so on. With slices, you’ll simply reserve computing resources (that have already been physically deployed) and provision the desired service. All of this must happen dynamically, with real-time activation being the target.
So, since the slice must deliver specified performance, we also need to ensure that our service assurance framework can deliver – which means that the relevant containers and micro-services that perform the monitoring to capture the data we need in order to know whether it is actually delivering the desired capabilities, must also be instantiated at the same time.
This also makes monitoring the User Plane even more important, so that we can prove that the slice obtains the QoS that the buyer expects.
Get Ready for An Entirely New Approach to Monitoring
In other words, slice composition and orchestration also require simultaneous composition and orchestration of the parallel service assurance framework – and the removal of this when the slice is no longer required.
Service assurance in 5G SA moves from being a purely passive framework to one that lives and breathes along with the dynamic nature of the SA core. And, you have to manage all of this alongside your other networks – because a service might span legacy elements and entities as well as the new.
Does that sound like a challenge? Well, let Jonas guide you through this jungle and show how you can extend service assurance to 5G SA and secure the insights you need to assure all those new, high-value services, with the scale and dynamic capabilities you’ll need.
