Our Multi-X Intelligent Automation Reference Solution, MX-AI, the intelligence complement of MX-PDK, is an open innovation platform, intended for accelerating development, and deployment of network GenAI applications. MX-AI enables an Agentic approach to network operations, and optimization by integrating Large Language Models (LLMs) and optimized data pipelines at its core.

Let’s have a functional view of how MX-AI delivers RAN configurations to achieve power management objectives of the network operator.

The user asks to MX-AI the following query:

To achieve our RAN power management objectives, we need to improve the power consumption of tracking area XYZ by better than 10%. The power measure of interest is the average total consumed power by the RAN node over a 24-hour period of week-day traffic load. Produce a power management strategy recommendation with the best power budget reward.

The query is sent to the MX-AI Orchestrator which uses the A2A protocol to find the following specialized agents to handle the request:

1. SMO Agent: This agent is responsible for managing the network blueprints and configurations.
2. xApp/rApp Agent: This agent is responsible for deploying and managing the xApps/rApps in the network.
3. Kubernetes Agent: This agent is responsible for managing the Kubernetes cluster and its resources.

These are only those agents which are evaluated as useful for the task by the MX-AI Orchestrator, but there will be more agents available. An important one is the Digital Twin Agent, responsible for deploying and managing the lifecycle of a Network Digital Twin. We will see how this Agent will play a fundamental role later.

The Orchestrator reformulates the query into three targeted versions, each tailored for a specialized agent:

• Q1: Targeting >10% power reduction in tracking area XYZ (weekday 24h avg). Consider adjusting the bandwidth during low traffic periods or modifying ARFCN assignments to consolidate carriers.
• Q2: Seeking >10% power saving in tracking area XYZ over 24h weekday periods. Identify xApps/rApps for intelligent RAN energy management (e.g., traffic-aware activation, AI-based load prediction). Recommend apps with highest power-saving potential and deploy them after user’s acknowledgement.
• Q3: We aim to reduce RAN node power consumption in tracking area XYZ by >10% (24h avg on weekdays). Evaluate options such as dynamic CPU/memory scaling, node hibernation, or pod affinity/anti-affinity rules to optimize workload placement and reduce energy use. Recommend changes with significant power savings potential.

The Orchestrator sends each of these to the respective agent, and the agents respond with the following recommendations:

• R1: SMO Agent recommendation: Reducing channel bandwidth during low-demand hours can significantly lower power usage. Adjusting ARFCN to consolidate active carriers further enhances efficiency.
• R2: xApp/rApp Agent recommendation: Deploying an AI-based rApp for traffic prediction and adaptive cell activation can optimize RAN energy use dynamically. A sleep-mode orchestration xApp can further reduce power by deactivating underutilized cells.
• R3: Kubernetes Agent recommendation: I recommend implementing dynamic resource scaling and node autoscaling based on real-time traffic load in tracking area XYZ. Additionally, deploying energy-aware scheduling policies can consolidate workloads onto fewer nodes during off-peak hours.

The Orchestrator decides to discard the solution from the Kubernetes Agent because infra-level optimizations usually yield marginal returns in RAN-specific power consumption compared to domain-aware RAN configurations and AI-driven control.

To evaluate the other two solutions, the Orchestrator:

• Instruct the Digital Twin Agent to create two Network Digital Twin instances.
• Instruct the SMO Agent to apply the modified RAN configurations (bandwidth, ARFCN, TDD) to the first twin.
• Instruct the xApp/rApp Agent to deploy the AI-based power optimization rApp to the second twin.
• Instruct the Digital Twin Agent to compare both twins, identifying the one with at least 20% power reduction while maintaining service KPIs. Assume the rApp performs better.
• Instruct the Digital Twin Agent to delete both test environments.
• Ask the User whether to proceed with production deployment.
• If approved, instruct the xApp/rApp Agent to deploy the rApp in the production environment.

The whole process may require a few seconds to minutes to run, depending on the complexity of the network and the delay introduced by the agents. However, everything is potentially done with zero human intervention apart from the initial query and the final deployment confirmation, which are needed to ensure that the user is aware of the changes being made to the network but still optional. The Orchestrator can also provide a report to the user with the details of the changes made, the expected power savings, and any potential impact on performance.

Tools used to construct this multi-agent system:

• Python with LangChain and LangGraph libraries: used to build and orchestrate multi-agent workflows with LLM-powered agents.
• A2A protocol: facilitates inter-agent communication and coordination using standardized messaging.
• At least one LLM instance (either through APIs or on-prem, depending on the available hardware): powers the agents’ reasoning and decision-making capabilities.
• Docker: Ensures isolated, reproducible, and scalable deployment of individual agents.
• An SMO, rApp/xApp catalog and Digital Twin framework (provided by BubbleRAN in MX-AI and/or MX-PDK). Supplying network management functions, real-time simulation, and integration tools for RAN automation and orchestration. Allows to test the agentic solution in real use-cases.