The Core is where network autonomy becomes experience

Фото: Conny Schneider (Unsplash) — https://unsplash.com/photos/a-blue-background-with-lines-and-dots-xuTJZ7uD7PI?utm_source=dev48&utm_medium=referral

Source: ericsson.com•

The Core is where network autonomy becomes experience

Most Core operations still run reactively. Issues are addressed piecemeal as they surface and capacity is sized on assumptions, which also limits how quickly differentiated services can be launched and assured.Extending a common automation foundation into the Core lets teams see conditions…

In the first part of this series, we looked at why autonomous networks need a common foundation. The second explored how applications turn that foundation into action in the RAN. The same journey is now reaching the Core, where network intelligence shapes service experience, resilience and business agility directly.

From my work with operators across the Americas, I apply a simple test for differentiation: can the end user actually experience it, and can the operator deliver it at scale with control, predictability and viable economics? A premium or assured service that stops at a commercial promise or a one-time configuration fails that test. It has to be introduced quickly, observed continuously and adapted as conditions change with reduced demands on the operations teams.

Why the Core, and why now

That is demanding in an environment where network functions, cloud infrastructure, management systems, orchestration tools and operational teams all contribute to the outcome, like links in a chain. Automation on its own does not remove the complexity. If every new use case creates another isolated data path or control loop, the burden moves rather than reduces. The shift that matters is from intelligent links to a coordinated end-to-end experience and separation of concerns.

Four pressures are converging on the Core at the same time: resilience and security, consistent performance, premium experience, and growth beyond basic connectivity.

What changes when the common foundation reaches the Core

Ericsson Intelligent Automation Platform, EIAP, now extends the common automation foundation from the RAN into the Core. Core-specific automation applications, cApps, use network data and intelligence to identify conditions, recommend responses and, where appropriate, trigger controlled action. The purpose is to connect data, decisions and action, so operators can move from understanding what happened to anticipating what is changing, and then verify whether the response delivered the intended result.

cApps are built for non-real-time Core use cases and cluster into two areas: network use cases that improve resilience and performance and protect the network, and service use cases that protect and lift the customer experience. Like rApps in the RAN, they follow an open model, developed by Ericsson, by operators and by third parties. They also use the same development environment as rApps, so the tooling, skills and applications an ecosystem has already invested in carry forward into the new domain.

Not all intelligence belongs in the same place. Strict real-time decisions need to sit close to the network functions. Broader, non-real-time analysis and coordination are better centralized through cApps. A common platform connects both layers, so each decision is taken where it can be made well.

One foundation across RAN and Core also opens the door to use cases that require information or action across domains: correlating a service issue, coordinating a capacity decision, applying business intent end to end. That is potential the shared foundation creates, and it grows as more of the network runs on it.

What this looks like in practice

The journey is already becoming tangible through emerging capabilities such as network-function anomaly detection and Core root-cause explanation. Both are concrete steps toward a more preventive and resilient operating model.

Looking forward, three directions show the broader potential:

  • Assuring a differentiated experience across its lifecycle, from launch through every change in conditions that follows.
  • Predicting capacity pressure before it reaches a service.
  • Progressing from issue detection toward preventive healing.

The end user sees the outcome rather than the architecture: a service that arrives faster, performs more consistently and is less likely to be disrupted. For the operator, the same foundation reduces repeated integration, helps teams act with better context and creates a more practical path to introducing differentiated connectivity and reduce the burden and complexity of operations.

Where to start

There is no need to replace what you run today. Existing automation can be re-implemented as cApps over time, which reduces technical debt while preserving the operational intent already built into it.

My view is that the most practical starting point is one clear outcome: an experience to assure, a capacity risk to anticipate, or a resilience problem to prevent. Build confidence from the data, connect the insight to controlled action, verify the result, then expand. A realistic sequence follows the same logic. Observability first, then one resilience or capacity use case, then predictive intelligence, then closed loops and intent-driven operations.

Discover how intelligent Core automation and cApps advance the journey to a more autonomous Core.

  • Advanced core network autonomy with cApps and Ericsson Intelligent Automation Platform
  • Ericsson Intelligent Core
  • One automation platform. Expanding from RAN to core

What this article says