MEC, Edge, and Cloud — What Should Run Where?

This is a conversation between Me and Tech Explorer 📶, based on real-world deployments and hands-on telecom architecture.

Tech Explorer 📶: Mohamed, I’ve been trying to wrap my head around all these layers — cloud, edge, MEC… Everyone says “move to the edge” — but what actually belongs where?

Me (Mohamed): That’s a very common confusion. I’ve had this conversation with many technical teams. Let’s break it down based on real deployment logic, not just marketing slides.

🏗️ First: What Are the Layers?

We usually talk about three key layers in modern telecom architecture:

1. Central Cloud: Hosted in national or regional datacenters or hyperscaler facilities (e.g., AWS, Azure).

2. Edge Cloud / MEC (Multi-access Edge Computing): Deployed at regional aggregation points — often within central offices or telco edge zones.

3. Far Edge / Cell Site Cloud: Located directly at or near gNBs (gNodeBs) or DUs (Distributed Units) — very close to the radio access.

Each layer provides different characteristics in terms of latency, cost, and scalability.

Tech Explorer 📶: So what determines where we put a function?

Me (Mohamed): Good question. In practice, it comes down to three technical drivers:

1. ⏱️ Latency: How fast must the function respond?

2. 🌐 Bandwidth savings: Can we reduce traffic backhaul/core load?

3. 💵 Cost and complexity: Is it worth managing this function locally?

Here are real-world deployment examples I’ve worked on:

📡 At the Cell Site (Far Edge)

• Functions: DU layer processing, HARQ scheduling, beamforming logic.

• Why? Needs tight timing constraints — especially for 5G NR uplink and massive MIMO.

• Example: For uplink beamforming, latency beyond just a few milliseconds can severely degrade performance.

🛣️ At the Regional Edge / MEC

• Functions: Content delivery (CDN), AR/VR rendering, private 5G UPF, local NEF, or TSN controllers.

• Why? These applications benefit from being closer to users to save on backhaul and cut round-trip latency.

• Example: In one enterprise deployment, we placed the UPF and NEF at the MEC level to avoid routing enterprise app traffic back to the core — reducing delay and increasing efficiency.

☁️ In the Central Cloud

• Functions: SMF, UDM, PCF, NWDAF, and training ML models.

• Why? These don’t need real-time execution and are easier to operate, scale, and secure centrally.

• Example: Operators often centralize thousands of slices, offloading only latency-critical ones to the edge.

Tech Explorer 📶: What about MEC platforms from hyperscalers?

Me (Mohamed): That’s a growing trend.

Today, operators can deploy hyperscaler MEC nodes directly within or near their network:

• AWS Wavelength in operator edge zones

• Azure Operator Nexus in telco datacenters

• Google Distributed Cloud Edge at private 5G or enterprise sites

These are powerful enablers for IT + telecom convergence, especially for:

• 💡 Smart manufacturing

• 🎮 AR/VR gaming

• 🏥 Remote surgery and diagnostics

In one PoC I supported, a factory ran vision AI inference at the edge using MEC. Cameras connected over a private 5G network — and the traffic never touched the public internet.

Tech Explorer 📶: So when should operators really invest in MEC?

Me (Mohamed): Here’s my practical recommendation roadmap:

✅ Start with private 5G + local UPF — easiest ROI and fast wins.
✅ Add MEC for latency-sensitive or mission-critical enterprise apps.
✅ Partner with hyperscalers selectively — avoid lock-in when possible.
✅ Apply hybrid placement:

• Centralize what doesn’t need ultra-low latency

• Push to edge only what truly requires it

📌 Not all edge is created equal — the value comes from aligning function placement with actual app needs.

Final Thoughts

MEC and Edge aren’t just buzzwords — they are enablers of real business value, especially when used strategically and in alignment with application demands.

🎓 Want to go deeper? Check out our recorded course on 5G Architecture & Edge Design: