RAN Fault Management (GB1523A): autonomy level assessment

RAN Fault Management (GB1523A) is the TM Forum high value scenario that measures how much of the handling of radio network faults runs without people, from the first alarm to the verified repair. Its level is assessed task by task through the five IAADE steps, and it was among the first scenarios published for ANLET and covered by ANLAV at its launch.

What this scenario covers

The scenario covers what happens between a fault in the radio access network and its confirmed resolution. It spans:

• Detecting. Collecting alarms and performance degradations from base stations and their management systems, and removing duplicates and noise.
• Understanding. Correlating alarms to a probable root cause, telling a site fault from a transport or power problem, and estimating the impact on service.
• Deciding. Prioritising, choosing between a remote action and a field intervention, and opening or enriching the trouble ticket.
• Acting. Applying the fix: a remote reset, a configuration change, compensation by neighbouring cells, or dispatching a technician with the right information.
• Closing the loop. Checking that the fault is cleared and the service restored, then closing the ticket and feeding what was learned back into the rules.

The ITU-T X.733 alarm reporting function defines a classic alarm model. 3GPP specifies TS 28.111, Management and orchestration; Fault management (FM), and TM Forum publishes the TMF642 Alarm Management API.

The level always applies to this scenario only. The same team can be highly automated on alarm correlation and still manual on RAN energy efficiency.

How ANN structures it

In ANN, the questionnaire for GB1523A is organised in tabs by sub-scenario, then by task. Each task is rated from L0 to L5 through the IAADE steps: Intent, Awareness, Analysis, Decision and Execution.

The table below shows what each IAADE step asks here. It is an illustration written by CEVIA, not an extract from a TM Forum questionnaire.

When a reference standard is known for a task, it appears as a chip under the task name, for example X.733, TS 28.111 or TMF642. A chip marked "CEVIA proposal" is a mapping suggested by CEVIA that does not come from a sourced annex. Chips never change the score.

Once the sub-scenarios are complete, the results screen shows the scenario score following IG1252, expressed as Lbase, Lextra and Lscenario, an IAADE radar and the gaps for each sub-scenario. A task without an answer stays "Not assessed" and is never counted as zero.

For RAN Fault Management, the results screen also offers a Data Request Pack: the list of data to request from the operator, exportable as PDF or XLSX. It also lists what is not requested: no subscriber data is asked for.

Evidence to prepare

For fault management, evaluators look for both what the organisation says and what its systems did.

Declarative evidence describes how the work is meant to be done:

• the fault and incident management process, with its escalation rules
• the automation policy: which faults may be fixed without approval, and who signs off the others
• the roles: who owns alarm rules, correlation logic and remediation scripts

Technical evidence shows how the work was actually done:

• exports of alarm filtering and correlation rules from the fault management system
• samples of correlated incidents, showing the alarms grouped and the root cause proposed
• logs of tickets opened, enriched and closed automatically, with timestamps
• records of remote remediation actions and their verification result
• repair time statistics over a representative period, by fault type

In ANN, each piece of evidence is attached to a task once its level is chosen, typed as declarative or technical, and kept with its history. The Evidence guide tab lists examples by IAADE step for each available scenario. It is a preparation aid built by CEVIA from operator practice, not an official TM Forum nomenclature.

ANN also shows an evidence coverage indicator: technical evidence counts in full, declarative evidence alone counts half, and the default coverage threshold is 80 %. This weighting is a CEVIA method, not a TM Forum rule, and it does not change the maturity score.

What Level 4 looks like here

At Level 4, analysis and decision are performed by systems, not only execution. For fault management, a system correlates alarms across domains, identifies the root cause, chooses the remedy, applies it and checks the result, often before customers notice. People define the policies and handle what the system cannot resolve.

When ANLAV became generally available in June 2025, TM Forum Inform listed RAN fault management among the scenarios covered, and reported that China Mobile was nearing Level 4 in several domains, including RAN fault management. This is a public statement about that operator, not about an ANN user.

A self-assessed level becomes a validated one only through ANLAV, with a certified evaluator. Our page on how to prepare for ANLAV explains what the auditor expects.

Source of the questionnaire

Each scenario in ANN states where its questionnaire comes from: a real ANLAV report where one exists, or a reconstruction documented by CEVIA from published TM Forum questionnaires. A reconstructed scenario is never presented as an official TM Forum table.

GB1523A is one of the scenarios currently available in ANN, listed on the scenarios page. The same logic applies to Core Network Fault Management (GB1523B) and IP Network Fault Management (GB1523E). For how task ratings become a scenario level, read IG1252 explained; for the questionnaire itself, see What is ANLET?.