1. Define the service before the node
An edge investment should begin with a workload and a measurable service outcome. A building, rack or server located outside a hyperscale region has limited standalone meaning. Its value arises when proximity improves latency, bandwidth use, autonomy, data control, resilience or customer experience enough to support revenue.
The service definition should state the user or machine population, application, data source, processing path, latency budget, throughput, availability, recovery, security, retention and geographic constraint. It should also state which elements remain in a central cloud or hyperscale region.
3GPP describes edge computing as bringing core-network and cloud-computing capabilities closer to customers to reduce physical distance and latency.[1] ETSI defines Multi-access Edge Computing as an information-technology service environment at the network edge and recognises deployment options from on-premise edge to network edge.[2][3] These definitions support a placement continuum rather than one fixed asset type.
The investment case should compare at least three placements: central region, metropolitan or network edge, and customer or operational edge. Each placement carries a different combination of cost, performance, control and scale.
Author framework. Workload evidence should determine placement before capital is committed.
2. Build an edge taxonomy
The word edge can describe devices, gateways, enterprise rooms, telecommunications sites, metropolitan facilities and regional data centres. A financing file needs a stable taxonomy because land rights, power, cooling, security, operating model and replacement differ by location.
An on-device or gateway layer processes a narrow workload near the data source. Customer-premise edge can sit within an industrial, retail, healthcare, logistics or office site. A far-edge node can occupy a street cabinet, base-station or access location. A near-edge node can serve a metropolitan cluster. An in-country regional facility can aggregate workloads and connect to central cloud regions.
The European Commission's Edge Observatory monitors categories including on-premise, far edge, near edge and in-country edge data centres.[4] Its 2025 work examines taxonomy, deployment trends, sustainability and security in Europe and international markets.[5] This public taxonomy offers a useful benchmark while each project retains its own contractual definitions.
Table 1. Distributed-compute node taxonomy
| Node type | Typical location | Service role | Principal asset risk | Financing implication |
|---|---|---|---|---|
| Device or gateway | machine, vehicle or local equipment | filtering, control and immediate response | embedded hardware, narrow use and replacement | generally financed with equipment or service contract |
| Customer-premise edge | factory, hospital, campus, store or warehouse | local analytics, private applications and data control | customer access, tenancy and environment | customer-backed lease or managed-service model |
| Far edge | access, tower, street or network site | radio, content, network and low-latency service | small power envelope, physical security and fragmented operations | portfolio lease, operator credit and standard node design |
| Near edge | metropolitan colocation or telecom facility | multi-tenant compute and regional application delivery | utilisation, fibre diversity and competitive supply | staged project or portfolio capital with anchors |
| In-country regional | national data-centre campus | aggregation, control, storage and cloud interconnection | larger capex, power connection and market concentration | conventional data-centre finance with distributed-service overlay |
| Central cloud region | hyperscale availability zone | elastic compute, storage and control plane | concentration, distance and egress dependency | hyperscale or wholesale data-centre model |
Capacity and operating characteristics require site-specific evidence.
3. Screen workloads for edge value
Low latency alone does not establish willingness to pay. The diligence case should identify the maximum end-to-end latency, the portion attributable to network distance, and the economic consequence of missing the target.
Industrial control, machine vision and safety systems can require fast and dependable response. Video analytics can reduce backhaul by processing large streams locally. Content delivery and gaming can improve response and reduce transit. Private networks can combine local packet processing with application compute. Regulated or sensitive data can require geographic or organisational control.
Some workloads remain better in central regions. Batch analytics, model training, archival storage and applications with little network sensitivity can benefit from scale, resource pooling and specialised hardware. A hybrid design can keep data ingestion or inference at the edge while using central capacity for training, orchestration and durable storage.
Every workload should pass five tests: a measured proximity benefit, a defined user population, sustained resource demand, a technically feasible placement and an enforceable payment route.
4. Translate latency into a service-level agreement
An application latency budget should decompose device, radio or access, transport, routing, application, storage and response time. Moving compute closer affects only part of that chain.
3GPP notes that edge placement can reduce latency materially under illustrative network assumptions.[1] ETSI MEC specifications support network and service information through standardised interfaces.[2] The contracted service should define the measurement point, percentile, interval, exclusions and remedy.
Average latency can conceal tail events. A service-level agreement may require a 95th, 99th or higher percentile, depending on the workload. Availability, packet loss, jitter and processing time may matter alongside latency.
Customer remedies should reflect the economic service. Credits can be appropriate for non-critical content delivery. Industrial or safety applications may require fail-safe operation, local autonomy, redundant nodes and carefully limited liability after qualified legal review.
5. Design the distributed architecture
A distributed platform needs a common control plane across heterogeneous sites. It should manage workload placement, identity, configuration, software images, observability, capacity, security policies, billing and failover.
The data plane may remain local while the control plane operates regionally or centrally. Some services require autonomous local operation during a wide-area network interruption. The architecture should state what continues, for how long, and how state reconciles after recovery.
Federation can allow workloads to move among operators, countries or providers. 3GPP work on edge applications includes discovery, roaming, federation and edge-node sharing.[6] ETSI maintains deployment and federation guidance across its MEC work.[3]
Interoperability should be tested rather than assumed. Hardware accelerators, virtualisation, containers, network functions, application interfaces and telemetry can create vendor dependencies that reduce asset reuse.
Author framework based on a hybrid control and workload model.
6. Establish the evidence file
The demand file should identify customer, workload, location, resource requirement, start date, ramp, contract, service level and termination. Non-binding forecasts should remain separate from contracted minimum payments.
The site file should cover tenure, access, planning, power, fibre, cooling, environmental range, physical security and operating responsibility. Telecom sites and customer premises may lack the space, noise control, power quality or cooling normally available in a data centre.
The technical file should include the workload architecture, hardware, accelerators, storage, networking, software stack, orchestration, telemetry, cyber controls, failover and acceptance tests. The commercial file should reconcile price, usage, minimum commitment, installation, migration, data transfer, support and exit.
Table 2. Edge-infrastructure evidence file
| File | Minimum content | Control | Decision use |
|---|---|---|---|
| Demand | named workload, user location, resource profile, start, ramp and payment | contract and technical-owner confirmation | deploy, defer or centralise |
| Site | tenure, access, power, cooling, fibre, security and environmental conditions | survey, utility and operator evidence | readiness and capital requirement |
| Network | route, carrier, latency, throughput, diversity, quality and failure modes | measured test and enforceable service level | service feasibility and resilience |
| Platform | compute, storage, accelerator, virtualisation, orchestration and licences | bill of materials and tested configuration | capex, reuse and refresh |
| Security | identity, boot, firmware, keys, isolation, patching, logging and response | approved architecture and independent test | workload eligibility and risk |
| Operations | monitoring, remote hands, spares, maintenance, incident and recovery | operating model and service records | availability and operating cost |
| Finance | revenue, capex, operating cost, tax, debt, reserves and residual value | integrated node and portfolio model | capital release and return |
Evidence should be current, attributable and reconciled across demand, assets and operations.
7. Gate power, cooling and fibre
Small node size does not remove infrastructure constraints. ITU-T L.1307 states that micro data centres require power sized for servers, storage, network, cooling, security and operations, together with environmental monitoring and energy-management information.[7][8]
The site survey should test available and maximum power, voltage, redundancy, distribution, backup, grounding, metering, heat rejection, ambient range, dust, humidity and fire systems. A nominal building supply may have insufficient continuous capacity after cooling and redundancy.
Fibre readiness should include physical route, carrier diversity, meet point, latency, throughput, packet performance, protection, repair and service credits. Two commercial contracts can share the same duct and fail together.
The capital model should distinguish reusable infrastructure from workload-specific equipment. Power distribution, secure enclosure and fibre can support multiple refresh cycles. Accelerators and specialised appliances may have shorter lives and limited alternative use.
Author framework. Every layer should pass before hardware is delivered to a site.
8. Price the climate and operating environment
Gulf edge sites can face high ambient temperature, dust, humidity and access constraints. Equipment ratings, filters, enclosure, cooling, corrosion protection and maintenance intervals should match the location.
Operating expenditure can be high per unit of compute because technicians, spares and travel are distributed. Remote monitoring and standard designs reduce variation, while critical repairs still require qualified local support.
The model should include site rent, power, network, licences, monitoring, remote hands, preventive maintenance, filters, batteries, spares, travel, insurance and security. A low-cost host location can become expensive after adaptation and service requirements.
Energy efficiency should be measured at the node and portfolio levels. A small lightly utilised site can have poor fixed-overhead efficiency even when its equipment is modern. Useful workload output should accompany facility energy measures.
9. Underwrite security as an operating system
Distributed infrastructure increases the number of physical locations, network paths, administrators and hardware instances. NIST identifies broader attack surfaces and inconsistent control implementation as important cloud and edge risks, and recommends a layered platform-security approach.[9]
The control baseline should cover secure boot, signed firmware, hardware roots of trust, virtualisation isolation, keys, encryption, identity, privileged access, patching, vulnerability management, logging, incident response and secure disposal. Remote sites also need tamper detection, controlled access and asset inventory.
NIST's 2026 5G network-security principles address separation of data, control and operations traffic.[10] The final architecture should be reviewed against the applicable jurisdiction, customer requirement and critical-infrastructure classification.
Security acceptance should occur before production workload and after material changes. A remote node that cannot be patched, attested or isolated should not receive a sensitive workload merely because it improves latency.
10. Map Gulf deployment conditions
The UAE and Saudi Arabia have invested in advanced mobile and cloud infrastructure. TDRA reported UAE 5G coverage above 99.5 per cent of populated areas and more than 23,000 sites in November 2025.[11] Its 2024 work allocated additional spectrum for advanced mobile services and connected applications, with implementation expected during 2025 and 2026.[12]
TDRA's October 2024 private-5G workshop identified network construction cost and technical requirements among deployment challenges.[13] These are relevant to edge cases that combine private networks with local compute.
Saudi CST regulates cloud services and requires provider registration under defined conditions.[14][15] Its cloud information describes physical, virtual and service layers and highlights security and business-continuity considerations.[16] These requirements need current legal interpretation for each proposed service and data class.
GSMA's MENA analysis found that 5G Standalone deployments were concentrated in Gulf states by 2023 and identified edge compute and network slicing among important 5G-Advanced capabilities.[17] This creates technical foundations, while commercial demand and site economics still require transaction-specific evidence.
11. Benchmark international deployment
The European Union's Digital Decade programme targets at least 10,000 highly secure, climate-neutral edge nodes by 2030.[18] The European Commission's 2026 digital-decade assessment reports an estimated 7,451 qualifying nodes at the end of 2025, across on-premise, far-edge, near-edge and in-country categories.[19]
The same assessment describes a larger population when climate-neutral and security criteria are set aside, showing that node counts depend materially on definition. It also observes geographic concentration and a strong role for on-premise deployments.[19]
This benchmark supports three lessons for Gulf finance. Edge development can involve many small sites rather than a single new asset class. Qualification standards can determine which nodes support regulated or high-value workloads. Deployment can concentrate around industrial and metropolitan demand even when policy seeks broad coverage.
International numbers should not be transferred directly into Gulf forecasts. Population, industry, network topology, regulation, cloud regions and customer demand differ. The value lies in architecture, taxonomy and deployment discipline.
12. Build the revenue model
Edge revenue can arise from reserved compute, metered compute, network service, storage, platform licences, managed applications, installation and support. The model should avoid counting the same customer payment in both network and compute revenue.
A minimum capacity payment can support node capex. Usage revenue can provide upside when measurement and price are clear. An availability or performance payment can align service, though credits and penalties require conservative modelling.
Data-transfer and cloud-egress charges can affect customer economics. The comparison should include the complete application cost across edge, network and central cloud. A low node price can be offset by integration, platform and operational expense.
Customer concentration is especially important during early deployment. One anchor can make a node financeable and create termination risk. Contracts should address migration, early termination, equipment ownership, data return and site restoration.
Table 3. Edge-service contract and risk matrix
| Contract element | Minimum definition | Principal risk | Protection mechanism |
|---|---|---|---|
| Reserved capacity | compute, memory, storage, accelerator and term | payment covers capacity while workload ramps | minimum payment and commissioning gate |
| Usage | meter, unit, interval and price | volume below forecast or disputed measurement | auditable meter, floor and reconciliation |
| Service level | latency, availability, throughput and exclusions | credits exceed margin or service is unmeasurable | clear point of measurement, cap and cure |
| Site access | rights, hours, emergency entry and host obligations | inability to maintain or recover equipment | enforceable access and step-in rights |
| Network | route, capacity, diversity, performance and repair | common-mode fibre failure | route evidence, dual carrier and remedy |
| Security | control baseline, audit, incident and data handling | workload loss, breach or regulatory action | acceptance, audit, notification and allocation |
| Refresh | trigger, scope, price and migration | obsolete equipment or unfunded replacement | indexed refresh charge and technology reserve |
| Exit | termination, data, equipment, software and restoration | stranded capex and operational disruption | termination payment, reuse rights and transition plan |
Terms require project-specific technical, commercial and legal review.
13. Standardise the node design
Standardisation can reduce survey, design, procurement, spares, training, software and acceptance cost. A platform can use several capacity classes while maintaining common power, network, management and security interfaces.
The reference design should specify enclosure, power envelope, cooling, racks, compute, storage, accelerator options, network, security, telemetry and commissioning. Variants should require approved reasons such as host constraint, workload or regulation.
Standard hardware alone is insufficient. Software images, configuration, observability, service catalogue, billing and operational procedures should also be controlled. Configuration drift can increase outage and cyber risk across a large fleet.
Procurement should preserve competition and substitution. Component interfaces, software portability, data export and workload migration can protect residual value when a supplier changes strategy or pricing.
14. Stage capital by deployment wave
A distributed programme should avoid purchasing a full fleet against demand forecasts. Capital can be released through repeatable gates: signed workload, site control, power and fibre readiness, design approval, delivery, technical acceptance and revenue commencement.
Long-lead equipment and price commitments can be managed through framework agreements, call-off orders and volume bands. Cancellation and rescheduling terms have financial value and should be modelled.
Portfolio construction can begin with a small number of anchor nodes that test demand, operations and platform portability. Later waves can expand within proven service zones and introduce new locations after evidence improves.
Author framework. Capital should follow evidence and acceptance at each deployment wave.
15. Integrate node and portfolio economics
The node model should calculate revenue, equipment, site adaptation, installation, power, network, software, support, maintenance, rent, insurance, tax, working capital and replacement. It should also identify shared platform costs outside the node.
The portfolio model should consolidate central orchestration, network operations, security operations, engineering, spares, procurement, sales and general administration. Allocation rules should avoid presenting a positive node margin while shared costs remain unfunded.
Utilisation should be measured by billable resource and constrained component. Processor, accelerator, memory, storage, network and power can have different utilisation. Average server utilisation can conceal a bottleneck that prevents new revenue.
Residual value should be conservative. General-purpose equipment may move between nodes or to a central facility. Specialised hardware, short vendor support or customer-specific appliances can have limited recovery value.
16. Finance the portfolio
Early deployments may rely on sponsor equity, vendor finance, customer prepayments or corporate facilities because contracted cash is limited and assets are dispersed. Project or asset-backed debt becomes more plausible as the platform establishes recurring revenue, standard assets and performance history.
Debt sizing should use contracted minimum payments, termination protection, proven operating costs and conservative residual value. Usage upside can remain outside the base debt case.
Security may include equipment, receivables, bank accounts, contracts, insurance and rights under site agreements, subject to local law and host consent. Lenders need access and step-in arrangements that remain practical across many locations.
Portfolio diversification can reduce exposure to one site and introduce correlation through common software, supplier, network or customer. Stress testing should include simultaneous fleet events.
Hypothetical management values demonstrate the reconciliation; they are not an actual forecast.
17. Test a hypothetical 24-node platform
The following case demonstrates the method. Every value is a hypothetical management assumption. It does not describe an actual network, operator, customer or investment result.
Assume a platform deploys 24 nodes across six metropolitan and industrial service zones. Four regional aggregation nodes each provide 1.5 MW of IT capacity. Eight near-edge nodes each provide 400 kW. Twelve customer or far-edge nodes each provide 100 kW. Total initial IT capacity is 10.4 MW.
Assume 70 per cent of initial capacity is covered by five-year minimum service commitments at acceptance. Usage revenue begins above the commitment. The central platform provides orchestration, security, monitoring, billing and workload mobility.
Table 4. Hypothetical 24-node edge-platform case
| Item | Hypothetical management assumption |
|---|---|
| Total nodes | 24 across six service zones |
| Installed IT capacity | 10.4 MW |
| Initial committed capacity | 7.3 MW equivalent |
| Total development and equipment capex | USD 96 million |
| Central platform and launch capex | USD 14 million |
| Sponsor equity | USD 70 million |
| Senior and vendor facilities | USD 40 million |
| Full-year contracted revenue after ramp | USD 18.0 million |
| Full-year usage and ancillary revenue | USD 4.2 million |
| Full-year site, power, network and platform operating cost | USD 11.9 million |
| Annual refresh reserve | USD 1.9 million |
| Portfolio cash before debt service and tax | USD 8.4 million |
| Hypothetical cash yield on sponsor equity | 12.0% |
Every number is a hypothetical management assumption created solely to demonstrate the method.
The hypothetical base case depends on committed revenue and portfolio operating discipline. Usage increases the return, while the funding case should remain viable without assuming maximum node utilisation.
The model should also show cash by deployment wave. Capital can precede revenue by several months, and customer acceptance can shift even when construction finishes on time.
18. Stress demand, technology and operations
Edge risk can transmit across commercial, technical and operating systems. A delayed workload creates idle site and equipment cost. A hardware shortage delays several nodes. A common software defect can interrupt the entire fleet.
Refresh risk is central. Compute performance and customer requirements can change within a debt term. Contracts should allocate refresh cost and preserve migration rights. The model should fund replacement on a schedule or through contracted charges.
The operating case should include technician response, spare availability, access restrictions and extreme environmental events. A remote node can experience a longer outage than a staffed central facility.
Table 5. Distributed-compute stress matrix
| Stress | Hypothetical management case | Financial transmission | Required response |
|---|---|---|---|
| Anchor delay | two major workloads start nine months late | idle capex, lower revenue and working-capital draw | call-off gate, customer payment and redeployment rights |
| Utilisation shortfall | billable capacity reaches 45% rather than 65% | lower usage revenue and weak node margin | contract floor, resize and consolidate workloads |
| Hardware obsolescence | refresh moves forward by 18 months | higher capital and disposal loss | refresh reserve, customer charge and modular design |
| Common software event | fleet-wide outage lasts six hours | service credits, remediation and reputational loss | staged release, rollback, isolation and tested recovery |
| Fibre failure | two contracted routes share one duct | multi-node service interruption | physical-route evidence and alternative access path |
| Power and cooling constraint | six sites lose 20% usable capacity in peak conditions | curtailed compute and lost revenue | environmental design, power cap and workload movement |
| Customer termination | anchor exits at first break date | stranded node and concentration loss | termination payment, portable hardware and replacement pipeline |
| Regulatory change | data or cloud requirement changes | migration, redesign or ineligible service | jurisdiction review, data controls and change clause |
Every scenario is a hypothetical management assumption and should be replaced with project-specific evidence.
19. Operate through one dashboard
The platform dashboard should report contracted and used capacity, revenue, workload performance, latency, availability, power, energy efficiency, temperature, network quality, incidents, security state, patching, spares and customer credits.
Portfolio metrics should remain decomposable to node, customer and workload. Aggregation can conceal an unprofitable site or repeated service failure.
Capacity planning should consider resource-specific headroom, expected demand, delivery lead time and available migration. ITU-T L.1307 recommends considering expansion and offloading to nearby micro data centres or central cloud before physical expansion.[7]
The operating committee should approve new capacity, refresh, consolidation and closure. A node with weak demand can serve resilience or regulatory value, but that purpose and funding should be explicit.
20. Procure interoperability and exit
Procurement should require standard interfaces, supported software, security updates, telemetry export, workload portability and documented dependencies. Commercially attractive hardware can create long-term platform lock-in through licences or proprietary orchestration.
Supplier diligence should cover product roadmap, support term, component availability, vulnerability response, warranty, replacement and financial capacity. A distributed estate magnifies the cost of an unsupported component.
Exit planning should state how workloads migrate, data returns, equipment moves, licences terminate and sites restore. Reusable assets should be identified by node class and location.
Federation can expand demand and resilience when commercial, technical and security responsibilities are clear. Identity, charging, discovery, service levels, data and incident handling need consistent treatment across providers.
21. Execute through 150 days
The programme should move from workload evidence to architecture, site validation, market testing, contracts, financing and a controlled first wave. A portfolio-wide procurement can proceed alongside node-specific capital gates.
Author framework. Every gate requires approved evidence, ownership and a recorded decision.
Table 6. 150-day edge-platform execution plan
| Days | Workstream | Principal output | Gate |
|---|---|---|---|
| 1 to 15 | workload and service | user, application, placement, latency, data and payment definition | edge need approved |
| 16 to 35 | architecture and taxonomy | node classes, control plane, workload mobility and security | reference design approved |
| 36 to 55 | site and network survey | tenure, access, power, cooling, fibre, environment and operations | sites classified by readiness |
| 56 to 75 | market engagement | host, network, equipment, platform, operations and finance offers | executable options received |
| 76 to 95 | integrated model | node and portfolio revenue, capex, cost, refresh, cash and stress | wave economics accepted |
| 96 to 115 | contracts and regulation | customer, site, network, cloud, data, security and supplier terms | risk allocation approved |
| 116 to 135 | pilot acceptance | installed first wave, measured service and operating evidence | acceptance and payment confirmed |
| 136 to 150 | financing and decision | facility, reserves, conditions, dashboard and expansion rules | deploy, revise or defer |
Sequencing is indicative and should reflect workload, site, regulatory and procurement status.
22. Set the investment decision
The committee should approve workload placement, node class, service boundary, sites, power, cooling, fibre, platform, security, operating model, customer contracts, supplier agreements, capital, financing, refresh and exit.
Conditions should cover site access, utility capacity, fibre diversity, technical acceptance, customer minimum payment, regulatory review, security testing, insurance, lender consent and central-platform readiness.
The platform should pause or resize when latency value is unmeasured, demand lacks a payment route, site readiness is incomplete, equipment arrives before acceptance conditions, software portability is weak, common-mode failure is uncontrolled or refresh remains unfunded.
Expansion should follow evidence from the live fleet. A new node can be approved when the workload cannot be served economically through existing capacity and the incremental contract supports the complete node and platform cost.
23. Limitations and conclusion
Applications, networks, standards, data rules, cyber threats, hardware, energy, cloud services, customer demand and capital markets can change. Decisions require current evidence from customers, operators, utilities, site hosts, vendors, engineers, cyber specialists, regulators, lawyers, lenders and qualified advisers.
The cited sources describe standards, public programmes, regulatory materials and technical guidance within their stated purposes. They do not establish the demand, latency, security, cost, licensing, revenue or return of a specific Gulf edge platform.
Every numerical value and result in the worked case is a hypothetical management assumption. No actual customer, network, node, revenue, capital structure or investment result is represented.
Distributed compute becomes financeable when proximity creates a measurable service, each node passes power and fibre readiness, common controls make the fleet operable, and customer payments support both local and shared costs.
The most valuable architecture may combine central cloud, regional facilities and a selective edge layer. Evidence-led placement, standard nodes, staged capital and workload portability allow investors to capture proximity value without funding an unproven fleet.
References
- [1] 3GPP, Edge Computing, official technology overview, 5 June 2023. https://www.3gpp.org/technologies/edge-computing
- [2] ETSI, Multi-access Edge Computing, official technical-group page and specifications, accessed 13 August 2026. https://www.etsi.org/technical-groups/mec/
- [3] ETSI, MEC White Papers, official catalogue, accessed 13 August 2026. https://portal.etsi.org/TB-SiteMap/MEC/MEC-White-Papers
- [4] European Commission, The Edge Observatory for the Digital Decade, official policy page. https://digital-strategy.ec.europa.eu/en/policies/edge-observatory
- [5] European Commission, The Edge Observatory Publications, updated 15 July 2026. https://digital-strategy.ec.europa.eu/en/policies/edge-observatory-publications
- [6] 3GPP, EDGEAPP: Roaming, Federation and Edge Node Sharing, 19 September 2023. https://www.3gpp.org/technologies/edge-app
- [7] International Telecommunication Union, Recommendation ITU-T L.1307: Energy Efficiency in Micro Data Centres for Edge Computing, approved 8 March 2024. https://www.itu.int/rec/T-REC-L.1307-202403-I/en
- [8] International Telecommunication Union, ITU-T L.1307 Recommendation Database Summary. https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=15767
- [9] United States National Institute of Standards and Technology, NIST IR 8320: Hardware-Enabled Security for Cloud and Edge Computing, 4 May 2022. https://doi.org/10.6028/NIST.IR.8320
- [10] United States National Institute of Standards and Technology, 5G Network Security Design Principles, March 2026. https://csrc.nist.gov/pubs/cswp/36/e/5g-network-security-design-principles/final
- [11] UAE Telecommunications and Digital Government Regulatory Authority, TDRA Announces the Launch of the 6G Initiative, 11 November 2025. https://tdra.gov.ae/en/media/press-release/2025/6-g
- [12] UAE Telecommunications and Digital Government Regulatory Authority, National Frequency Plan Update for International Mobile Telecommunications, 30 November 2024. https://tdra.gov.ae/en/media/press-release/2024/international-mobile-telecommunications
- [13] UAE Telecommunications and Digital Government Regulatory Authority, TDRA Holds Workshop on Private 5G, 25 October 2024. https://tdra.gov.ae/en/media/press-release/2024/tdra-holds-workshop-on-private-5g
- [14] Saudi Communications, Space and Technology Commission, Cloud Computing Service Provisioning Regulations, approved 8 October 2023. https://www.cst.gov.sa/en/regulations-and-licenses/decisions/Regulation-1482
- [15] Saudi Communications, Space and Technology Commission, Cloud Computing Registration, official service page. https://www.cst.gov.sa/en/business/services/Cloud-Computing-Registration
- [16] Saudi Communications, Space and Technology Commission, Cloud Computing, official knowledge page, accessed 13 August 2026. https://www.cst.gov.sa/en/knowledge-center/digital-knowledge/cloud-computing
- [17] GSMA, The Mobile Economy Middle East and North Africa 2023, December 2023. https://www.gsma.com/solutions-and-impact/connectivity-for-good/mobile-economy/wp-content/uploads/2023/12/051223-Mobile-Economy-Middle-East-and-North-Africa-2023.pdf
- [18] European Commission, State of the Digital Decade 2024, Edge Nodes analysis. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52024DC0260
- [19] European Commission, State of the Digital Decade 2026, Edge Infrastructure assessment, June 2026. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52026DC0288
About the Author
Chennakeshav Adya is an independent researcher and Managing Partner of Matchpoint Partners. His research focuses on investment strategy, capital formation, transaction execution, governance and operating-model design across international markets.
