Nokia connects AI network operations with MantaRay automation

Nokia applies AI to the networks that move information between people, devices and data centers. Its most useful story for operators is the connection between network observations, operational objectives and controlled configuration changes. MantaRay makes that connection in the radio access network, while a broader autonomous networks portfolio covers other domains. The practical question is which decisions an operator can delegate with enough evidence to trust the result.

01 / ProductNetwork infrastructure with AI in the operating loop

The current Nokia company overview centers the business on connectivity across fixed, mobile and transport networks. That is the company covered here. A familiar consumer-device brand is not a useful description of this enterprise offer: the buyer is generally operating infrastructure, planning capacity or supporting a communications service whose behavior depends on many interacting systems.

MantaRay SMO is Nokia’s service management and orchestration solution for the radio access network, or RAN. It connects multi-supplier management, application automation and orchestration. The portfolio includes MantaRay Network Management, SON, AutoPilot and a RAN Slice Controller. These components do different jobs; the existence of a common family does not mean every installation includes every function.

AutoPilot works from predefined operational intents and target performance indicators. Nokia describes a loop that detects degradation against an intent and takes corrective action. The broader autonomous networks portfolio extends beyond radio into fixed access, IP, optical and service operations. This makes Nokia relevant to AI infrastructure as well as to applying AI within ordinary network operations.

02 / AudienceA useful fit when telemetry and operating authority meet

A mobile operator with recurring congestion or labor-intensive optimization has a concrete reason to investigate MantaRay. Its network engineers already understand the tradeoffs between coverage, capacity, customer experience and energy consumption. The opportunity is to make repeated decisions more consistent while preserving the ability to explain why a change happened and whether it helped.

A data-center networking team needs a different product conversation. The Arista blueprint examines network infrastructure and operational tooling in that environment, while the Cisco blueprint provides a broader enterprise networking comparison. Those are useful adjacent choices; a radio optimization requirement should still be evaluated against radio-specific capabilities, supported equipment and the operator’s existing management systems.

The weakest starting point is an organization with unreliable inventory or poorly understood counters that wants AI to compensate for missing operational knowledge. An optimizer can react consistently to an incorrect signal. Establishing which measurements are trustworthy, who owns the affected service and which settings may change is therefore part of the implementation, rather than paperwork added after a demonstration.

03 / WorkflowA proposed pilot for recurring busy-hour congestion

Consider an operator whose engineers repeatedly investigate a cluster of cells with poor evening performance. This proposed pilot evaluates assistance and bounded optimization within that cluster. It is an editorial evaluation design, not a deployment we tested. Choose a region where the operations team can observe adjacent cells and reverse changes through its established network management process.

Begin by reconstructing a representative baseline. Align traffic counters, configuration history, alarms and maintenance windows on the same timeline. Separate ordinary busy periods from exceptional events such as an outage or a major gathering. Define the customer-facing performance measure before considering an optimization: higher resource utilization is only useful if the relevant service remains acceptable.

Next, map the proposed objective to a supported AutoPilot intent. Ask Nokia to show the exact variables that the selected configuration observes and the actions it can initiate. Start by reviewing recommendations or reproducing changes in the operator’s approved evaluation environment. Do not infer a particular observation-only product mode from this suggested sequence; agree the supported pilot arrangement with the supplier.

Keep neighboring cells inside the evaluation boundary. Moving traffic can improve a local indicator while creating another bottleneck nearby. Compare the target cells and their neighbors under comparable demand, and record whether a new configuration caused additional handovers, coverage concerns or support incidents. The network team should decide which tradeoffs count as acceptable rather than allow a single headline metric to determine success.

For a permitted live trial, bound the change window and the set of writable parameters. Capture the prior configuration, the triggering evidence, the proposed action, approval where required and the observed result. Establish what happens when telemetry is delayed or contradictory. A stopped or deferred optimization can be the correct outcome when the input no longer describes the live network reliably.

End with an engineering review of accepted, rejected and reversed actions. Count investigation time as well as operating results, because fast automatic changes can still create expensive follow-up work. The valuable deliverable is a repeatable operating procedure with known failure conditions. Expand to another cluster only after the team can explain which parts of the first result should transfer and which depend on local topology.

04 / PricingA scoped enterprise deployment, with no public flat tariff

The consulted MantaRay product page and autonomous networks overview lead to expert contact rather than a public per-seat or per-action price. No verified universal subscription amount is available from those pages. Treat the commercial conversation as a scoped infrastructure project, and have the proposal identify platform components, applications, integration and operating support separately.

Nokia’s June 2026 portfolio announcement describes on-premises options for the Autonomous Networks Suite and an expanded Agent Library. That announcement is not a licence schedule for MantaRay or a promise that each agent is included in every purchase. Match the quoted version and delivery model to the actual workflow before comparing bids.

An economic assessment should include the work needed to connect data sources and maintain compatibility through equipment upgrades. Ask which activities are recurring and which belong to initial integration. A comparison based solely on a software line item can miss the engineering effort that determines whether the system remains useful after the first pilot.

05 / DistinctionsCoordination matters more than an isolated AI feature

The distinctive element in MantaRay’s architecture description is the coordination of network management, existing automation and newer rApps. Nokia describes an SDK and a marketplace with its own and partner applications. This offers an evolutionary route for operators with existing systems, although portability and compatibility still need confirmation for the specific application and deployment.

The 2026 update also describes agents for anomaly investigation, service operations and network troubleshooting. These are vendor-described capabilities. We have not tested their accuracy or used the announcement’s productivity percentages as a forecast. Our assessment is that the stronger evaluation asks whether evidence, intent and action remain connected in an engineer’s review of a real incident.

06 / QuestionsResolve mixed-vendor behavior and competing objectives

A multi-vendor label does not identify every supported equipment release, counter mapping or permitted configuration change. Request a compatibility matrix tied to the proposed bill of materials, and include at least one awkward legacy integration in the pilot. If a feature depends on a particular interface version, make that dependency visible before the rollout reaches a less modern region.

Also establish how separate applications coordinate conflicting objectives. An energy-saving action and a capacity action can each be reasonable in isolation. Ask which component arbitrates, how decisions are logged and whether the operator can reconstruct the sequence later. Operational responsibility remains with the network organization even when several suppliers contribute to the automation chain.

Finally, distinguish current deployment capability from future AI-native network plans. A roadmap can inform a longer investment horizon, but a near-term operating case should be built from the exact released configuration available to the team. Confirm data placement, access controls and upgrade ownership as part of that configuration, rather than assume one architecture applies to Nokia’s entire portfolio.

07 / DecisionChoose the network decision before choosing the automation

Nokia is a substantial candidate for teams modernizing telecommunications operations. A narrow optimization objective makes its broad portfolio easier to evaluate. The decision should rest on supported integration, explainable operational evidence and a manageable change boundary, with wider autonomy earned through repeated results.