Predictika · Ericsson radio network changes

An AI agent's change to the radio network, checked before it is pushed

An AI agent or rApp proposes a batch of changes to the sites of an Ericsson radio access network: configuration changes, software upgrades, neighbor list changes, cell locks, new radios and NR standalone enablement. Before anything is pushed, the batch goes to the Predictika validator, which checks it against the site graph (macro sites, hub sites and emergency-service critical sites, their Baseband 6630, 6648 and 6651 units, overlapping neighbor sites and the software release each runs), the software release NR standalone needs, the basebands each radio fits, and the operator's own change policy, and returns every finding in one answer. The validator runs on the graph a network inventory tool exports, with the operator's own policy. The area, the tickets, the change policy and the software release names on this page belong to a fictional operator, Nordlys Mobil; the baseband and radio families follow Ericsson's public Radio System product information. Ericsson is not involved with it and has not endorsed it.

Scope: change batches for radio access networks with macro, hub and critical sites. See everything this validator covers

This validator checks one kind of request: a batch of proposed changes to the sites of a radio network, from an AI agent, an rApp or a person, against the site graph and a change policy. It handles any batch of such changes on the sites in the graph, not only the scenarios shown on this page. It does not generate configurations and does not push anything.

  • Covered: overlapping neighbor sites — changes to both of two overlapping neighbor sites in one batch are blocked; the neighbor comes from the graph, not from the batch. A software upgrade that would leave two neighbor sites more than one release step apart is blocked, in either direction.
  • Covered: NR standalone, radios and software releases — enabling NR standalone on a site that does not yet run the required release is blocked, and an upgrade in the same batch does not count; adding a Massive MIMO radio (AIR 3268 or AIR 6449) to a Baseband 6630 is blocked.
  • Covered: scope, rollback and window — a network-wide change with no rollback reference, or outside the approved change window, is blocked; a narrower change outside the window needs approval.
  • Covered: agent actions on live state — an rApp action to lock a cell whose transport link is degraded while the neighbor coverage is already down is blocked, because it would leave subscribers without coverage; with the neighbor coverage up, the same action is allowed.
  • Covered: approvals and velocity — changes to critical emergency-service sites need a minimum approval rank on the ticket, and a limit on hub and critical site changes per window sends the batch to a person.
  • Supplied by the operator's own systems, not by the validator — the site graph, the ticket approvals, the change policy values, whether each change is inside the approved window, the rollback reference, and the transport and neighbor coverage state from monitoring.
  • Not covered — configuration syntax, coverage or capacity simulation, performance modeling, and any rule the operator has not written into its policy. Other rules can be added.
The AI agentProposes the batch of network changes and says it is ready to push.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

8 scenarios in 4 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where rules-based change approval gets it wrong
Click to expand
    
Our assessment of what a typical rules-based change approval workflow (ticket fields, approval chains and validation rules) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

    
What the validator caughtTypical rules-based change approvalPredictika
A feature that needs a newer software release than the site runsOnly with workarounds
Whether NR standalone can be enabled depends on the release the site runs today, not the one a batch will leave it on. Ticket rules do not know either, so the check is done by an engineer reading release notes, or not at all.		The running release comes from the site graph, the feature's minimum release from the operator's feature matrix, and an upgrade in the same batch is correctly not counted.
Neighbor sites on software releases too far apartOnly with care
An upgrade ticket names one site. Whether it leaves its overlapping neighbor too far behind depends on the neighbor's release and a policy limit, which approval rules rarely hold side by side.		The target release is compared with the neighbor's running release from the graph, in either direction, against the operator's limit.
Both of two overlapping sites in one batchOnly with workarounds
A change-approval workflow looks at one change at a time. Seeing that two changes in the same batch hit two overlapping neighbors needs a view across the whole batch and the neighbor relation from the network inventory, which is usually done in a script outside the workflow.		The whole batch is evaluated together against the graph; both changes are reported, each naming its neighbor.
Network-wide scope that depends on a rollback and a windowOnly with care
Approval rules can require a rollback or a window for a change type, but scope has to be set correctly on each ticket, and a rule per combination grows quickly.		Scope, rollback reference and window are checked together for each change in the batch; partial fixes show exactly what is still missing.
An agent action that depends on live stateOnly with workarounds
Whether it is safe to lock a cell with a degraded transport link depends on the state of the neighbor coverage at that moment. Ticket rules do not see telemetry, so the check ends up inside the rApp or not at all.		The monitoring state travels with the change as a field, so the same cell lock is blocked with the neighbor coverage down and allowed with it up.
Approval rank by site role, plus a rate limitOnly with care
A rank requirement for critical sites and a limit on hub changes per window are separate thresholds that approval chains handle one at a time.		Both are checked on every batch and reported together, with the numbers behind them.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the batch; approval findings need a person to sign off. The wording shown is an example from the test runs; device names and numbers change with the batch. The policy values come from a fictional customer.

    
1Both overlapping neighbor sites in one batch (blocks): change item-02 on macro-101b and its overlapping neighbor site macro-101a are both in this batch. Change policy: two neighboring sites are changed in separate batches so that coverage is never lost in both at once.
2Cell locked while transport is degraded and neighbor coverage is down (blocks): change item-01 would lock a cell on macro-101a whose transport link is degraded, but the neighbor coverage is already down. Locking it would leave subscribers without coverage; restore the neighbor coverage first.
3NR standalone needs a newer software release than the site runs (blocks): change item-02 enables NR standalone on macro-104a, which runs software 24.Q4; in the operator feature matrix NR standalone needs software 25.Q2 or later. An upgrade in the same batch does not count: the feature can be enabled only once the site is running the release.
4Neighbor sites would run software releases too far apart (blocks): change item-01 upgrades macro-102a to software 25.Q4, but its neighbor site macro-102b runs 24.Q4. Change policy: neighboring sites may not run software releases more than one release step apart.
5Network-wide change without a rollback (blocks): change item-03 is network-wide and has no rollback reference. Change policy: stage a rollback before a network-wide change.
6Radio does not fit the baseband of the site (blocks): change item-04 adds radio AIR-3268 to hub-4, whose baseband is a Baseband 6630. The Massive MIMO radios (AIR 3268, AIR 6449) need a Baseband 6648 or 6651; conventional radios fit every baseband.
7Site not in the area (blocks): change item-01 names macro-999z, which is not a site in area nordlys-north.
8Change outside the change window (needs approval): change item-01 on critical-1a is outside the approved change window. Change policy: a person must approve it.
9Critical site change needs higher approval (needs approval): change item-01 is on critical site critical-1a (emergency-service coverage) and ticket chg-8102 carries rank 1 approval; change policy requires rank 3 for critical site changes.
10Too many hub and critical site changes (needs approval): this batch brings hub and critical site changes to 4 within the policy window; change policy allows 3.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Software releases and radios: A two-release jump, NR standalone on a 24.Q4 site, a network-wide change, a Massive MIMO radio on a Baseband 6630

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8103: an upgrade of macro-102a to software 25.Q4 (rollback rb-9101), the enabling of NR standalone on macro-104a (rollback rb-9102), a network-wide neighbor list change through hub-1, and the addition of an AIR 3268 radio on hub-4 (rollback rb-9104). All of it is in tonight's approved change window. No hub or critical site change has been made in this window yet. It is ready to push.

    
Verdict: Blocked.

    
    
      
  • Neighbor sites would run software releases too far apart. Change item-01 upgrades macro-102a to software 25.Q4, but its neighbor site macro-102b runs 24.Q4. Change policy: neighboring sites may not run software releases more than one release step apart.
    • 
      
  • NR standalone needs a newer software release than the site runs. Change item-02 enables NR standalone on macro-104a, which runs software 24.Q4; in the operator feature matrix NR standalone needs software 25.Q2 or later. An upgrade in the same batch does not count: the feature can be enabled only once the site is running the release.
    • 
      
  • Network-wide change without a rollback. Change item-03 is network-wide and has no rollback reference. Change policy: stage a rollback before a network-wide change.
    • 
      
  • Radio does not fit the baseband of the site. Change item-04 adds radio AIR-3268 to hub-4, whose baseband is a Baseband 6630. The Massive MIMO radios (AIR 3268, AIR 6449) need a Baseband 6648 or 6651; conventional radios fit every baseband.
    • 
    

    
2. Software releases and radios: Upgrade lowered and rollback added; the NR standalone fix and the radio still fail

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8103: an upgrade of macro-102a to software 25.Q2 (rollback rb-9101), an upgrade of macro-104a to software 25.Q2 (rollback rb-9105), the enabling of NR standalone on macro-104a (rollback rb-9102), a network-wide neighbor list change through hub-1 (rollback rb-9103), and the addition of an AIR 3268 radio on hub-4 (rollback rb-9104). All of it is in tonight's approved change window. No hub or critical site change has been made in this window yet. It is ready to push.

    
Verdict: Blocked.

    
    
      
  • NR standalone needs a newer software release than the site runs. Change item-03 enables NR standalone on macro-104a, which runs software 24.Q4; in the operator feature matrix NR standalone needs software 25.Q2 or later. An upgrade in the same batch does not count: the feature can be enabled only once the site is running the release.
    • 
      
  • Radio does not fit the baseband of the site. Change item-05 adds radio AIR-3268 to hub-4, whose baseband is a Baseband 6630. The Massive MIMO radios (AIR 3268, AIR 6449) need a Baseband 6648 or 6651; conventional radios fit every baseband.
    • 
    

    
3. Software releases and radios: NR standalone on a hub already on 25.Q4, and a radio that fits

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8103: an upgrade of macro-102a to software 25.Q2 (rollback rb-9101), the enabling of NR standalone on hub-3 (rollback rb-9102), a network-wide neighbor list change through hub-1 (rollback rb-9103), and the addition of a Radio 8863 on hub-4 (rollback rb-9104). All of it is in tonight's approved change window. No hub or critical site change has been made in this window yet. It is ready to push.

    
Verdict: Allowed.

    
4. Neighbor sites: Upgrade of both overlapping neighbor sites

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8101: an upgrade of macro-101a to software 25.Q4 (rollback rb-9201) and an upgrade of macro-101b to software 25.Q4 (rollback rb-9202). Both are single-site changes in tonight's approved change window. No hub or critical site change has been made in this window yet. It is ready to push.

    
Verdict: Blocked.

    
    
      
  • Both overlapping neighbor sites in one batch. Change item-01 on macro-101a and its overlapping neighbor site macro-101b are both in this batch. Change policy: two neighboring sites are changed in separate batches so that coverage is never lost in both at once.
    • 
      
  • Both overlapping neighbor sites in one batch. Change item-02 on macro-101b and its overlapping neighbor site macro-101a are both in this batch. Change policy: two neighboring sites are changed in separate batches so that coverage is never lost in both at once.
    • 
    

    
5. Neighbor sites: Upgrade one site, change another pair

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8101: an upgrade of macro-101a to software 25.Q4 (rollback rb-9201) and a configuration change on macro-103a (rollback rb-9202). Both are single-site changes in tonight's approved change window. No hub or critical site change has been made in this window yet. It is ready to push.

    
Verdict: Allowed.

    
6. rApp cell lock: Lock a cell with a degraded link, neighbor coverage down

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8102: lock a cell on macro-101a, whose transport link monitoring has flagged as degraded (rollback rb-9301), and make a configuration change on macro-103a (rollback rb-9302). Both are in tonight's approved change window. One hub or critical site change has already been made in this window. It is ready to push.

    
Verdict: Blocked.

    
    
      
  • Cell locked while transport is degraded and neighbor coverage is down. Change item-01 would lock a cell on macro-101a whose transport link is degraded, but the neighbor coverage is already down. Locking it would leave subscribers without coverage; restore the neighbor coverage first.
    • 
    

    
7. rApp cell lock: Neighbor coverage restored

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8102: lock a cell on macro-101a, whose transport link monitoring has flagged as degraded (rollback rb-9301), now that the neighbor coverage for that cell has been restored, and make a configuration change on macro-103a (rollback rb-9302). Both are in tonight's approved change window. One hub or critical site change has already been made in this window. It is ready to push.

    
Verdict: Allowed.

    
    
      
  • Neighbor coverage is up. Change item-01 locks a cell on macro-101a while the neighbor coverage is up; traffic moves to the neighbor cells.
    • 
    

    
8. Approvals: Critical site change outside the window on a lower-rank ticket

    
The agent's request. Please push this batch on the Nordlys Mobil north area under ticket chg-8102: a configuration change on critical-1a (rollback rb-9401), scheduled outside tonight's approved change window, and a configuration change on macro-103a (rollback rb-9402), inside it. Both are single-site changes. No hub or critical site change has been made in this window yet. It is ready to push.

    
Verdict: Needs approval.

    
    
      
  • Change outside the change window. Change item-01 on critical-1a is outside the approved change window. Change policy: a person must approve it.
    • 
      
  • Critical site change needs higher approval. Change item-01 is on critical site critical-1a (emergency-service coverage) and ticket chg-8102 carries rank 1 approval; change policy requires rank 3 for critical site changes.
    • 
    

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. An AI agent or rApp proposes a batch of changes to the sites of an Ericsson radio access network: configuration changes, software upgrades, neighbor list changes, and more. Before anything is pushed, the batch goes to the Predictika validator, which checks it against the site graph (macro sites, hub sites and emergency-service critical sites, their Baseband 6630, 6648 and 6651 units, overlapping neighbor sites and the software release each runs), the software release NR standalone needs, the basebands each radio fits, and the operator's own change policy, and returns every finding in one answer. The validator runs on the graph a network inventory tool exports, with the operator's own policy. The area, the tickets, the change policy and the software release names on this page belong to a fictional operator, Nordlys Mobil; the baseband and radio families follow Ericsson's public Radio System product information. Ericsson is not involved with it and has not endorsed it.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Please push this batch on the Nordlys Mobil north area under ticket chg-8103: an upgrade of macro-102a to software 25.Q4 (rollback rb-9101). All of it is in tonight's approved change window. The rest of the request is on screen.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with four findings, all in one answer. Change item-01 upgrades macro-102a to software 25.Q4, but its neighbor site macro-102b runs 24.Q4. Change policy: neighboring sites may not run software releases more than one release step apart. Change item-02 enables NR standalone on macro-104a, which runs software 24.Q4; in the operator feature matrix NR standalone needs software 25.Q2 or later. An upgrade in the same batch does not count: the feature can be enabled only once the site is running the release. Change item-03 is network-wide and has no rollback reference. Change policy: stage a rollback before a network-wide change. The other one is on screen.
    6. 
      
  6. The validator returned four blocking findings in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the batch are checked against each other.
    7. 
      
  7. What this shows: for neighbor sites on software releases too far apart, a rules-based change approval is error-prone for this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the item Software upgrade on macro-102a, one site, rollback rb-9101, inside the change window; target software release 25.Q4 to Software upgrade on macro-102a, one site, rollback rb-9101, inside the change window; target software release 25.Q2 and the item Neighbor list change on hub-1, network-wide, rollback none, inside the change window to Neighbor list change on hub-1, network-wide, rollback rb-9103, inside the change window. It adds the item Software upgrade on macro-104a, one site, rollback rb-9105, inside the change window; target software release 25.Q2.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Still blocked, with two findings, all in one answer. Change item-03 enables NR standalone on macro-104a, which runs software 24.Q4; in the operator feature matrix NR standalone needs software 25.Q2 or later. An upgrade in the same batch does not count: the feature can be enabled only once the site is running the release. Change item-05 adds radio AIR-3268 to hub-4, whose baseband is a Baseband 6630. The Massive MIMO radios (AIR 3268, AIR 6449) need a Baseband 6648 or 6651; conventional radios fit every baseband.
    12. 
      
  12. Two findings cleared. Still blocking: NR standalone needs a newer software release than the site runs and radio does not fit the baseband of the site.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the item Enable NR standalone on macro-104a, one site, rollback rb-9102, inside the change window to Enable NR standalone on hub-3, one site, rollback rb-9102, inside the change window and the item Add a radio on hub-4, one site, rollback rb-9104, inside the change window; radio AIR-3268 to Add a radio on hub-4, one site, rollback rb-9104, inside the change window; radio Radio-8863. It removes the item Software upgrade on macro-104a, one site, rollback rb-9105, inside the change window; target software release 25.Q2.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. The validator also returns the line-item quote. It starts with Software upgrade on macro-102a and Enable NR standalone on hub-3; the other two lines are on screen.
    18. 
      
  18. Both earlier findings are cleared.
    19. 
      
  19. Four problems caught in one call, fixed in two passes, and a clean batch. That is the value of Predictika's validator: catching mistakes before the change is made. Now you can try the other scenarios yourself.
    20.