1. Frame the acquisition question
The acquisition question is how much a buyer should pay today for a network-automation business whose proposition extends from present 4G and 5G operations into AI-RAN and future 6G architecture. The answer requires several valuations inside one transaction. Existing subscription and services revenue can be assessed through contracts, margins, retention and cash conversion. Customer operating benefits require technical attribution. Portability requires evidence across networks and suppliers. Future standards participation creates an option whose exercise conditions remain uncertain.
A disciplined buyer begins with the operating problem solved. Network automation can improve energy use, capacity, throughput, quality, fault management, planning or engineering productivity. Each use case has a different data requirement, decision interval, integration burden and failure consequence. A product that recommends a weekly configuration change is economically and operationally different from a closed-loop controller that acts within seconds.
The transaction thesis should state which use cases create value, where that value appears, who receives it and which evidence proves it. The buyer can then test whether the target owns a product, an integration practice, proprietary data, a customer-specific workflow or an assemblage of third-party components.
Table 1. Network-automation value layers and transaction treatment
| Value layer | Present evidence | Principal diligence question | Transaction treatment |
|---|---|---|---|
| Contracted software | Signed recurring revenue and renewal history | Does revenue survive ownership and vendor changes? | Base enterprise value |
| Operating improvement | Measured network KPI and cost effect | Is the counterfactual credible and persistent? | Validated uplift or earn-out |
| Deployability | Repeat deployments and integration records | Can the product travel across operators and stacks? | Portability premium |
| Data and models | Lawful rights, lineage and reproducibility | Can the buyer continue training and operation? | Asset value subject to rights |
| Ecosystem position | Standards contributions and partner acceptance | Does influence translate into adoption? | Strategic option |
| 6G readiness | Standards-aligned architecture and trials | Which capability exists before commercial 6G? | Capped, milestone-based option |
Each layer needs separate evidence, economics and risk treatment.
2. Separate current value from future option value
Current value arises from products that operators deploy, pay for and renew. It includes recurring software revenue, implementation income that supports adoption, and measurable customer benefits that improve renewal or expansion. Future option value arises from capabilities that may become useful as interfaces, architectures, spectrum arrangements and operator investment plans mature.
The separation prevents a circular thesis. A target cannot justify a high price through a future market and then use the price as evidence that the market exists. The buyer should identify the present product, present customer, present decision and present economic benefit. Future features belong in a separate option register with triggers, expiry conditions and additional capital requirements.
Option value is strongest when the present platform creates learning that remains useful across standards generations. Data-engineering capability, model governance, integration tooling and operator trust can be durable. A claim tied to one provisional interface or a narrow vendor implementation may decay. The buyer should pay for transferable capability rather than a label.
3. Understand the standards clock
The standards clock sets boundaries around technical certainty. ITU-R Recommendation M.2160 describes the IMT-2030 framework and six usage scenarios. ITU reported in March 2026 that draft technical performance requirements had been agreed for twenty requirements, including seven new ones, with formal approval expected in December 2026. Evaluation methodology and candidate-technology work continue through the international process.
This timeline matters because commercial descriptions can run ahead of approved technical requirements and deployable systems. A target may conduct research that is relevant to 6G without possessing a 6G product. It may also create significant value in present networks through techniques likely to persist into future generations.
The diligence team should build a standards matrix. Each material feature should map to an approved specification, a draft item, a research concept or a proprietary implementation. The matrix should name the interface, release, dependency and expected change risk. Valuation should follow the maturity of the underlying dependency.
4. Distinguish AI-RAN meanings
AI-RAN can describe AI used to improve the radio network, AI workloads sharing network compute, or network capability designed to serve AI applications. Those propositions have different customers, assets and economics. An acquisition case should state which meaning applies to every product.
AI for RAN includes traffic forecasting, energy management, mobility optimisation, anomaly detection, capacity planning and parameter control. AI and RAN may combine telecommunications and accelerated-compute workloads on common infrastructure. AI on RAN can refer to distributed inference or services enabled through network reach. A target may participate in more than one category, but the buyer should not merge their addressable markets.
Product documentation, contracts and deployment diagrams should use consistent terminology. When management uses a broad label, the diligence team should translate it into data inputs, model outputs, network actions, hardware dependencies, service levels and invoiced units.
5. Map the control architecture
The control architecture shows how observations become actions. Telemetry can originate from cells, radios, user equipment, transport, core functions, energy systems and operational support systems. It is normalised and governed before models or policies use it. Actions may return through service-management and orchestration, non-real-time controllers, near-real-time controllers or vendor-specific systems.
O-RAN's architecture distinguishes non-real-time and near-real-time functions and defines interfaces including A1, R1 and E2. Non-real-time applications can support policy, model training and longer-horizon optimisation. Near-real-time applications can influence network behaviour at shorter intervals. The target's actual placement determines latency, integration and safety requirements.
The buyer should trace one use case end to end. The trace should identify every data source, transformation, interface, decision, safeguard and network action. Missing links reveal where human services or incumbent-vendor tools complete the product.
Diligence follows one decision from governed telemetry through models and policy to a reversible network action.
6. Build an evidence ladder
An evidence ladder prevents a promising demonstration from receiving the same weight as repeatable production economics. The first rung is simulation or laboratory evidence. The second is a controlled field trial. The third is a commercial-network trial with defined scope. The fourth is a limited production deployment. The fifth is repeat performance across periods, regions, configurations and operators.
Each rung should record who designed the test, who controlled the baseline, which traffic and hardware were included, how long the observation lasted and whether adverse outcomes were measured. Vendor and operator case studies can show feasibility. They require transaction-specific reproduction before supporting a material acquisition premium.
Evidence can move downward as well as upward. A model may perform after deployment and degrade when traffic, devices, software or radio configurations change. The target should demonstrate monitoring, retraining, approval and rollback. A buyer is acquiring a performance system, not a static accuracy result.
7. Establish the counterfactual
The counterfactual is the result that would have occurred without the target's product. It can be a matched control area, randomised switchback, staged rollout, comparable period or engineering model. A simple before-and-after comparison can misattribute weather, traffic, hardware refresh, spectrum changes or another optimisation to the software.
The diligence team should reproduce key calculations from raw or controlled data. The target should disclose exclusions, missing periods and manual intervention. The analysis should show central tendency, distribution and failure cases rather than one peak result.
Economic attribution follows technical attribution. If a product reduces energy per unit of traffic, the buyer should identify electricity prices, equipment states, traffic growth and any hardware cost required. If it improves throughput, the buyer should show whether the benefit delays capital expenditure, protects customer experience or creates saleable capacity.
8. Test KPI persistence
Network performance gains can fade. Operators change software, traffic patterns, frequency configurations, hardware and commercial priorities. A target's evidence should therefore cover persistence, not only initial uplift.
The buyer should inspect cohort curves by site, region, use case and time since deployment. A stable average can conceal deterioration in high-load or unusual environments. The model should record how often engineers override recommendations and how frequently rollback is triggered.
Persistence also influences pricing. A one-off engineering improvement may support project revenue. A continuously monitored optimisation with durable gains may support recurring software fees or benefit sharing. Contract economics should match the work performed after launch.
9. Reconcile throughput and spectral efficiency
Throughput and spectral efficiency are related but distinct. A model can improve the rate experienced by selected users while changing fairness, coverage or resource use elsewhere. A buyer should avoid valuing a headline percentage without the denominator and network context.
The analysis should separate average, median and tail performance. It should identify cell load, radio conditions, device mix, spectrum, scheduler, mobility and measurement period. Performance during congestion may carry more commercial value than performance when capacity is abundant.
SoftBank and Ericsson reported in August 2026 that a commercial-network AI-in-RAN trial achieved location-dependent gains, including up to 25 percent spectral efficiency and up to 50 percent downlink user throughput, with approximately 10 percent average improvement across evaluated locations. These vendor and operator results show feasibility. They do not establish transferable results for another target or network.
10. Validate energy economics
Energy automation can switch capacity, adjust radio states, coordinate cooling or manage site infrastructure. The benefit should be measured against traffic, coverage, service levels, equipment configuration and ambient conditions. Energy savings that depend on new radios or site equipment should be separated from software effects.
Published vendor and operator cases report meaningful results in particular deployments. Ericsson and Far EasTone reported daily RAN energy savings of 25 percent without adverse network performance in their case. Another Ericsson case describes a 14 percent saving from machine-learning-assisted MIMO energy management. These results are useful reference points and remain specific to their stated environments.
The acquisition model should use verified target deployments, local tariffs and expected persistence. It should deduct compute, integration, licensing and operational costs. The benefit can be capitalised only when the operator can retain it and the software has a durable claim on the resulting cash flow.
11. Measure availability and resilience
An automation product can create value while operating normally and destroy value when it behaves incorrectly. Availability analysis should cover the application, data pipeline, controllers, interfaces and target network function. The team should review failure modes and recovery time.
Safe deployment requires guardrails, bounded actions, canary releases, human approvals where appropriate and automatic rollback. Logs should allow an operator to reconstruct why a recommendation or action occurred. A model that cannot be explained at the operational level may still be usable if controls make its behaviour observable and reversible.
Transaction warranties should reflect actual control. The vendor can warrant its software, security and conformance. The operator controls network configuration, implementation and acceptance. Shared responsibility should be documented rather than left to a generic service-level agreement.
12. Quantify engineering productivity
Automation can reduce planning cycles, alarm triage, parameter tuning and repetitive analysis. Productivity value depends on whether engineer time is removed, redeployed or consumed by new integration and monitoring tasks.
The buyer should map the prior workflow and the automated workflow. It should count activities, handoffs, elapsed time, interventions and exceptions. A model that produces recommendations without integration may shift work rather than remove it.
Productivity also supports scale. An operator may manage greater network complexity without proportionate headcount growth. The valuation should connect this effect to approved staffing plans, avoided outsourcing or faster delivery. Unsupported estimates should remain management assumptions and should not be presented as observed savings.
13. Test interoperability in production
Conformance to an interface is necessary and may be insufficient for production interoperability. Vendors can implement optional features differently. Data semantics, performance, security and operational procedures can vary. The buyer should distinguish standards alignment, laboratory conformance, integration success and sustained production use.
The target should provide a deployment matrix covering operator, geography, network vendor, software release, interface, hardware and use case. Repeated deployment with a stable product core is stronger evidence than multiple bespoke projects.
Portability should be measured by elapsed deployment time, engineering effort, reused components, regression defects and performance retained. A target that requires a large custom team may still be valuable as a specialist integrator; it should receive an integrator's economics rather than a product premium.
14. Evaluate O-RAN dependencies
O-RAN creates an architecture for disaggregated and intelligent radio-network functions. Working groups cover service management and orchestration, the non-real-time controller, the near-real-time controller, interfaces and application ecosystems. Release 5, completed in June 2026, included AI and machine-learning workflow enhancements and additional optimisation features.
The buyer should list which specifications the product depends on, which versions customers use and which functions remain vendor-specific. It should identify whether the target sells an rApp, xApp, controller, data platform, assurance layer or integration capability.
Standards participation can improve information, credibility and partner access. It does not guarantee procurement. The valuation should follow live interoperability, operator acceptance and commercial contracts. Standards contributions belong in the strategic-option case.
15. Analyse incumbent-vendor dependence
Many network-automation products rely on incumbent-vendor data, APIs, configuration access or controller behaviour. A change in access policy, licensing, software release or roadmap can affect the target's product.
The diligence team should identify each critical dependency and contractual protection. It should test whether the target has documented interfaces, support commitments, certification and escalation routes. Reverse-engineered or unofficial access can create continuity and legal risk.
Dependence is not automatically negative. A strong partnership can accelerate distribution and integration. Its value depends on durability, economics, exclusivity and change-of-control treatment. The buyer should model both continuation and loss of the relationship.
16. Audit data rights
Network telemetry can contain commercially sensitive, security-sensitive or personal information. The target needs rights to access, process, retain and use data for the contracted purpose. Rights to train general models may be narrower than rights to optimise one customer's network.
The data register should identify source, controller, processor, location, retention, permitted purpose, model use, sharing and deletion. It should connect contracts to actual pipelines. A broad statement that the target owns its data should receive no valuation weight without evidence.
Acquisition can change the permitted use or counterparty. Change-of-control provisions, operator policies and national-security controls may affect continuity. The buyer should secure consents or structure access before completion.
17. Inspect model lineage
Model lineage records the code, training data, features, parameters, evaluation sets, approvals and deployed versions. It enables reproducibility and helps determine which improvements belong to the target, customer or technology supplier.
The target should show how it prevents leakage between customers and protects confidential configurations. It should document open-source and third-party model components, licences and obligations. Training and inference infrastructure should be identifiable and costed.
Lineage becomes an acquisition asset when it shortens validation, supports audit and enables continued development. Weak lineage can turn proprietary performance into an unverifiable claim. The buyer should condition value on a clean and usable record.
18. Review MLOps and lifecycle control
Production network models require monitoring, drift detection, retraining, testing, promotion, rollback and retirement. These processes should operate across customers without creating an unmanageable release burden.
The diligence team should inspect approval roles, automated tests, shadow mode, canary deployment and incident handling. It should compare documented process with release records. A slide describing MLOps is weaker than evidence of controlled model changes.
Lifecycle cost belongs in gross-margin analysis. Customer-specific models, manual retraining and frequent intervention can make reported software revenue service-intensive. The forecast should include compute, engineering and assurance resources required to maintain promised performance.
19. Assess cybersecurity and supply chain
Network automation sits near critical infrastructure. A compromise could expose operational data, alter configurations or disrupt service. Security should cover software development, dependencies, identity, secrets, data, update mechanisms and operational access.
The buyer should review secure-development evidence, vulnerability management, penetration testing, incident history, software bills of materials and privileged-access controls. It should test whether deployment architecture limits blast radius and supports rapid revocation.
National requirements and operator policies can restrict hosting, support locations and supplier ownership. These constraints can affect market access and integration cost. The acquisition plan should include security remediation and customer re-approval.
20. Identify concentration risk
Early network-software companies often depend on a small number of operators, vendors or geographies. Concentration can provide deep validation and create bargaining risk.
Revenue analysis should separate paid production, paid trial, project, pass-through and non-recurring income. The buyer should inspect renewal, expansion, termination, acceptance and most-favoured terms. Pipeline probability should reflect procurement history and deployment readiness.
Technical concentration matters as much as revenue concentration. A product proven on one network stack may require material work elsewhere. The valuation should not treat one operator's footprint as a general market share.
21. Normalise commercial metrics
Annual recurring revenue should include only contracted, recurring consideration for a continuing service. Implementation, hardware, cloud pass-through and engineering projects should be identified separately. Benefit-sharing revenue should be assessed against measurement and dispute provisions.
Gross margin should include deployment engineering, customer support, compute, data movement, third-party licences and lifecycle work. Capitalised development can make current profitability appear stronger while deferring cost to the balance sheet.
Retention should distinguish logo, contract and product retention. Expansion can arise from more cells, regions, modules or measured benefits. The buyer should understand which unit drives price and whether it grows with value delivered.
22. Connect network benefits to cash flow
Technical improvement becomes acquisition value only when it affects cash flow. Energy savings may lower operating expense. Capacity improvement may defer radios or spectrum investment. Better experience may protect revenue or reduce complaints. Faster planning may accelerate rollout.
The bridge should identify the operator's benefit, the target's contractual capture and the buyer's ownership period. A customer benefit does not automatically accrue to the software vendor. Strong evidence can support renewal and pricing, but the contract determines realised revenue.
Benefits should be discounted for attribution, persistence, implementation cost and sharing. The team should avoid adding the same benefit to both the customer's savings and the target's forecast revenue.
Table 2. Evidence ladder for network-automation value
| Evidence stage | Required record | Typical limitation | Valuation response |
|---|---|---|---|
| Simulation or laboratory | Dataset, model, environment and reproducible result | Limited network realism | Research asset only |
| Controlled field trial | Baseline, control, scope and signed result | Short duration or narrow configuration | Contingent technical value |
| Commercial-network trial | Live scope, safeguards and operator validation | Trial economics may not recur | Milestone value |
| Limited production | Contract, service level and persistent KPI | Customer or vendor concentration | Discounted operating value |
| Repeat multi-operator production | Renewals, margins and portability evidence | Remaining scale and market risks | Core enterprise value |
Acquisition value increases when evidence progresses from technical possibility to repeatable contracted economics.
23. Build the automation KPI scorecard
The scorecard should combine performance, economics and control. Performance measures include throughput, spectral efficiency, energy, availability and optimisation precision. Economic measures include avoided cost, deployment effort, gross margin and renewal. Control measures include overrides, rollback, incidents and audit completeness.
Every KPI should identify source, owner, frequency, baseline and threshold. Claimed maximum performance should be shown beside observed averages and conservative acquisition assumptions. This prevents a peak result from dominating valuation.
The scorecard should remain useful after completion. It can support integration priorities, earn-out tests and customer reporting. Definitions should be agreed before signing because changing measurement after closing creates disputes.
Illustrative index scores show how diligence discounts a headline claim for scope, persistence and capture.
24. Model the capex curve
Automation can alter the timing of network capital expenditure. Better use of existing capacity may delay densification. More precise planning may reduce overbuild. Shared compute or new controllers may require additional capital.
The model should compare a conventional plan with an automation-enabled plan by year. It should use the same traffic, coverage, spectrum and service assumptions. Deferred capital should be distinguished from permanently avoided capital because delay still has value and a different terminal effect.
Implementation and compute cost should be included. If a model requires accelerated compute at many sites, the net curve can differ materially from a centralised optimisation service. The buyer should test load, energy and hardware under the target architecture.
Illustrative management assumptions; automation defers part of densification but requires integration and compute investment.
25. Value the present business
The present business can be valued through a discounted cash-flow method, comparable transactions or revenue and earnings multiples, subject to availability and comparability. The forecast should begin with contracted revenue and build through evidence-based expansion.
The buyer should normalise research grants, pilots, hardware and non-recurring engineering. It should include productisation and compliance spending needed to scale. A high growth rate should connect to operator budgets, procurement cycles and deployment capacity.
Comparable companies may combine software, equipment and services. The transaction team should adjust for business mix, margin, concentration, growth, intellectual property and maturity. A generic AI or software multiple can obscure telecommunications economics.
26. Price validated customer value
Validated customer value can support a premium when it is independently measured, repeatable and linked to commercial capture. The buyer can compare the present value of customer benefit with subscription fees and switching costs.
The premium should be limited by competitive alternatives and contract terms. Operators may build similar capability, obtain it from network vendors or procure another independent supplier. Open interfaces can expand the market and lower barriers.
Benefit evidence is strongest when customers renew, expand and permit reference use. A buyer should speak directly with technical, operational and procurement stakeholders. Enthusiasm from an innovation team does not replace a production budget.
27. Value portability
Portability reduces dependence on one customer and one vendor stack. It can accelerate revenue growth and improve strategic relevance. Its value depends on reusable software, stable interfaces, automated onboarding and evidence that performance survives transfer.
The team should calculate a portability coefficient: the proportion of code, models, tests and integration assets reused in the next deployment. It should measure deployment time and engineering effort. These measures should be verified from project records.
The premium can be staged. Part may be paid at closing for demonstrated deployments. Further consideration can follow acceptance on a new operator or stack. This aligns price with realised transferability.
28. Cap 6G option value
The 6G option represents the right to participate in future operator spending and architecture. It should not be valued as forecast 6G revenue when products, timing and procurement remain uncertain.
An option register can score standards relevance, technical reuse, partner access, intellectual property, required investment and time to commercial evidence. The value should be capped by the incremental capital needed and probability of exercise.
Milestones can include approved standards, accepted interfaces, successful trials, operator budgets and signed contracts. Consideration linked to these events protects the seller's upside and the buyer's capital.
29. Construct the valuation bridge
The valuation bridge begins with the present business and adds only distinct, supportable value. It can add validated KPI economics, portability and strategic options. It subtracts integration, concentration, rights, cybersecurity, performance and standards risks.
In the hypothetical case, the parties discuss an enterprise value of USD 300 million. The bridge is a decision aid rather than a valuation opinion. The amounts show how the method prevents the 6G narrative from carrying the entire price.
The buyer should run downside, base and upside cases. Each adjustment needs an evidence owner and closing treatment. Risks that can be cured before signing should be conditions. Risks whose outcome emerges after closing should be reflected through contingent consideration or holdback.
Illustrative management assumptions in USD millions; the future standards option is deliberately capped.
30. Structure consideration
Cash at completion should fund verified present value. Seller rollover can maintain alignment when founders and technical leaders remain important. Earn-outs can pay for revenue, production deployment or validated portability after closing.
Technical earn-outs require objective definitions. The agreement should state the network scope, baseline, KPI, measurement period, control conditions, independent verifier and consequences of buyer decisions. A vague milestone invites conflict.
Milestone payments can address standards and 6G uncertainty. They should reward outcomes within the seller's influence and account for buyer funding. Long schedules need governance, information and dispute provisions.
31. Use representations and indemnities
Representations should cover ownership, licences, data rights, open-source use, security, standards claims, customer contracts, model records and regulatory compliance. They should reflect disclosed facts and actual control.
Specific indemnities or escrow may address identified chain-of-title, cybersecurity or customer-consent issues. Insurance can support parts of the risk and may exclude forward-looking performance.
Technical claims used in valuation should appear in diligence records and transaction schedules. Marketing language should not become an unintended warranty, and material evidence should not remain outside the deal documents.
32. Protect key people and know-how
Network-automation value can depend on engineers who understand operator systems, model behaviour and informal integration pathways. The buyer should map key-person concentration and documentation gaps.
Retention should combine role clarity, incentives, career path and resources. Restrictive covenants require jurisdiction-specific advice. Knowledge transfer should be measured through completed documentation, tests and successor capability.
The operating model should reduce heroic dependence. Product, deployment, data science, standards and customer ownership should have accountable leaders and repeatable processes.
33. Plan integration before signing
Integration decisions affect product credibility. Operators may need to approve a change in ownership, hosting or support. Combining code repositories and security processes too quickly can disrupt releases.
The first plan should preserve service continuity, customer trust, privileged access and roadmap focus. Corporate systems can be integrated in stages. Product architecture should change only through a tested plan.
Synergies should identify owner, cost, timing and dependency. Revenue synergy through the buyer's channels requires technical enablement and procurement access. Cost synergy should not remove the engineering capacity needed for delivery.
34. Build the first 100-day plan
The first 100 days should validate rights, customer commitments, product releases, security controls and KPI baselines. The buyer should freeze a verified inventory of code, models, data, interfaces and deployments.
Customer meetings should confirm continuity and expansion plans. Product teams should reproduce material evidence and establish a common measurement standard. Finance teams should reconcile revenue quality and delivery cost.
The board should approve the present-value roadmap and the option roadmap separately. Capital for future standards work should follow technical and commercial milestones.
35. Create a board dashboard
The board dashboard should cover recurring revenue, renewal, gross margin, deployment time, portability, KPI persistence, incidents, overrides and standards milestones. Each measure needs a stable definition.
The dashboard should show observed, customer-validated and acquisition-case values. It should distinguish maximum results from fleet averages. Exceptions should remain visible.
Management can use the dashboard to decide whether to scale, remediate or stop a use case. A composite score should not hide failure in security, rights or resilience.
Table 3. Hypothetical transaction and financing case
| Item | Base assumption | Diligence condition | Deal response |
|---|---|---|---|
| Enterprise value discussion | USD 300 million | Present business supports majority of value | Limit cash at completion |
| Contracted recurring revenue | USD 36 million | Contract, renewal and revenue-quality review | Base-value input |
| Adjusted EBITDA | USD 8 million | Include delivery, compute and lifecycle cost | Normalise earnings |
| Validated KPI value | USD 32 million bridge contribution | Independent reproduction and persistence | Earn-out or premium |
| Portability value | USD 26 million bridge contribution | Accepted deployment across another stack | Milestone payment |
| 6G option | USD 18 million capped contribution | Standards, trial and contracted adoption gates | Deferred option payment |
| Risk deductions | USD 21 million | Integration, concentration, rights and standards | Price adjustment or escrow |
Illustrative management assumptions only; no amount represents observed company data or a valuation opinion.
36. Establish the diligence workplan
The workplan should join commercial, technical, operational, legal, regulatory, cybersecurity and financial diligence. Separate streams should use one claim register so that the same benefit is not accepted in one workstream and challenged in another.
Material claims should identify evidence, owner, verifier and transaction consequence. The team should prioritise value-bearing claims: recurring revenue, customer savings, portability, rights and future-option dependencies.
Testing should include code and architecture review, data-right mapping, model reproduction, deployment sampling, customer calls and contract reconciliation. Findings should flow into valuation, conditions, covenants and integration.
37. Prepare the data room
The data room should include entity records, intellectual-property assignments, source-code inventory, licences, model lineage, architecture, security evidence, customer contracts, deployments, KPI studies, incident history, financial records and standards contributions.
Evidence should be attributable and dated. Screenshots and presentations should link to underlying records. Customer-sensitive network data may require controlled review rather than broad disclosure.
The target should maintain a red-flag register with owners and closure dates. A clean data room shortens transaction time and improves confidence; it does not replace substantive evidence.
38. Apply a go, reprice or stop decision
A go decision requires a defensible present business, usable rights, manageable integration and a credible path to scale. Repricing is appropriate when the asset remains useful and value claims exceed evidence. A stop decision is appropriate when critical rights, security, customer continuity or technical attribution cannot be cured.
The decision should be explicit about future optionality. A buyer can acquire a valuable 5G automation business while assigning little value to 6G. It can also pursue a partnership or option instead of acquiring an immature platform.
Decision records should identify assumptions and unresolved matters. This preserves accountability when technology and standards evolve.
Table 4. Board and diligence scorecard
| Domain | Minimum evidence | Red flag | Decision response |
|---|---|---|---|
| Revenue | Contracts, invoices, renewals and margin bridge | Trial income presented as recurring | Normalise or reprice |
| KPI impact | Baseline, counterfactual, persistence and customer validation | Peak claim without raw evidence | Exclude uplift |
| Interoperability | Repeat deployment across defined stacks | Bespoke integration hidden as product | Reduce product premium |
| Data and models | Rights, lineage, reproducibility and lifecycle control | Training rights unclear | Cure before completion |
| Security | Secure development, access control and incident evidence | Critical-infrastructure exposure | Remediate or stop |
| 6G option | Standards map, reusable capability and adoption milestone | Forecast revenue before product definition | Cap and defer value |
Each domain requires evidence before material value is attributed.
39. Recognise limitations
This framework supports acquisition analysis. It does not determine whether a product is safe, compliant or suitable for a specific network. Qualified technical, regulatory, security, legal, tax, accounting and valuation advice is required.
Standards, interfaces and operator plans continue to evolve. Results published by vendors and operators are specific to their described deployments. They should not be generalised without reproduction.
The hypothetical case demonstrates a method. Actual revenue, costs, benefits, probabilities, terms and values require transaction-specific evidence. No figure in the case is a forecast or recommendation.
40. Conclude with evidence before optionality
Network automation can create measurable value before 6G. It can lower energy use, improve capacity, strengthen resilience and make engineering more productive. Acquisition value follows when those effects are attributable, persistent, contractually captured and portable.
AI-RAN architecture and standards activity broaden the strategic opportunity. They also increase the need for precise definitions. Standards alignment should be mapped; interoperability should be demonstrated; future value should be staged.
The disciplined transaction sequence is to value the present operating business, verify customer outcomes, test portability, price integration and rights risk, and place 6G upside behind observable milestones. This approach allows a buyer to participate in future network intelligence while paying today for evidence that exists today.
References
- International Telecommunication Union. IMT-2030 technical performance requirements for the 6G future. 17 March 2026. https://www.itu.int/hub/2026/03/imt-2030-technical-requirements-for-the-6g-future/
- International Telecommunication Union. IMT-2030 portal and process. https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2030/pages/default.aspx
- International Telecommunication Union. Recommendation ITU-R M.2160-0: Framework and overall objectives of the future development of IMT for 2030 and beyond. 2023. https://www.itu.int/rec/R-REC-M.2160-0-202311-I
- International Telecommunication Union. Work programme: framework for network architecture for IMT-2030. https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=23853
- O-RAN Alliance. Working Group 2: Non-real-time RIC and A1/R1 interfaces. https://www.o-ran.org/technical-groups/wg2
- O-RAN Alliance. Technical groups. https://www.o-ran.org/technical-groups
- O-RAN Alliance. O-RAN Alliance completed Specification Release 5. 8 June 2026. https://www.o-ran.org/blog/o-ran-alliance-completed-its-specification-release-5-o-ran-r005
- O-RAN Alliance. 60 new or updated O-RAN technical documents released since March 2025. https://www.o-ran.org/blog/60-new-or-updated-o-ran-technical-documents-released-since-march-2025
- O-RAN Alliance. Open and AI-driven RAN priorities. 28 March 2025. https://mediastorage.o-ran.org/press-release/O-RAN.EC.2025-03-28.PR%20MWC25%20summit%20messages.pdf
- 3rd Generation Partnership Project. 3GPP Highlights, Issue 10. https://www.3gpp.org/images/newsletters/3GPP_Highlights_Issue_10_WEB.pdf
- Ericsson. Far EasTone uses AI and machine learning for RAN energy savings. 2023. https://www.ericsson.com/en/cases/2023/ericsson-far-eastone
- Ericsson. Augmenting MIMO energy management with machine learning and AI. https://www.ericsson.com/en/cases/2019/augmenting-mimo-energy-management-with-machine-learning-and-ai
- Ericsson. Elisa Finland and Ericsson energy-efficiency case. 2023. https://www.ericsson.com/en/cases/2023/elisa-finland-and-ericsson
- Ericsson and SoftBank. Japan commercial-network AI-in-RAN trial. 20 August 2026. https://www.ericsson.com/en/press-releases/2/2026/softbank-corp-and-ericsson-conduct-japans-first-trial-of-ericsson-ai-in-ran-on-5g-commercial-network
- Ericsson. The RAN gets smarter: Ericsson puts AI where it matters. June 2026. https://www.ericsson.com/en/news/2026/6/the-ran-gets-smarter-ericsson-puts-ai-where-it-matters
- Ericsson and KDDI. Live AI-powered RAN optimisation rApps. 2026. https://www.ericsson.com/en/cases/2026/kddi-boosts-uplink-with-live-ai-powered-ran-optimization-rapps
- Ericsson and AT&T. Shaping the networks of tomorrow with a programmable network. 2025. https://www.ericsson.com/en/cases/2025/shaping-networks-of-tomorrow
- Ericsson and TAWAL. Energy infrastructure operations in Saudi Arabia. 2023. https://www.ericsson.com/en/press-releases/5/2023/tawal-reaps-benefits-of-ericsson-energy-infrastructure-operations-in-saudi-arabia
- SoftBank. AI-RAN: Unveiling the Future of Telecom with Breakthrough Innovations. 7 February 2025, version 1.1. https://www.softbank.jp/corp/set/data/technology/research/story-event/wp_location/pdf/SoftBank_AI-RAN%20Unveiling%20the%20Future%20of%20Telecom%20with%20Breakthrough%20Innovations_Feb7_2025_Ver.1.1.pdf
- IFRS Foundation. IFRS 3 Business Combinations. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
- IFRS Foundation. IAS 36 Impairment of Assets. https://www.ifrs.org/issued-standards/list-of-standards/ias-36-impairment-of-assets/
- IFRS Foundation. IAS 38 Intangible Assets. https://www.ifrs.org/issued-standards/list-of-standards/ias-38-intangible-assets/
- IFRS Foundation. IFRS 13 Fair Value Measurement. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/
About the Author
Chennakeshav (CK) is a corporate finance and investment banking executive with 25+ years of global experience in deal origination, structuring and execution across M&A, growth capital and corporate strategy. He has led value-creation mandates for founders, corporates and funds — bridging the boardroom view to hands-on execution and close.
His career spans Morgan Stanley, HSBC, Lloyds Banking Group, EWEC, ADQ portfolio companies and Emirates Growth Fund, across TMT, real estate, fintech, deeptech, cleantech, infrastructure and energy. He has partnered with C-suite leaders, private equity and venture funds, sovereign wealth funds and family offices to finance complex fund raises and scale-up ventures, and has led M&A due diligence, post-merger integration and business-transformation initiatives to create value.
At Matchpoint Partners he is Managing Partner, leading the firm's corporate finance, M&A and capital-raising practice. He holds an MBA from London Business School, an engineering degree from VTU and a Master of Laws (LLM, in progress) from UCL London.
An active start-up mentor, CK mentors at Techstars, DIFC FinTech Hive, Startup Grind, Founder Institute and IN5, serves as Entrepreneur Mentor in Residence (EMiR) at London Business School, and judges the Entrepreneurship World Cup.
https://www.linkedin.com/in/ckadya/
https://www.matchpoint-partners.com/team/ck-adya.html
This paper is part of a continuing series on the structure of private and alternative markets. The views expressed are the author's own. The paper is for information only, describes market structure in general terms, and does not constitute investment, legal, tax or regulatory advice or a recommendation in respect of any security, vehicle or counterparty.
