/
POC: AI PDP Design in Policy Framework

POC: AI PDP Design in Policy Framework

This page outlines the high level initial ideas on implementing a PDP in Policy Framework with AI capabilities. The new PDP will be implemented as a spring boot microservice with an AI module for the business logic implementation. The pdp will be managed by PAP in the Policy Framework.

Various implementation options are briefly discussed in the upcoming sections for the further analysis.

1. Predictive PDP

This PDP might use ML models to predict the future state of the network based on the learned patterns from historical data.

This can use a trained ML model and make predictions. Training data required to be supplied to learn the patterns based on the use case.

Sample input:

{ "cpuUsage": [0.6, 0.65, 0.7], "memoryUsage": [0.5, 0.55, 0.6], "networkTraffic": [80, 90, 95] }

Possible output based on the learned models:

{ "prediction": "OVERLOAD_RISK", "probability": 0.87, "recommendedAction": "Scale up VNFs or reroute traffic" }

 

Maven artifacts for ML libraries: Smile ML, Weka

Suitability: May be good for Fault management, autoscaling etc..

Cons: Needs trained ML models. More input models for better prediction. Risk of misprediction.

 

2. Anomaly Detection PDP

This is similar to Predictive pdp but uses an unsupervised ML algorithm instead of trained models. Only the normal data input is provided and no thresholds are defined. The anomaly detection is based on the Ai algorithm configured. This can act as an alert system that flags unusual network activities.

This can be a continuous monitoring component which receives continuous input feeds from NFs. If an anomaly is predicted, this can be used to raise an alarm, auto-scaling, healing etc..

Sample input data:

{ "cpuUsage": [0.3, 0.62, 0.71], "memoryUsage": [0.45, 0.46, 0.44], "packetLoss": [0.01, 0.02, 0.05] }

Possible action:

{ "anomalyDetected": true, "reason": "CPU usage spike and packet loss > threshold", "recommendedAction": "Trigger remediation workflow via Apex PDP" }

Maven artifacts for ML libraries: Smile ML, Weka

Suitability: Can be used for alert management and can be combined with other pdps for alert-response.

This requires only normal data and the configured algorithm can detect the abnormality automatically.

Cons: Needs normal models for learning.

 

3. Optimization PDP

This can use reinforcement learning (RL) / optimization algorithms to select best action among many valid options.

Reinforced Learning is different from supervised learning. Instead of making decisions based on the trained models, the agent learns by interacting with an environment. We define the following in the business logic and the Ai takes the decision.

constraints (rules that must never be violated)

Example:

  • CPU utilization ≤ 80%

objective (define what best means among feasible actions)

Example:

  • Minimize total cost

  • Maximize throughput

  • Minimize latency

Current state/ input data:

Example:

Metrics from NFs, SDN, or monitoring system.

 

How the PDP works :

Takes an action → gets a reward/Penalty based on the consequence → Updates policy.

Can be used to make decisions on use cases like optimal configuration or action, resource allocation, etc.. Learns and improves decisions over time.

Sample input:

{ "cpuUsage": 0.85, "latency": 75, "traffic": 1500 }

Optimization logic is deciding

  • Action A: Scale out NF

  • Action B: Do nothing

PDP Decision:

Scale out NF by +1 instance.

After Action(from monitioring)

{ "cpuUsage": 0.55, "latency": 45, "traffic": 1500 }

Reward Function:

Reward = (latency improvement + cpu improvement) → +15. If PDP had choseen "Do Nothing" CPU might stay at 0.85, latency at 75. Reward = -5 (penalty).

Maven artifacts for RL library: OptaPlanner from Red Hat

Suitability: can be used for various usecases.

Cons: Might be non deterministic as it learns based on the consequence.

 

What could be the Tosca policy definition for AI PDPs:

The tosca policy definition might include the following instead of the hardcoded logic.

  • Use this PDP type (Predictive/Anomaly/Optimization).

  • Use this trained AI model (location, version or module name).

  • Use these input data sources (metrics, telemetry).

  • Define the expected output contract (prediction, decision, anomaly score).

policies: - predictive_scale_policy: type: onap.policies.optimization.Predictive properties: modelRef: "models/cpu_predictor_v1.pkl" dataSource: "dcae:vm_metrics" outputFormat: "prediction,confidence,recommendedAction"

 

Thoughts on the pros and cons of AI based PDPs:

Having a PDP with AI capabilities can be used for purposes like alarms, notifications, network predictions in advance etc..

Making decisions/action points on the network from the AI module may cause high unpredictability and inconsistent behavior.

Training the AI models may be more challenging.

Right use case should be determined where the AI capability in the PDP adds a real value.

 

Apex-PDP AI extension

Training a custom AI model from scratch is complex and carries no guarantee of success. Instead, the idea is to provide the necessary AI support to empower users to build their own agents using open-source models.

Enhancing ONAP Apex-PDP: Bridging Traditional Automation with Generative AI

The evolution of network automation requires moving beyond static, rule-based systems toward "intent-driven" architectures capable of reasoning. By extending the ONAP Apex-PDP (Policy Decision Point) to include an AI-enabled engine via Spring AI, we provide a sophisticated bridge between legacy operational stability and the transformative power of Large Language Models (LLMs).

Why Extend Apex-PDP?

Apex-PDP has long been the powerhouse of ONAP’s closed-loop automation, renowned for its low-latency execution and high-performance policy enforcement. Integrating an AI engine directly into this framework is a strategic choice for three primary reasons:

  1. Orchestration Context: Apex-PDP is already at the center of the ONAP ecosystem, receiving real-time telemetry from DCAE and commanding orchestrators like SO. By adding AI capabilities here, we ensure that AI decisions are immediately actionable within the network fabric.

  2. Deterministic Enforcement: While AI models (like those run via Ollama) provide "reasoning," they can be unpredictable. By keeping Apex-PDP as the host for this AI integration, we maintain the "Guard Policy" framework. This ensures that even if an AI agent proposes a change, it must still pass through the hardened, deterministic validation rules that network operators have trusted for years.

  3. Unified Microservices Architecture: By refactoring Apex-PDP as a Spring Boot application, we align the platform with modern cloud-native standards. Leveraging Spring AI allows for seamless connectivity to local models (via Ollama) or cloud-based providers, making the platform future-proof and modular.

What Can Customers Build?

Rather than attempting the risky and resource-heavy task of training a proprietary AI model from scratch, this approach empowers customers to implement their own AI Agents using high-quality open-source models. With this support, operators can deploy intelligent agents for:

1. Predictive Root-Cause Analysis (RCA)

Instead of waiting for an alarm and triggering a generic script, customers can implement an agent that consumes a stream of logs, configuration snapshots, and topology data. The AI agent can provide a natural-language summary of the incident and suggest precise, context-aware remediation steps, significantly reducing Mean Time to Repair (MTTR).

2. Adaptive Configuration Optimization

Customers can build agents that monitor network performance metrics (e.g., latency, packet loss, or energy consumption). The AI agent can dynamically suggest and "dry-run" configuration changes to the VNF or network slice parameters, ensuring the network is always optimized for the current traffic load.

3. Automated Compliance and Security Guardrails

Customers can deploy "Compliance Agents" that scan proposed policy changes against regulatory requirements or security best practices. The AI can highlight potential conflicts or security gaps before a policy is ever deployed to the live network, acting as a sophisticated, pre-deployment auditor.

Conclusion: Flexibility Without Complexity

By providing an AI-ready framework rather than a "black-box" AI solution, we offer customers the ultimate flexibility. They gain the power of advanced intelligence—customized to their specific network requirements—while retaining the safety, security, and proven reliability of the ONAP Policy Framework. This is not just automation; it is the transition to Cognitive Orchestration.

Steps for the implementation

1. Upgrade Apex-pdp in SpringBoot

2. Ollama

Ollama is an open-source tool designed to make running Large Language Models locally on your own machine incredibly simple.

Instead of needing complex setups or high-level coding knowledge, Ollama provides a streamlined command-line interface that handles the heavy lifting of model management, configuration, and execution.

It is widely used by developers and AI enthusiasts who want to experiment with powerful AI models without relying on third-party cloud services or managing complex infrastructure.

Ollama Docker Image: https://hub.docker.com/r/ollama/ollama

List of supported AI models: https://ollama.com/library

3. Use Spring AI to connect to Ollama

Spring AI is an application framework designed to simplify the integration of Artificial Intelligence capabilities into Java applications. It brings the familiar, modular, and "POJO-centric" design principles of the Spring ecosystem to the AI domain.

Its primary goal is to provide a consistent, portable API layer that allows developers to interact with various AI models and vector databases without being locked into a single provider’s SDK.

Spring AI provides native, first-class support for Ollama, enabling Java developers to integrate locally running Large Language Models (LLMs) into their Spring Boot applications seamlessly.

4. Define a Policy for AI

Example of Policy:

eventInputParameters: OllamaConsumer: carrierTechnologyParameters: carrierTechnology: Ollama parameterClassName: org.onap.policy.apex.plugins.event.carrier.ai.OllamaCarrierTechnologyParameters parameters: servers: ollama:11434 model_name: "llama3" eventProtocolParameters: eventProtocol: String parameters: pojoField: OllamaResponseEvent eventName: AcElementEvent eventNameFilter: AcElementEvent eventOutputParameters: logOutputter: carrierTechnologyParameters: carrierTechnology: FILE parameters: fileName: outputevents.log eventProtocolParameters: eventProtocol: String OllamaReplyProducer: carrierTechnologyParameters: carrierTechnology: Ollama parameterClassName: org.onap.policy.apex.plugins.event.carrier.ai.OllamaCarrierTechnologyParameters parameters: servers: ollama:11434 model_name: "llama3" eventProtocolParameters: eventProtocol: String parameters: pojoField: OllamaResponseStatusEvent eventNameFilter: (LogEvent|OllamaResponseStatusEvent) name: onap.policies.native.apex.ac.element version: 1.0.0

5. Create a demo

Create a demo using Clamp, policy-participant, api, pap, apex-pdp and Ollama that is using AI as a proof of concept. it not needs to resolve a specific problem but proofs that Apex-pdp could be configured to be an Agentic AI.

6. User case

Apex-pdp (Adaptive Policy Execution) is a lightweight, high-performance policy engine within the ONAP Policy Framework. It is designed to execute automated, event-driven decision logic in real-time. By processing incoming events—such as faults, performance metrics, or configuration updates—Apex-pdp evaluates state-based policies and triggers corrective actions.

Common Use Cases:

  • Closed-Loop Automation: Automatically responding to network faults or performance degradation (e.g., triggering a self-healing action).

  • Dynamic Configuration: Adjusting network elements based on real-time traffic or environmental stimuli.

  • Predictive Maintenance: Analyzing trends to prevent failures before they occur.

The AI capability, could be used to extend the analysis in real time with queries and results in a natural language.

Participant-monitoring

Using Ollama and Spring AI capability, we can implement a new participant with monitoring role (The name is based on what participant is able to do and not based in the technology used).

Operations

  • PRIME: checks that Ollama and the Model is up and running

  • PRECHECK: ACM-r send some URLs to participants (health endpoints), participant collects data, build a prompt, calls Ollama and sends result to ACM-r

  • DEPLOY: ACM-r send all URLs to participants (health and metrics endpoints, Prometheus endpoint, ElasticSearch endpoint for logs).

  • REVIEW: participant collects data, build a prompt, calls Ollama and sends result to ACM-r

  • UNDEPLOY: nothing

  • DEPRIME: nothing

It is better that this participant does not make decisions, and not get involved in DEPLOY/UNDEPLOY state change.

Example for log analysis

Note: Only models with tag “tool“ are able to use Tolls. (Es llama3.2).

Example of tools:

@Service class MyTools { @Tool(description = "Get ID error") public String getIdName(@ToolParam(description = "ID") String id) { var result = ... return result; } }

Example to process a log (log should be filtered and chunked):

import org.springframework.ai.chat.client.ChatClient; import org.springframework.stereotype.Service; import java.util.Map; @Service public class LogAnalyzerService { private final ChatClient chatClient; private final MyTools myTools; public LogAnalyzerService(ChatClient.Builder builder) { // Initialize the client this.chatClient = builder.build(); this.myTools = myTools; } public String analyzeLog(String logContent) { return chatClient.prompt() // 1. Define the role: Senior SRE expert .system("You are a senior SRE expert. Analyze the provided log, " + "identify the root cause, and suggest a clear solution.") // 2. Pass operational tools .tools(myTools) // 3. Inject the log content dynamically using parameters .user(userSpec -> userSpec.text(""" Analyze the following log: --- {logContent} """) .param("logContent", logContent)) // Execute the call and return the result .call() .content(); } }

system parameter could be passed as property from DEPLOY and user parameter could be passed as property from REVIEW.

Other example for tools

/** * MyTool. */ @Slf4j @Service @RequiredArgsConstructor public class MyTool { /** * Get health from a given application. * * @param application the application * @return UP */ @Tool(description = "Get health from a given application") public String getHealthApplication(String application) { var result = """ { "status": "UP" } """; if (application != null && application.equals("App3")) { result = "404 Not found"; } log.info("call getHealth({}): {}", application, result); return result; } /** * Get state from a given application. * * @param application the application * @return OK */ @Tool(description = "Get state from a given application") public String getStateApplication(String application) { var result = "OK"; if (application != null && application.equals("App4")) { result = "In Error"; } log.info("call getStateApplication({}): {}", application, result); return result; } }

For an easy query, it works.

Example: using system as "You are a system administrator" and user as

Get health from App1. Get health from App2. Get health from App3. Check if these applications are UP.

The result:

I call getHealthApplication for each application The health of the applications is: App1: UP App2: UP App3: Not Found (404 error) Note that for App3, the application was not found, resulting in a 404 error.

But complex easy query, it not work every time.

Example:

Get health from App1. Get health from App2. Get health from App3. Check if these applications are UP. Get state from App4. Get state from App5. Get state from App6. Check if these applications are OK.

Result:

The status of the applications are: App1: UP App2: UP App3: UP App4: OK App5: OK App6: In Error Please note that "In Error" indicates an application is not functioning correctly, and "404 Not found" typically indicates a server error or unreachable application.

When the result should be “App3: Not Found (404 error)” and “App4: In Error“

Use case scenario

Using REVIEW to make custom queries or specific operation:

  • properties: operation: QUERY query: Get health from App1 Get health from App2 Check is these applications are up
  • properties: operation: LOG_ANALYSIS filterBy: <traceId> applications: App1

The “operation” property define the specific operation to be executed.

If the operation is “QUERY”, participant will make a query using the property “query“.

If the operation is “LOG_ANALYSIS”, participant will make a log analysis using the property “applications“ to find out the list of applications that need to be analyzed. “filterBy” property could be used to filter the log by a specific value.

Comments