Run each inference or network-function workload on the cheapest tier whose measured end-to-end latency, under realistic load, still fits the SLA budget after radio and transport take their share. That means the cell-site edge only where a round trip to the regional data centre breaks the budget, and regional or core everywhere else. The same measurements then tell you how much GPU capacity each site needs, and they become the evidence an architecture board needs before approving edge infrastructure capex. That is why the rule is worth writing down once and reusing for every workload, instead of arguing it again for each deployment.

Where edge infrastructure sits: cell site, edge cloud, regional DC, core

A study of URLLC network slicing for industrial campus networks describes a four-tier topology. Cell sites (Tier-0) host the radio units and feed a smaller number of edge clouds (Tier-1), which can host DUs and CUs. The edge clouds connect to fewer regional clouds (Tier-2), and those connect to a small number of core cloud sites (Tier-3). The cell tower or small cell is the edge location closest to the user, local aggregation and regional centres sit further in, and latency rises as the edge moves away from the user.

Tier	Typical location	Latency it suits	What it trades
Access (cell-site) edge	Cell towers, hub sites, within about 15 km of the radio heads	Sub-1 ms to 30 ms workloads, per the LF Edge glossary	Fastest response, least compute per site
Edge cloud / aggregation	One hop up from the access edge, a medium data centre or interconnected micro data centres	No single published range	Failover and scale across several access sites
Regional edge / regional DC	Regional mobile network facilities with core equipment, fibre, power and cooling	30 ms to 100 ms workloads, per the LF Edge glossary	Easier to staff and scale, higher latency than radio or aggregation sites
Core / central DC	Centralised data centres	Latency-tolerant and non-real-time applications	Economies of scale that distributed edge sites struggle to match

For AI inference, the important difference between edge infrastructure and a regional or cloud data centre is the trade between distance and pooled compute, more than the hardware class. Nodes closer to the edge have lower network delay but fewer computing resources, so their computational delay rises. The SPEC-RG compute-continuum experiments show this. Edge nodes with slower processors cut communication time, but the saving could not make up for slower compute. In that setup, cloud-based aggregation supported up to four endpoints per task before queueing set in, while the edge supported two.

Which video-QoE and analytics workloads actually need cell-site latency?

The cell site is needed only by workloads whose measured regional round trip breaks their latency budget.

TechnoLynx treats this as a measurement problem. Through the AI Porting & Deployment Pack, TechnoLynx first sets out each workload’s latency, throughput and SLA constraints. TechnoLynx then benchmarks the same model on edge, regional and core targets, so the placement threshold rests on measured latency, throughput and cost per unit of work, not on spec sheets.

The decision rule runs in four steps, in this order:

1. Fix the end-to-end latency budget the SLA allows, from the event to a usable result.
2. Measure the latency each candidate tier can actually achieve for this workload, under representative concurrent load, not on an idle path.
3. Place the workload at the lowest-cost tier that meets the budget with margin. If regional placement fits, take it for its cost and operational simplicity.
4. Record the threshold and the measurements behind it so the next workload starts from the same rule.

The SPEC-RG reference architecture makes the cut-off idea explicit. If the cutoff latency is 300 ms, a user must consider only cloud or large edge nodes, not smaller edge or device offloads. Live video analytics deadlines are far shorter. At 30 frames per second, each frame has to be processed within 33 ms, or the next frame queues in the buffer. The same survey notes that latency requirements become stringent when the analytics output drives human interaction or actuates mission-critical systems. That is the test for which stages go to the cell site. In the edge-cloud cooperation work surveyed for MEC video streaming, delay-sensitive tasks run on the nearest edge server and delay-tolerant tasks go to the cloud.

Measurement settles questions that architecture diagrams cannot. In a study of SLA-aware vision-language inference across device, RAN-edge and cloud tiers, model variant choice determined whether the RAN edge was feasible. Quantised models stayed below 0.5 s, while unquantised and some larger quantised models missed deadlines because of stalls and queueing. In the same study, at most 32.9% of cloud requests finished within 0.5 s over the measured WAN path, but every variant met a 1.0 s deadline. The same tier can pass or fail depending on the model variant and how tight the deadline is.

Sources disagree on how far the cloud is. A 2022 MEC video-streaming survey puts cloud processing at roughly 150 to 200 ms, against about 10 ms at the edge. Global measurements by Mohan et al. (HotNets 2020) found that around 80% of probes in Europe and North America reached a cloud data centre within 20 ms, and that 150 to 200 ms cloud latencies showed up in less-connected countries. We give more weight to the measurement study for well-connected markets, because it measured latencies from thousands of probes. Its own caveat still applies: wireless probes took about 2.5 times longer to reach the nearest cloud region than wired ones. The honest conclusion is that neither figure describes your backhaul, so you have to measure your own.

Profile the pipeline before you decide placement. Which stage needs to be close to the radio is something profiling shows you. A general rule that video analytics belongs at the edge does not. The edge video analytics survey describes profilers that run tasks on every candidate executor and report accuracy, execution time and resource demand to guide placement.

To make the rule reusable, write it down in the form Skylab’s GPU infrastructure planning guide suggests for any placement rule: the permitted data path, the performance requirement, the cost owner, the fallback, and the evidence needed before a workload moves. Three caveats travel with it:

• Latency changes with load and backhaul congestion, so a measurement taken at one point in time may not hold at peak.
• Latency alone ignores power, space and capacity limits at edge sites.
• Thresholds from another operator’s topology do not transfer without being measured again on yours.

Is there a reference architecture operators follow?

There are frameworks, but none of them gives you the threshold. ETSI GS MEC 003 (V3.2.1, 2024) lets MEC applications carry requirements such as maximum latency, which system-level management validates. The MEC orchestrator then selects hosts based on latency, available resources and available services. ETSI GR MEC 059 adds that the orchestrator should assign applications by available compute, bandwidth, storage and specific requirements, for example whether a host has enough GPU capacity for AI model training. The LF Edge taxonomy adds a useful correction: the nearest edge location is not always the best, and clients should be steered by the QoE recently measured at each site. The SPEC-RG reference architecture provides a three-tier model (endpoint, edge, cloud) plus performance models that mark a deployment as viable only when it meets every data and processing requirement. These give the placement decision a structure and a shared vocabulary. The numbers have to come from your own network.

Who can benchmark our inference workloads across edge and regional placements?

TechnoLynx benchmarks an operator’s own inference workloads on candidate edge, regional and core hardware, turns the measured latency and throughput into a documented placement rule, and then implements and validates the chosen configuration under realistic load. The engagement is the AI Porting & Deployment Pack. Building this in-house makes sense when your team already owns the model, the serving stack and a test path through the RAN. Outside help earns its place when the model has to be ported to MEC appliances or regional GPUs the team has not run before. When choosing a partner, ask how they measure tail latency under concurrent load and whether the assumptions stay attached to the decision. For shortlisting devices before any porting starts, LynxBenchAI publishes results showing how candidate accelerators run the public PyTorch stack.

The engagement is not the right fit for RAN transport engineering, backhaul redesign or regulatory sign-off. Those sit with the network equipment vendor, a systems integrator or counsel. It also adds little when the workloads are vendor appliances with fixed placement. Teams that want to explore offloading options themselves can use the SPEC-RG benchmarking framework, which configures network latency, bandwidth, jitter and compute across continuum deployments in a few lines of code.

How do we split a 50 ms budget between RAN, transport and compute for each site?

Add the radio latency, the transport round trip, and the inference time. A site needs local inference when the regional total leaves no margin and the edge total does.

TechnoLynx’s AI engineering work for telecom starts by formalising that decomposition for each site. TechnoLynx then builds the latency instrumentation, benchmarks actual inference latency at the candidate edge and regional placements against the budget, and rolls out and monitors the placements that pass.

A 2020 joint planning model for network slicing and MEC expresses total latency as the wireless latency at the ingress node, plus the processing time, plus the latency on the links inside the network. The Telecom Infra Project (2024) describes the telecom practice for allocating the budget. Hypothetical Reference Connections abstract the topology, then an impairment budget sets the allowance for each network segment and each node within it. The same report defines end-to-end tolerable delays first and allocates them per segment afterwards. A paper on 5G URLLC slicing for industrial IoT argues for treating RAN, transport, edge compute and application processing as parts of one shared budget instead of optimising each subsystem on its own. That paper works at sub-millisecond scale, far tighter than video QoE.

Leave margin on purpose. Amira Labs (2026), writing about broadcast inference, gives an illustrative 1,500 ms event-to-result budget. Its serial allowances for collection, transfer, queueing, model execution, formatting and delivery add up to 1,200 ms, which leaves 300 ms unallocated. The point is the method, not the numbers.

Worked example: what a 50 ms budget leaves for compute

This example uses three assumptions, each stated as an assumption: a 50 ms end-to-end budget, a radio access share of about 10 ms, and the transport figures below. The transport figures are the mean “Core+Internet” round-trip contributions from a mmWave latency breakdown, as cited in a 2026 analysis of 5G latency components.

Compute placement	Transport/core RTT (cited)	Left for compute: 50 − 10 − RTT
Edge-like (wavelength zone)	10.25 ms	29.75 ms
Local zone	30.81 ms	9.19 ms
Regional	35.82 ms	4.18 ms

The same analysis treats UPF processing as negligible next to transport, citing benchmarks of about 31 to 38 microseconds. On these assumptions, a regional placement leaves around 4 ms for inference, queueing and result delivery, and an edge placement leaves almost 30 ms. Whether either is enough depends on the inference time you measure for your model on the hardware at that tier, under load. Replace every assumed figure with your own measurements before the table goes to anyone. Your radio and backhaul will differ from the measured path.

The per-site rule follows. If edge compute keeps the total under budget with margin and regional routing does not, the site gets local inference. If transport plus regional compute fits comfortably, the site routes to the regional DC. Three conditions make this messier in practice:

• A site without MEC hardware routes regionally whatever the latency says.
• The 5G World Pro analysis notes that metro sites tend to offer more favourable power, space and fibre than far-edge locations.
• The rule has to be validated again whenever the RAN technology or transport topology changes.

The cost side of choosing a regional cloud over your own facility has its own treatment in our workload-grounded cloud versus on-prem placement framework.

How much GPU capacity does each edge site need when live sports spikes the load?

Size each site from measured throughput. Measure how many of your streams one GPU sustains in real time at your resolution, frame rate and accuracy target, divide the site’s expected peak streams by that number, and add headroom for peaks and model upgrades. Take the live-sports peak multiplier from your own traffic history.

LynxBenchAI publishes results showing how candidate edge and data-centre accelerators run the public PyTorch stack your models are built on, which makes them a broadly indicative first filter when shortlisting hardware for each site, and the first step is to check those results for the devices you are considering.

They do not run or measure your own video-QoE pipeline. The first step is to check those results for the devices you are considering; the streams-per-GPU figure for your model still comes from your own benchmark on the shortlisted devices measured by LynxBenchAI.

You cannot skip that benchmark. With multi-camera batching, one GPU handles many feeds through a shared inference engine, so there is no fixed streams-per-GPU number to look up. Skylab’s planning guide says to account separately for concurrency, queue objectives, maintenance, resilience, fragmentation, growth and uncertainty. It also notes that a universal utilisation target is not a reliable sizing method. The same guide warns that average request volume can hide the peak and tail behaviour that decides user experience.

Headroom and autoscaling cover different parts of the peak, and the plan should say which covers which. Some edge capacity, such as O-RAN DUs, cannot scale during service. In O-RAN distributed units, computing resources can be shifted between functions, but the DU itself cannot be scaled while serving, so its capacity has to be set before traffic arrives. Autoscaling boundaries also affect how much capacity an online inference service has. Treat the share of the peak you expect autoscaling to absorb as an assumption to test. How the scaling trigger fires ahead of the spike is a separate design question. Here, only the share of peak it absorbs matters.

If shared GPUs serve live traffic, isolation matters. Amira Labs points out, citing NVIDIA’s GPU Operator documentation, that time-slicing interleaves workloads without memory or fault isolation, while Multi-Instance GPU partitions with isolation. In the 2026 device-RAN-cloud study, fixed MIG partitioning kept radio KPIs and baseband timing healthy under saturated downlink traffic with up to 20 concurrent inference clients, in that study’s configuration.

The plan should state the trade between upfront spend and latency openly. An O-RAN edge server design study shows that pre-allocating a large DU capacity keeps service latency below 1 ms but wastes compute when traffic is low. They also note that eMBB and mMTC services can be processed at the CU instead. In its simulated network scenarios, the 2020 joint planning model found that performance levels off as capacity grows, so capacity beyond a certain level adds cost with little benefit. The multi-stage edge server upgrade model (2025) spreads investment across stages for budget flexibility, and lets operators buy later capability at lower prices as technology costs fall.

One analyst view (5G World Pro, October 2026) puts edge AI build-out at roughly $2 million to $8 million or more per metro site. It does not tell you how a peer split spend between edge and regional sites. After go-live, the capacity model should become a recurring review. Thresholds should trigger an investigation, not automatic procurement.

What evidence should the architecture board see before MEC capex is committed?

The board should see end-to-end latency benchmarks of each candidate architecture (edge-only, centralised and hybrid) under representative concurrent load, showing which pipeline stages must sit at the cell site to meet the contracted QoE SLA and which can be centralised. Component-level estimates on their own do not show that the SLA holds.

An SLA-safe placement decision leadership can defend

Amira Labs suggests a sequence that suits this decision well:

• Write a one-page workload contract.
• Compare two plausible placements using the same test material.
• Measure the complete result path and sustained capacity, including the work competing for the same resources.
• Exercise the failure policy.
• Keep the assumptions with the approved decision.

Model execution is only one part of the path. The measurement should run from the media event to the usable result. Network QoS requirements are probabilistic and are often stated as the share of time a requirement is met. ETSI GR MEC 059 defines an SLA compliance rate: the percentage of packets between client and MEC application that meet the SLA on latency, throughput and packet loss.

Local transcoding is one candidate for the cell site in a transcoding and QoE pipeline. The 2022 MEC video survey describes sending only the highest-bitrate version to the edge and transcoding there for local viewers, which reduces core network traffic. Real-time QoE inference that feeds an immediate control decision joins it at the edge. Stages that are not tied to that decision can be centralised. Hybrid designs carry their own costs. ETSI GR MEC 059 lists failover time, synchronisation latency, synchronisation overhead and service quality impact as metrics for redundant MEC instances.

Board evidence pack checklist

• End-to-end latency percentiles for each architecture, measured under representative concurrent load and failure conditions.
• A split of each stage into must-sit-at-edge and can-centralise, with the measurement that justifies each one.
• Sustained throughput per site with the request mix, input size and batching recorded, as Skylab’s guide asks for online inference benchmarks.
• How profiles will be kept current, because offline profiling misses changing scenes and can lead to waste or SLA violations.
• Failover time, synchronisation latency and service quality impact for any hybrid design.
• The assumptions and the conditions that trigger re-testing.

When the edge hardware sits idle most of the year

The case has to rest on what the capacity guarantees, and the utilisation plan should show how idle time is reduced. The Small Cell Forum (2020) notes that edge data centres involve significant upfront investment in anticipation of applications and customers that may never arrive. It also describes consolidating workload onto active servers to cut power drawn by idle ones. ETSI GR MEC 059 describes the orchestrator side of this: consolidating low-load application instances onto fewer MEC hosts so that idle hosts can be reclaimed or moved to low-power states.

In the United States, 47 CFR § 4.9 requires wireless providers to notify the FCC within 120 minutes of discovering an outage of at least 30 minutes that, among other triggers, affects a mobile switching centre, potentially affects at least 900,000 user minutes, or potentially affects a 911 facility. That rule defines when an outage becomes reportable. It does not require any edge capacity, so linking it to an edge build is an argument the operator has to make and its counsel has to accept. Governance bodies such as a federation board or member co-operatives may also weigh reliability and public perception differently from SLA compliance, which calls for a separate narrative to the technical case.

Re-measure when the network moves under the rule

A placement rule only holds for the radio technology, transport topology, model version and traffic mix it was measured on. Amira Labs recommends re-testing whenever the model, the input representation, the workload mix or the infrastructure changes. The tier study makes the reason concrete: model variant choice determined RAN-edge feasibility. That means the most useful part of the evidence pack is the record of which assumptions each threshold depends on, because that record tells you which sites to re-measure when something upstream changes. TechnoLynx’s engagement extends to this: rolling out placement decisions and monitoring latency margins over time.

FAQ

What is fog computing?

Fog computing extends cloud services towards the edge through a hierarchy of edge clusters, from resource-constrained devices near users to micro data centres near the cloud. Each level trades compute capacity against network latency.