Janos Korognai | AI, Automation & Customer Solutions

SON to rApp migration

SON to rApp migration #1: Why this migration matters

Janos Korognai · October 1, 2026

SON to rApp migration - 1/12 Why this migration matters

AT&T and Ericsson have published a useful account of a real RAN automation transition. AT&T is moving disparate SON functionality into a unified environment built around the Non-RT RIC and rApps. Its public priorities include traffic steering, outage compensation, load balancing, energy savings and self-healing.

That gives us a concrete question for this series: How would you take a familiar SON function and express its dependencies through R1 services?

I will walk through three example functions: PCI optimization, mobility load balancing and cell outage compensation. PCI gives us a clear configuration example. Load balancing brings in performance and policy. Outage compensation brings together alarms, topology and recovery.

The three functions illustrate a standards-based method. AT&T has published its direction and priorities, not its algorithms, settings or internal procedure.

The public architecture matters because several boundaries change at once. Ericsson describes EIAP as the overall RAN automation solution, with R1 facing rApps and management interfaces including O1 connecting the platform to network functions. Its case says AT&T aims to migrate proven internal automation functions into rApps and also bring in other suppliers. That is a stated aim, not evidence that every legacy function has already moved.

Who participates? The operator owns the intended network outcome and operational controls. The platform supplies exposed services and authorization. The rApp provides decision logic. Network management functions supply observations and carry out approved changes. This is my architectural reading of the public material; exact responsibilities depend on the deployment.

What changes in a migration? An existing function's inputs, decisions, outputs and lifecycle must be mapped to available services. The R1 specification calls R1 an open logical interface between rApps and the Non-RT RIC framework. It supports service discovery, authentication, authorization, data exchange and RAN OAM-related access. The existence of that interface alone does not tell us which specific data types or policies an operator has enabled.

Ericsson reported a third-party rApp performing optimization on AT&T's live network over R1 in July 2025. That milestone establishes production use of the interface. The announcement does not name the vendor or say which function was deployed.

Next: the contract hidden inside a SON module.

Sources: https://lnkd.in/g3bzXJ5a
https://lnkd.in/gMYsGYE9
https://lnkd.in/g2Nx6WfS

#ORAN #OpenRAN #rApps #NonRTRIC #SON #RANautomation

SON to rApp migration

SON to rApp migration #2: The SON contract

Janos Korognai · October 2, 2026

Before migrating a SON function, the engineering team should write down its contract.

For each function, I want five answers:

1. What triggers execution: a timer, alarm, KPI threshold or operator request?
2. Which network facts are required: cells, neighbors, configuration, measurements or alarms?
3. Which decision does the algorithm make?
4. Which action can it request, and through which management path?
5. How do we know the action helped?

Take PCI optimization as an example. A 3GPP SON specification describes detection of PCI collision or confusion, analysis of network data and measurements, and PCI reconfiguration. Those are useful anchors for defining the input, decision and output of our example.

The operator also defines excluded cells, allowed windows, approval mode, rate limits, rollback criteria and audit records. These are engineering considerations, not claims about a particular operator's implementation.

Once that contract is explicit, the R1 mapping becomes easier to review. The rApp team can identify which data and management services it needs, while the operator can review the scope of its actions.

Who should document the contract? SON specialists can explain the current function's triggers and algorithm assumptions. RAN operations can identify maintenance windows, alarms, escalation rules and the evidence needed to accept a result. The rApp and platform teams can then map each dependency to a specific service and permission. This division of work is a proposed migration practice.

The contract should include more than field names. A measurement needs a unit, collection interval, granularity, timestamp and object scope. A configuration parameter needs its owning object, permissible values, dependency rules and readback behavior. An alarm needs a source, severity, state and correlation rule. The migration team should record what happens when a field is absent or late.

3GPP TS 28.313 provides a useful example of why these details matter. It distinguishes distributed SON and centralized SON approaches to NR PCI configuration. Its centralized procedure collects PCI-related measurements, analyzes network resource model data, determines a new value and uses provisioning management services to reconfigure it. In the distributed procedure, a network-side PCI function can select a value from an updated list. Moving a function into an rApp therefore requires a precise choice about where the decision is made.

The output contract also needs ownership: Is the rApp giving a recommendation, requesting a CM write, or managing an A1 policy? Those are different operations and require different validation and authorization.

Next: what R1 actually exposes.

Sources: https://www.etsi.org/deliver/etsi_ts/128300_128399/128313/16.00.00_60/ts_128313v160000p.pdf
https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #SON #rApps #3GPP #RANautomation

SON to rApp migration

SON to rApp migration #3: What R1 gives the rApp

Janos Korognai · October 5, 2026

R1 is the logical interface through which an rApp uses services exposed by the SMO and Non-RT RIC framework. It covers more than a single API endpoint.

The public ETSI specification describes service management and exposure, data management and exposure, A1-related services, and RAN OAM-related services. The latter include network information, alarms, performance information and configuration access.

For our three examples, the useful mapping is:

• PCI: cell information, current configuration, performance evidence and a controlled configuration request.
• Load balancing: cell relationships and load indicators, followed by an approved optimization action or an A1 policy where the supported policy type fits.
• Outage compensation: fault information, affected cells, neighbors and recovery observations.

A1 has a specific role. An rApp can use an R1 A1 policy management service to manage a supported policy toward a Near-RT RIC. A configuration change can instead use the R1 configuration management service. The route depends on the use case and available capabilities.

The implementation starts by naming each required service and checking whether it is exposed, authorized and suitable for the required data or action.

Who provides the services? The ETSI R1 specification describes the SMO/Non-RT RIC framework as producer of service management and exposure functions, and RAN OAM-related functions as producers of network information, FM, PM and CM services. rApps can consume these services and can also produce services for other rApps.

How does an rApp find them? A bootstrap service may supply endpoints, but bootstrap is optional. A consumer discovers available services by selection criteria, and the framework applies identity and authorization checks. A producer registers a service it offers; a consumer discovers a service it wants to use. These are distinct procedures.

For data, DME types describe available data using an identifier and schema. An authorized consumer can discover a type and request a single data instance or subscribe for potentially repeated deliveries. A request or subscription can specify time interval, collection granularity, delivery periodicity, scope and target. Network information and RAN OAM-related services provide other paths for particular information. The correct mapping depends on the platform's exposed capabilities.

For action, R1 CM includes getting schemas, reading configuration and requesting writes. R1 A1 policy management can discover supported policy types and create, update, delete or query policies and their status. An rApp must choose a supported service path and check the outcome. A1 is a route toward Near-RT RIC policy control; a CM write is a management configuration request.

Next: PCI as the first migration example.

Source: https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #NonRTRIC #SMO #RANautomation

SON to rApp migration

SON to rApp migration #4: PCI optimization walkthrough

Janos Korognai · October 6, 2026

Consider two neighboring NR cells with the same PCI. A PCI rApp must confirm the neighborhood and the evidence for a collision or confusion before evaluating candidate values.

A possible engineering flow:

1. Discover the network information, configuration and performance services available to this rApp.
2. Read the current PCI values and neighborhood relationships.
3. Check measurement evidence and produce candidates.
4. Apply guardrails: reserved values, adjacency constraints and scope of impact.
5. Present a proposed change for approval.
6. Request the configuration update through the available R1 CM service.
7. Read back the value and observe post-change evidence.

The 3GPP SON specification describes PCI collision and confusion procedures, including centralized PCI reconfiguration. ETSI's R1 specification describes reading and writing configuration through an R1 CM service. The workflow above combines them into an illustrative sequence.

For a real migration, recommendation mode gives engineers a way to compare the new rApp decision with existing operations before enabling a configuration write.

A detail from 3GPP TS 28.313 is easy to miss: centralized SON and distributed SON have different PCI procedures. The centralized procedure collects PCI-related performance measurements, analyzes network resource model data and measurements, determines values and invokes provisioning. The distributed procedure can involve changing an allowed PCI list, after which the network-side function selects a value. The migration team must identify which behavior the legacy function actually performs before assigning the decision to an rApp.

What does R1 contribute? The Network Information service can expose aggregated cell-related information. The CM service can return supported configuration schemas, read current attributes and accept a requested change with a status response. PM can provide collected measurements. FM can provide alarms. These are service capabilities in the public specification; a deployed platform still needs to expose the necessary objects, measurements and rights.

How should a candidate be selected? The engineer needs to check more than whether a number differs from the neighbor's number. The review should document candidate rules, affected cells, concurrent optimization and post-change measurements. These are recommended checks, not a universal algorithm from the R1 specification.

A write response, configuration readback and evidence that the collision or confusion has cleared are three separate observations. Recording them separately helps identify whether a failure arose in the decision, provisioning or verification stage.

Next: data discovery and subscriptions.

Sources: https://www.etsi.org/deliver/etsi_ts/128300_128399/128313/16.00.00_60/ts_128313v160000p.pdf
https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #SON #5G #RANautomation

SON to rApp migration

SON to rApp migration #5: Data access is a migration task

Janos Korognai · October 7, 2026

A SON algorithm is only as useful as the data it receives. During migration, the rApp and platform teams should inventory every required field and its meaning before adapting the algorithm.

Example for PCI:

• Identity: cell ID and managed object reference.
• Context: frequency and neighboring cells.
• State: current PCI and administrative status.
• Evidence: alarms and relevant performance measurements.
• Quality: timestamps, freshness and missing-data behavior.

R1 Data Management and Exposure includes discovery of available data types and procedures to request or subscribe to data. The R1 specification also describes network information, fault, performance and configuration services. These are related capabilities, and a real implementation must map each needed field to an available service and data type.

A dependency ledger can record required field → source service → permission → freshness → fallback. When a required data type is unavailable, the rApp should explain why its recommendation cannot proceed.

That ledger gives the operator a concrete basis for a migration review, including the choice to stop when a measurement is late or its object identity cannot be mapped with confidence.

The DME specification has an important distinction: discovering a DME type means a consumer may request or subscribe to that type; it does not guarantee that a data instance is already present. Production may begin only after a request or subscription. A one-time request and an ongoing subscription have different lifecycles, so the rApp should use the one that matches its algorithm's timing.

Who owns data meaning? The producer and platform must describe the type and schema they expose. The rApp team must verify that it is the same measurement or managed-object concept expected by the old SON logic. The operator should validate whether the sampling window and object scope are adequate for a network decision. This is migration governance, rather than an automatic guarantee from R1.

For a data request, ETSI describes status query and cancellation. For subscriptions, it describes subscribe, update, query and unsubscribe procedures, with delivery choices such as push or pull. A data instance can be characterized by its DME type, time interval, collection granularity, delivery periodicity, scope and managed-object target.

A dependency ledger should therefore specify the exact needed type, schema version, source, object mapping, time window, collection interval, authorization and failure behavior. If two platforms expose fields with the same friendly label but different semantics, the rApp's calculations may change. Portability requires testing that meaning with known input cases.

Next: mobility load balancing.

Source: https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #SMO #DataManagement #RANautomation

SON to rApp migration

SON to rApp migration #6: Mobility load balancing walkthrough

Janos Korognai · October 8, 2026

AT&T's public case lists traffic steering and load balancing among the functions it intends to prioritize. Mobility load balancing combines performance data and supported control capabilities.

Suppose one cell has sustained high load while a suitable neighbor has spare capacity. The rApp obtains network information and performance data, checks mobility and service quality guardrails, and proposes a bounded steering action. After activation, the operator monitors both cells and the mobility outcomes.

Steps:

1. Discover available network information and PM services.
2. Select candidate source and target cells.
3. Confirm capacity, eligibility and minimum evidence quality.
4. Choose an action supported by this deployment.
5. Apply an approved policy through the R1 A1 policy management service, if a suitable A1 policy type is available, or use an appropriate CM path.
6. Measure load and service quality after the action.
7. Withdraw or revise the action if guardrails fail.

R1 specifies discovery and management of supported A1 policy types. The rApp must check whether the required policy type and target Near-RT RIC are available before choosing that path.

The thresholds and choice of action depend on the operator's network. The AT&T source establishes strategic priorities without disclosing its internal tuning rules.

Who makes the steering decision? The rApp may evaluate candidate source and target cells using aggregated cell information and PM data. The operator decides the acceptable service quality and mobility guardrails. The platform enforces access to the management or policy service. This is a possible split of responsibilities; the AT&T case does not disclose its algorithm.

What can the action path be? ETSI R1 describes an A1 policy management service that lets an rApp discover available A1 policy types, query their details, create or update policies, and query enforcement status. A policy request identifies a policy type and a Near-RT RIC. A supported policy type must exist for this path. R1 also defines a CM service for reading and requesting configuration changes to managed entities. Which path is suitable depends on where the intended control resides.

How do we assess success? Measure both the congested cell and candidate neighbors over a defined before-and-after interval. The operator may examine load distribution, mobility results and service quality for affected users, then compare with its own acceptance limits. Those metrics and limits are design choices; the operator case gives priorities, not parameter values.

Before acting on a pending recommendation, refresh network state and record the applied policy or CM request. An outage or intervening change can invalidate the proposal.

Sources: https://www.ericsson.com/en/cases/2025/shaping-networks-of-tomorrow
https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #NonRTRIC #LoadBalancing #RANautomation

SON to rApp migration

SON to rApp migration #7: Cell outage compensation walkthrough

Janos Korognai · October 9, 2026

A cell outage compensation rApp is a good test of whether the migration design handles uncertainty.

When a cell raises an outage alarm, traffic and neighbor-cell indicators may change. An outage compensation rApp can query fault and performance information, identify the affected area, and evaluate whether neighboring cells can safely absorb some traffic.

A possible engineering workflow:

1. Confirm the alarm and the affected cell's state.
2. Correlate neighboring cells and recent measurements.
3. Exclude candidate neighbors with insufficient capacity or poor data quality.
4. Produce a compensation recommendation with expected effect and risk.
5. Seek approval or execute within a defined automation policy.
6. Observe coverage and service indicators.
7. Restore the prior settings when the cell recovers, after checking the current network state.

The R1 specification describes alarm queries, network information, PM queries and CM access. AT&T's public case identifies outage compensation and self-healing as priority functions. Compensation settings and rollback rules require operator-specific design and validation.

A stale alarm or missing neighbor measurements should block automatic action until the evidence is sufficient.

Who decides when to compensate? Fault management can provide an alarm, while performance information and cell relationships help establish the impact and available alternatives. The operator defines whether the rApp can act automatically or must request approval. The platform exposes the authorized services; RAN operations retain responsibility for the operational policy. This is a recommended responsibility model.

The ETSI R1 FM service supports querying all alarms, a filtered subset or an individual alarm, and changing acknowledgement state. Acknowledgement is an alarm-handling operation; it does not itself repair the fault. The Network Information service can provide aggregated cell information, PM can query collected measurements, and CM can read or request configuration changes.

The difficult part is restoration. When the failed cell returns, the rApp should inspect the current network before reversing compensation. Other changes may have happened during the outage. A recorded pre-change value can support a rollback decision, but blindly writing an old value may overwrite a valid later change. Approval rules, observation windows and rollback conditions are operator design choices.

The public AT&T/Ericsson case lists outage compensation and self-healing as priorities. It gives no alarm thresholds, neighbor selection rules, configuration parameters or recovery MOP. The sequence in this post is an engineering example derived from the available R1 service capabilities.

Sources: https://www.ericsson.com/en/cases/2025/shaping-networks-of-tomorrow
https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #SelfHealing #SON #RANautomation

SON to rApp migration

SON to rApp migration #8: Onboarding and service discovery

Janos Korognai · October 12, 2026

Who is involved in onboarding? The rApp developer packages the function, the platform team deploys it, and the operator authorizes the capabilities and operational scope.

During onboarding, the parties review the package and requested capabilities. After deployment, the rApp registers and discovers the services and data types it is authorized to use.

The ETSI R1 general specification describes optional bootstrap, rApp registration, service registration and discovery, and authorization. If bootstrap is unavailable, the endpoint can be provisioned. An rApp consuming a service does not have to register that service as its own; service registration applies when it produces one.

The visible checkpoints would be:

• Package and version identified.
• Credentials provisioned by the platform workflow.
• rApp registered and authorized.
• Required services discovered.
• Required data types available.
• Initial execution in recommendation mode.

Packaging and operational approval workflows vary by platform and operator. The R1 procedures provide defined interaction points after deployment.

A useful failure case: the rApp can see a PM service, but it lacks authorization for the requested data. The run stops and records the reason.

The word “onboarding” covers work at more than one layer. A package has to be accepted and deployed by the chosen platform. Once running, the rApp uses R1 procedures to register and interact with exposed services. The cited R1 general specification defines those interface procedures; it does not define every platform's package approval workflow or how security credentials are provisioned.

In ETSI TS 104 228, an rApp registration may include name, vendor, software version, certificates, producer or consumer role and security credentials. Successful registration returns an rApp instance identifier. The specification separately describes authentication and authorization, including policy-based access such as role- or target-based controls. Service discovery is filtered by the consumer's identity, authorization and selection criteria.

If the rApp produces a service, it can register, update or deregister information about that service. If it only consumes the platform's PM service, it discovers and invokes that service. A data type has another registration and discovery flow in DME. Keeping rApp registration, service registration and data-type registration separate prevents confusion during integration.

An operational checklist should also record the rApp's version, required service/API versions, permitted network targets and behavior when authorization changes. A missing service or denied access should fail clearly. These checklist items are implementation recommendations, while the registration and authorization procedures come from the ETSI specification.

Source: https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #SMO #NonRTRIC #RANautomation

SON to rApp migration

SON to rApp migration #9: Closing the loop with evidence

Janos Korognai · October 13, 2026

A successful API response is only one checkpoint in a RAN automation loop.

For PCI, the operator should distinguish four results:

• The requested configuration write was accepted.
• The managed cell reports the intended PCI.
• The collision or confusion evidence clears within an observation window.
• Neighbor performance remains within agreed bounds.

For load balancing, the operator monitors both source and target cells. For outage compensation, it watches service indicators in the affected area and the failed cell's state. The automation record should retain the input snapshot, recommendation, approval, action, readback and observed outcome.

ETSI R1 defines CM write status and access to PM and fault information. The verification logic and observation windows in this post are proposed operational design choices. They should be set for the network and use case, then tested before closed-loop operation.

An engineer should be able to reconstruct why the rApp acted, which version and policy were active, what changed, and whether the result met the operator's goal.

Who verifies the outcome? The rApp can collect observations, while the operator defines acceptance criteria and decides whether to continue, pause or reverse automation. The platform can return operation status and expose data for later checks. The ownership of review and escalation belongs in the operator's process.

The R1 CM service provides a response to a write request with status or an appropriate failure cause. It also supports reading configuration. The FM service supports querying alarms, while the PM service supports filtered queries of collected performance data. These capabilities allow an application to gather evidence, but the standard does not prescribe a universal pass threshold for PCI, balancing or outage compensation.

A practical record links six moments: the input snapshot, decision and rationale, authorization or approval, requested action, configuration or policy status, and later observations. Include object identifiers and timestamps so another engineer can reconstruct the sequence. A failed write should not be recorded as an unsuccessful algorithm decision; a completed write without improved KPIs calls for a different investigation.

For A1 policy control, the R1 service includes policy status queries and status subscriptions. Even an enforced policy status does not by itself establish that the network objective improved. The loop needs independent measurement and defined observation time. Rollback criteria should be prepared before automatic actions are enabled. The observation period should cover the relevant network behavior, and a result should be tied to the cells and time window actually affected.

Next: multiple rApps and overlapping objectives.

Source: https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #ClosedLoop #NetworkAutomation #RANautomation

SON to rApp migration

SON to rApp migration #10: When rApps disagree

Janos Korognai · October 14, 2026

Imagine a load balancing rApp trying to move traffic onto Cell C while an energy saving rApp wants to reduce Cell C's capacity. Both recommendations might be reasonable in isolation.

A platform conflict check can evaluate overlapping requests before an action is applied:

• Identify the managed cells and parameters each recommendation touches.
• Compare objectives, priority and valid time windows.
• Check live state and constraints.
• Allow one action, defer both for approval, or reject the lower-priority request.
• Record the decision and its evidence.

Ericsson's public R1 explanation describes the platform's role in avoiding conflicts between changes requested by rApps. The operator and platform team still need to define priority and approval rules for their deployment.

The conflict decision should record which request proceeded, which was deferred, and which policy determined the outcome. When the denied request is retried, it needs a fresh view of the target cell and active constraints.

Who owns arbitration? The SMO/Non-RT RIC platform and operator need a way to evaluate overlapping requests, while each rApp should state its intended target, expected effect and validity period. Ericsson's public R1 explanation says its platform handles requested updates so changes from multiple rApps do not conflict. It does not publish a universal priority algorithm for every operator.

What kinds of conflict exist? Two rApps may request different values for the same cell parameter. They may touch different parameters but pursue opposing objectives, as with steering traffic onto a cell while reducing its capacity. An old recommendation can also race with a newer network event. Merely comparing parameter names will miss those cases.

How can a deployment handle this? The operator can define ownership of targets, allowed time windows, priority rules, approval routes and conditions for rejecting stale recommendations. The platform can serialize or arbitrate requests, check current state before applying them and log the outcome. These are proposed engineering controls, not an exhaustive set of procedures mandated by the R1 general specification.

A conflict record should identify both proposals, their input timestamps and targets, the applicable rule, the action allowed or denied and the subsequent measurements. That record is useful when an rApp behaved according to its own objective but the combined network result was poor.

Open interfaces allow more applications to participate. Operators need explicit rules for simultaneous automation, including whether a rejected action can be retried and whether a later change supersedes an earlier approval.

Next: conformance and portability.

Source: https://www.ericsson.com/en/blog/2023/12/how-the-o-ran-alliance-r1-interface-empowers-a-global-ran-automation-community

#ORAN #OpenRAN #rApps #NonRTRIC #NetworkAutomation #RANautomation

SON to rApp migration

SON to rApp migration #11: Portability needs a test

Janos Korognai · October 15, 2026

R1 provides a standardized interface for rApps to use services from an SMO and Non-RT RIC framework. Portability still depends on the services, versions, data types, policy types and authorization available in each target deployment.

A portability test matrix for one PCI rApp:

• Can it register and discover the required R1 services?
• Are the required cell and configuration fields available?
• Can it obtain the same meaning from each platform's data?
• Do authorization failures produce clear outcomes?
• Does a recommendation produce the same decision on the same input snapshot?
• Can the CM request, readback and verification be completed?

O-RAN's R1 conformance and interoperability tests are a starting point for interface validation. The use-case tests above add algorithm and operational checks.

Testing should include a target platform that lacks a required data type. The rApp should stop cleanly and explain the gap before an action is requested.

Who tests portability? The rApp vendor tests behavior against the R1 APIs it claims to support. The platform vendor exposes documented service versions and data types. The operator checks data meaning, policy availability, permissions and network outcomes in its environment. A passed interface test is one part of that review.

ETSI describes R1 as independent of a particular SMO/Non-RT RIC implementation and extensible with new services and data types. O-RAN's February 2026 publication summary lists R1 conformance and interoperability tests for CM, FM, DME subscription, HTTP push/pull, configuration schema and selected AI/ML operations. Those tests check defined interface behavior; they cannot establish that a PCI algorithm will improve every network.

A useful matrix separates four layers. Transport and API: can the rApp call the supported version and handle errors? Service availability: do Network Information, PM, CM or A1 policy services exist? Data semantics: do object identifiers, schemas and measurement windows mean what the algorithm expects? Operational behavior: do recommendations, writes, readback and rollback meet the operator's criteria?

Portability may also be limited by a vendor extension. Ericsson describes “R1*” services in its platform for capabilities that were ahead of standardized R1 at the time of its 2023 article. An application relying on an extension should identify that dependency and test it separately. Dates matter: specs and implementations keep evolving.

Sources: https://www.o-ran.org/blog/71-new-or-updated-o-ran-technical-documents-released-since-november-2025
https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf
https://www.ericsson.com/en/blog/2023/12/how-the-o-ran-alliance-r1-interface-empowers-a-global-ran-automation-community

#ORAN #OpenRAN #rApps #Interoperability #Testing #RANautomation

SON to rApp migration

SON to rApp migration #12: Who owns the migration

Janos Korognai · October 16, 2026

A SON to rApp migration crosses several teams. Clear ownership matters because each team controls a different part of the automation loop.

The operator defines the objective, the cells in scope, approval rules, performance guardrails and rollback conditions. The SON specialists document the existing function, its input meanings and known failure modes. The rApp developers adapt the decision logic and declare the data and services it needs. The SMO and Non-RT RIC platform team exposes authorized R1 capabilities and manages the operational lifecycle. RAN operations verify the result in the network.

A practical sequence is:

1. Inventory the SON function's triggers, inputs, decision, action and verification.
2. Map each dependency to an available R1 service or data type.
3. Confirm permission, service version and field semantics.
4. Onboard the rApp and test its decisions against known cases.
5. Run recommendation mode and review outcomes.
6. Enable controlled actions within agreed scope.
7. Observe results, handle conflicts and maintain a rollback path.

This is an engineering sequence, not an AT&T-specific procedure. The public AT&T and Ericsson case describes the strategic move from disparate SON capabilities to a Non-RT RIC-based environment. ETSI specifies the R1 service families that can support such a migration. Ericsson also reported a third-party rApp performing optimization on AT&T's live network via R1 in July 2025.

Which dependency has proved hardest in your experience: data semantics, service availability, approval rules or verification?

A prudent progression is to replay known cases, run in recommendation mode, enable a narrow approved scope and expand after verification. This is an operational proposal.

SON specialists validate legacy behavior. Data and platform teams confirm schemas and access. rApp developers handle decisions and missing inputs. The operator defines targets, approval and rollback. RAN operations reviews results.

Before enabling a write, the team should answer: Which service performs it? Which managed objects are in scope? What pre-change state is stored? How is success measured? What happens if the request succeeds but readback differs? Who can stop the loop? These questions apply across PCI, balancing and outage compensation.

ETSI specifies R1 services, while the AT&T/Ericsson case states the operator direction. Neither supplies a migration MOP for these three examples.

My Son to rApps Migration demo is available here: https://r1lab.kaldrivon.com

Sources: https://www.ericsson.com/4ab65a/assets/local/cases/customer-cases/2025/att-customer-case-network-transformation.pdf
https://www.ericsson.com/en/press-releases/6/2025/att-deploys-first-third-party-rapp-on-live-production-network-via-ericsson-intelligent-automation-platform
https://www.etsi.org/deliver/etsi_ts/104200_104299/104228/11.00.00_60/ts_104228v110000p.pdf

#ORAN #OpenRAN #rApps #SON #SMO #Telecom

Posts, articles & perspectives

Kaldrivon MiniSMO in action

Janos Korognai · September 28, 2026

Following yesterday’s release post, here’s Kaldrivon MiniSMO in action. Feedback welcome!

Download: https://lnkd.in/gzWFHM_b

#OpenRAN #SMO #Telecom #NetworkManagement

Watch the demonstration on LinkedIn ↗

Posts, articles & perspectives

Kaldrivon MiniSMO 0.2.0 is available

Janos Korognai · September 27, 2026

What if you could download an SMO, install it on a Windows PC, connect an O1-capable network function and start experimenting?

That is what I am trying to build.

Kaldrivon MiniSMO 0.2.0 is now available. Short demo: https://lnkd.in/g89MikqG

This is aimed at small operators, telecom labs, R&D teams, engineers and anyone experimenting with O1, NETCONF, YANG, O-RAN or 3GPP management who does not need a huge OSS footprint.

The Community version is free for up to 5 external network functions.

And this is no longer just a UI demo.

MiniSMO 0.2.0 can connect to external NFs and perform real management functions including:

• FM, CM and PM monitoring
• NETCONF capability discovery
• YANG library discovery
• O-RAN FM support
• IETF alarm support
• 3GPP AlarmList support
• YANG-Push PM collection
• O-RAN measurement statistics
• VES fault and perf3gpp ingestion
• Configuration snapshots and version history
• Configuration diffing
• Safe external NF configuration changes
• Alarm acknowledgement and notes
• CSV export
• Automatic reconnect and event replay handling
• Per-NF connection and subscription health

There is also a built-in simulated network, so you can explore MiniSMO even if you do not currently have access to real radio equipment.

If you DO have access to an O1-capable 4G or 5G NF, O-DU, O-CU, simulator or O-RAN lab environment, I would especially like you to try it.

Connect something I have never tested.

Try a different YANG model.

Throw alarms at it.

Send PM data.

Change configuration.

Break it.

Then tell me what happened.

That is exactly what I need at this stage.

This is still very much a work in progress, and there are known limitations. There is currently no A1, O2 or E2 support, it is single-user and single-PC, and the Windows installer is not code-signed yet, so SmartScreen may warn when installing it.

I would rather publish the limitations openly and improve the product with real telecom feedback than pretend an early release is finished.

The philosophy behind it remains:

RAN operations without the Tier-1 OSS footprint.

Download Kaldrivon MiniSMO 0.2.0:

https://lnkd.in/gzWFHM_b

If you work with O1, SMO, O-RAN, 4G/5G RAN, OSS, private networks, telecom labs or R&D, please try it or share it with someone who might.

And if you manage to connect a real NF successfully, I definitely want to hear about it.

#ORAN #OpenRAN #SMO #O1 #5G #4G #RAN #OSS #NETCONF #YANG #VES #3GPP #NetworkManagement #Telecom #Private5G #TelecomSoftware

Posts, articles & perspectives

Introducing KaldrivonR1Lab

Janos Korognai · September 25, 2026

https://lnkd.in/g-s5dzyM

I’m extremely proud of this demo - and fair warning: it gets very technical, so approach with caution! 🙂

Introducing KaldrivonR1Lab: an interactive SON to rApp Migration Workbench exploring one question:

How do you move a proven SON function into an rApp without losing control of the network?

The demo walks through PCI optimization, mobility load balancing and cell outage compensation - from extracting the original SON contract and mapping inputs and actions to R1 services, through building and testing the rApp, to approval, execution and checking the outcome.

What I’m especially proud of is the detail between those steps: the approvals, the evidence, the safe stops and the explanation of what happened and why. You can even download the generated rApp with its tests.

This is an independent, synthetic demonstration grounded in public O-RAN, ETSI and 3GPP sources. It’s a way to explore migration decisions and the path toward production.

📚 A post series is coming soon.

If you work with SON, rApps, Non-RT RIC or telecom automation, I’d love to hear your perspective: where would you put this approach to the test?

#OpenRAN #rApps #SON #Telecom #NetworkAutomation

View the original post and screenshot on LinkedIn ↗

Posts, articles & perspectives

A first look at SON-to-rApp migration

Janos Korognai · September 24, 2026

A sneak peek at what I’ve been building.

From SON to rApp, the interesting part is what happens in between.

This screenshot only tells part of the story. Full demo coming soon.

#OpenRAN #rApp #SON #NetworkAutomation #TelecomInnovation

View the original post and screenshot on LinkedIn ↗

SMO Architecture Notes

Introduction: What SMO is and where it fits in autonomous networks

Janos Korognai · June 24, 2026

What SMO is, where it fits in autonomous networks, and what I think SMO platforms should address

I'm starting a series on Service Management and Orchestration (SMO). Before it begins, here's the frame - what SMO is, why it matters, and the principles SMO platforms should be measured against.

This series is based on public standards, public industry discussions, and my personal perspective.

What is SMO

In the Open RAN architecture defined by the O-RAN ALLIANCE, the SMO is the management and orchestration layer above the radio network. It handles fault, configuration, performance, accounting and security management; hosts the Non-RT RIC and its rApps; orchestrates the cloud infrastructure; and connects to the network through open interfaces - O1 for management, O2 toward the cloud, A1 for policy, and R1 for rApp services. In plain terms, it's the control room of a software-defined network: where data is collected, intelligence runs, decisions are made, and changes are pushed back out.

Where it fits in the autonomous-network journey

TM Forum defines Autonomous Network Levels 0 to 5, from manual operations to full autonomy. ETSI's Zero-touch network and Service Management (ZSM) defines the closed-loop automation to get there. 3GPP defines the management and slicing models, and the O-RAN ALLIANCE defines the open, intelligent RAN. The SMO sits at the center: closed loops need somewhere to run, data needs collecting and exposing, and intelligence needs a host. If a network is to observe, decide, act and verify with increasing autonomy, SMO is one of the key places that capability comes together.

What I think SMO platforms should address

Reading across the public standards, the same principles keep surfacing - and these are where I believe SMO platforms will increasingly be judged:

• Openness and data ownership - the operator's data stays the operator's, exposed through open interfaces.
• Decoupled architecture - data, intelligence and infrastructure management kept modular, not fused into one proprietary block.
• Trustworthy automation - zero-touch only adds value when it's validated, auditable and governed.
• Security by evidence - hardened components, zero-trust access and provable supply-chain integrity, not assurances.
• Safe autonomy - as more autonomous functions act, detecting and resolving their conflicts becomes essential.
• Freedom from lock-in - open packaging, portable apps and standard interfaces protect an operator's long-term options.

My view is simple: the vendors who lean into these - rather than competing on closed data and proprietary dependencies - will be the ones operators trust with their autonomous future.

The posts that follow will turn these public principles into evaluation themes, each linked to a public reference. I'd welcome your perspective in the comments: agree, disagree, or add the principles you think are missing.
#SMO
#OpenRAN
#AutonomousNetworks
#ServiceManagementOrchestration
#Telecom
#5G
#Standards

SMO Architecture Notes

Operational data exposure

Janos Korognai · June 25, 2026

SMO ARCHITECTURE NOTES #1 / 50 - Operational data exposure

How should operational network data be exposed?

Public reference: TM Forum - Open Digital Architecture (open data) (https://lnkd.in/ghijY2aG)

Why it matters

Public frameworks describe a clear direction of travel for how a management platform should treat the data it collects. TM Forum's Open Digital Architecture frames open, model-driven data and Open APIs as the connective tissue between systems, while the O-RAN ALLIANCE describes the Non-RT RIC and its data-management function exposing data to applications through defined interfaces. The common thread across these public sources is that the platform is a producer and broker of data, not its sole owner.

That distinction matters in practice. When operational data - faults, performance counters, configuration state and topology - is reachable only through one vendor's tooling and formats, every downstream analytics, assurance or AI use case inherits that dependency. When the same data is exposed through open, documented interfaces, it can feed an operator's own systems from day one. A useful lens for any SMO discussion is whether a platform treats data as something to expose by default, or something to retain by default.

A strong platform position should come with specifics rather than slogans: a list of exposed domains, links to public interface definitions, and a clear statement that no data is held back by default. A weaker platform position treats data access as a feature to be enabled later, or routes everything through a single proprietary export path. For anyone weighing platforms against public frameworks, the gap between those two answers is often the gap between a data partner and a data gatekeeper.

What I think matters for SMO platforms

• Which data domains are exposed through open, documented interfaces?
• Can data be routed to an operator's own systems without vendor-specific tooling?
• Are the interface and schema specifications publicly available?
• Is data access governed by open APIs rather than one-off custom exports?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Decoupling the data layer

Janos Korognai · June 26, 2026

SMO ARCHITECTURE NOTES #2 / 50 - Decoupling the data layer

Should the data layer be decoupled from the management platform?

Public reference: O-RAN ALLIANCE - Specifications portal (Non-RT RIC / data management) (https://lnkd.in/gQNV_Sni)

Why it matters

Public O-RAN architecture material describes the Non-RT RIC and its data-management entity sourcing application inputs from defined data sources, and industry discussion of decoupled SMO architectures explores how far that can go. The question is whether analytics and applications can read from an operator's chosen data infrastructure, rather than being tied to a parallel store that lives only inside the platform.

Decoupling is attractive because it preserves choice. A platform whose intelligence is welded to its own internal database tends to pull every new use case back toward that database. A platform that can source data from where the operator already keeps it lets the operator evolve its data strategy independently of any single vendor's roadmap. Public standards point toward configurable data sourcing as an enabler of this flexibility, so a fair thing to probe is how much of the platform genuinely works against external data versus a documented exception.

In practice, full decoupling is rarely all-or-nothing; most platforms keep some internal state for active processing while sourcing the rest externally. The honest question is where the line sits and whether it is documented. A platform that can name exactly which functions still require its internal store - and why - is far easier to plan around than one that simply claims external data support without detail. Reading that boundary against the public decoupled-SMO discussion helps separate genuine flexibility from marketing.

What I think matters for SMO platforms

• Can applications declare and consume data from an external, operator-chosen source?
• Is external data sourcing a documented, supported configuration?
• What platform functions still depend on the internal data store?
• How is consistency maintained between internal and external data?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

System of record for telemetry

Janos Korognai · June 29, 2026

SMO ARCHITECTURE NOTES #3 / 50 - System of record for telemetry

Where should the system of record for network telemetry live?

Public reference: TM Forum - Open Digital Architecture & Open APIs (https://lnkd.in/ghijY2aG)

Why it matters

Modern data architectures built on hyperscale cloud data platforms and data lakes are widely documented in public industry literature, and many operators have standardised their analytics on them. A recurring theme in public SMO discussions is whether the management platform can forward telemetry - alarms, counters, configuration changes and inventory updates - to that external platform continuously and with predictable latency.

The design choice here is about where the authoritative copy of data lives. If the platform is the only durable store, the operator's wider data estate is always one integration behind. If the platform reliably streams to the operator's own system of record, the SMO becomes a feeder into a larger ecosystem rather than a silo beside it. Public frameworks such as TM Forum ODA emphasise Open APIs for exactly this kind of exchange, so latency targets, delivery guarantees and export limits are reasonable things to examine.

It is worth distinguishing a short operational buffer from a permanent store. Keeping a small local buffer for active control loops is sensible engineering; retaining everything indefinitely inside the platform is a different choice with different lock-in implications. A platform that streams promptly to the operator's system of record, and keeps only what closed-loop stability requires, reflects the open-exchange direction in the public frameworks and makes the operator's wider data estate the authoritative one.

There is an AI/ML dimension here too. Models are only as good as the data that trains and feeds them, and public material on the Non-RT RIC treats data exposure as the foundation for AI/ML inference. A platform that streams complete, timely telemetry to where an operator trains and runs models keeps that pipeline healthy; one that traps data behind a proprietary boundary starves it.

What I think matters for SMO platforms

• Can the platform forward telemetry to an external endpoint in real time?
• What latency targets are documented for each data domain?
• Are there volume or licensing constraints on data export?
• Is delivery guaranteed and recoverable after an interruption?
• Can the telemetry feed support AI/ML training and inference pipelines?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Open data schemas

Janos Korognai · June 30, 2026

SMO ARCHITECTURE NOTES #4 / 50 - Open data schemas

In what formats should data cross system boundaries?

Public reference: O-RAN ALLIANCE - Specifications (open interfaces & data models) (https://lnkd.in/gQNV_Sni)

Why it matters

Open, documented schemas - including event models and YANG-based configuration models referenced across O-RAN and broader telecom standards - exist so that data can be consumed without a proprietary decoder. When data arrives in a published, normalized format, an operator's existing tools can read it immediately; when it arrives as raw proprietary output, every consumer needs custom parsing.

Based on publicly available frameworks, a normalized schema plus a published schema registry is what turns a months-long integration into a configuration step. It also reduces lock-in, because portable formats can be carried to another system later. The practical question is not just whether open schemas are supported, but whether the full catalogue is documented, whether raw formats are mapped to normalised output, and how vendor-specific extensions and model deviations are disclosed.

Open schemas turn a six-month integration into a configuration step, but only if the documentation is complete. The detail that matters is the edge cases: how proprietary extensions are flagged, how model deviations are listed, and whether the published registry stays in step with releases. A platform that hands over a full schema catalogue is inviting scrutiny in a good way; one that describes formats only in general terms leaves the integration risk sitting with the operator.

This matters for AI/ML as much as for integration. Training and inference pipelines depend on consistent, well-described data, and normalized open schemas make features reproducible across model versions. Where formats are proprietary or undocumented, data-engineering effort balloons and model reliability suffers.

What I think matters for SMO platforms

• Are data outputs aligned to open, published schemas?
• Is a complete schema catalogue and registry available?
• How are proprietary extensions or model deviations documented?
• Are raw inputs mapped to the normalised output schema?
• Are schemas stable enough to support reproducible AI/ML features?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Self-serve configuration

Janos Korognai · July 2, 2026

SMO ARCHITECTURE NOTES #5 / 50 - Self-serve configuration

Who should control data-routing configuration?

Public reference: TM Forum - Open Digital Architecture (self-serve operations) (https://lnkd.in/ghijY2aG)

Why it matters

Public service-management frameworks emphasise operator self-service and automation over manual vendor change requests. A routine operational change - pointing data at a new destination, rotating credentials, adjusting an endpoint - ideally sits with the operator's own team rather than depending on a vendor ticket and a maintenance window.

Self-serve control is partly about speed and partly about ownership. Operators evaluating SMO platforms may consider whether common configuration is exposed through an admin console or API, whether it can be set independently per data domain, and whether a change is possible without a software release. Where every adjustment requires vendor involvement, the operator is effectively renting control of its own operations; where it is self-serve, the platform behaves like infrastructure the operator runs.

The test here is simple to apply: can a named operational change be made by the operator's own team, today, without a release or a ticket? Self-serve configuration signals trust and treats the platform as something the operator runs. Where routine changes still route through the vendor, the operating model carries a hidden tax in time and dependency that compounds across the life of the deployment.

What I think matters for SMO platforms

• Can endpoints and destinations be reconfigured self-service?
• Is configuration independently settable per data domain?
• Does a change require a maintenance window or a vendor ticket?
• Is configuration exposed through an API as well as a console?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Data coverage

Janos Korognai · July 3, 2026

SMO ARCHITECTURE NOTES #6 / 50 - Data coverage

How complete is the exposed data set?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

Public standards describe the wide range of managed objects and counters a management system ingests across fault, performance, configuration and inventory domains. A consideration raised in industry discussion is whether all of that is actually available through open interfaces, or only a curated subset - and in particular whether raw counters are exposed, not just pre-aggregated KPIs.

Coverage gaps tend to surface late, when an operator discovers that the very data point a new analytics or assurance use case needs was never exposed. A transparent platform can describe exactly what is exposed versus retained internally, per domain and per underlying network-element vendor. The deeper the visibility, the less the operator is constrained to the use cases the platform vendor anticipated.

Coverage questions are best answered with a matrix, not a reassurance. A document that lists, per domain and per underlying element type, what is exposed versus retained lets an operator check its own future use cases against reality before committing. The presence of raw counters alongside aggregates is a particularly useful signal, because it is the raw detail that unanticipated analytics tend to need later.

What I think matters for SMO platforms

• Which data types are exposed versus retained internally only?
• Are raw counters available, not just aggregated KPIs?
• Is coverage equivalent across different underlying network-element vendors?
• Is a data-coverage matrix available for review?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Resilience under disconnection

Janos Korognai · July 6, 2026

SMO ARCHITECTURE NOTES #7 / 50 - Resilience under disconnection

What happens to control loops if an external data platform is unreachable?

Public reference: ETSI - Zero-touch network & Service Management (ISG ZSM) (https://lnkd.in/gJfRvWmi)

Why it matters

ETSI's Zero-touch network and Service Management (ZSM) work addresses closed-loop automation and the resilience that production automation demands. Decoupling data and intelligence from a single internal store is sound architecture, but it raises a fair question: what happens to closed-loop control when an external dependency is briefly unavailable?

Public discussion of decoupled architectures notes that sufficient local operational state and buffering can keep control loops stable through a temporary outage, with data buffered and forwarded once connectivity resumes. The maturity of a platform shows in how gracefully it handles these moments. Worth probing: how long loops can run without the external platform, what state is held locally, and whether reconnection and catch-up are automatic rather than manual.

True decoupling is measured under stress, not on a clean diagram. The reassuring answers are concrete: a stated tolerance window, a description of exactly what is buffered, and automatic reconnection with catch-up forwarding. A vague assurance that the system is resilient is worth less than a documented outage behaviour an operator can actually test during acceptance.

What I think matters for SMO platforms

• How long can control loops operate without the external data platform?
• What state is buffered locally during an outage?
• Is reconnection and data catch-up automatic?
• Is any data lost during a disconnection event?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

AI/ML integration

Janos Korognai · July 7, 2026

SMO ARCHITECTURE NOTES #8 / 50 - AI/ML integration

How should SMO intelligence integrate with an operator's AI/ML stack?

Public reference: O-RAN ALLIANCE - White papers & resources (Non-RT RIC / AI) (https://lnkd.in/gewWiV_5)

Why it matters

Public material on the Non-RT RIC and AI-enabled RAN describes intelligence functions that consume data and produce insight or policy. Many operators have already invested heavily in their own data and MLOps platforms, so a recurring design consideration is whether the SMO's intelligence integrates with that existing stack or introduces a parallel one beside it.

Based on publicly available frameworks, the more valuable position is an intelligence layer that consumes from, and contributes back to, the operator's established platforms - making prior investments more useful rather than duplicating them. The questions that follow are about openness of the model and data interfaces, and which standard service interfaces let external analytics and rApps participate without bespoke integration.

The strongest position keeps the platform's own AI tooling optional rather than mandatory, so the operator can use it where it helps and bypass it where their own stack is better. Open model and data interfaces are what make that choice real. A platform that can only be intelligent through its own closed pipeline quietly recreates the lock-in that decoupling was meant to avoid.

What I think matters for SMO platforms

• Can intelligence functions consume from and contribute to existing data platforms?
• Are model and data interfaces open and documented?
• Which standard interfaces support external analytics and rApps?
• Is the platform's AI tooling optional rather than mandatory?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Cloud resource management

Janos Korognai · July 8, 2026

SMO ARCHITECTURE NOTES #9 / 50 - Cloud resource management

How are cloud infrastructure resources discovered and managed?

Public reference: O-RAN ALLIANCE - Specifications (cloud infrastructure interfaces) (https://lnkd.in/gQNV_Sni)

Why it matters

As radio networks move onto cloud infrastructure, the management layer takes on the job of discovering and managing that infrastructure too. O-RAN's publicly specified cloud architecture defines standardised infrastructure management through open interfaces between the management system and the cloud platform, so this can be done consistently across suppliers.

Public standards point toward managing infrastructure through open, interface-driven models rather than a closed integration that only works with one stack. That matters because a cloud-native network whose management is locked to a single infrastructure vendor inherits that lock-in everywhere. Reasonable things to examine are which standardised interfaces and profiles are implemented, and whether infrastructure from multiple suppliers can be managed through the same mechanisms.

The signal to look for is breadth of supported infrastructure through the same standardised mechanisms. A platform that manages diverse infrastructure consistently is far easier to live with than one that works cleanly only with a single stack. Independent testability of that conformance turns a claim into something an operator can verify before it becomes a dependency.

What I think matters for SMO platforms

• Are infrastructure interfaces standards-based and documented?
• Can the platform manage infrastructure from multiple suppliers?
• Which standard interface profiles are supported?
• Is conformance to those interfaces independently testable?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Standardised interfaces

Janos Korognai · July 9, 2026

SMO ARCHITECTURE NOTES #10 / 50 - Standardised interfaces

Which standard interfaces govern infrastructure and deployment?

Public reference: ETSI - Network Functions Virtualisation (ISG NFV) (https://lnkd.in/g5uPNM3G)

Why it matters

Publicly documented profiles - for example ETSI NFV and Kubernetes-based deployment models - define how a management system interacts with cloud platforms to deploy and operate network functions. Conformance to these public profiles is what keeps an operator's infrastructure choices open over time.

Every proprietary infrastructure interface is a future migration cost in waiting. Operators evaluating SMO platforms may consider which standardised profiles are implemented, whether more than one is supported to handle a heterogeneous estate, and whether conformance can be independently verified rather than simply asserted. Standards adherence at this layer is one of the clearest signals that a platform is built to fit into a multi-supplier world.

Supporting more than one profile is often the difference between a platform that fits a real estate and one that assumes a greenfield. Version handling matters too: standards evolve, and a platform that tracks profile versions cleanly avoids forcing disruptive upgrades. Independent verification, through public testing rather than self-declaration, is the strongest form of this assurance.

What I think matters for SMO platforms

• Which standardised deployment profiles are implemented?
• Is more than one profile supported for heterogeneous clouds?
• Is conformance independently verifiable?
• How are profile versions and upgrades handled?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

NF lifecycle automation

Janos Korognai · July 10, 2026

SMO ARCHITECTURE NOTES #11 / 50 - NF lifecycle automation

How is the full lifecycle of cloud network functions automated?

Public reference: ETSI - Network Functions Virtualization (ISG NFV) (https://lnkd.in/g5uPNM3G)

Why it matters

Deploying a cloud network function is the easy part; operating it across its whole life is where the work sits. ETSI NFV and O-RAN material describe lifecycle management - initial deployment, healing, scaling, software upgrade and termination - carried out through standardized operations rather than manual runbooks.

Based on public frameworks, lifecycle automation coordinated by the management layer is what turns a cloud network from a deployment project into a living, largely self-managing system. The useful questions are which lifecycle actions are genuinely automated end to end, whether the status of each operation is exposed so it can be tracked and assured, and whether those actions are driven through standard interfaces that other systems can rely on.

Lifecycle automation is most valuable when higher-level orchestration can both trigger and observe it, closing the loop end to end. A platform that automates deployment but leaves healing, scaling or upgrade as manual exercises has automated the easy part. Exposed per-operation status is what lets assurance trust the automation rather than shadow it with manual checks.

Increasingly, lifecycle actions are themselves AI/ML-driven; public material on autonomous networks describes models forecasting demand and triggering scaling or healing. A platform whose lifecycle operations can be invoked and observed through open interfaces lets AI/ML logic, including rApps, drive them safely, with humans able to supervise.

What I think matters for SMO platforms

• Which lifecycle actions are automated end to end?
• Is per-operation status exposed through the interface?
• Are lifecycle operations driven through standard interfaces?
• Can higher-level orchestration trigger and monitor these actions?
• Can AI/ML logic safely trigger and observe lifecycle actions?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Infrastructure visibility

Janos Korognai · July 13, 2026

SMO ARCHITECTURE NOTES #12 / 50 - Infrastructure visibility

What visibility exists into deployment and infrastructure state?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

You cannot assure what you cannot see, and in cloud networks visibility is the hard part. Public standards emphasise observability of where functions run and the live status of operations, so that automation and assurance work from current truth rather than a stale snapshot.

A design consideration is whether the platform exposes a single, queryable view of placement and operation state, or whether that picture has to be reassembled from fragments. Clear, trustworthy visibility is the precondition for any automation an operator is willing to rely on. It is reasonable to ask whether the platform can report where each function is deployed, whether live operation state is queryable, and whether all of this is available through an open interface.

Real-time visibility and periodically refreshed visibility are not the same thing, and the difference shows under fault conditions. A single queryable view that other systems can consume through an open interface is what lets assurance and orchestration act on current truth. Where the picture must be reassembled from fragments, every automated decision inherits the risk of acting on stale facts.

Trustworthy visibility is also what makes AI/ML safe: models reason over the state the platform exposes, so gaps or staleness propagate straight into model decisions. A single, current, queryable view is as much a precondition for reliable AI/ML as it is for human operators.

What I think matters for SMO platforms

• Can the platform report where each function is deployed?
• Is the live state of each operation queryable?
• Is this exposed through an open interface?
• Is the information real-time or periodically refreshed?
• Is exposed state reliable enough for AI/ML to reason over?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Securing deployment artifacts

Janos Korognai · July 14, 2026

SMO ARCHITECTURE NOTES #13 / 50 - Securing deployment artifacts

How are sensitive deployment artifacts protected?

Public reference: NIST SP 800-207 - Zero Trust Architecture (https://lnkd.in/g4qXk5kX)

Why it matters

Every secret, key and credential a network function needs is also something an attacker would value. Public security guidance, including NIST and cloud-native security practice, calls for explicit confidentiality, integrity and access-control models for these sensitive artifacts rather than informal handling.

How a platform handles secrets is a direct statement of how seriously it takes security. Operators may consider whether sensitive artifacts are protected under a defined, auditable model end to end, whether integrity and confidentiality can actually be demonstrated, and how access is controlled and logged. The concrete mechanism can vary, but the guarantee should not - and it should be evidenced rather than assumed.

The reassuring answer describes a concrete model - encryption at rest and in transit, controlled and logged access, integrity verification - rather than a general claim of careful handling. Because the mechanism can legitimately vary, the thing to insist on is evidence: that the guarantees hold, and that access to sensitive material leaves an auditable trail.

What I think matters for SMO platforms

• Is there a defined security model for secrets and credentials?
• Are confidentiality and integrity protections auditable?
• How is access to sensitive artifacts controlled and logged?
• Are secrets encrypted at rest and in transit?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Service orchestration

Janos Korognai · July 15, 2026

SMO ARCHITECTURE NOTES #14 / 50 - Service orchestration

How are infrastructure and network-function changes coordinated?

Public reference: TM Forum - Open Digital Architecture (service orchestration) (https://lnkd.in/ghijY2aG)

Why it matters

The hardest orchestration problems live in the seams between infrastructure and the network running on top of it. Public architecture frameworks describe service orchestration coordinating infrastructure provisioning and network-function lifecycle activities while maintaining a consistent view of the resulting service and network state.

TM Forum ODA frames orchestration around higher-level service intent and automated realization. Instead of treating infrastructure provisioning, network-function lifecycle and service configuration as disconnected activities, the goal is to coordinate them as part of an end-to-end flow.

The real test comes when something does not go according to plan. If one part of a coordinated change fails, can the platform understand the dependencies, preserve a consistent state and recover without leaving infrastructure, network functions and inventory out of sync? Cross-domain orchestration matters most when reality deviates from the happy path.

AI/ML adds another dimension to intent-driven orchestration. Models can help predict demand, identify optimisation opportunities or recommend actions, while the orchestration layer translates approved intent into controlled changes across infrastructure and network functions. Keeping intelligence separate from deterministic execution allows operators to introduce AI-driven decisions without giving up governance over how changes reach the network.

What I think matters for SMO platforms

• Does a service-orchestration layer coordinate infrastructure and NF changes?
• Is inventory kept aligned with actual state?
• Are results reported back to higher-level logic?
• Can orchestration express intent rather than only low-level steps?
• Can AI/ML-driven intent be applied under deterministic guardrails?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Inventory and topology

Janos Korognai · July 16, 2026

SMO ARCHITECTURE NOTES #15 / 50 - Inventory and topology

How is inventory and topology kept current?

Public reference: O-RAN ALLIANCE - Specifications (Topology & Inventory) (https://lnkd.in/gQNV_Sni)

Why it matters

An inventory that is out of date is worse than no inventory, because it invites confident decisions based on wrong facts. Public standards define topology and inventory functions that should continuously reflect real network state as functions are deployed, scaled, healed and removed.

Accurate, self-updating inventory is the quiet backbone of trustworthy automation - assurance and orchestration are only as good as the picture of the network they work from. A platform that keeps inventory aligned automatically, and reconciles discrepancies when they appear, gives every layer above it a reliable foundation. Reasonable questions are whether inventory updates automatically with lifecycle actions, whether other functions work from that current state, and how mismatches are detected and corrected.

Self-updating inventory is the unglamorous foundation everything else stands on. The useful test is what happens after a healing or scaling event: does the inventory reflect reality automatically, and are discrepancies detected and reconciled rather than left to drift? Exposing topology for external consumers to query extends that reliable picture to the operator's wider tooling.

What I think matters for SMO platforms

• Is inventory updated automatically as lifecycle actions occur?
• Do assurance and orchestration work from current state?
• How are discrepancies detected and reconciled?
• Is topology exposed for external consumers to query?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Heterogeneous cloud

Janos Korognai · July 17, 2026

SMO ARCHITECTURE NOTES #16 / 50 - Heterogeneous cloud

Can orchestration span heterogeneous clouds?

Public reference: Cloud Native Computing Foundation (CNCF) (https://www.cncf.io)

Why it matters

No large operator runs a single, uniform cloud, and the management layer has to live with that reality. Public profiles such as ETSI NFV and Kubernetes, together with CNCF practice, acknowledge mixed estates and define how orchestration can work across them.

A platform that only behaves in a lab-clean, homogeneous environment is not ready for production. The relevant consideration is whether the same orchestration logic operates consistently across multiple infrastructure types and deployment profiles, so that diversity becomes a configuration concern rather than a re-platforming project. It is fair to ask which profiles and infrastructure types are supported and how heterogeneity is handled operationally.

The practical question is what happens when a new infrastructure type arrives. A platform that absorbs it as a configuration change has designed for the real world; one that needs re-architecting has designed for a lab. Consistent orchestration logic across profiles is what keeps a mixed estate manageable rather than fragmented.

What I think matters for SMO platforms

• Are multiple deployment profiles and infrastructure types supported?
• Does orchestration logic remain consistent across them?
• How is heterogeneity handled operationally?
• Can new infrastructure types be added without re-architecting?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Zero-touch integration

Janos Korognai · July 20, 2026

SMO ARCHITECTURE NOTES #17 / 50 - Zero-touch integration

What does zero-touch integration aim to achieve?

Public reference: ETSI - Zero-touch network & Service Management (ISG ZSM) (https://lnkd.in/gJfRvWmi)

Why it matters

The business case for automation is straightforward: fewer hands on every site, faster time to service, and lower operational cost as rollouts scale. ETSI ZSM frames these end-to-end automation goals, describing closed-loop, zero-touch operation as the destination for network and service management.

Zero-touch is about freeing skilled people from repetitive work that machines should be doing, and doing it with consistent quality. The useful questions are which integration steps are genuinely automated versus still manual, what scale and time savings are documented, and how the automation is governed so that speed does not come at the expense of control.

The honest version of zero-touch is explicit about where a human remains in the loop and why. Automation that hides its boundaries invites surprises; automation that documents them invites trust. Stated scale and time savings, backed by a clear account of where governance sits, are more meaningful than a blanket claim of full automation.

Higher autonomy levels are explicitly AI-driven. TM Forum's Autonomous Network Levels associate the top of the scale with intelligent automation using AI, and ETSI ZSM frames AI-assisted closed loops. A platform that can host AI/ML in its automation, with clear governance, is positioned for the levels operators are targeting rather than stuck at assisted operation.

What I think matters for SMO platforms

• Which integration steps are automated versus manual?
• What scale and time savings are documented?
• How is the automation governed?
• Where does a human remain in the loop, and why?
• How does the platform incorporate AI/ML into higher-autonomy operation?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Parameter generation

Janos Korognai · July 21, 2026

SMO ARCHITECTURE NOTES #18 / 50 - Parameter generation

How are configuration and parameter sets produced?

Public reference: ETSI - Zero-touch network & Service Management (ISG ZSM) (https://lnkd.in/gJfRvWmi)

Why it matters

The hand-built configuration spreadsheet, assembled site by site, is a relic worth retiring. Automated generation of configuration from design inputs is a documented automation goal across public frameworks, and it directly attacks one of the largest sources of rollout error.

Manual configuration does not just cost time; it introduces inconsistency that surfaces as faults later. A platform that generates validated configuration sets automatically from collected design inputs, and adapts the same engine across different network architectures, makes rollout repeatable and scalable. It is reasonable to ask whether configuration can be generated automatically, whether one engine covers different architectures, and how generated output is validated before use.

AI/ML increasingly assists this step, learning from past deployments to propose better starting configurations. The safeguard is the same as for any automation: generated or model-proposed configuration should be validated before it is applied, not trusted blindly.

What I think matters for SMO platforms

• Can configuration sets be generated automatically from design inputs?
• Does the same engine support different network architectures?
• How are generated configurations validated?
• Are inputs collected automatically or entered by hand?
• Can AI/ML assist configuration generation, with validation before apply?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Hardware detection

Janos Korognai · July 22, 2026

SMO ARCHITECTURE NOTES #19 / 50 - Hardware detection

How is on-site hardware detected and provisioned?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

A site visit that ends with the hardware not being what was expected is pure wasted cost. Automated discovery and provisioning of hardware - servers, radio units and cards - is part of the zero-touch integration goals described in public material, removing the manual identification step.

Automated detection turns site integration from a careful manual checklist into a repeatable process the system performs itself: it recognises what is physically present and provisions it accordingly. The network adapts to the hardware rather than the other way around. Worth examining: whether hardware is detected automatically, whether provisioning follows from that detection, and which hardware types are covered.

The scenario this addresses is the costly one: arriving on site to find the hardware is not what the records assumed. Automatic detection and provisioning turn that into a self-correcting step. The handling of unexpected or mismatched components is especially telling, because it is the exceptions, not the happy path, that determine whether automation scales.

What I think matters for SMO platforms

• Can the system detect hardware automatically?
• Is provisioning automated based on detected hardware?
• Which hardware types are supported?
• How are unexpected or mismatched components flagged?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Validation and execution

Janos Korognai · July 23, 2026

SMO ARCHITECTURE NOTES #20 / 50 - Validation and execution

How are scripts validated and executed?

Public reference: ETSI - Zero-touch network & Service Management (ISG ZSM) (https://lnkd.in/gJfRvWmi)

Why it matters

The riskiest moment in any rollout is a human running a change they have not fully checked. Public automation frameworks emphasise built-in validation before execution as a core governance control, so that changes are verified before they touch the live network.

Automating execution without automating validation simply lets mistakes happen faster. The stronger pattern is a single governed pipeline where generation, validation and execution are joined, validation runs automatically before anything is applied, and failures are caught and handled cleanly. It is fair to ask whether these stages form one pipeline, whether validation is automatic, and how failures are detected and contained.

What I think matters for SMO platforms

• Are generation, validation and execution a single governed pipeline?
• Is validation automatic before changes are applied?
• How are failures detected and handled?
• Can changes be rolled back automatically on failure?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Pre/post-launch validation

Janos Korognai · July 24, 2026

SMO ARCHITECTURE NOTES #21 / 50 - Pre/post-launch validation

How is success measured before and after launch?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

A deployment that completes and a service that works correctly are two different statements. Public material describes pre- and post-launch validation with real performance assessment – coverage, interference and quality – rather than simply confirming that a script ran without error.

The difference between deployed and working is measured in validation, and operators benefit when that measurement is automated and trustworthy. A platform that checks performance automatically before and after launch, and holds anything outside expected bounds, catches problems before they reach customers. Reasonable questions are whether checks are automated, which performance indicators are assessed, and what thresholds trigger a hold or rollback.

This is a natural home for AI/ML. Anomaly detection and learned performance baselines can flag subtle post-launch regressions that fixed thresholds miss. A platform that supports model-based assessment, with results captured, lets validation improve over time rather than staying static.

What I think matters for SMO platforms

• Are pre- and post-launch checks automated?
• Which performance indicators are assessed?
• What thresholds trigger a hold or rollback?
• Are results captured for later review?
• Can AI/ML anomaly detection augment fixed validation thresholds?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Reporting and auditability

Janos Korognai · July 27, 2026

SMO ARCHITECTURE NOTES #22 / 50 - Reporting and auditability

How auditable are automated processes?

Public reference: ETSI - Zero-touch network & Service Management, GS ZSM 009-1 (closed-loop governance and supervision) (https://lnkd.in/gJfRvWmi)

Why it matters

Automation that cannot show its work is automation few teams will fully trust. ETSI's ZSM closed-loop automation work defines governance and supervision of closed loops - including how their actions are tracked and reviewed - with step-by-step reporting as a built-in output rather than an afterthought.

Good reporting is exactly what lets a cautious operations team hand more and more work to automation with confidence: a clear, reviewable record of what was done, what was checked, and what the results were. It also supports compliance review. Worth probing: whether detailed reports are generated automatically per step, whether a complete audit trail exists, and whether reports can be exported for compliance purposes.

Auditability extends to AI/ML decisions. When a learned function acts, operators need a record of what it did and why, so model-driven steps should be reported and retained like any other. Explainable, logged AI/ML actions are what let teams trust autonomy over time.

What I think matters for SMO platforms

• Are detailed reports generated automatically per step?
• Is a complete audit trail available?
• Can reports be exported for compliance?
• Are reports retained and searchable over time?
• Are AI/ML-driven actions logged and explainable in reports?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Self-healing

Janos Korognai · July 28, 2026

SMO ARCHITECTURE NOTES #23 / 50 - Self-healing

How are closed-loop self-healing functions realised?

Public reference: O-RAN ALLIANCE - White papers & resources (Non-RT RIC) (https://lnkd.in/gewWiV_5)

Why it matters

The goal is not a network that never has problems, but one that corrects most of them itself before they become customer-affecting. O-RAN Non-RT RIC material describes closed-loop control — observe, decide, act and verify — running continuously under defined policy.

Self-healing is where automation stops merely saving time and starts protecting customer experience directly. But autonomous recovery also introduces risk. Operators need to know which loops can act autonomously, what policies and guardrails constrain them, whether a loop can be paused or overridden, and how stability is assured so automation does not oscillate or overcorrect.

AI/ML can make these loops more adaptive by informing detection and recovery decisions. As more decision logic becomes learned rather than explicitly programmed, policy boundaries, validation, monitoring and human oversight become even more important.

What I think matters for SMO platforms

• Which closed loops operate autonomously?
• How are policies and guardrails defined?
• How is loop stability assured?
• Can an operator pause or override a loop when needed?
• Are AI/ML-driven healing decisions bounded by policy and override?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Optimisation applications

Janos Korognai · July 29, 2026

SMO ARCHITECTURE NOTES #24 / 50 - Optimisation applications

How is continuous RAN optimisation delivered?

Public reference: O-RAN ALLIANCE - Specifications (rApps / optimization) (https://lnkd.in/gQNV_Sni)

Why it matters

A network that is optimal at noon is rarely optimal at midnight, so static tuning leaves performance on the table. O-RAN’s rApp model enables optimization applications that use network data to support decisions as conditions such as traffic, mobility and interference change.

An open rApp environment also gives operators the ability to introduce first- and third-party optimization logic rather than relying only on capabilities supplied by the platform vendor. The useful questions are which optimization functions adapt to changing conditions, whether third-party rApps are supported, how objectives reflect operator intent, and how competing goals such as capacity, quality and energy efficiency are balanced.

AI/ML can take this further. AI/ML-enabled rApps can use network data to identify patterns, predict conditions and recommend or trigger optimization actions. The important questions then include how models are governed, validated and updated, and whether third-party AI/ML-enabled rApps can participate under the same platform controls.

What I think matters for SMO platforms

• Which optimisation functions adapt continuously?
• Can third-party optimisation logic run on the platform?
• How are optimisation objectives configured?
• How are competing optimisation goals balanced?
• Can third-party AI/ML optimisation models run on the platform?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

RAN sharing independence

Janos Korognai · July 30, 2026

SMO ARCHITECTURE NOTES #25 / 50 - RAN sharing independence

How is independent control supported in shared networks?

Public reference: 3GPP - Standards organization (RAN sharing) (https://www.3gpp.org)

Why it matters

When two operators share one network, each still wants to feel like it is theirs. 3GPP defines RAN sharing arrangements such as MORAN and MOCN, and public standards point toward interfaces and isolation that let each party manage its own resources independently within shared infrastructure.

Network sharing only works when independence is real, and the management layer is where that independence is won or lost. The useful questions are which interfaces and isolation mechanisms support independent control, whether one party’s actions can affect another’s, what security boundaries apply, and how shared resources are allocated and accounted for. Fairness and visibility are important parts of making the arrangement work in practice.

What I think matters for SMO platforms

• What interfaces and isolation support independent control?
• Can one party's changes affect another's?
• What security boundaries apply?
• How are shared resources allocated and accounted for?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Cross-party conflict

Janos Korognai · July 31, 2026

SMO ARCHITECTURE NOTES #26 / 50 - Cross-party conflict

How are conflicting actions avoided in shared environments?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

Shared infrastructure plus shared automation is a recipe for two parties quietly undoing each other’s work. With multiple autonomous functions acting on shared resources, public O-RAN discussion of conflict mitigation becomes directly relevant: detecting and resolving collisions before they degrade performance.

In shared networks, conflict management is not a nice-to-have; it is part of what keeps the arrangement working. The questions worth asking are how conflicting actions are detected in shared scenarios, how they are resolved under agreed rules, and whether shared applications are themselves conflict-aware so that one party’s optimisation never silently undermines another’s.

AI/ML makes this harder and more necessary at once. When multiple parties run learned optimisation on shared resources, their model-driven actions can interact in ways neither party anticipated. Conflict-aware design that accounts for AI/ML-driven actions, under agreed rules, becomes increasingly important as network automation moves toward greater autonomy.

What I think matters for SMO platforms

• How are conflicting actions detected in shared scenarios?
• How are they resolved?
• Are shared applications conflict-aware?
• How are resolution rules agreed between parties?
• Are AI/ML-driven actions from multiple parties accounted for?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Energy efficiency

Janos Korognai · August 3, 2026

SMO ARCHITECTURE NOTES #27 / 50 - Energy efficiency

How is energy efficiency optimised?

Public reference: GSMA - Industry association (network energy efficiency) (https://www.gsma.com)

Why it matters

Energy is now one of the largest line items in running a network, and one of the most automatable. GSMA and broader industry work document network energy efficiency as a major operational and sustainability lever, with demand-adaptive power management combined with performance safeguards.

Energy optimisation is where sustainability goals and cost discipline point in the same direction: adjust the network to real demand, power down where it is safe, and restore capacity where it is needed, all under closed-loop control. The relevant questions are which energy-saving functions are available, how performance safeguards are applied so savings do not harm experience, and what efficiency gains are documented in public sources.

Energy optimisation is increasingly model-driven, with AI/ML predicting demand and helping shape power decisions. The important part is keeping those decisions bounded by performance safeguards. A platform that supports closed-loop, reversible energy optimisation while protecting service performance reflects where autonomous network operations are heading.

What I think matters for SMO platforms

• Which energy-saving functions are available?
• How are performance safeguards applied?
• What efficiency gains are documented publicly?
• Is energy optimisation closed-loop and reversible?
• Is AI/ML-driven energy optimisation bounded by performance safeguards?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Local autonomy

Janos Korognai · August 4, 2026

SMO ARCHITECTURE NOTES #28 / 50 - Local autonomy

How do control loops handle dependency interruptions?

Public reference: ETSI - Zero-touch network & Service Management (ISG ZSM) (https://lnkd.in/gJfRvWmi)

Why it matters

A control loop that depends on a perfect, always-on connection is not one to stake a network on. Resilient automation requires control loops to handle dependency interruptions predictably, maintaining sufficient state and recovering cleanly when dependencies return.

The maturity of an automation platform shows in how gracefully it handles the moments when something it relies on is unavailable. Resilience built into the architecture - rather than assumed away - is what makes closed-loop control trustworthy in production. It is fair to ask whether loops can operate through short dependency outages, how much local state they retain, and how reconciliation is handled afterward.

When closed loops incorporate AI/ML, dependency management becomes even more important. The architecture should define what happens when an external data source, model service or other dependency becomes unavailable, including whether the loop can continue operating locally, degrade gracefully, or fall back to a safe operating state.

What I think matters for SMO platforms

• Can loops operate through short dependency outages?
• How much local state is retained?
• How is reconciliation handled afterwards?
• What is the maximum tolerated interruption before degradation?
• Can AI/ML inference continue locally through short interruptions?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Slice data model

Janos Korognai · August 5, 2026

SMO ARCHITECTURE NOTES #29 / 50 - Slice data model

Which standards govern the slice data model?

Public reference: 3GPP - Standards organization (network slicing) (https://www.3gpp.org)

Why it matters

A slice model that only one vendor understands is not really a slice model; it is a dependency. 3GPP, GSMA and ETSI provide specifications and frameworks relevant to network slicing, pointing toward standards-aligned, portable slice definitions rather than proprietary ones.

Standards compliance in slicing is what separates a future-proof investment from a clever dead end, because portable slices can interwork across a multi-vendor environment. The questions worth asking are which slicing standards a platform conforms to, whether the slice model is portable across vendors, and how any deviations from the standard model are documented.

What I think matters for SMO platforms

• Which slicing standards are supported?
• Is the slice model portable across vendors?
• How are deviations documented?
• Is the model aligned to current standard releases?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Modular slicing architecture

Janos Korognai · August 6, 2026

SMO ARCHITECTURE NOTES #30 / 50 - Modular slicing architecture

How modular is the slicing architecture?

Public reference: 3GPP - Standards organization (slice management roles) (https://www.3gpp.org)

Why it matters

Slicing locks up quickly when management functions are fused into one monolithic block. 3GPP defines distinct slice-management roles such as CSMF, NSMF and NSSMF, and a modular implementation with standard interfaces between them supports incremental adoption.

Modularity is what lets slicing grow with an operator instead of forcing a big-bang commitment, and it allows the pieces to slot into existing orchestration. Reasonable questions are which slice-management roles are implemented as separate components, whether those components can integrate with the operator’s existing orchestration, and whether the interfaces between them are standards-based rather than proprietary.

What I think matters for SMO platforms

• Which slice-management roles are implemented as separate components?
• Can components integrate with existing orchestration?
• Are the interfaces standards-based?
• Can roles be adopted independently and incrementally?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Slice lifecycle

Janos Korognai · August 7, 2026

SMO ARCHITECTURE NOTES #31 / 50 - Slice lifecycle

How is the full slice lifecycle managed?

Public reference: GSMA - Industry association (slice templates) (https://www.gsma.com)

Why it matters

Creating a slice is the demo; managing it through its whole life is the product. Public frameworks from 3GPP and GSMA describe creation, modification, monitoring, assurance and decommissioning as a coherent, automated flow rather than a one-time configuration.

The value of slicing is realised over the slice’s lifetime, which is exactly where lifecycle management earns its keep. Slices become living, managed entities with assurance built in. The useful questions are whether the full lifecycle is automated, whether assurance is part of the flow rather than bolted on, and which standard interfaces the lifecycle operations use.

Slice assurance is increasingly AI/ML-assisted, with models detecting SLA risk and triggering action across the lifecycle. A platform whose lifecycle exposes the data and hooks such models need supports closed-loop, intelligent slice management rather than static configuration.

What I think matters for SMO platforms

• Is the full slice lifecycle automated?
• Is assurance built in?
• Which standard interfaces are used?
• How are slice modifications handled without disruption?
• Can AI/ML-based assurance act across the slice lifecycle?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Independent RAN slicing

Janos Korognai · August 10, 2026

SMO ARCHITECTURE NOTES #32 / 50 - Independent RAN slicing

Can RAN slice management be deployed independently?

Public reference: O-RAN ALLIANCE - Specifications (RAN slice management) (https://lnkd.in/gQNV_Sni)

Why it matters

Operators may want to manage the radio part of a slice without waiting for full end-to-end orchestration. O-RAN specifications address RAN slice management as a distinct management capability, with standardized interfaces supporting integration into the broader management and orchestration environment.

This gives operators a path to adopt slicing progressively rather than treating it as an all-or-nothing transformation. The useful questions are whether RAN slice management can operate independently, which dependencies remain, and whether its interfaces allow integration with wider or third-party orchestration as the architecture evolves.

What I think matters for SMO platforms

• Can the RAN slice function deploy standalone?
• Are interfaces open for later integration?
• What dependencies exist?
• Can it interwork with a third-party end-to-end orchestrator?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Third-party integration

Janos Korognai · August 11, 2026

SMO ARCHITECTURE NOTES #33 / 50 - Third-party integration

How well does slicing integrate with third parties?

Public reference: 3GPP - Standards organization (slicing APIs) (https://www.3gpp.org)

Why it matters

No operator wants its slicing future dictated by a single vendor’s roadmap. 3GPP specifications define standardized capabilities and interfaces relevant to network slicing, providing a foundation for integration across multi-vendor environments and external orchestration.

Open integration is the difference between a slicing solution and a slicing silo. The questions worth asking are whether standards-based APIs are exposed for external orchestrators, whether interoperability with other vendors has actually been demonstrated, and which specific standard interfaces and APIs the platform supports.

What I think matters for SMO platforms

• Are standards-based APIs exposed for external orchestrators?
• Is interoperability with other vendors demonstrated?
• Which standard APIs are supported?
• Can third-party network elements participate in a slice?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Application packaging

Janos Korognai · August 12, 2026

SMO ARCHITECTURE NOTES #34 / 50 - Application packaging

What package format do applications use?

Public reference: O-RAN ALLIANCE - Specifications (rApp package format) (https://lnkd.in/gQNV_Sni)

Why it matters

If onboarding an application means a custom project every time, the ecosystem never scales. O-RAN defines application packaging and onboarding mechanisms intended to make deployment more consistent across applications and implementations.

Standard packaging is the foundation of a real application ecosystem; without it, every integration risks becoming a one-off. A platform that adopts a documented format and onboarding process makes it easier for first- and third-party applications to be introduced consistently. The useful questions are whether the packaging and onboarding mechanisms follow O-RAN specifications, how well they are documented, and whether third-party applications are genuinely supported.

For AI/ML-enabled rApps, this becomes even more important. Applications may introduce additional model artifacts, data dependencies and lifecycle requirements. A mature platform needs an onboarding approach that can accommodate these requirements without turning every AI-enabled rApp into a custom integration project.

What I think matters for SMO platforms

• Is a standard package format used?
• Is the format specification published?
• Does it support third-party applications?
• Are all package components fully specified?
• Does the package format accommodate AI/ML model artifacts and dependencies?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Onboarding chain

Janos Korognai · August 13, 2026

SMO ARCHITECTURE NOTES #35 / 50 - Onboarding chain

How open is the application onboarding chain?

Public reference: O-RAN ALLIANCE - Specifications (onboarding) (https://lnkd.in/gQNV_Sni)

Why it matters

A closed onboarding process quietly tells third-party developers they are not really welcome. O-RAN material describes application onboarding mechanisms, and openly specified processes lower the barrier for outside developers to participate.

Openness is not a marketing claim; it is measured by how easy a platform makes it for someone else’s application to run on it. The useful questions are whether the onboarding process is publicly specified, whether third parties can onboard without a bespoke integration project each time, and what validation and approval steps are required along the way.

For AI/ML-enabled rApps, onboarding can introduce additional requirements around model artifacts, dependencies and validation. A well-defined onboarding process should accommodate these requirements without making third-party AI/ML applications a special integration project.

What I think matters for SMO platforms

• Is the onboarding chain fully specified publicly?
• Can third parties onboard without bespoke projects?
• What approvals are required?
• Is the onboarding process the same for first- and third-party apps?
• Does onboarding handle AI/ML model provenance and lifecycle?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Validation transparency

Janos Korognai · August 14, 2026

SMO ARCHITECTURE NOTES #36 / 50 - Validation transparency

How transparent are onboarding validation tests?

Public reference: O-RAN ALLIANCE - White papers & resources (https://lnkd.in/gewWiV_5)

Why it matters

Developers cannot build to a standard they are not allowed to see. Public documentation of the validation tests an application must pass makes onboarding predictable and fair, letting developers build to those requirements rather than discover failures late.

Transparent validation criteria turn onboarding from a black box into a clear, buildable contract. A platform that documents its validation requirements and lets developers test against them beforehand gives third parties a predictable path to onboarding. The useful questions are whether validation tests are documented, whether developers can test against them in advance, how results are reported, and whether the same criteria apply consistently to first- and third-party applications.

What I think matters for SMO platforms

• Are validation tests documented?
• Can developers test against them beforehand?
• How are results reported?
• Is the same validation applied to all suppliers equally?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Application ecosystem

Janos Korognai · August 17, 2026

SMO ARCHITECTURE NOTES #37 / 50 - Application ecosystem

How open is the application ecosystem?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

The most valuable application on a platform might be one its vendor never wrote. O-RAN’s model enables a multi-supplier application ecosystem, where open interfaces and documented onboarding can let operators source best-of-breed applications rather than being confined to a single vendor’s catalogue.

The platforms that thrive will be the ones that make room for everyone else’s innovation, not just their own. The relevant questions are whether applications can genuinely come from multiple suppliers, what concretely enables third-party participation, and whether there is a catalogue or marketplace model that makes discovery and adoption practical.

AI/ML makes that ecosystem potentially even more valuable. Innovation in analytics, optimization and automation does not have to come from the SMO platform vendor itself. An open rApp ecosystem can give operators a path to introduce third-party AI/ML capabilities while retaining common platform governance, onboarding and lifecycle controls.

What I think matters for SMO platforms

• Can applications come from multiple suppliers?
• What enables third-party participation?
• Is there a marketplace or catalogue model?
• Are third-party apps treated as first-class citizens?
• Are third-party AI/ML models supported with proper workflow services?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Onboarding visibility

Janos Korognai · August 18, 2026

SMO ARCHITECTURE NOTES #38 / 50 - Onboarding visibility

How visible is onboarding progress?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

Whether an application is onboarded should not be a question anyone has to chase. Surfacing onboarding and validation status in the interface is a usability consideration that makes day-to-day operations smoother and the platform more trustworthy.

Visibility into onboarding makes a real operational difference: operators should know exactly where an application is in the process and what, if anything, needs attention. The questions worth asking are whether onboarding progress and validation stages are visible, how issues are surfaced when they arise, and whether status is also available through APIs so it can be integrated into the operator’s own tooling and automation.

What I think matters for SMO platforms

• Is onboarding progress visible in the interface?
• Are validation stages shown?
• How are issues surfaced?
• Is status available through an API as well as the UI?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Application portability

Janos Korognai · August 19, 2026

SMO ARCHITECTURE NOTES #39 / 50 - Application portability

How portable are applications across platforms?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

An application that cannot move is one that quietly locks an operator in. Standard packaging and interfaces can support portability across compliant platforms, reducing dependency on a single implementation.

Portability is one of the strongest tests of openness. The useful questions are whether applications are portable across compliant platforms in practice and not just in principle, what standards underpin that portability, and what switching costs realistically remain.

AI/ML-enabled rApps make the portability question more complex. Beyond the application itself, models may depend on specific data, runtime environments and supporting services. The practical test is therefore not only whether an rApp can move, but how much adaptation is required before its AI/ML capabilities operate correctly in another compliant environment.

What I think matters for SMO platforms

• Are applications portable across compliant platforms?
• What standards underpin portability?
• What switching costs remain?
• Has portability been demonstrated in practice?
• Are AI/ML rApps portable across compliant platforms in practice?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Why conflict management matters

Janos Korognai · August 20, 2026

SMO ARCHITECTURE NOTES #40 / 50 - Why conflict management matters

Why does conflict management matter as autonomy grows?

Public reference: O-RAN ALLIANCE - White papers & resources (Non-RT RIC) (https://lnkd.in/gewWiV_5)

Why it matters

Put enough automated decision-makers on one network and, eventually, they can start working against each other. O-RAN material addresses conflict mitigation because the value of multiple autonomous functions depends on keeping their actions coordinated.

The more automation an operator adds, the more conflict management matters; it becomes an important governance mechanism for safe autonomy. The questions worth asking are whether conflict management is treated as a first-class capability, which conflict types are addressed, how the approach scales as more applications are introduced, and whether it works consistently across traditional and cloud-based RAN environments.

AI/ML raises the stakes further. When multiple learned or AI-assisted functions act on the same network, their combined behaviour may be harder to anticipate than independently designed rules suggest. Detecting conflicting actions, applying policies and coordinating remediation therefore become increasingly important as networks move toward higher levels of autonomy.

What I think matters for SMO platforms

• Is conflict management a first-class capability?
• Which conflict types are addressed?
• How does it scale as more applications are added?
• Is it applicable across both traditional and cloud RAN?
• Does conflict management account for multiple AI/ML-driven functions?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Detecting direct conflicts

Janos Korognai · August 21, 2026

SMO ARCHITECTURE NOTES #41 / 50 - Detecting direct conflicts

How are direct conflicts detected?

Public reference: O-RAN ALLIANCE - Specifications (conflict mitigation) (https://lnkd.in/gQNV_Sni)

Why it matters

The most dangerous conflicts are the ones nobody notices until performance has already slipped. Public O-RAN material addresses direct conflicts, where multiple applications or control functions attempt incompatible actions on the same network resources.

You cannot manage a conflict you cannot see, so detection is the first step. The useful questions are whether direct conflicts can be detected across applications and external systems, which network environments are covered, how detections are surfaced to operators, and how quickly a conflict can be identified before it affects service performance.

What I think matters for SMO platforms

• Are direct conflicts detected, including with external systems?
• Which network types are covered?
• How are detections surfaced?
• How quickly are conflicts detected after they arise?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Resolving conflicts

Janos Korognai · August 24, 2026

SMO ARCHITECTURE NOTES #42 / 50 - Resolving conflicts

How are conflicts resolved?

Public reference: O-RAN ALLIANCE - Specifications (conflict mitigation) (https://lnkd.in/gQNV_Sni)

Why it matters

Detecting a conflict is half the job; resolving it cleanly is the half that actually protects the network. Public conflict-mitigation discussion pairs detection with resolution for both direct and the subtler indirect conflicts, applied under clear and predictable rules.

Resolution is where conflict management proves its worth: detection warns you, but resolution keeps the network healthy by reconciling competing actions rather than letting them fight it out in production. The relevant questions are whether both direct and indirect conflicts are resolved, what rules govern resolution, and whether that resolution is automated or requires manual intervention.

With AI/ML in the mix, resolution rules and operator override matter even more, because the conflicting actions may come from models whose reasoning is not transparent. Clear, predictable resolution policy that operators can set is what keeps learned behaviour from being fought out unsupervised in production.

What I think matters for SMO platforms

• Are both direct and indirect conflicts resolved?
• What rules govern resolution?
• Is resolution automated?
• Can operators define or override resolution policy?
• Can operators set resolution policy over AI/ML-driven actions?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

External-system conflicts

Janos Korognai · August 25, 2026

SMO ARCHITECTURE NOTES #43 / 50 - External-system conflicts

How are conflicts with external systems handled?

Public reference: O-RAN ALLIANCE - Specifications portal (https://lnkd.in/gQNV_Sni)

Why it matters

Automation does not live alone, and the systems next door do not always play nicely. Real environments mix tools that all touch the same configuration, so public discussion notes that conflict handling ideally extends beyond a platform's own applications to neighbouring external systems.

Conflict management that stops at the platform's edge is not enough, because the real world does not respect those boundaries. A platform that detects and resolves conflicts with external applications acknowledges that the operator's environment is heterogeneous and behaves like a good neighbour in it. Worth asking: whether conflict handling includes external applications, how boundaries are defined, and what coordination mechanisms exist across them.

What I think matters for SMO platforms

• Does conflict handling include external applications?
• How are boundaries defined?
• What coordination mechanisms exist?
• How are external systems made known to the platform?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Component hardening

Janos Korognai · August 26, 2026

SMO ARCHITECTURE NOTES #44 / 50 - Component hardening

How is component hardening evidenced?

Public reference: CIS - Center for Internet Security Benchmarks (https://lnkd.in/gZMm2MJy)

Why it matters

In security, trust us is the least convincing thing a vendor can say. CIS Benchmarks provide public, recognised hardening baselines for databases, web servers and other components, and evidence against them substantiates security claims objectively.

Benchmarked, evidenced hardening is how a platform earns security trust; everything else is words. A vendor that runs its components against established baselines and shares the results turns security from an assertion into a verifiable position. The useful questions are whether components are benchmarked against public baselines, whether the results are available for review, and how often hardening is re-assessed as components change.

What I think matters for SMO platforms

• Are components benchmarked against public baselines?
• Are the results available?
• How often is hardening re-assessed?
• Which baseline versions are used?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Zero-trust access

Janos Korognai · August 27, 2026

SMO ARCHITECTURE NOTES #45 / 50 - Zero-trust access

How is access control designed?

Public reference: NIST SP 800-207 - Zero Trust Architecture (https://lnkd.in/g4qXk5kX)

Why it matters

The old model of a trusted internal network faded the day everything became interconnected. NIST SP 800-207 defines zero-trust principles: authenticate and authorise every access, every time, with no implicit trust granted on the basis of network location.

Zero trust is not a buzzword; public guidance frames it as the baseline expectation for any platform touching critical infrastructure. Access is granted on verified identity and permission rather than assumed from where a request originates. It is fair to ask whether access control is built on zero-trust principles, whether every service interaction is authenticated and authorised, and how identity is verified across components.

AI/ML adds attack surface - model endpoints, training data and pipelines - so zero-trust principles extend to them. Authenticating and authorising access to model services, and protecting the data that feeds them, is part of securing an AI-enabled SMO rather than an afterthought once models are in production.

What I think matters for SMO platforms

• Is access control based on zero-trust principles?
• Is every service interaction authenticated and authorised?
• How is identity verified?
• Is least-privilege enforced across components?
• Do zero-trust controls extend to AI/ML model and data services?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Supply-chain integrity

Janos Korognai · August 28, 2026

SMO ARCHITECTURE NOTES #46 / 50 - Supply-chain integrity

How is artifact and supply-chain integrity assured?

Public reference: Cloud Native Computing Foundation (CNCF) - software supply chain (https://www.cncf.io)
Why it matters

The configuration you deploy is only as trustworthy as the path it travelled to get there. Public guidance from NIST and CNCF software supply-chain practice calls for integrity and provenance across artifacts such as images, configurations and credentials.

Supply-chain integrity has moved from a niche concern to a board-level one, and operators increasingly expect it handled by design. A platform that applies integrity protection and provenance controls across the artifact lifecycle gives assurance that what runs is exactly what was intended, unaltered. The questions worth asking are whether artifacts are integrity-protected end to end, whether provenance is verifiable, and how tampering is detected.

AI/ML expands what supply-chain integrity must cover: model artifacts, training-data lineage and dependencies all need provenance. Public guidance on software supply chains applies to models too. A platform that can attest to where a model came from, and that it has not been tampered with, treats AI/ML as part of the trusted boundary.

What I think matters for SMO platforms

• Are artifacts integrity-protected end to end?
• Is provenance verifiable?
• How is tampering detected?
• Are software bills of materials provided?
• Does supply-chain integrity extend to AI/ML models and training data?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Compliance and auditability

Janos Korognai · August 31, 2026

SMO ARCHITECTURE NOTES #47 / 50 - Compliance and auditability

How auditable is the security posture?

Public reference: CIS - Center for Internet Security Benchmarks (https://lnkd.in/gZMm2MJy)

Why it matters

When the auditor arrives, we are confident it is secure is not an acceptable answer. Auditability - inspectable controls, reviewable logs and presentable evidence - lets an operator demonstrate compliance to regulators and its own risk teams rather than merely claim it.

Auditability is security made accountable, and it is what lets an operator stand behind a platform to everyone it answers to. Public benchmarks and frameworks support this kind of evidence-based posture. It is reasonable to ask whether controls and logs are inspectable, whether evidence is available for auditors and regulators, and which recognised frameworks the platform's controls are mapped to.

What I think matters for SMO platforms

• Are controls and logs inspectable?
• Is evidence available for auditors and regulators?
• Which frameworks are mapped?
• How long are audit logs retained?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Multi-vendor interoperability

Janos Korognai · September 1, 2026

SMO ARCHITECTURE NOTES #48 / 50 - Multi-vendor interoperability

How is multi-vendor interoperability achieved?

Public reference: O-RAN ALLIANCE - Specifications (open interfaces) (https://lnkd.in/gQNV_Sni)

Why it matters

No operator builds a single-vendor network anymore, so the SMO has to thrive in a crowd. Open, standardised interfaces from O-RAN and the broader ecosystem are what enable interoperability across vendors rather than a platform that works best only with its own vendor's equipment.

In a multi-vendor world, interoperability is not a feature to charge for; it is the price of entry. A platform that commits to open, standardised interfaces throughout, and can demonstrate genuine interoperability, adds value across the operator's whole estate. The useful questions are whether interfaces are open and standards-based throughout, whether interoperability is demonstrated across vendors, and which standards the platform conforms to.

What I think matters for SMO platforms

• Are interfaces open and standards-based throughout?
• Is interoperability demonstrated across vendors?
• Which standards are conformed to?
• Is conformance verified through public testing or plugfests?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Total cost and lock-in

Janos Korognai · September 2, 2026

SMO ARCHITECTURE NOTES #49 / 50 - Total cost and lock-in

How should total cost of ownership and lock-in be assessed?

Public reference: TM Forum - Open Digital Architecture (avoiding lock-in) (https://lnkd.in/ghijY2aG)

Why it matters

The cheapest platform on the slide can be the most expensive one to live with. Public service-management frameworks such as TM Forum ODA emphasise open data, self-service and portability as the practical ways to limit the cost of lock-in over a platform's life.

The lowest sticker price and the lowest total cost of ownership are rarely the same product, because proprietary dependencies, data-retention constraints and per-change service requests add up over years. Smart evaluation prices in lock-in. The questions worth asking are what proprietary dependencies create switching cost, whether data, applications and interfaces are portable, and how predictable ongoing operational costs really are.

What I think matters for SMO platforms

• What proprietary dependencies create switching cost?
• Are data, applications and interfaces portable?
• How predictable are ongoing operational costs?
• What would it take to migrate away from the platform?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

A public-standards evaluation lens

Janos Korognai · September 3, 2026

SMO ARCHITECTURE NOTES #50 / 50 - A public-standards evaluation lens

What public-standards lens helps in evaluating an SMO platform?

Public reference: O-RAN ALLIANCE - Industry association (https://www.o-ran.org)

Why it matters

After forty-nine questions, a pattern emerges. Across openness, automation, slicing, conflict management and security, public frameworks from O-RAN, 3GPP, GSMA, TM Forum, ETSI, NIST and CIS keep pointing to the same handful of criteria: openness, standardisation, transparency and operator control.

Based on publicly available frameworks, these criteria offer a consistent lens for structuring an objective evaluation independent of any single vendor's narrative. The best SMO is not the one with the longest feature list, but the one that makes the operator more capable, more independent and more in control. The closing questions are whether a platform favours open interfaces and open data, whether its security is evidenced against public benchmarks, and whether the operator retains control and portability.

AI/ML runs through this whole lens. The Non-RT RIC, rApps and the autonomy levels operators are targeting are increasingly model-driven, so openness to third-party models, transparency of model behaviour and control over learned actions are now part of judging any SMO. The same criteria - open, standardised, transparent, operator-controlled - apply to a platform's AI/ML as much as to its interfaces.

What I think matters for SMO platforms

• Does the platform favour open interfaces and open data?
• Is security evidenced against public benchmarks?
• Does the operator retain control and portability?
• Does it align with published standards rather than proprietary equivalents?
• Is the platform's AI/ML open, transparent and operator-controlled?
#SMO
#OpenRAN
#ServiceManagementOrchestration
#NetworkAutomation
#Telecom
#5G
#Standards

SMO Architecture Notes

Conclusion: The one thing all fifty questions were really asking

Janos Korognai · September 4, 2026

That's 50. Here's the one thing all fifty questions were really asking.

Over the past weeks I've posted 50 design questions on SMO and Open RAN - each grounded in a public reference from the O-RAN ALLIANCE, 3GPP, GSMA, TM Forum, ETSI, NIST or CIS. Fifty questions, fifty sources, one independent lens.

All 50 questions are now collected in the “50 Design Questions” tab of my interactive SMO demo, with each question linked directly to the relevant part of the platform:
https://smo.korognai.net

Reading back across all of them, the same thread runs through every one. Strip away the specifics - data exposure, closed loops, slicing, conflict management, supply-chain integrity, AI/ML governance - and each question is really testing the same four things:

Openness. Standardisation. Transparency. Operator control.

That's the whole series in four words. Call it a stance. In my view the best SMO platform is the one that leaves the operator more capable, more independent and more in control of their own network and their own data. Capability lists rarely decide that.

And that lens only gets sharper as autonomy arrives. The Non-RT RIC, rApps and the autonomy levels operators are targeting are increasingly model-driven - so openness to third-party models, transparency of model behaviour and control over learned actions are now part of judging any platform. The four criteria don't change. They just extend to the AI too.

The point of doing this in public, against published standards, was to make vendor evaluation an objective exercise anyone can run for themselves. The questions are yours to use now.

I wrote this series because the topic matters, whether or not it trends. If it helps even one operator walk into a vendor conversation with a sharper question to ask - or one vendor build a better product because those questions are being asked - it did its job.
#SMO
#OpenRAN
#AutonomousNetworks
#ServiceManagementOrchestration
#Telecom
#5G
#Standards

SMO Vendor Series

#1 · Before Choosing a Vendor — What an SMO Is Really For

Janos Korognai · September 8, 2026

SMO Vendor Series #1: Before Choosing a Vendor - What an SMO Is Really For

An SMO purchase looks like a software-procurement exercise. What it actually settles is who - or what - will operate the RAN for years.

Operators are offered SMOs as the control layer for a more open, cloud-native, autonomous RAN. The architecture is attractive: standardized interfaces, a Non-RT RIC, rApps, policy control, O-Cloud orchestration and closed-loop automation.

An architecture diagram, on its own, changes no operating cost, no customer experience and no rollout schedule. Those outcomes appear when the platform turns fragmented network data into trusted decisions and executes them safely across a real brownfield network.

The first question worth settling is which operating model you want to run for the next decade. Vendor comparison follows from that answer.

An operator protecting a large legacy RAN will value coexistence, mature network management and proven SON. One building a cloud-native network may prioritize O-Cloud lifecycle, CI/CD, observability and vendor-independent onboarding. A third may care most about cross-domain orchestration, or about building its own rApps.

Before comparing vendors, I'd define six measurable ambitions:

● How much manual work should disappear from Day 0, 1 and 2 operations?
● Which optimization decisions can be closed-loop, and which stay human-approved?
● How many RAN vendors, generations and deployment models must be managed together?
● Who owns the data models, policies, AI models and automation apps?
● How will failures, conflicting rApps and unsafe recommendations be caught and reversed?
● Which business KPI - energy, rollout speed, utilization, MTTR or SLA - will prove value?

The majors answer these from different starting points. Nokia builds from deep RAN management and SON. Ericsson builds from an industrialized automation platform and rApp ecosystem now reaching into the core. Samsung ties SMO to large-scale vRAN. Rakuten Symphony builds from cloud-native OSS simplification. Amdocs builds from service orchestration and multi-vendor integration.

Supplier durability now belongs on the same scorecard. In the past year, two of the most-cited independent SMO/RIC efforts dropped out of the standalone field - one licensed into a competitor, one left uncertain under new ownership. Post 7 covers both.

The heritage a platform carries is the real variable. The risk is choosing one whose design centre pulls against the transformation you actually want.

The strongest SMO business case is unglamorous: a controlled migration from fragmented tools and manual procedures toward repeatable, measurable, increasingly autonomous operations.

Over the next posts, I'll take each major platform in turn - where it is most compelling, and what to validate before a long-term commitment.

#SMO #OpenRAN #RANAutomation #AutonomousNetworks #Telecom #NetworkOperations

SMO Vendor Series

#2 · Nokia MantaRay SMO

Janos Korognai · September 9, 2026

SMO Vendor Series #2: Why an Operator Might Choose Nokia MantaRay SMO

Nokia MantaRay SMO is most compelling for the operator evolving a large, complex RAN with no illusion the brownfield network can be swapped out overnight.

Nokia's advantage begins with operational heritage. MantaRay combines network management, SON, orchestration, Non-RT RIC functionality and rApps in a portfolio built for purpose-built RAN, Cloud RAN and multi-supplier environments.

Most operators are not starting from a clean Open RAN slate. They carry multiple radio generations, historical parameter models, existing SON investments, vendor-specific workflows and years of operational knowledge embedded in their OSS. MantaRay's strongest draw is evolutionary continuity: pursue O-RAN-aligned automation while keeping control of the network you already own.

Where it fits well:

● A large brownfield network where mature configuration, fault and performance management stay essential.
● An operator already on Nokia RAN, MantaRay Network Management (the NetAct evolution) or Nokia SON (the EdenNet evolution), wanting a lower-risk automation path.
● A multi-vendor environment where the SMO must coordinate traditional RAN and newer cloud-native domains.
● A strategy focused on energy optimization, slicing, anomaly detection and intent-based operations.
● An organization that wants vendor-supported rApps and no appetite to build an app ecosystem from scratch.

On the public record: Nokia positions MantaRay as O-RAN-aligned, with MantaRay SON providing multi-supplier Non-RT RIC functionality over the O-RAN R1 interface, and broader O-RAN interface support on the roadmap. Its intent-based MantaRay AutoPilot layer autonomously orchestrates SON modules and rApps, and Nokia detailed upgraded agentic-AI autonomous-network capabilities at DTW26 in June 2026. AutoPilot work has been advanced with operators including NTT DOCOMO.

That heritage matters. SON is one of the few areas where RAN automation has run at national scale for years, so an SMO that reuses it can reach value faster than one starting with a new platform and a small app catalog.

Diligence should reach past feature availability. How easily can third-party rApps read normalized data? Can policies span non-Nokia RAN without dropping into vendor-specific projects? How portable are the apps? What evidence exists for closed-loop operation at your scale?

Keep platform capability and autonomy claims separate. Reaching a high autonomy level for one use case is a narrower statement than running the whole RAN autonomously. The contract should name which workflows are automated, which approvals remain, and which outcomes are guaranteed.

For a large legacy estate, the case comes down to continuity: one migration path carrying traditional network management, proven SON and the emerging rApp model together.
#Nokia
#MantaRay
#SMO
#SON
#NonRTRIC
#RANAutomation
#AutonomousNetworks

SMO Vendor Series

#3 · Ericsson Intelligent Automation Platform

Janos Korognai · September 10, 2026

SMO Vendor Series #3: Why an Operator Might Choose Ericsson Intelligent Automation Platform

Ericsson EIAP is a strong candidate when the operator wants RAN automation to grow into an industrial platform, well beyond a set of isolated optimization tools.

The Ericsson Intelligent Automation Platform combines service management and orchestration, a Non-RT RIC (the Ericsson Intelligent Controller), data management and an rApp ecosystem with an open SDK. In June 2026 Ericsson extended it from RAN into 5G Core with a new class of core automation apps (cApps), positioning EIAP as one platform for RAN and core.

EIAP's central selling point is platform consistency. An operator stands up one environment for data ingestion, policy, application lifecycle, automation workflows and governance, instead of integrating every use case on its own.

EIAP is at its best for:

● An operator with a major Ericsson RAN footprint wanting tight operational integration and vendor accountability.
● A Tier-1 operator seeking a governed rApp marketplace and repeatable application onboarding.
● A network where optimization, energy efficiency, deployment automation and healing must share one data foundation.
● An operator extending automation beyond RAN to create synergies with 5G Core operations.
● An organization that prefers a large incumbent to own platform integration, support and lifecycle.

The rApp strategy is central. Rather than shipping every automation function as a platform release, EIAP gives Ericsson, partners and operators an environment to build and deploy apps. That can shorten the path from business problem to operational use case - as long as the APIs, data access and certification are genuinely open.

EIAP also draws on Ericsson's installed base and radio expertise. Automation decisions are only as good as the models behind them, and deep understanding of radio behavior, parameter dependencies and operational risk is what turns generic AI into safe network action.

The main diligence issue is openness in practice. A platform can support standard interfaces while creating dependency through proprietary data models, tooling, certification or workflows. Test whether a third-party rApp can be onboarded, trained, observed, governed and replaced without a major professional-services project.

Test EIAP in a genuinely mixed network as well. Multi-vendor support should be demonstrated against your actual vendors, software releases and use cases before it is believed.

EIAP suits operators that want a strategically important automation layer backed by a global RAN supplier, a growing app ecosystem and a common operational model. The pull is running RAN, and now core, automation as one governed software platform with lifecycle control at scale.

#Ericsson #EIAP #SMO #rApps #RANAutomation #OpenRAN #AutonomousNetworks

SMO Vendor Series

#4 · Samsung CognitiV NOS

Janos Korognai · September 11, 2026

SMO Vendor Series #4: Why an Operator Might Choose Samsung CognitiV NOS

Samsung CognitiV NOS is most compelling when the SMO is part of a wider decision to deploy and scale a cloud-native Samsung vRAN or Open RAN architecture.

Samsung positions CognitiV Network Operations Suite as an AI-powered operations portfolio with an O-RAN-compliant SMO and RIC. Its public references tie the platform to automated vRAN deployment, multi-party infrastructure and ongoing optimization - including KDDI in Japan and, in North America, TELUS in Canada. The TELUS engagement, announced in September 2025 as Canada's first commercial AI-powered RIC, delivers Samsung's RIC within CognitiV NOS, with rApps such as KPI Anomaly Detector, RAN Anomaly Insight, Energy Saving Manager and Load Balancing Manager across TELUS's vRAN and O-RAN network.

With Samsung, the draw is architectural cohesion. Operators adopting Samsung vRAN can align RAN software, cloud integration, deployment automation, management and optimization under one accountable supplier.

CognitiV NOS fits:

● An operator running a large Samsung-led vRAN rollout that needs repeatable site deployment at scale.
● A greenfield or major refresh program where cloud infrastructure and RAN lifecycle automation are designed together.
● An operator that wants O-RAN interfaces without assembling the full operational stack alone.
● A network seeking AI-assisted troubleshooting, optimization and QoS improvement integrated with the RAN.
● A buyer valuing one supplier accountable for radios, vRAN software and the automation layer.

Samsung's commercial vRAN experience matters because much of an SMO's value lands during deployment, ahead of optimization. Automating cloud onboarding, software lifecycle, configuration and thousands of site activations can build a more immediate business case than an rApp that lifts a single KPI a few percent.

So the platform appeals to operators whose central problem is industrializing a cloud-native RAN rollout. There, deployment is the pressing job, and SON replacement can wait.

The key diligence question is multi-vendor breadth. Samsung describes support for multi-party solutions and an expanded ecosystem; validate exactly which third-party RAN functions, O-Cloud platforms and existing OSS are supported in production.

Examine the boundary between open orchestration and Samsung-specific optimization. Tight integration is an advantage when you want performance and accountability, and a constraint when the goal is supplier interchangeability.

CognitiV NOS reads as part of a broader Samsung RAN transformation, where the SMO absorbs the complexity that virtualization and disaggregation introduce - making cloud-native RAN deployment and operation a single coordinated engineering system.

#SamsungNetworks #CognitiV #SMO #vRAN #OpenRAN #CloudRAN #RANAutomation

SMO Vendor Series

#5 · Rakuten Symphony Open RAN & SMO

Janos Korognai · September 14, 2026

SMO Vendor Series #5: Why an Operator Might Choose Rakuten Symphony Open RAN & SMO

Rakuten Symphony is the most provocative SMO choice because it begins from a different assumption: that the legacy OSS model itself is the constraint worth removing.

Rakuten Symphony positions its Open RAN and SMO capabilities inside a broader AI-native OSS platform that unifies monitoring, observability, assurance and closed-loop automation across disaggregated, multi-vendor networks. Public references for its OSS and observability stack include DISH (Boost Mobile) in the US and 1&1 in Germany, where Rakuten is a named technology partner in a cloud-native Open RAN build.

Its strongest pitch is architectural: a simpler operating stack, with less dependence on separate vendor-specific management silos.

Rakuten Symphony suits:

● A greenfield or digitally ambitious operator willing to redesign processes around cloud-native software.
● An Open RAN deployment where multi-vendor observability and centralized operational control are strategic.
● An operator moving from traditional SON toward programmable RIC- and rApp-driven control loops.
● A company that values web-scale automation, unified telemetry and software-driven lifecycle management.
● An organization ready to participate in transformation instead of outsourcing every operational decision to an incumbent RAN vendor.

Rakuten's credibility comes partly from operating experience. Its software grew from the effort to build and run a highly automated, disaggregated mobile network. The model does not copy directly to another operator, and it gives the platform a design centre distinct from a traditional element-management system.

The potential gain is a cleaner operational architecture: fewer fragmented tools, a common view of network health and a tighter link between observability and automation. For operators whose OSS estate has become a barrier to change, that can be powerful.

The trade-off is transformation risk. A software-led platform still leaves the hard work of data normalization, process redesign, systems integration, organizational change and cross-vendor accountability - and a software-led model tends to surface those responsibilities the operator once left to the stack.

Diligence should center on production references, supported vendor combinations, migration tooling, operational scale and the boundary between product and customization. Ask how much of Rakuten's own experience is encoded in reusable software, and how much depended on a unique organizational model.

Rakuten Symphony fits an operator that treats SMO as one move in a broader OSS reset. What it offers is a route toward running a disaggregated network as a software system - and a decision about whether the organization is ready for the commitment that comes with it.

#RakutenSymphony #SMO #OpenRAN #CloudNative #OSS #AIOps #RANAutomation

SMO Vendor Series

#6 · Amdocs Open RAN Automation

Janos Korognai · September 15, 2026

SMO Vendor Series #6: Why an Operator Might Choose Amdocs Open RAN Automation

Amdocs gets interesting for operators whose hardest SMO problem is wiring the RAN into end-to-end service operations- the layer above any single radio domain.

Amdocs positions its Open RAN Automation around analytics, service management and orchestration, closed-loop optimization, end-to-end automation and systems integration. That reflects its heritage in OSS/BSS and service orchestration; radio hardware was never its business.

Amdocs leads with neutrality at the service layer: the SMO coordinates multiple RAN suppliers while connecting network behavior to inventory, assurance, orchestration, customer intent and business services. Amdocs has taken that message public -in late 2024 it argued operators should think twice before letting a single RAN vendor also own the SMO -and has shown O-RAN management work alongside partners including Vodafone and Dell.

Amdocs is most attractive to:

● A complex operator with a large Amdocs OSS/BSS footprint needing to connect RAN automation to service workflows.
● A multi-vendor Open RAN program that needs a systems integrator to assemble and operationalize the ecosystem.
● An operator that treats SMO as one layer of end-to-end service orchestration.
● A transformation needing data, analytics, closed-loop assurance and process integration across organizational boundaries.
● A buyer seeking one party responsible for integration across RAN, cloud, transport, core and OSS.

This addresses a real limitation of radio-centric SMOs: they optimize the radio domain while the customer-facing service spans more than radio. A service-impacting problem may involve RAN congestion, transport degradation, cloud pressure and core behavior together, and protecting an SLA takes context that a radio-only view cannot supply.

Amdocs can also help where an operator lacks the internal capacity to integrate a disaggregated ecosystem; there the integration capability can matter as much as the SMO software. The stance is self-interested for a neutral integrator and still defensible.

The main diligence question is productization. Identify which capabilities are standard platform functions, which are reusable accelerators and which arrive as custom integration. A solution that looks flexible gets expensive when every use case becomes a project.

Define architectural boundaries early. Amdocs may coexist with vendor-specific RAN managers, SON platforms, RICs and cloud orchestrators and without clear ownership those layers duplicate policy and produce conflicting automation.

Amdocs fits an operator that treats the SMO as the RAN component of a broader autonomous-service architecture and wants a neutral integrator to connect the domains-putting RAN automation inside the wider service and business picture a radio-centric SMO cannot see.

#Amdocs #SMO #OpenRAN #ServiceOrchestration #OSS #ClosedLoopAutomation #AutonomousNetworks

SMO Vendor Series

#7 · Consolidation, Exits and Open Source

Janos Korognai · September 16, 2026

SMO Vendor Series #7: The SMO Field Just Narrowed - Consolidation, Exits and Open Source

Not every company that positioned an SMO or RIC two years ago is still selling one. The past year thinned the field - a due-diligence signal in itself: this early, supplier durability weighs as much as any feature.

Juniper - now inside Nokia. Juniper built a credible, standards-led O-RAN SMO from Beyond Labs, with its own RIC and O-Cloud orchestration, trialled at Deutsche Telekom and Vodafone. HPE completed its ~$14B acquisition of Juniper in July 2025; effective October 2025, Nokia licensed the RIC technology from HPE and moved the Juniper team into Nokia, folding it into MantaRay. Light Reading called it an exit from the standalone SMO/RIC market. Juniper SMO is no longer an independent choice - the people and IP now sit inside a competitor's roadmap.

VMware - sidelined under Broadcom. VMware built a near-RT RIC and Telco Cloud Platform RAN. After Broadcom's acquisition the roadmap went quiet, and by late 2024 reporting called the RIC's status unclear. No formal shutdown was announced, yet operators no longer treat it as a live option. Two of the field's most-cited independent RIC efforts have now left the standalone market inside a year - a plain signal to weigh staying power alongside features.

Mavenir - still in software, changed in shape. It remains relevant in RIC and vRAN software (Near-RT/Non-RT RIC, rApps/xApps, SMO components, cloud-native baseband), but in mid-2025 it refinanced ~$1.3B of debt and exited Open RAN radio-unit hardware to refocus on software. Confirm scope, roadmap and financial footing before assuming its 2022-2023 breadth.

NEC and the NTT DOCOMO OREX ecosystem remain important, mostly through OREX SAI - the DOCOMO/NEC joint venture (2024) that packages multi-vendor Open RAN and acts as integrator, with Southeast Asia momentum. Be clear which entity supplies the SMO, integrates it, and stays accountable after launch.

Open source - building blocks that still need an operating model around them. The O-RAN Software Community (a Linux Foundation Networking project as of 2026) and ONAP (now modular, cloud-native tools) can cut licensing dependency for operators with strong software teams. Product management, security, testing, upgrades, certification, integration and support still have to be funded.

So the comparison runs operating model against operating model - an integrated vendor platform, a best-of-breed ecosystem, or an operator-built/open-source stack, each trading control against accountability - plus a candid read on which suppliers will still be here in three years. Ask who integrates the whole solution, who investigates a failed automation loop at 2 a.m., and who carries the risk when two compliant components refuse to work together. The SMO was created to open the RAN; its evaluation should not hide accountability or ignore supplier durability.

#OpenRAN #SMO #RIC #Mavenir #OREX #OpenSource #TelecomArchitecture

SMO Vendor Series

#8 · There Is No Best SMO — Only the Best Fit

Janos Korognai · September 17, 2026

SMO Vendor Series #8: There Is No Best SMO - Only the Best Fit for an Operator's Strategy

An operator should not select an SMO from a feature-count spreadsheet. Most vendors can place the same acronyms on the same architecture diagram.

The meaningful differences show up in heritage, operating model, integration responsibility, evidence at scale - and, as the last post showed, supplier durability.

Based on the major commercial choices still standing, I'd frame the decision this way:

● Nokia MantaRay - when brownfield RAN management, SON evolution and an incremental path toward autonomy are the priorities.
● Ericsson EIAP - when you want an industrialized automation platform, a governed rApp ecosystem, alignment with a major Ericsson footprint, and a path now extending into the core.
● Samsung CognitiV NOS - when the SMO is part of a Samsung-led vRAN/Open RAN rollout and deployment automation drives the business case.
● Rakuten Symphony - when you're willing to rethink the OSS model and pursue cloud-native, software-led operations across a disaggregated network.
● Amdocs - when the primary need is neutral integration, connecting RAN automation to end-to-end service orchestration and OSS/BSS.

If your priority is open orchestration and cross-domain slicing independent of a traditional RAN vendor, the option most often cited for that - Juniper - is no longer a standalone product; its RIC now sits inside Nokia (see Post 7). That requirement points instead toward Amdocs at the service layer, a deliberately assembled best-of-breed stack, or open source - each carrying the integration ownership that implies.

Every selection should pass the same proof test. Require a live demonstration on your own data and representative network complexity. Put operational outcomes in the contract alongside software delivery. Test third-party onboarding directly, instead of sitting through an API presentation. Define automation safety, conflict management, rollback and auditability. Model the total cost of integration, applications and lifecycle over several years.

Autonomy arrives as a progression. A credible roadmap moves use case by use case: observe, recommend, approve, automate, then verify. Different workflows will run at different autonomy levels for a long time.

The winning SMO will prove three things in your environment: it creates a trustworthy, normalized operational view of the network; it converts intent and policy into safe, repeatable action; and it demonstrates measurable value without building a new closed silo.

The prize sits beyond installing an SMO: a RAN operating system that keeps improving while staying governable, explainable and open to innovation. That bar is higher than standards compliance, and it is the bar operators should use.

#SMO #RANAutomation #OpenRAN #AutonomousNetworks #TelecomStrategy #OSS #AI

SMO Vendor Series

#9a · Scoring the Field — The Lens and the Scorecard

Janos Korognai · September 18, 2026

SMO Vendor Series
#9a: Scoring the Field - The Lens and the Scorecard

Post 8 argued there is no single best SMO, only best fit. These two posts do the thing Post 8 warned against - pick a lens and rank - deliberately, using the lens from my separate 50-question SMO design series. Read those questions across O-RAN, 3GPP, GSMA, TM Forum, ETSI, NIST and CIS and they collapse to four words: openness, standardisation, transparency and operator control.

One caution governs everything below. These bands describe each platform's public posture and design centre - what it is built around and how it presents in public materials - and not tested results in your network. The 50 SMO questions exist to pressure-test posture against reality, so treat this as a starting shortlist to verify, vendor by vendor.

Five criteria, mapped to the 50 questions:

● Openness - open interfaces and operator data ownership, no lock-in by default (Q1-8, 49).
● Standards - O-RAN, 3GPP and TM Forum conformance with real multi-vendor interoperability (Q9-10, 29-33, 48).
● Automation - zero-touch, self-healing and safe autonomy, including conflict management (Q17-24, 40-43).
● Ecosystem - standard rApp packaging, open third-party onboarding and application portability (Q34-39).
● Control - transparency, evidence-based security and operator control (Q5, 22, 44-47).

The scorecard (image) reads each platform across those five. Bands: Strong = the criterion is the platform's stated design centre; Solid = clearly supported and positioned; Emerging = present but narrower in public materials. In text form, Openness / Standards / Automation / Ecosystem / Control:

● Nokia MantaRay: Solid / Strong / Strong / Solid / Solid
● Ericsson EIAP: Solid / Strong / Strong / Strong / Solid
● Amdocs Open RAN Automation: Strong / Strong / Solid / Solid / Strong
● Rakuten Symphony: Strong / Solid / Solid / Emerging / Solid
● Samsung CognitiV NOS: Emerging / Solid / Solid / Emerging / Solid

The bands point to where to look. Post 9b turns them into a ranking on the series' openness-first weighting, then shows how the order moves the moment you weight differently.
#SMO
#OpenRAN
#RANAutomation
#Standards
#VendorSelection
#Telecom
#OpenRANArchitecture

SMO Vendor Series

SMO Vendor Series #9b: Ranking the Five - and How the Order Moves

Janos Korognai · September 21, 2026

SMO Vendor Series #9b: Ranking the Five - and How the Order Moves

Post 9a set the lens - openness, standardisation, transparency, operator control - and the scorecard behind it. This post ranks the five on that weighting, reading public positioning only, and then reweights it.

1. Nokia MantaRay SMO. The best balance of an open, vendor-neutral posture with proven multi-vendor operation and national-scale automation. Public reporting notes operators running it over rival radios, which is the openness pillar shown in the field rather than asserted on a slide. The standing caveat for any incumbent: validate that openness on your own multi-vendor estate.

2. Ericsson EIAP. The deepest industrial platform - the most developed rApp SDK and ecosystem, strong standards conformance, and automation now reaching into 5G Core through cApps. The flag the series keeps raising is openness in practice: whether third-party apps and data move as freely as the architecture implies.

3. Amdocs Open RAN Automation. The strongest on pure neutrality and operator control, from a service and OSS layer that is RAN-agnostic by design; Amdocs argues publicly against letting one RAN vendor own the SMO. It carries less native radio-domain automation depth, having no RIC or SON heritage of its own.

4. Rakuten Symphony. The most openness- and independence-by-design of the five, AI-native and observability-led, built from operating a disaggregated network. The item to prove is scale: fewer at-scale, multi-vendor brownfield references, and more transformation burden left with the operator.

5. Samsung CognitiV NOS. The most cohesive when the SMO is part of a Samsung vRAN build, with real RIC deployments (TELUS in Canada, KDDI in Japan) and strong deployment automation. It sits last on this particular lens because its multi-vendor and openness breadth outside Samsung-led deployments stays thin in public materials - an evidence gap that on-Samsung builds simply don't expose.

The order is the product of one weighting. Shift it and the ranking shifts:

● Weight proven scale and brownfield depth, and Nokia and Ericsson pull further clear.
● Weight pure openness and operator independence, and Amdocs and Rakuten rise toward the top.
● Weight single-supplier vRAN cohesion and deployment automation, and Samsung rises sharply - for an operator building on Samsung vRAN, it may well be first.

Which is the real takeaway: the ranking follows from what you value, and the earlier 50 questions are how you turn what you value into evidence you can check with a vendor. Independent analysis, public sources only, no sponsorship - and, as always, I'd welcome the order you would put them in.

#SMO #OpenRAN #RANAutomation #AutonomousNetworks #VendorSelection #Telecom #Standards

Radio AI automation without SMO

Radio AI automation without SMO #1 - Radio AI automation through existing systems

Janos Korognai · September 22, 2026

Radio AI automation without SMO #1 - Radio AI automation through existing systems

What if an operator is not ready to introduce SMO? How can operators add Radio AI automation while retaining their existing management systems?

The focus is applications at the OSS or umbrella operations level. Start with a specific operational task: finding a radio problem, forecasting congestion, reducing energy consumption or preparing a maintenance action.

Across vendors, network management and OSS systems collect measurements, expose alarms and configuration data, and support operational workflows and network changes. Radio AI applications use these capabilities, together with other available network data sources, to predict conditions, diagnose problems or recommend actions.

The functional relationship is:
Network data → AI analysis → engineering decision → existing execution process → measured result.

For an automated action, the operator also needs defined permissions, operating limits, rollback and performance checks. A recommendation can deliver value through an established engineering workflow.

This series focuses on specific applications and services with documented engineering, centralized SON and network-management delivery paths:

• Nokia: AutoPilot decisions for existing SON, AI/ML energy optimization in SON, AI Digital Assistant and Predictive Care.
Benefits: energy savings, quicker technical support and earlier maintenance decisions.

• Ericsson: Cognitive Software for diagnostics, planning, optimization recommendations and Virtual Drive Test.
Benefits: faster analysis, more informed investment and quicker site acceptance.

• Samsung: VISTA NetAIr and CustomAIr analytics above the network.
Benefits: faster fault analysis and better visibility of customer experience.

• Huawei: specific AI maintenance, experience-prediction and optimization features associated with existing iMaster MAE deployments.
Benefits: faster fault analysis and better radio resource decisions.

• ZTE: Network Insight Agent deployed with its wireless AIOps system at network-management sites.
Benefits: faster queries, coordinated analysis and engineering recommendations.

The AI sits in the named model, analytics feature or application. Data collection and configuration interfaces provide the supporting functions. An AI feature embedded within a management system should be identified individually.

For each use case, specify the software or service, required data, output, execution owner and measurable benefit. The delivery scope must fit the existing operational environment.

Throughout this seven posts series, I’ll identify where the intelligence sits and the operational benefits it supports. Where model details are undisclosed, I’ll make that clear.

When evaluating Radio AI automation, how clearly does your vendor explain where the AI sits and which decisions it improves?

#Telecom #RadioAI #AI #RAN

Radio AI automation without SMO

Radio AI automation without SMO #2 - Nokia AI for SON and engineering support

Janos Korognai · September 23, 2026

Radio AI automation without SMO #2 - Nokia AI for SON and engineering support

At the centralized SON and OSS level, Nokia’s Radio AI capabilities can be considered at the level of AutoPilot with existing SON, individual SON features and mobile-network support services.

MANAGEMENT AND EXECUTION

NetAct/MantaRay NM provides network information, configuration management and operational interfaces. In this discussion, those functions support the AI applications and the existing change process.

WHERE THE AI SITS

1. MantaRay AutoPilot with existing SON
AI sits in AutoPilot’s intent-based analysis and decisions. It selects optimization policies and execution timing; SON applies changes to the base stations.
Benefit: less manual policy design and faster adaptation. DOCOMO’s June 2026 deployment describes AutoPilot working with its existing SON, with cycles as short as 15 minutes.

2. MantaRay SON Energy Savings Management
The AI/ML logic sits in the energy-saving module. It optimizes how base-station energy-saving features operate.
Benefit: lower energy consumption while maintaining service performance. Nokia’s stc case reports a 6% reduction across the operator’s 4G network with no degradation in network KPIs. This is a result from that deployment.

3. Nokia AI Digital Assistant
Generative AI supports access to telecom technical information through the assistant.
Benefit: less time searching documentation and quicker engineering support. The engineer can use the response within an existing troubleshooting workflow.

4. Predictive Care
AI sits in the care service’s centralized hardware and software analytics, contextual interpretation and preventive recommendations.
Benefit: earlier identification of risks and more informed maintenance decisions. Scope the radio-network assets and data feeds covered by the service.

Define each application’s data, AI-generated output and execution owner. AutoPilot makes optimization decisions; SON executes them. NM supports data access and management.

For energy optimization, measure both electricity consumption and service KPIs. For engineering support, measure time to a useful answer. For predictive maintenance, measure warning quality and avoided disruption.

The scope here is AutoPilot with existing SON, individual SON features and engineering support services. The delivery design should preserve the operator’s existing management environment.

References:
https://lnkd.in/dPkDkt-E
https://lnkd.in/dryvJf-B
https://lnkd.in/dM5DKfas

#Nokia #SON #RadioAI #AI

Radio AI automation without SMO

Radio AI automation without SMO #3 - Ericsson AI in engineering applications

Janos Korognai · September 24, 2026

Radio AI automation without SMO #3 - Ericsson AI in engineering applications

Ericsson’s Cognitive Software provides a route to Radio AI through network design and optimization software and services. Ericsson has documented both service delivery and standalone software in this portfolio.

The scope is centralized engineering applications above the radio sites. They analyze network data and supply recommendations to existing operational processes.

WHERE THE AI SITS

1. Performance Diagnostics
AI in the application detects and classifies cell issues, analyzes likely causes and recommends remedies.
Benefit: quicker investigation and less manual problem hunting.

2. Performance Optimizers
Learning algorithms, including deep reinforcement learning, generate optimization recommendations. Digital twins support evaluation.
Benefit: better-informed decisions about mobility, interference and energy parameters.

3. Cognitive Planning
Predictive models forecast traffic, KPIs and capacity constraints.
Benefit: earlier identification of bottlenecks and more targeted investment.

4. Cognitive Tuning and Virtual Drive Test
AI-powered geolocation works with live-network call traces to support radio analysis and acceptance.
Benefit: less physical testing and faster site reporting. Ericsson’s XL Axiata case describes a deployment introduced in 2018 and reports 60% faster site-level report generation.

THE SUPPORTING SYSTEMS

Network elements and supported data interfaces supply the observations. ENM can support data access and changes where integrated. The AI analysis sits in Cognitive Software. An engineer or the established change process applies the recommendation.

Network data → application analysis → engineering review → existing change process → KPI check.

This makes the operational benefit concrete: the team receives a diagnosis, a forecast or a proposed parameter change that it can assess and use.

For each application, define the software or service scope, supported data sources and output format. Include the processing environment and interfaces in the design. Historical deployment evidence establishes a delivery approach; the current release and contract still determine the implementation.

Which engineering task would benefit most from faster, more consistent analysis: diagnosing poor cells, planning capacity or accepting new sites?

References:
https://lnkd.in/gntU-cfM
https://lnkd.in/ducUYu7D

#Ericsson #NetworkOptimization #RadioAI #AI

Radio AI automation without SMO

Radio AI automation without SMO #4 - Samsung AI in centralized network analytics

Janos Korognai · September 25, 2026

Radio AI automation without SMO #4 - Samsung AI in centralized network analytics

Samsung’s VISTA analytics suite provides an OSS and umbrella-level starting point for Radio AI. Its published architecture brings network data into a common analytics environment with specific AI applications.

WHERE THE AI SITS

1. VISTA NetAIr
AI/ML supports anomaly detection, alarm correlation, root-cause analysis and problem-solving using configuration, fault and performance data from management systems.
Benefit: quicker identification and investigation of network problems.

2. VISTA CustomAIr
AI and machine learning analyze subscriber traffic and service experience.
Benefit: better visibility of who is affected by degraded service and more informed prioritization of engineering work. For Radio AI, scope the analysis to mobile users, cells and radio-related experience issues.

3. Network Sentinel within the CustomAIr offering
Samsung lists automatic anomaly detection and next-best-action capabilities.
Benefit: earlier identification of service issues and guidance on the next operational step. It is an application use case within the analytics portfolio.

THE SUPPORTING SYSTEMS

The VISTA platform provides data collection, storage and workflows. Its AI/ML framework supports the analytics applications. NetLiner contributes trace visibility and troubleshooting evidence. Individual AI functions should be identified separately from trace collection and reporting.

This is a centralized analytics relationship:
Network and management data → analytics application → diagnosis or recommendation → existing operational workflow.

Samsung and Zhilabs announced CustomAIr for the TELUS Service Operations Centre in 2020, providing a documented example of the umbrella analytics approach. Use that as historical delivery evidence and verify current product packaging and support.

For an operator, a practical first use case could be correlating poor mobile service experience with radio alarms and performance trends. The team would review the evidence, assign an action and check the outcome through its established process.

Measure time to isolate a problem, actionable findings and the reduction in repetitive investigation. Any automatic corrective action needs an explicitly supported integration and execution scope.

References:
https://lnkd.in/dZziHZ8e
https://lnkd.in/dB6d6sgg

#SamsungNetworks #RadioAI #AI #OSS

Radio AI automation without SMO

Radio AI automation without SMO #5 - Huawei AI within existing radio operations

Janos Korognai · September 28, 2026

Radio AI automation without SMO #5 - Huawei AI within existing radio operations

For operators already using iMaster MAE, Huawei documents Radio AI features within its wireless management and optimization environment. The focus is the analytics and decision features at the management level, using information from multiple cells.

WHERE THE AI SITS

1. Intelligent fault analysis
AI-assisted analysis supports radio fault localization and maintenance.
Benefit: quicker investigation and earlier identification of problems requiring attention.

2. Experience prediction and optimization
Scenario recognition and user-experience prediction inform performance optimization.
Benefit: more informed decisions about where radio performance needs intervention.

3. Machine-learning parameter optimization
Huawei’s published Vodafone Turkey pilot describes MAE using machine learning to analyze cell coverage, traffic and interference and generate parameter sets.
Benefit: reduced manual parameter exploration. Treat the pilot as evidence of the method and deployment context.

4. Intelligent energy analysis
Huawei describes analysis across radio technologies and frequency layers to support energy saving.
Benefit: coordinated energy decisions that account for network conditions.

MANAGEMENT AND EXECUTION

MAE combines management, control and analysis. Its collection and configuration functions support the process. The AI sits in MAE’s specific prediction, diagnosis or learning feature. Radio sites supply observations and implement the resulting settings.

That distinction also helps when discussing ordinary deployment workflows. A workflow’s automation should be described separately from any model making a prediction or decision within it.

For an existing MAE environment, scope the feature against the installed release and supported radios. Identify the measurements it uses, the output it produces and the existing mechanism that implements a change.

A useful acceptance exercise is to select a known radio problem, review the feature’s diagnosis or recommendation, apply an approved action and compare the resulting KPIs with the baseline.

Measure the benefit at task level: investigation time, recommendation quality, parameter-review effort or energy consumption with service performance maintained.

This post covers the documented MAE feature approach for existing deployments. Exact model architecture and current feature packaging require product documentation. Availability and deployment eligibility vary by market.

Reference:
https://lnkd.in/gdy8ppnz

#Huawei #RadioAI #AI #RAN

Radio AI automation without SMO

Radio AI automation without SMO #6 - ZTE AI for network insight

Janos Korognai · September 29, 2026

Radio AI automation without SMO #6 - ZTE AI for network insight

ZTE’s Network Insight Agent provides a focused Radio AI example at the centralized wireless network-management level.

ZTE documents commercial deployment alongside its AIOps system at 24 provincial-level network-management sites across three operators in China. AIOps means applying AI to operational analysis and workflows.

WHERE THE AI SITS

The agent uses generative AI and the Nebula telecom large model to organize queries, coordinate analysis and summarize findings. The named functions include:

1. Network structure analysis
The agent organizes queries about sites and configuration.
Benefit: faster access to relevant network context.

2. Coverage and capacity insight
Specialist agents use analysis tools to examine radio conditions and capacity.
Benefit: less manual coordination across engineering views.

3. Equipment-health insight
The health agent queries operational interfaces for outages, alarms and equipment issues.
Benefit: quicker assembly of information needed for investigation.

4. Consolidated recommendations
The coordinating agent combines specialist findings into a summary and proposed improvement measures.
Benefit: a more usable starting point for engineering decisions.

THE SUPPORTING SYSTEMS

Configuration records, operational interfaces and analysis tools supply the evidence. Model and agent logic organize the task and generate the response. The documented workflow returns findings to the operations or engineering user. The model and agent services operate above the radio sites.

An operator could ask for an assessment of a busy district, then review the agent’s coverage, capacity and health findings together. The engineering team would select an action and use its existing change process.

The scope is insight and recommendation within the deployed wireless AIOps environment. Each action affecting the network needs an identified execution owner and interface.

For evaluation, compare time spent gathering data, completeness of the analysis and usefulness of the recommendations. Ask the system to show the observations supporting its conclusions so engineers can check them.

Keep the implementation brief specific: the insight application, model service, approved data connections and engineering output. That gives the operator a measurable starting point for Radio AI automation.

Reference:
https://lnkd.in/dhr3j2Md

#ZTE #RadioAI #AI #Telecom

Radio AI automation without SMO

Radio AI automation without SMO #7 - Compare Radio AI by operational task

Janos Korognai · September 30, 2026

Radio AI automation without SMO #7 - Compare Radio AI by operational task

For an operator retaining its management systems, the Radio AI comparison starts with an OSS or umbrella-level application, a task and a measurable result.

Here is the narrower functional map from this series:

NOKIA
AI: AutoPilot decisions for existing SON, SON energy-saving models, Digital Assistant generative AI and Predictive Care analytics.
Supporting environment: existing SON and network-management interfaces, plus engineering and care workflows.
Benefits: reduced energy use, faster access to technical information and earlier maintenance decisions.

ERICSSON
AI: Cognitive Software diagnostics, optimization recommendations, planning predictions and Virtual Drive Test geolocation.
Supporting environment: software or service delivery using supported network data and existing engineering processes.
Benefits: quicker diagnosis, better planning and faster site acceptance.

SAMSUNG
AI: VISTA NetAIr and CustomAIr analytics, including anomaly detection and next-best-action capabilities.
Supporting environment: centralized analytics, management data and service operations workflows.
Benefits: faster investigation and better mobile customer-experience visibility.

HUAWEI
AI: specific MAE fault-analysis, experience-prediction, parameter-learning and energy-analysis features.
Supporting environment: existing MAE management and control functions and supported radios.
Benefits: faster investigation and more informed radio resource decisions.

ZTE
AI: Network Insight Agent and its large-model-assisted query, analysis and recommendation capabilities.
Supporting environment: wireless AIOps, network-management data and operational interfaces.
Benefits: less information gathering and more coordinated engineering analysis.

These are different implementation paths. AutoPilot coordinates centralized SON optimization. Umbrella analytics correlates network and service observations. An engineering application supplies a recommendation. A care service provides preventive insight. Match the delivery model to the task.

For each selected capability, document:
1. The application or feature containing the AI.
2. Its input data and output.
3. The required software, service and processing environment.
4. The existing team or system applying the result.
5. The baseline and success measure.

An AI-generated recommendation can already improve an operation. Automated execution adds requirements for permissions, limits, rollback and outcome monitoring.

If SMO becomes a future priority, build on the Radio AI use cases that have already delivered measurable value. Define the required workflows, data interfaces and operational controls, then introduce SMO in phases where it improves coordination across applications and vendors. Let proven operational needs guide the architecture and investment.

#Telecom #RadioAI #AI #RAN

Posts, articles & perspectives

More than a CV

Janos Korognai · September 18, 2026

More than a CV. This is what I bring to the table: https://kaldrivon.com

Posts, articles & perspectives

Could a future SMO create its own rApp?

Janos Korognai · August 28, 2026

Could a future SMO create its own rApp?

This is one of the more interesting questions emerging from AI-native network management.

Consider a future 6G network.

An SMO observes a recurring degradation pattern across a group of cells.

PM identifies the performance signature.

FM provides associated events.

CM shows the configuration conditions.

Topology identifies affected relationships.

Historical data shows how engineers resolved similar situations before.

An AI agent now has enough context to formulate a candidate remediation.

What if the system could turn that remediation into a new automation capability?

Generate the logic.

Define required O1 data and operations.

Specify its execution scope.

Test against historical data.

Run it against a Network Digital Twin.

Evaluate KPI impact.

Check operator policies.

Define rollback conditions.

Canary it on a small group of cells.

Observe the result.

Expand deployment after successful verification.

The network has now acquired an operational capability that wasn’t explicitly programmed when it was deployed.

Pieces of this direction are already appearing independently.

O-RAN Release 5 expands AI/ML workflow capabilities across the Non-RT and Near-RT RIC.

Network Digital Twins are progressing through 3GPP work.

ETSI is exploring architectures involving collaborating AI agents.

Research into autogenic network management is discussing self-programming and self-architecting capabilities.

None of this means an SMO can dynamically create and deploy production rApps today.

But it raises a specific architectural question for the 6G era:

Could the rApp lifecycle itself eventually become a closed loop?

Today:

Developer → rApp → SMO → Network

Future:

Network observation
→ AI reasoning
→ automation generation
→ digital-twin validation
→ policy verification
→ controlled deployment
→ KPI verification
→ operational learning

That creates questions we rarely discuss today.

Who signs machine-generated automation?

How is its O1 access scope determined?

How do we certify code that didn’t exist yesterday?

Does every generated automation receive its own identity and immutable audit trail?

When independently generated automations compete for the same network resources, who decides which one survives?

Perhaps one day an operator will open the SMO in the morning and discover:

“Three new optimization capabilities were identified overnight. Two passed simulation. One is ready for controlled validation.”

That would give self-evolving network a very concrete meaning.
#SMO
#ORAN
#6G
#AINative
#AutonomousNetworks

Posts, articles & perspectives

Scaling Mobile Networks for the Next Five Years

Janos Korognai · August 26, 2026

Mobile traffic is accelerating. AI is reshaping uplink demand. And simply adding more capacity every time traffic grows is an expensive strategy.

So, how do we scale the RAN without scaling cost at the same rate?

In the attached article, I explore a five-year approach that brings together RAN capacity evolution, SMO/RIC intelligence, automation, and AI-driven optimization, from spectral efficiency and Massive MIMO to traffic steering, energy optimization, and closed-loop assurance.

The opportunity is bigger than carrying more traffic.

It is building networks that become more efficient, measurable, and adaptable as they grow.

Curious to hear how others in the industry are approaching this challenge.
#5G
#RAN
#NetworkAutomation
#AIRAN
#Telecommunications

Scaling Mobile Networks for the Next Five Years: Why RAN Capacity and Network Intelligence Must Evolve Together

Mobile traffic growth is a familiar challenge for network operators. Each generation of mobile technology has brought increasing demand, and the industry has responded with additional spectrum, more efficient radio technologies, better antennas, new sites, and progressively more sophisticated network architectures.

The next five years add another dimension to that challenge. Operators need to absorb substantially more traffic while maintaining network performance, controlling energy consumption, managing increasing architectural complexity, and keeping capital and operating costs economically sustainable.

The June 2026 Ericsson Mobility Report provides a useful indication of the scale. Total global mobile network traffic, including Fixed Wireless Access, reached approximately 203 EB per month at the end of 2025 and is forecast to reach approximately 515 EB per month by 2031. That represents roughly 2.5 times the traffic and a 17 percent compound annual growth rate over the forecast period.

This growth creates a strategic question for operators:

How can network capacity scale significantly while the cost of carrying that traffic grows much more slowly?

I believe the answer lies in combining two disciplines: disciplined RAN capacity evolution and increasingly intelligent network operations through SMO, RIC, analytics, and automation.

The RAN provides the physical capacity. The intelligence layer helps operators determine where that capacity is needed, how effectively existing resources are being used, and when additional investment becomes economically justified.

The traffic curve is already moving

The 203 EB per month starting point is significant, although the direction of travel matters even more.

Mobile network data traffic grew approximately 22 percent year over year in Q1 2026. At the end of 2025, approximately 48 percent of mobile data traffic was already carried over 5G, with that share forecast to reach around 85 percent by 2031.

These numbers indicate that 5G is rapidly becoming the primary platform carrying mobile traffic. They also demonstrate why a five-year network strategy needs enough flexibility to accommodate growth that may arrive faster, slower, or in different locations than the original forecast assumed.

A critical qualification applies to these numbers. The 17 percent CAGR is a global planning envelope. It should never become a per-cell dimensioning assumption.

A real operator would forecast at cluster and site level using busy-hour traffic, PRB utilization, subscriber growth, spectrum availability, FWA penetration, congestion, QoS measurements, mobility patterns, and urban, suburban, and rural characteristics. Individual cells can behave very differently from the global average.

This leads to an important planning principle:

Total traffic tells us the scale of the problem. Traffic density and local KPIs tell us where to invest.

Traffic growth is also changing shape

Volume is only one part of the forecast. The composition and direction of traffic are changing as well.

Video remains the largest traffic category, accounting for roughly 75 percent of traffic. Higher-resolution streaming, live content, short-form video, and increasing consumption continue to create substantial downlink demand.

At the same time, uplink deserves increasing attention.

Mobile networks have historically been engineered around downlink-heavy usage. Streaming and browsing primarily move information from the network toward the device. AI assistants, collaboration applications, video calls, user-generated content, cameras, vehicles, robots, sensors, and multimodal applications create more traffic in the opposite direction.

Current industry forecasts indicate that uplink demand could reach around three times 2025 levels by 2031 under certain AI and collaboration workload scenarios.

Downlink capacity will continue to matter enormously, particularly because of video. Future network planning will increasingly need to consider growth in both directions.

FWA introduces another dimension. A household broadband connection can generate a very different usage profile from a smartphone. As mobile infrastructure increasingly carries fixed broadband traffic in selected markets, operators can see substantial additional load concentrated in specific geographic areas.

Enterprise 5G adds performance requirements alongside traffic growth. These services can require predictable throughput, latency, availability, security, and differentiated service quality. Commercial 5G SA slicing is also expanding, increasing the need for networks capable of managing differentiated traffic and service requirements.

Together, these trends create a multidimensional planning problem: more traffic, changing traffic patterns, greater geographic concentration, and higher performance expectations.

The economic challenge

Adding capacity remains essential. The difficult part is deciding how and where to add it.

If every increase in traffic leads directly to additional radios, spectrum, sites, power consumption, maintenance, and operational effort, the engineering solution can create an economic problem.

The objective should therefore be to make the relationship between traffic growth and cost increasingly nonlinear.

This is where I see value in a two-track strategy.

Track A focuses on RAN capacity. Track B focuses on SMO and RIC intelligence.

The two tracks operate together throughout the planning period.

Track A: Extract more capacity from existing assets first

RAN capacity can be approached through a hierarchy of investment options. The exact sequence depends on local network conditions, spectrum holdings, equipment, traffic distribution, and business priorities. The general principle is to extract value from existing assets before moving toward progressively more capital-intensive interventions.

Start with spectral efficiency

Spectral efficiency describes how much information can be transported through a given amount of spectrum, typically measured in bits per second per Hertz.

Improving spectral efficiency means carrying more traffic through spectrum the operator already owns.

Several mechanisms contribute to this, including improved scheduling, modulation, interference management, antenna optimization, beamforming where supported, and software or configuration improvements.

This makes spectral efficiency one of the most attractive early capacity levers. The operator can potentially create additional headroom without acquiring spectrum or building another site.

There are diminishing returns. A well-optimized site eventually reaches the point where additional tuning produces relatively small gains. At that stage, additional physical resources become necessary.

Continue with spectrum refarming

Spectrum refarming reallocates frequencies previously used for older mobile generations toward newer technologies such as 5G.

Its economic appeal is straightforward. The operator already owns the spectrum.

Execution depends heavily on local conditions. Legacy subscriber populations, device penetration, regulatory requirements, existing spectrum holdings, and technology sunset plans determine how quickly frequencies can be reassigned.

For this reason, refarming is best treated as a continuous, market-specific activity rather than a single network-wide event.

Use carrier aggregation and upgrade existing sites

Carrier aggregation allows multiple carriers to work together, creating greater effective bandwidth for compatible devices.

Radio and baseband upgrades can also extend the useful life and capabilities of existing sites. Depending on the starting architecture, an operator may be able to introduce additional bands, newer radio technology, more efficient equipment, or additional 5G functionality while continuing to use existing site infrastructure.

The financial principle remains consistent: maximize existing spectrum and sites before introducing additional locations.

Expand Massive MIMO where traffic justifies it

Massive MIMO is one of the most powerful capacity tools available in modern RAN.

Large antenna arrays enable spatial multiplexing and sophisticated beamforming, allowing an existing site to serve multiple users more efficiently over the same spectrum.

The technology can significantly increase capacity while using a site the operator already owns, potentially avoiding some of the acquisition and construction requirements associated with densification.

Deployment should follow local evidence. Traffic density, spectrum position, propagation environment, equipment capabilities, energy requirements, and expected return all influence the decision.

This is where network intelligence becomes especially valuable.

Densify where additional cells are justified

Some locations will eventually require additional cells.

Small-cell densification can provide significant capacity in persistent hotspots, although it also introduces additional site acquisition, transport, power, integration, maintenance, and operational requirements.

That makes densification a more selective capacity lever.

The hierarchy should remain flexible. A hotspot experiencing severe congestion today should be addressed today when the evidence supports the investment. The capacity hierarchy provides financial discipline and a decision framework. It does not require an operator to tolerate a known performance problem until a particular year in a roadmap.

Track B: Build intelligence around the RAN

Track A determines how capacity can be created. Track B improves the information used to decide where, when, and how those capacity investments should occur.

This is why I would introduce SMO and RIC capabilities early in the five-year period.

Capacity forecasting

A meaningful capacity forecast requires considerably more information than a global traffic CAGR.

At cluster and site level, I would want to understand busy-hour utilization, PRB utilization, user throughput, congestion duration, subscriber growth, traffic growth by cluster, mobility patterns, FWA penetration, service quality, and available spectrum.

Historical patterns can then be combined with current measurements to forecast where capacity constraints are likely to emerge.

AI and machine learning can strengthen this process by identifying relationships across large datasets and recognizing patterns that may be difficult to detect through manual analysis alone. Engineering judgment remains essential for validating the conclusions and translating them into investment decisions.

The objective is to identify emerging capacity problems early enough to act economically.

Policy optimization

Policy optimization translates business and network objectives into operational rules.

An operator may define policies around user experience, congestion, mobility stability, energy consumption, service levels, or specific enterprise requirements. Automation can then operate within those defined boundaries.

This provides an important governance model for increasingly autonomous networks. Operators continue to define objectives, thresholds, safeguards, and escalation rules while automation executes approved actions within those constraints.

Traffic steering

Traffic steering provides a practical example.

A heavily loaded cell can exist beside another cell, frequency layer, or neighboring resource with available capacity. Keeping every user connected purely according to the strongest signal can therefore produce an inefficient distribution of demand.

Traffic steering can consider radio conditions, load, mobility, available resources, and operator policy to distribute users more effectively.

This can improve customer experience and create additional usable headroom before further hardware investment becomes necessary.

Energy optimization

Energy is becoming increasingly important to the economics of RAN evolution. Industry estimates place energy at approximately 20 to 40 percent of network OpEx in many operator environments.

Network demand also varies significantly throughout the day.

An intelligent energy-management system can identify periods when full capacity is unnecessary. Within operator-defined coverage and performance constraints, selected carriers or resources can enter energy-saving states and return as demand increases.

The value comes from the closed-loop process. The system measures conditions, applies an approved action, monitors the resulting KPIs, and can reverse the action if service quality deteriorates.

This creates a continuous optimization process between network performance and energy consumption.

Assurance and closed-loop operations

The same model applies to network assurance.

Traditional operations can involve detecting an alarm, sending it to an operations team, analyzing the problem, identifying a likely root cause, selecting a corrective action, implementing the change, and checking the result.

Automation can progressively close parts of this loop.

Monitoring and analytics identify anomalies. Root-cause analysis narrows the problem. Policy determines which actions are permitted. Automation can recommend or execute an action, validate the outcome, and roll back when necessary.

The business value comes from handling increasing network complexity without requiring operational headcount to grow at the same rate.

Non-RT RIC and Near-RT RIC serve different purposes

Different optimization problems require different control timescales.

The Non-RT RIC supports control loops above one second and provides the environment for rApps handling functions such as capacity forecasting, policy optimization, and energy management.

Near-RT RIC operates on a faster timescale, approximately 10 milliseconds to one second, and can support xApps for functions such as rapid load balancing and mobility optimization through the E2 interface.

A practical architecture should apply Near-RT RIC where the use case and deployed RAN architecture justify sub-second control. Many strategic optimization problems can remain at the SMO and Non-RT RIC level.

This keeps architectural complexity aligned with measurable value.

The pairing is the point

RAN capacity and SMO/RIC intelligence become substantially more valuable when treated as one investment strategy.

Track A creates physical headroom. Track B provides the visibility and automation needed to use existing resources more efficiently, recognize emerging bottlenecks, and target future capacity investment.

There are clear physical limits to what automation can achieve. A cell that genuinely requires additional radio resources still needs a capacity intervention. Spectrum scarcity, propagation, interference, antenna characteristics, and site constraints remain fundamental engineering realities.

The value of automation lies in making those physical investments more precise and making the resulting network more efficient to operate.

This creates several potential benefits: better utilization of existing capacity, earlier identification of congestion, delayed or avoided capital expenditure where sufficient headroom exists, more precise targeting of necessary investment, reduced manual intervention, lower energy consumption, and improved performance consistency as traffic increases.

A five-year roadmap

The sequencing of these capabilities matters because the intelligence developed in the early years can improve the quality of larger capital decisions later.

Year 1: Establish the foundation

The first year should establish visibility and measurement.

Deploy the SMO and Non-RT RIC foundation, onboard the multi-vendor RAN inventory, establish baseline KPIs, perform a spectrum-utilization audit, and identify early congestion and spectrum opportunities.

Multi-vendor inventory is especially important. Capacity forecasting, energy optimization, assurance, and policy management all depend on having a trusted understanding of the network assets being managed.

Baseline measurements are equally important. Future claims about savings, performance improvement, automation coverage, and operational efficiency require a reliable starting point.

Year 2: Optimize and automate

With the foundation established, automation can expand into high-value operational use cases.

Traffic steering and energy optimization can begin in high-traffic clusters. Selective spectrum refarming, carrier aggregation, and radio optimization can continue in parallel. Hotspots should receive immediate capacity relief wherever local KPIs justify intervention.

The selective approach is important because network conditions differ substantially between markets and clusters.

Year 3: Scale capacity

By Year 3, the operator should have significantly better evidence about where demand is developing and how much additional headroom the earlier optimization measures have created.

A broader RAN investment wave can then focus on Massive MIMO, targeted small cells, continued refarming, and radio upgrades in the highest-growth locations identified through network data.

Capital spending becomes more targeted because it is informed by two years of improved traffic and performance visibility.

Critical capacity problems should already have been addressed wherever required. Year 3 represents the point where targeted capacity expansion becomes a major program.

Year 4: Scale slicing and closed-loop assurance

As the 5G SA foundation matures, commercial network slicing can expand alongside broader closed-loop assurance.

Automation maturity can also move toward more policy-driven operation. Selected high-value scenarios such as energy optimization, anomaly handling, traffic management, and assurance are realistic candidates for increasingly autonomous operation.

The scope matters. Achieving a high level of autonomy in selected operational domains is a more credible objective than assuming complete network-wide autonomy within five years.

Year 5: Mature optimization and prepare for the next cycle

By Year 5, the AI and machine-learning models supporting rApps should have accumulated substantial operational history. They can be refined using observed traffic, performance, energy, and automation outcomes.

This is also an appropriate stage to begin a 6G-readiness assessment.

A readiness assessment allows operators to evaluate future spectrum, architecture, transport, compute, and operational implications while continuing to extract value from the 5G investments already in place.

A five-year plan needs regular decision points

Traffic forecasts inevitably change.

FWA adoption can accelerate in one market. Enterprise demand can reshape another. Spectrum availability can change. Automation may create more headroom than expected. A new hotspot can emerge considerably faster than the national traffic trend suggests.

For that reason, I would introduce milestone reviews every two quarters, with a complete annual re-baselining against the latest traffic forecast.

Those reviews can change both timing and investment priorities.

Capacity investment can move forward when traffic accelerates. Hardware expenditure can move later when optimization creates sufficient headroom. Capital and engineering resources can shift toward clusters experiencing faster growth. Automation programs that fail to generate expected value can also be reconsidered.

The roadmap therefore establishes strategic direction while preserving the ability to respond to evidence.

Investment should follow defined gates

The same principle can be applied to funding.

The foundation investment can be approved early, while larger future capacity investments are released progressively against measurable decision gates.

Four categories provide a useful framework.

Capacity gates include busy-hour utilization, congestion duration, PRB utilization, throughput degradation, and traffic CAGR by cluster.

Automation gates include the percentage of the network under closed-loop management, number of manual interventions, MTTR, and automation success or rollback rates.

Economic gates include energy per site, OpEx per site, cost per transported GB, avoided or delayed CapEx, and time-to-value.

Performance gates include user throughput, latency, availability, dropped sessions, and mobility success.

This turns the roadmap into an investment governance model. Each major capital tranche has to demonstrate why it should proceed.

Cost per transported GB deserves particular attention

Traffic growth alone tells us relatively little about economic efficiency.

Consider an operator carrying twice as much traffic five years from now. If network cost also doubles, the network has successfully scaled capacity while achieving limited improvement in the economics of carrying that traffic.

If traffic doubles while total network cost rises considerably more slowly, cost per transported GB declines.

That provides a useful measure of whether spectrum efficiency, automation, energy optimization, capacity targeting, and operational improvements are collectively changing the economics of the network.

It also connects engineering decisions directly to the business case.

What does the evidence say about economic viability?

Industry evidence provides useful reference points, although the figures come from different contexts and should be interpreted accordingly.

Ericsson analysis estimates up to 10 percent RAN OpEx savings over five years for brownfield operators through SMO-driven automation. This is an industry estimate rather than a universally realized deployment result.

A separate reference point comes from NTT DOCOMO’s OREX announcement in September 2023. The date is important because these figures were published almost three years before the June 2026 Ericsson traffic forecast discussed earlier.

DOCOMO’s 2023 announcement described expected reductions of up to 30 percent in total cost of ownership and up to 50 percent in base-station power consumption under its OREX assumptions. These were estimated targets. They are best understood as an indication of the economic ambition associated with the program rather than as realized 2026 savings.

A more recent operational reference comes from Rakuten Mobile. In February 2026, the operator reported approximately 20 percent RAN energy conservation from autonomous closed-loop optimization in a live Open RAN environment, associated with a TM Forum Level-4 validated RAN energy use case.

These examples carry different evidentiary weight. Ericsson provides an industry estimate. DOCOMO’s 2023 OREX announcement provides forward-looking expected benefits. Rakuten provides a realized result for a specific live-network use case.

Together, they support a reasonable strategic hypothesis: intelligent automation can help operators carry increasing traffic while keeping the cost curve materially flatter than the traffic curve.

A precise ROI or payback period would require operator-specific information, including the network cost baseline, traffic distribution, spectrum position, energy prices, site costs, integration investment, and actual deployment architecture.

Performance remains part of the economic case

Efficiency has to be evaluated alongside network performance.

A relevant example comes from a Samsung and KDDI commercial-network trial completed in June 2026. Samsung’s AI-powered RAN Speed Optimizer produced a reported 31 percent average improvement in peak-hour 5G downlink throughput across the trial area, reaching up to 52 percent in dense urban locations.

The trial ran across hundreds of cells on KDDI’s live commercial 5G SA network. It represents a field-trial result from a specific deployment environment, so the percentages should be interpreted within that scope.

Its significance lies in demonstrating how targeted optimization can extract additional performance from deployed network resources.

This is an important part of the automation business case. Network intelligence can contribute to operational efficiency while also improving how effectively existing radio resources deliver user performance.

AI-RAN should be evaluated through maturity and use case

AI-RAN is likely to become increasingly relevant to this architecture, although different AI-enabled network functions are at very different stages of maturity.

SMO and Non-RT RIC already support practical applications such as forecasting, policy optimization, energy management, and anomaly analysis.

More ambitious real-time AI-RAN concepts involve AI models participating directly in radio-resource decisions. This area remains earlier in its maturity cycle, with much of the current industry activity centered on trials and progressively more sophisticated use cases.

A practical five-year strategy can generate value from mature automation capabilities today while maintaining an architecture capable of adopting more sophisticated AI-RAN functions as commercial evidence develops.

This also gives operators a disciplined way to evaluate AI. Each use case can be assessed through measurable outcomes such as throughput, congestion, energy consumption, operational effort, and cost.

Edge AI changes where network demand appears

AI also introduces an architectural question about where inference occurs.

Inference can run in a centralized cloud, at a network edge, close to the RAN, or directly on the device. Each placement affects the network differently.

Centralized cloud inference creates radio traffic and transport demand. Edge inference can reduce transport requirements because data travels a shorter distance through the network. The radio uplink may still carry audio, video, sensor data, or contextual information from the device to the edge compute location.

On-device inference has the greatest potential to remove that traffic from the network because processing happens locally.

For network planning, the key uncertainty is therefore where future AI traffic terminates and how much data must traverse each part of the architecture.

This strengthens the case for annual reforecasting. AI traffic assumptions made today will need to evolve as devices, edge platforms, applications, and user behavior develop.

RF fundamentals remain fundamental

Increasing intelligence in the network does not reduce the importance of RF engineering.

Link budgets still determine whether sufficient signal reaches the receiver after transmit power, antenna gain, propagation losses, penetration losses, and other margins are considered.

Spectrum characteristics still determine the fundamental relationship between coverage and capacity. Low bands provide broader coverage and stronger penetration. Mid-band spectrum provides the central coverage-capacity balance for much of 5G. High-band spectrum offers substantial capacity over shorter distances.

Antenna patterns still shape coverage and interference. Beamforming still depends on the phase and amplitude relationships across antenna elements. Massive MIMO still depends on the underlying propagation environment and radio conditions.

These RF decisions establish the physical operating envelope of the network.

SMO and RIC provide another layer of capability. They can observe performance across that physical infrastructure, correlate network conditions with traffic, apply policy, automate selected operational decisions, and provide evidence for future investment.

This creates a useful relationship between the two disciplines:

RF engineering defines the physical possibilities and constraints of the network. Network intelligence helps operators use those resources more efficiently over time.

The five-year opportunity is an operating-model transformation

It is easy to frame network evolution around individual technologies such as Massive MIMO, Open RAN, SMO, RIC, AI-RAN, slicing, edge computing, or eventually 6G.

The larger opportunity comes from how these capabilities work together.

An operator can continuously improve the efficiency of spectrum and infrastructure already deployed. Spectrum can be refarmed as legacy demand declines. Carrier aggregation can increase usable bandwidth. Massive MIMO can add substantial capacity to selected existing sites. Densification can address locations where the physical capacity requirement warrants additional cells.

At the same time, the intelligence layer can forecast congestion, steer traffic, optimize energy consumption, automate assurance, and provide increasingly accurate evidence about where the next investment should go.

The resulting operating model becomes iterative:

Measure, forecast, optimize, invest, validate, and re-baseline.

That cycle is particularly valuable during a period when traffic patterns, AI workloads, enterprise requirements, spectrum availability, and network technology are all evolving.

Final thought

The forecast of approximately 203 EB per month in 2025 growing to 515 EB per month by 2031 provides a useful picture of the scale ahead.

The exact 2031 number will matter less to an individual operator than its ability to respond intelligently as reality diverges from the forecast.

Some markets will grow faster. Others will grow more slowly. FWA adoption will vary. AI applications will change the uplink and downlink mix. More inference will move toward the edge and onto devices. Spectrum positions and enterprise opportunities will differ significantly between operators.

A resilient five-year strategy therefore needs physical capacity, operational intelligence, financial discipline, and regular opportunities to change course.

RAN investment creates the capacity required by growing demand. SMO and RIC improve visibility into how that capacity is being used and where future investment can generate the greatest value. Automation can reduce energy and operational effort, while RF engineering continues to define the physical constraints within which the network operates.

The objective for the next five years is larger than carrying more traffic.

It is building a mobile network that becomes more efficient, measurable, and adaptable as traffic grows.

Posts, articles & perspectives

Nobody has standardized rApp economics yet

Janos Korognai · August 24, 2026

Nobody has standardized rApp economics yet

rApps are moving fast on the technical side. The business model underneath them is still much less mature.

The R1 interface is intended to give rApps standardized access to services exposed by the Non-RT RIC/SMO, creating the foundation for a more portable, multi-vendor rApp ecosystem - and helping reduce the vendor lock-in that limited earlier approaches to RAN automation such as SON.

Momentum is real. Major vendors including Ericsson, Samsung, Nokia and others are building out rApp platforms and automation portfolios. In the US, NTIA made up to $450 million available in its third Wireless Innovation Fund round for software-focused Open RAN innovation, including solutions leveraging RIC capabilities and automated multi-vendor integration.

Commercialization is happening too. Ericsson already has a directory of commercially available Ericsson and third-party rApps and has taken the model further with rApp as a Service through AWS Marketplace. Nokia also has an rApp Marketplace with Nokia and partner applications.

Even more interesting: Nokia and Ericsson recently agreed to cross-list on each other’s marketplaces - Ericsson joining Nokia’s SMO Marketplace, Nokia joining Ericsson’s rApp Ecosystem. That’s real cross-vendor movement, but it’s happening at the discovery and catalog level. It doesn’t yet touch the harder commercial questions underneath.

Here’s the part the industry still hasn’t really solved: how does an independent rApp developer make money across a genuinely multi-vendor ecosystem?

What happens commercially when an rApp from Vendor A runs on an SMO from Vendor B? Who owns the customer relationship? Is pricing subscription-based, per network, per cell, usage-based or outcome-based? Who handles entitlement, support and lifecycle responsibility? And if a marketplace sits between the developer and operator, how does revenue sharing work?

Compare that with mainstream software ecosystems, where commercial models, developer agreements, billing, entitlement, revenue sharing and lifecycle responsibilities are already well understood.

Individual vendors can answer many of these questions inside their own ecosystems.

The harder problem is answering them across ecosystems.

Until operators, SMO vendors and independent rApp developers converge on more common commercial frameworks - not just technical interfaces - the vision of a truly cross-vendor “app store for RAN” remains unfinished.

R1 helps address the technical interface.

The business interface still needs work.
#ORAN
#SMO
#rApps
#RANAutomation
#Telecom

Posts, articles & perspectives

An AI Agent for the O-RAN O1 Simulator

Janos Korognai · August 21, 2026

I just gave my O-RAN O1 Simulator an AI Agent.

It watches live NETCONF fault and performance data from simulated O-DU/O-RU network functions, runs deterministic anomaly detection, then the AI Agent asks Gemini for root-cause reasoning - live, streamed, no black box. Read-only by design: it observes, it never acts. Pure insight, ready for a downstream SMO rApp to consume.

Try it: https://lnkd.in/geZaAAZZ
#AIAgent
#ORAN
#5G
#Telecom
#AI
#OpenRAN

Posts, articles & perspectives

What Level 4 autonomy actually requires

Janos Korognai · August 19, 2026

Every operator briefing this year seems to mention Level 4 autonomy. Fewer explain what that actually requires.

TM Forum’s maturity model runs from L0 (fully manual) to L5 (fully autonomous). L4 specifically moves toward agent-centric autonomous decision-making: the network senses, analyzes, decides and executes based on intent rather than relying only on predefined automation. Field operations, expert intervention and manual approval for complex or high-risk cases can still remain.

Where does the industry actually stand?

In a recent TM Forum survey of 80 operators worldwide, about a quarter expect to reach L4 or above by 2027, and roughly four in five expect to get there by 2030. By June 2026, more than 30 operators had carried out L4 practices, while 18 specific scenarios across nine operators had reached L4 through TM Forum’s assessment validation.

The case studies are worth looking at precisely because they move the discussion from aspiration to measurable outcomes.

Vodafone Türkiye reports a 20% reduction in MTTR and an increase in automated fault diagnosis from 25% to 65%, using domain-specific agents together with cross-domain coordination.

DNB Malaysia describes closed-loop traffic optimization covering monitoring, prediction, analysis, decision, execution and validation or rollback, reporting 5–7% throughput improvements in congested cells with minimal manual intervention.

But perhaps the most refreshing part of the report is that TM Forum calls out the hype problem directly.

It says some operators are overly focused on obtaining L4 certification for marketing purposes, at a pace that is out of step with actual technological advancement. TM Forum argues that assessment should instead identify gaps between the live network and the target state and help prevent excessive hype around L4.

Assessment should identify gaps, not decorate a press release.

That’s the more useful lens for evaluating an autonomous network claim: not simply which level number is cited, but which specific scenario has been validated, in which domain, and with what measurable outcome.

The gap between “we’re deploying L4” and “we’ve closed the loop on wireless fault management, materially reduced MTTR, but still rely on human approval for complex or high-risk cases” is exactly where the real conversation should happen.

Autonomy is something that needs to be demonstrated scenario by scenario, domain by domain, with measurable outcomes.
#AutonomousNetworks
#TMForum
#SMO
#NetworkAutomation

Posts, articles & perspectives

Building a public O-RAN O1 playground

Janos Korognai · August 17, 2026

I may have built the only publicly accessible O-RAN O1 playground on the Internet.

That’s a bold claim, but I searched extensively before making it.

There are O-RAN simulators, SMO/OAM platforms, NETCONF tools and YANG browsers. What I couldn’t find was a place where anyone could simply open a browser, enter an O-RAN O1 environment and start experimenting.

So I built one.

No installation, Docker setup, account or lab environment required. Behind the UI is an O-RAN SC-based simulated O-DU with real NETCONF/YANG interaction, built with the help of Claude Code. It’s not a PowerPoint representation of one.

You can:

• Explore YANG models and navigate the schema tree
• Inspect the NETCONF <hello> and advertised capabilities
• Execute real GET and GET-CONFIG RPCs
• Perform controlled EDIT-CONFIG operations
• Inspect the actual NETCONF request and response XML
• Generate and investigate alarms
• Explore Configuration, Fault and Performance Management
• Experiment with O1 supervision, including supervision notifications, reset cycles and supervision state
• Inspect topology, transactions and logs

The path is real:

SMO/OAM → O1 → NETCONF/YANG → O-DU

My goal was to make O1 tangible. Instead of starting with specifications and architecture diagrams, you can see the protocol, models and management operations working together and experiment with them yourself.

I haven’t found another open O-RAN O1 environment that brings all of this together in quite the same way. If you know of one, I’d genuinely be interested in seeing it.

Projects like this are also why I enjoy working at the intersection of SMO/OSS architecture, technical pre-sales and network automation: taking complex technology and making it understandable, demonstrable and useful.

It’s still a work in progress and not fully polished, but there’s enough there now that I wanted to put it out in the open and let people experiment with it.

The playground is live. Try it, explore it, and let me know what you think:

👉 https://lnkd.in/geZaAAZZ
#ORAN
#O1
#NETCONF
#SMO
#Telecom

Posts, articles & perspectives

Knowledge Objects for AI-native autonomous networks

Janos Korognai · August 14, 2026

Could Knowledge Objects become the building blocks of future AI-native autonomous networks?

I recently read Ericsson and Telstra's white paper, "From Automation to Autonomy." One of its central ideas is a Knowledge Plane as a foundational capability for AI-native autonomous networks, complementing intent by providing the structured knowledge needed for safe, explainable decision-making.

It made me think about the next architectural step.

A Knowledge Plane provides the foundation, but it also raises an important question:

How should knowledge itself be represented, managed and exchanged?

One possible answer is Knowledge Objects.

A Knowledge Object represents a standardized, reusable unit of operational knowledge that autonomous systems can create, validate, query, exchange and reason over throughout the network lifecycle.

Each Knowledge Object could contain:

• Facts and semantic relationships
• Causal relationships
• Provenance and ownership
• Confidence score
• Supporting evidence
• Applicability (vendor, software release, topology and domain)
• Explainability metadata
• Validity period
• Version history
• Trust attributes

Rather than remaining fragmented across OSS databases, AI models, documents and vendor repositories, Knowledge Objects provide every autonomous function with a common, machine-interpretable representation of validated operational knowledge.

The second part of the architecture is the Knowledge Lifecycle.

Knowledge isn't static. Networks evolve, software changes and operational practices improve. Knowledge should evolve with the network.

A standardized lifecycle could include:

Acquisition → Validation → Publication → Federation → Consumption → Reasoning → Evolution → Versioning → Aging → Retirement

Managing knowledge this way allows autonomous systems to continuously improve while retiring obsolete or low-confidence knowledge before it influences decisions. It enables systems to reason not only with knowledge, but also about its confidence, provenance and trustworthiness.

A natural extension would be standardized knowledge services for publishing, querying, validating, subscribing to, explaining and federating Knowledge Objects, supported by common information models and interoperable APIs.

Ericsson and Telstra's paper establishes an important architectural foundation with the Knowledge Plane.

The next architectural challenge is standardizing how knowledge is represented, governed and evolved across autonomous systems. Knowledge Objects and a standardized Knowledge Lifecycle provide a practical path toward that goal.

Just as A1, O1 and O2 accelerated interoperability in O-RAN, standardized Knowledge Objects and Knowledge Lifecycle services could become the foundation for interoperable intelligence across AI-native autonomous networks.

Posts, articles & perspectives

Should autonomous networks be allowed to experiment?

Janos Korognai · August 12, 2026

Should autonomous networks be allowed to experiment?

Autonomous networks are expected to observe, decide and act with less human intervention.

But there is an uncomfortable question:

How does an autonomous system determine whether an action will improve the network without experimenting on the live network?

Telecom is not an ideal environment for trial and error.

Changing mobility parameters, energy-saving policies or optimization thresholds can improve one KPI while degrading another. At scale, even a well-intentioned optimization can have an unexpected blast radius.

This is where Network Digital Twins could become much more important.

Not simply as virtual replicas for planning, but as experimentation environments for network autonomy.

Imagine an autonomous function detects a degradation and generates several candidate actions.

Instead of immediately applying one, the loop could become:

Observe → Hypothesize → Simulate → Compare → Select → Deploy selectively → Validate → Expand or Roll back

The digital twin would not need to predict every detail of the physical network perfectly.

It may need to answer a more practical question:

Which action is most likely to achieve the intent with acceptable risk?

This is not purely hypothetical.

O-RAN research is already exploring Digital Twin RAN for areas such as AI/ML training and testing, network testing, planning, energy saving and site-specific optimization.

ETSI and 3GPP are also developing Network Digital Twin concepts supporting automation, simulation, prediction and the evaluation of changes before they reach the live network.

So the foundations are emerging. The interesting question is what happens when we connect them more directly to autonomous decision-making.

Suppose the twin predicts a 6% improvement, but the live network delivers only 2%.

That difference is valuable feedback.

The autonomous system could compare predicted and observed outcomes, identify where its model is inaccurate, and use that feedback to improve future decisions.

The closed loop then becomes more than:

Observe → Decide → Act

It starts looking like:

Observe → Simulate → Act → Validate → Learn

For SMO and future autonomous-network architectures, this raises some interesting questions:

Should an rApp be able to request simulation before initiating a network change?

Should high-risk autonomous actions require digital-twin validation?

How should predicted and actual outcomes be compared?

And in a multi-vendor network, who provides the models needed to create a trustworthy twin?

Perhaps the digital twin of the future will not just tell us what the network looks like.

It could become the place where an autonomous network asks:

“What is likely to happen if I do this?”

before touching the production network.
#AutonomousNetworks
#DigitalTwin
#SMO
#ORAN
#AI
#RAN
#NetworkAutomation

Posts, articles & perspectives

The data engineering challenge behind AI in the RAN

Janos Korognai · August 10, 2026

One of the hardest engineering problems in “AI in the RAN” often isn’t the AI at all.

Every network constantly generates performance counters, alarms, handover events and radio-condition data - some collected periodically, some arriving asynchronously, and often represented differently across vendors.

Massive MIMO adds another layer: highly granular radio measurements and channel information. For latency-sensitive functions, much of that information has to be processed close to where it is generated, in the radio or baseband. Shipping every raw sample to a centralized platform would be neither practical nor necessary.

Multiply the selected measurements across thousands of sites, frequency layers and millions of subscribers, and the scale becomes significant very quickly.

That is why “just add AI” dramatically undersells the actual work.

Building the data foundation across the RAN, SMO and RIC layers - collecting, normalizing, correlating, contextualizing and routing the right information to the right application - can become as significant an engineering challenge as developing the ML model itself.

The Near-RT RIC operates on control-loop timescales of roughly 10 milliseconds to one second. It cannot simply ingest everything and determine afterward what matters. The measurements, E2 service models, subscriptions, reporting intervals, aggregation and transport paths have to be engineered around the use case.

The Non-RT RIC has more time, operating above one second, but faces a different challenge: turning recent and historical information from large numbers of cells and potentially multiple vendor systems into data that applications can use consistently.

The RIC and the model get the headlines.

The telemetry foundation underneath them - collection, transport, normalization, context and data quality - can consume a huge amount of the engineering effort in a real deployment.

Without that foundation, even the best model is making decisions from incomplete, poorly timed or inconsistent data.

Posts, articles & perspectives

Autonomy changes work in three ways

Janos Korognai · August 8, 2026

Autonomy changes work in three ways.

Some tasks disappear.

Routine configuration, monitoring and optimization that once required someone to notice a condition, decide what to do and make the change can increasingly happen inside a closed loop.
The human may only become involved when the system reaches an exception, a policy boundary or something it cannot resolve safely.

Some tasks change shape.

A role that used to mean "configure the parameters" might increasingly mean "review what the automation proposed, approve or override it, and handle the exceptions."
The domain knowledge and judgment are still needed. The daily work shifts from making every change directly toward supervising what the automation is doing.

Some tasks are new - or becoming much more important.

Someone has to define the policies and guardrails the automation operates within. Someone has to monitor automated decisions for unexpected behavior, performance degradation or model drift.
And in a multi-vendor environment, someone has to deal with consistent data, policy enforcement and conflicts between recommendations or automated actions coming from different applications.

That can get messy quickly. It still requires a lot of human judgment.

Autonomy isn't a straight line from "people do this" to "no one does this."

It's a redistribution of work:

Some disappears.
Some changes.
Some emerges.

I think that third category is the one the industry talks about least.

It's also the one that will decide who's still in the room when the network runs itself.

Posts, articles & perspectives

The next evolution of Direct-to-Cell

Janos Korognai · August 6, 2026

Starlink’s reported ambition to become a mobile operator got me thinking about what the next evolution of Direct-to-Cell (D2C) could look like.

Today, satellites are an outstanding coverage solution, but terrestrial networks remain the capacity layer. The reason is straightforward: a satellite beam covers a much larger area than an LTE or 5G cell, limiting how efficiently spectrum can be reused.

If Starlink wants to compete not just as a coverage extension but as a true mobile network, capacity will eventually become just as important as coverage.

One possible long-term direction is pushing today’s multibeam LEO architectures toward much denser, AI-managed spatial reuse inspired by the evolution of terrestrial Massive MIMO systems.

While electronically steered multibeam satellites already exist, the next step could be scaling beam density, autonomy and coordination to a point where satellite capacity begins to resemble terrestrial cellular architectures.

Imagine future LEO satellites supporting hundreds - or eventually thousands - of dynamically managed beams, with footprints significantly smaller than today’s satellite beams to enable much higher spatial frequency reuse. Combined with AI-driven beam management, dynamic beam shaping, advanced beam steering and increasingly intelligent radio resource management, satellites could evolve from simply filling coverage gaps to becoming an active part of the network capacity layer.

This would naturally fit with where the industry is already heading:

• AI optimizing radio resources in real time.
• SMOs orchestrating terrestrial and non-terrestrial RAN together.
• Users connecting seamlessly to whichever access network offers the best experience, regardless of whether it’s a tower or a satellite.

The engineering challenges are significant - antenna aperture, onboard processing, power budgets, Doppler, beam steering, thermal management and interference coordination - but so were many of the technologies that are now standard in 5G.

If Starlink’s strategy is indeed to become a mobile operator rather than simply a satellite provider, the long-term differentiator may lie in how effectively terrestrial and non-terrestrial networks converge into a unified, AI-orchestrated RAN, applying common principles for spectrum reuse and radio resource management across both orbit and ground.

The attached animation illustrates today’s coverage-oriented Direct-to-Cell architecture alongside one possible future evolution. It is intended as a technical concept, not a representation of any announced Starlink roadmap.

Posts, articles & perspectives

How young is the SMO and rApp ecosystem?

Janos Korognai · August 5, 2026

Did you know that the standardized SMO, Non-RT RIC and rApp architecture most of us reference today has only existed in a commercially deployable form for roughly four to six years?

The O-RAN Alliance was founded in February 2018 through the combination of the xRAN Forum and C-RAN Alliance, with AT&T, China Mobile, Deutsche Telekom, NTT DOCOMO and Orange as its founding operators. That was more than eight years ago.

But “the O-RAN Alliance exists” and “a standardized, multi-vendor SMO and rApp ecosystem is commercially deployable” are two very different milestones.

The initial O-RAN architecture established the direction, but the detailed Non-RT RIC, R1 and rApp framework came later. The first Non-RT RIC architecture specifications appeared in the early 2020s, while dedicated R1 use-case, service and transport specifications continued developing afterward.

During this period, major vendors and software companies began introducing their own SMO, RIC and application-development platforms. These early implementations allowed operators and developers to build, host and test xApps and rApps, but they were often tied to a particular vendor’s platform, APIs, data models or integration framework.

That distinction matters.

Building an application that runs on one vendor’s platform is not the same as having a truly portable rApp that can be onboarded onto different SMO and Non-RT RIC implementations, discover available services through R1, access normalized network data, interact safely with policy and automation functions, and operate consistently across a multi-vendor network.

Those capabilities require much more than an application-hosting environment. They depend on standardized service exposure, data discovery, identity and access management, lifecycle management, observability, conflict mitigation, AI/ML model management and interoperability testing.

All of those areas have continued evolving well beyond the original O-RAN architecture.

Depending on where the starting line is drawn, vendor-specific SMO and RIC applications have been buildable and deployable for approximately four to six years. The more standardized and portable R1-based rApp ecosystem is younger still - and remains a work in progress across the industry.

That is a fraction of the development runway enjoyed by traditional OSS platforms, many of which have benefited from decades of operational feedback, integration work, security hardening and product iteration.

Worth remembering when the maturity of SMO and rApps is benchmarked directly against legacy OSS platforms that have had two or three decades to evolve.

Posts, articles & perspectives

Building Decoricepaper.ca from the ground up

Janos Korognai · August 3, 2026

Over the past several years, alongside my telecom career, I’ve also helped build Decoricepaper.ca⁠ from the ground up.

While my wife is the business owner, I’ve had the opportunity to contribute to many aspects of the business - from building and improving the Shopify website to SEO, analytics, inventory management, customer experience, automation, and solving the countless technical and operational challenges that come with running an e-commerce business.

Together, we’ve grown the business to serve more than 2,500 customers and fulfill over 4,000 orders, giving me hands-on experience turning data and technology into practical business outcomes.

Working in two very different worlds - large-scale telecommunications and a small Canadian online business - has been a great reminder that, regardless of company size, success comes from understanding customers, continuously improving processes, and delivering a great experience.

I’m proud of what we’ve built together and excited to keep supporting its growth while continuing my passion for AI-enabled telecom networks, OSS, SMO, and solution architecture.

Posts, articles & perspectives

AI-RAN: hardware specialization and software abstraction

Janos Korognai · July 31, 2026

Following up on Nokia’s AI-RAN launch: three hardware paths, one software stack, dedicated silicon back after years of “just virtualize everything.”

Worth separating two different claims here. One is about the pattern - the industry keeps cycling between abstraction and specialization. The other is about who wins this particular round. Those aren’t the same bet, and I’m a lot more confident in the first one.

The pattern: hardware wins a round because some workload (tensor-heavy AI-native processing, here) currently needs dedicated silicon to be efficient. But GPU price-performance keeps climbing and software keeps getting better at squeezing efficiency out of generic infrastructure. So the gap that justified “you need dedicated hardware” keeps shrinking - until someone credibly abstracts it again and the industry swings back toward cloud.

You can already see the seeds of the next swing inside Nokia’s own announcement - cloud-native COTS servers are one of the three paths, running the same GPU workloads. That’s the next loop starting before this one’s even rolled out.

But whether Nokia’s specific architecture is the one still standing when that swing happens is a separate question. Three vendors, three anyRAN-style software bets, three silicon partnerships (NVIDIA, Marvell, whoever else shows up) - the pattern says hardware-then-abstraction will keep repeating regardless of who’s supplying it. It doesn’t say Nokia’s the one holding the winning stack when it does.

Posts, articles & perspectives

Learning by building

Janos Korognai · July 30, 2026

One habit has shaped my career.

Whenever I encounter a new technology, I want to understand it deeply - not just enough to use it.

That usually means building something.

If it’s an API, I’ll integrate it.

If it’s AI, I’ll explore the models, build with them, and understand where they create real value.

If it’s infrastructure, I’ll deploy it myself.

That mindset followed me throughout my career.

Whenever Nokia introduced a new strategic platform that needed technical leadership, customer demonstrations, or pre-sales support, I ramped up quickly and became productive.

NetAct / MantaRay NM.

Archive Cloud.

Traffica.

Network360.

DCAP.

EdenNet / MantaRay SON.

MantaRay SMO.

Each transition meant learning new architectures, APIs, deployment models, customer use cases, and integration patterns until I could confidently discuss them with engineering teams and customers.

The same curiosity continues today.

I explored local LLMs, RAG, embeddings, prompt and context engineering, AI agents, and built Model Context Protocol (MCP) servers to understand how AI connects with external systems.

I installed Ubuntu Server, built Docker and Docker Compose environments, experimented with Linux, Raspberry Pi, self-hosted services, networking, Git, and GitHub to better understand modern software deployment.

One project explored turning Outlook PST archives into an AI-searchable knowledge base.

Another became an interactive vendor-neutral SMO platform covering Non-RT RIC, rApps, O1, A1, O2, intent management, FCAPS, cross-domain orchestration, conflict management, and AI-assisted closed-loop automation. I deployed it through GitHub Pages with custom DNS, HTTPS.

Throughout my career I’ve designed solution architectures, built proof-of-concepts, integrated REST APIs, supported Tier-1 operators, and worked across engineering, product management, sales, and executive teams.

Technology keeps changing.

That’s exactly what I enjoy.

If there’s one promise I can make, it’s this:

Give me a new platform, a new architecture, or a difficult technical problem, and I’ll ramp up quickly until I can contribute with confidence.

That’s the mindset I bring to every challenge. If your team’s tackling something like this, I’d like to talk.
#Telecom
#AI
#SMO
#ORAN
#OSS
#LLM
#MCP
#RAG
#Docker
#Linux
#CloudNative
#APIs
#Engineering

Posts, articles & perspectives

Nokia and Ericsson: different paths to AI in the RAN

Janos Korognai · July 29, 2026

Did you know that two of the largest Western RAN vendors are taking notably different approaches to AI inside the radio network?

Nokia is making a major bet on programmable accelerated computing. Built around Nokia's anyRAN software and NVIDIA's AI-RAN platform, its approach brings GPU-accelerated computing into the baseband.

Nokia says it has already demonstrated spectral-efficiency gains of more than 20%, with a roadmap targeting 50% by 2027 and more than 100% by 2028. Pilot deployments are planned for late 2026, with commercial availability targeted for 2027.

The potential upside is significant, but so are the questions around power, cooling, cost and utilization. High-performance GPUs can consume hundreds of watts under heavy workloads, although actual platform-level consumption depends on the accelerator, configuration, workload and how effectively its capacity is shared. Nokia has not published directly comparable system-level power figures for commercial deployments.

Ericsson's primary strategy is different: neural-network acceleration embedded in Ericsson Silicon, allowing AI-native RAN functions to operate on both purpose-built and cloud-based infrastructure without requiring external GPUs.

Its AI-native Scheduler with Link Adaptation is being tested with operators including AT&T and T-Mobile. T-Mobile's large-scale live-network trials produced close to a 10% improvement in spectral efficiency and up to a 15% increase in downlink throughput compared with legacy rule-based methods. Across Ericsson's broader deployments and trials, the company reports gains of up to 20% in downlink throughput and 10% in spectral efficiency.

Ericsson has also demonstrated its Cloud RAN software on NVIDIA AI infrastructure, so this is not simply "GPU versus no GPU." It is a difference in where each vendor believes specialized compute delivers the best technical and economic return.

Comparing this to, for example, Samsung which is pursuing another flexible path. It has demonstrated its vRAN software on NVIDIA infrastructure using an AI-based MIMO beamformer, while its existing commercial vRAN footprint - reported at approximately 53,000 sites by the end of 2025 - has largely been built on CPU-based platforms. That gives Samsung the option to use accelerated computing selectively rather than make it mandatory across every deployment.

There is another layer to the discussion: not every valuable use of AI in the RAN requires AI processing inside the baseband. Energy-saving rApps and RIC-based automation can analyze traffic patterns, optimize sleep modes and coordinate cell or carrier shutdowns independently of the underlying baseband processor.

So "AI-RAN" is not one architecture. It is a set of different bets across maximum spectral-efficiency potential, energy efficiency, hardware flexibility, deployment economics and time to commercial scale.

Posts, articles & perspectives

SMO beyond the RAN

Janos Korognai · July 21, 2026

Did you know? SMO may eventually extend far beyond the RAN - but there is no single cross-domain SMO standard yet.

Today, O-RAN defines SMO primarily for RAN management through the Non-RT RIC, rApps and interfaces such as O1, O2 and A1.

But tomorrow’s autonomous networks will require coordination across much more than the RAN.

A broader end-to-end architecture is emerging from several standards ecosystems:

• O-RAN Alliance – RAN intelligence and automation
• 3GPP SA5 – RAN, Core and network slice management
• ETSI ZSM – Cross-domain closed-loop automation
• ETSI NFV – Cloud and network-function lifecycle management
• TM Forum – Service orchestration, intent and assurance
• IETF / MEF – Programmable transport networks

In a real deployment, the future is likely to involve a federation of domain controllers, where RAN, transport, core and cloud each manage their own environments while coordinating around common service intent and SLA objectives.

For visualization purposes, my demo simplifies this into one conceptual Non-RT CIC - Cross-Domain Intelligent Controller.

The CIC is not presented as an existing standard or as the only possible architecture. It acts as a single visible coordination point so users can more easily understand how cross-domain intelligence, assurance and closed-loop automation could work across RAN, transport and core.

This is still a future concept, but it reflects the direction toward more coordinated and autonomous network operations.

Explore the interactive educational demo here:

https://smo.kaldrivon.com

How do you see cross-domain intelligence evolving: centralized, federated or hybrid?
#SMO
#OpenRAN
#NetworkAutomation
#AutonomousNetworks
#5G
#6G
#Telecom
#Canada

Posts, articles & perspectives

From business intent to network assurance

Janos Korognai · July 18, 2026

Did you know what enterprise customers increasingly expect from programmable networks?

They want to express the required outcome in clear business language, including what must be delivered, where it is needed and how success should be measured:

“Guarantee low latency for factory robotics at Plant 3.”
“Protect emergency-service reliability across downtown Toronto.”
“Maintain premium video throughput inside the stadium.”
“Reduce energy consumption across selected sites during off-peak hours.”

Intent-based assurance translates these business objectives into measurable expectations and coordinated actions across RAN, Core and Transport.

I built this part of my interactive SMO demo so we can explore together what this future could look like in practice.

In the demo, you can follow the complete flow:

→ Select a business intent
→ Define the required outcome and location
→ Translate it into measurable service expectations
→ Decompose it into per-domain targets
→ Deploy it across RAN, Core and Transport
→ Monitor live compliance
→ Trigger remediation when performance drifts
→ Detect conflicts when competing intents depend on the same limited capacity

This is a hands-on way to explore how outcome-based connectivity, SLA assurance, closed-loop automation and cross-domain coordination can come together as networks become more autonomous.

Explore the Intent-Based Assurance demo here:

https://lnkd.in/gthJpefF

Let’s learn together: which use case do you think will adopt this first - private wireless, network slicing, enterprise SLAs or energy optimization?
#IntentBasedNetworking
#SMO
#NetworkAutomation
#AutonomousNetworks
#ServiceAssurance
#ORAN
#5G
#6G
#Telecom

Posts, articles & perspectives

The Canadian SMO deployment landscape

Janos Korognai · July 16, 2026

Did you know that TELUS is currently the only Canadian mobile operator with a publicly confirmed commercial SMO deployment?

Based on my recent research, the Canadian landscape looks like this:

* TELUS – Samsung CognitiV NOS, deployed as part of its Open RAN and virtualized RAN strategy. https://lnkd.in/gBeGphy7

For the other major Canadian operators, I could not find a confirmed public announcement identifying a specific SMO platform:

* Bell
* Rogers
* Videotron/Freedom Mobile
* SaskTel
* Eastlink

This does not necessarily mean they are not testing, evaluating, or using SMO-related capabilities internally. Telecom operators often introduce automation platforms gradually, and many trials or deployments are not publicly disclosed.

As Open RAN, Non-RT RIC, rApps, and AI-driven network automation continue to evolve, SMO adoption in Canada will be an interesting area to watch.
#Telecom
#SMO
#OpenRAN
#ORAN
#5G
#6G
#NetworkAutomation
#AutonomousNetworks
#CanadaTelecom

Posts, articles & perspectives

An interactive SMO platform demo

Janos Korognai · July 14, 2026

Built a full SMO platform demo with AI assist which you can click through yourself: https://smo.kaldrivon.com. No backend, no server, no install - just something educational for anyone who wants to actually see how this stuff works instead of reading another slide about it.

It now also includes a cross-domain SMO concept, showing how service assurance and automation can extend beyond the RAN into the transport and core domains.

Fourteen tabs covering the full stack: multi-vendor RAN normalization, closed-loop rApps running real O-RAN SON logic, a Near-RT RIC running its own real-time loop visibly faster than the Non-RT RIC next to it (the split between the two trips up a lot of people - seeing it beats reading about it). FCAPS monitoring. Full slice lifecycle. Live conflict resolution when two rApps disagree - allow both and the network fights itself, first-come-first-served is simple but arbitrary, priority override works if someone's actually decided the ranking ahead of time. Security controls that show evidence, not just a checkbox. A scorecard that grades the whole thing on openness and actually recalculates from what's happening live in the demo.

I built it as a learning tool, for myself as much as anyone else. Going tab by tab through the whole platform - FCAPS, the RIC split, slicing, conflict handling, security, openness - forces you to work out how each piece actually connects to the next, not just know each concept in isolation. If you're new to SMO/O-RAN, a vendor thinking through what to build, or just want a plain-language explanation of terms like PRB, handover, or FCAPS, there's a full documentation tab built into the demo covering every term and every scenario.

21 years in OSS, SMO, and RIC pre-sales gave me the concepts. This is just turning "here's what I'd explain to a customer" into something clickable, built and refined over one working session.

Runs entirely in your browser, not tied to any vendor.

If you're anywhere near SMO, O-RAN, or network automation, tell me what's missing or what you'd add.

🔗 Live demo: https://smo.kaldrivon.com
🔗 Code: https://lnkd.in/giHCxAR6
#SMO
#OpenRAN
#RIC
#Telecom
#5G
#6G
#NetworkAutomation
#PresalesEngineering
#OSS

Posts, articles & perspectives

The SMO and intelligent automation vendor landscape

Janos Korognai · July 13, 2026

Did you know that nearly every major RAN vendor now offers an SMO or intelligent network automation platform?

Based on my recent research, the industry is increasingly adopting Service Management and Orchestration (SMO) as a key enabler for AI-driven operations, autonomous networks, and Open RAN.

Here’s a quick overview:

* Nokia – MantaRay SMO – https://lnkd.in/gTtjvdCf
* Ericsson – Intelligent Automation Platform (EIAP) – https://lnkd.in/gMdDEbgz
* Samsung – CognitiV Network Operations Suite (NOS) – https://lnkd.in/gX3YUvw6
* Huawei – iMaster MAE – https://lnkd.in/gdy8ppnz
* ZTE – uSmartNet – https://lnkd.in/gpWQkeB4
* Mavenir – MAVair (RIC & SMO) – https://lnkd.in/gHUwD_Dk
* Fujitsu – Virtuora SMO – https://lnkd.in/gHXRbA4G
* Rakuten Symphony – Symworld / Autonomous OSS – https://lnkd.in/gps-FKfh

Many of these platforms provide capabilities such as:

* Non-RT RIC and rApps
* AI-assisted network operations
* Closed-loop automation
* Multi-vendor management
* Cloud-native architecture
* Intent-based orchestration
* Network performance and energy optimization

As operators continue their journey toward autonomous networks, SMO is becoming an increasingly important component of modern telecom software, helping simplify operations, improve network performance, and enable greater automation.

This list focuses on major RAN vendors and Open RAN providers. Many other companies, including NEC, Ciena, Amdocs, Qualcomm (Cellwize), Juniper, HPE, VMware, and systems integrators, also offer SMO or complementary orchestration solutions.
#Telecom
#SMO
#OpenRAN
#ORAN
#5G
#6G
#AI
#NetworkAutomation
#CloudNative
#Telecommunications

Posts, articles & perspectives

AI-assisted development for technical pre-sales

Janos Korognai · July 8, 2026

Leaving Nokia after 21 years gave me an unexpected gift: the chance to see my own skill set from a different angle.

Here's a scenario every presales professional recognizes: a customer conversation is going well, and suddenly there's a request to demo the software's capabilities - on short notice, to a prospect where timing matters. Product and engineering teams are stretched thin, and a formal demo environment isn't always available. What you do have is deep product knowledge - the workflows, the value it delivers, the problems it solves.

This is where I've found AI genuinely valuable for presales professionals.

Using AI-assisted development, I can turn that product knowledge into a working demonstration quickly, without needing dedicated engineering resources. To be clear: this isn't a substitute for professional software engineering, and it doesn't diminish the skill and craftsmanship behind real production systems. It's a different tool for a different purpose - giving presales teams a way to show, not just describe, a solution's value when timing can influence a deal's outcome.

That thinking led to pulsehub-demo: a self-contained, browser-based demo of an agentic HR platform, covering engagement surveys, performance reviews, compensation planning, and an AI "Manager Agent" that supports data-grounded coaching and reviews. It includes role-based permissions reflecting a real org hierarchy and four guided, self-running walkthroughs built for exactly the "show me" moment presales conversations depend on.

The idea came from an earlier conversation with an HR tech company that didn't move forward - but the process was a valuable learning experience, and I wanted to build on it rather than let it go to waste.

A deliberate design choice: no frameworks, no backend, no install - one file, running entirely in the browser, so the demo doesn't depend on a server or live connection to work.

Despite to make it easy to see in action, I also put a live version online (pulsehub.kaldrivon.com), which meant handling a few basic technical tasks - setting up a CNAME, pointing the domain to the right host, and documenting the GitHub repo clearly. None of this is expected in a presales role - nothing sophisticated, just some foundational technical grounding that comes in handy.

Two decades in a specialized corner of telecom - OSS, network management, 5G/RAN, O-RAN, and Core integrations - taught me how to translate technical depth into a compelling customer narrative. That instinct doesn't disappear when the domain changes. AI just makes it faster to put into practice.

🔗 Live demo: https://lnkd.in/gv5FdYgK
🔗 GitHub: https://lnkd.in/gP4xwFhz
#Presales
#SolutionsArchitecture
#Leadership
#Telecom
#OSS
#AgenticAI
#DemoEngineering
#CareerTransition

Posts, articles & perspectives

After 21 years with Nokia: the next chapter

Janos Korognai · June 19, 2026

After 21 years with Nokia, I returned my badge and laptop last week.
I am grateful for the opportunities, colleagues, customers, and experiences that shaped my career across OSS, Network Management, SMO, Cloud and Telecom solutions.
Thank you to everyone I had the privilege to work with over the years.
As one chapter closes, I am looking forward to new opportunities in telecom, OSS/SMO, solution architecture, customer success, and technical leadership.
Onward to the next adventure.

Posts, articles & perspectives

Janos Korognai: a career conversation

Janos Korognai · June 18, 2026

If you’d like a different perspective on my background and experience, here’s a podcast conversation between Michele and Mark: https://lnkd.in/gkasjNMd

Kaldrivon MiniSMO

Customer experience. Business impact.

Canada

United States

Europe

Asia

Helping customers evaluate, adopt & operate.

Validating a new platform for a Canadian operator

Cloud OSS & resilient operations

Supporting a customer's automation roadmap

Licensing, security & lifecycle strategy

High Value Contribution to Project Success

AI, automation & hands-on projects

Kaldrivon MiniSMO

Kaldrivon SMO

What it demonstrates

Kaldrivon O1Sim

What it demonstrates

Kaldrivon R1Lab

What it demonstrates

Kaldrivon Network Rescue

What it demonstrates

Kaldrivon PulseHub

What it demonstrates

Kaldrivon FleetOps

What it demonstrates

Publications

SON to rApp migration

SMO Architecture Notes

SMO Vendor Series

Radio AI automation without SMO

Customer relationships backed by technical depth

A closer look at what I can offer.

From customer needs to working solutions.

A career across the full lifecycle.

Tools, platforms & working knowledge.

OSS & network management

Cloud, systems & operations

Interfaces & automation

Telecom & architecture

Security & resilience

AI, public cloud & modern delivery

Commercial & customer tools

Beyond telecom

Where I can contribute.

Solution architecture & enterprise integration

Solutions engineering & technical pre-sales

Customer success & technical accounts

Delivery, operations & technology leadership

Strategic accounts & partner enablement

AI discovery, prototyping & automation advisory

Network management API integration & tooling

A strong foundation. Ongoing development.

BSc, Computer Engineering

Google Cloud Generative AI Leader

Fortinet Certified Fundamentals

Scrum Alliance · Red Hat · Juniper

Nokia network management & SON

A few useful details.

Hiring for a permanent role? Let’s talk.

SON to rApp migration #1: Why this migration matters

SON to rApp migration #2: The SON contract

SON to rApp migration #3: What R1 gives the rApp

SON to rApp migration #4: PCI optimization walkthrough

SON to rApp migration #5: Data access is a migration task

SON to rApp migration #6: Mobility load balancing walkthrough

SON to rApp migration #7: Cell outage compensation walkthrough

SON to rApp migration #8: Onboarding and service discovery

SON to rApp migration #9: Closing the loop with evidence

SON to rApp migration #10: When rApps disagree

SON to rApp migration #11: Portability needs a test

SON to rApp migration #12: Who owns the migration

Kaldrivon MiniSMO in action

Kaldrivon MiniSMO 0.2.0 is available

Introducing KaldrivonR1Lab

A first look at SON-to-rApp migration

Introduction: What SMO is and where it fits in autonomous networks

Operational data exposure

Decoupling the data layer

System of record for telemetry