Closed-Loop Automation

The foundational reference model for autonomic computing and closed-loop automation. It decomposes the control cycle into five distinct phases:

• Monitor: Collect and aggregate real-time telemetry from sensors, logs, and metrics endpoints.
• Analyze: Process data against models to detect anomalies, predict degradation, or identify optimization opportunities.
• Plan: Determine the optimal corrective action from a set of permissible changes.
• Execute: Apply the planned configuration change via an actuator or API call.
• Knowledge: A shared repository of policies, historical state, and topology that informs all other phases. This model ensures a structured, auditable path from observation to action.

The Monitor phase relies on a shift from legacy polling to high-frequency, push-based streaming telemetry. Protocols like gRPC with Protocol Buffers enable network devices to continuously stream granular operational state—interface counters, buffer depths, CPU load—to a centralized collector. This provides the high-resolution, real-time data foundation necessary for the Analyze phase to detect micro-bursts and transient anomalies that interval-based SNMP polling would miss. Without this, the loop is blind.

Closed-loop automation does not operate on explicit step-by-step commands. Instead, it is driven by a declarative intent—a formal specification of the desired operational outcome. For example, an intent might declare 'all video traffic must have latency under 10ms' rather than specifying individual queue depths. The Analyze and Plan phases continuously compare the observed state against this declared intent. Any deviation, known as drift, triggers the Execute phase to remediate and restore the intended state.

A core function of the Execute phase is drift remediation—the automatic correction of unauthorized or unintended configuration changes. A reconciliation loop constantly compares the live state of a resource against its definition in the single source of truth (e.g., a Git repository in a GitOps workflow). If a manual change is made directly on a device, the loop detects the variance and automatically reverts it, enforcing immutable infrastructure principles and guaranteeing that the production environment always matches the declared, compliant state.

In complex systems like the O-RAN architecture, closed-loop automation operates at multiple time scales through a hierarchy of controllers:

• Near-Real-Time RIC (Near-RT RIC): Hosts xApps that execute control loops with latency between 10ms and 1 second for per-UE radio resource management.
• Non-Real-Time RIC (Non-RT RIC): Hosts rApps that execute loops greater than 1 second for policy guidance, ML model training, and network-wide optimization. This tiered approach ensures that fast, local decisions don't conflict with slower, global optimization goals.

Before a corrective action is applied to a live production network, the Plan phase can leverage a Network Digital Twin—a high-fidelity, real-time virtual replica. Proposed configuration changes are first validated in this simulated environment to predict their impact and verify they will achieve the desired intent without causing cascading failures. This 'what-if' analysis is critical for building operator trust and enabling fully autonomous execution in high-stakes environments.