Login
Register
Member Insights
BMC’s Sara Coppo explains why digital services fail at the interfaces between domains, vendors, tools and teams, and why autonomy will not arrive as a single black box but as governed collaboration across an ecosystem.
Sara Coppo
Why assurance needs open ‘data + domain’ federation and what packet core teaches the wider network
Modern networks generate more signals and more dependencies. A single service-impacting problem often requires telemetry, topology/inventory, configuration, traffic behavior, and service context from different systems – often from different suppliers. Teams still spend large amounts of time manually assembling that context, repeating work across shifts and suppliers, and making decisions when the picture is incomplete.
This shows up clearly in packet core, but the same pattern appears wherever failures propagate across domains.
Packet core failures can affect service quality quickly. That makes it a strong place to validate an approach under real operational constraints. In TM Forum’s Multi-agent intelligence for packet core operations Catalyst championed by Jio, Telia, Telus and Vodafone Three and demonstrated recently at DTW Ignite, packet core is the anchor domain. However, the aim is a repeatable workflow, not a one-off proof.
The workflow to prove is concrete: Group signals into a situation, add domain-specific explanation, reason about cause and impact, recommend or execute next steps under policy, and record outcomes for the next event.
In real networks, “What broke?” and “Who is affected?” usually need the same inputs: dependencies across domains, time-aligned signals and service/topology context. If operators do not build that picture once and reuse it, they tend to rebuild it twice – once for root-cause discussions and again for impact and prioritisation.
When operators talk about progressing toward higher autonomous network maturity, the practical meaning is often the same idea expressed two ways: shorten the path from detection to a defensible decision and keep that path repeatable as services, vendors and domains multiply. That is hard to do if “cause work” and “impact work” live in different tools, teams and partial graphs.
Unified assurance is a useful mental model here as one operational thread that can carry enough cross-domain context for triage, correlation and decision support.
Cross-domain health and probable cause capture the same intent: operators need health (including customer- and service-visible symptoms) and probable cause (what best explains the situation) to be assessed in a way that respects boundaries between domains and recognizes that what happens in one domain may correlate with events in other domains.
Most CSP networks use more than one vendor. A single-vendor AIOps product can work well for data that stays inside that vendor’s scope. It is weaker when the incident cuts across boundaries.
A workable pattern is:
The Catalyst program matches this split: Deep packet-core knowledge stays where it belongs, while the program still needs a coherent operational picture built from multiple inputs.
In practice, agentic assistance should be described in operational terms that can be verified during incidents and post-incident reviews.
If the industry wants autonomy to scale beyond pilots, interoperability cannot remain bespoke glue forever. A practical industry trajectory is:
That trajectory is bigger than any single Catalyst, but a Catalyst is a good place to pressure-test the assumptions with real workflows and real constraints.
If the goal is faster and safer restoration in real CSP environments, the practical question is whether investment goes mainly into more isolated domain tools, or into an open composition layer that works across vendors and preserves domain-owned technical truth.
Packet core is a good place to prove the workflow. The next step is to reuse the same pattern across additional domains without losing governance.
