Autonomous Networks
Autonomous networks cover intent-based operations, closed-loop automation, and assurance across Nokia NSP and AVA-based analytics. The exam tests how observe-analyze-decide-act loops work, how intents are translated into policy, and where guardrails and human escalation belong.
Automation architecture
Autonomy is a progression, not a binary state. A useful model is: observe telemetry, analyze against intent, decide an action, execute it, and verify the outcome. Nokia NSP provides intent-based orchestration and assurance; AVA adds analytics and anomaly detection. Closed loops should have guardrails, rollback, and escalation. A digital twin or simulation can validate a change before it is pushed to production. Autonomy levels describe increasing scope of closed-loop action, but the service architecture must still define policy ownership and accountability.
Rules to apply
- An intent states the desired outcome and constraints; it is not a CLI script.
- Every closed loop needs observability, a decision policy, an execution path, and verification.
- Guardrails limit blast radius: maintenance windows, change budgets, and protected services.
- Automation without rollback is not production-ready.
- AIOps can assist analysis, but autonomy requires policy and execution controls.
Worked example
An SLA on a network slice reports rising latency. NSP correlates telemetry, identifies a congested path, and checks policy: the slice permits rerouting but not capacity expansion. The loop reroutes the slice, verifies latency, and closes. If latency remains high, it escalates to an operator. The reasoning: the decision is constrained by intent and policy, and verification prevents a false close.
Traps that cost marks
Equating AIOps with full autonomy; automating actions without telemetry verification; omitting rollback; and defining intents as device commands rather than outcomes and constraints.