The Cloud-RAN Architecture with Edge Caching

Why Cloud-RAN Needs Caching

Cloud-RAN (C-RAN) is the dominant architecture for 5G/6G networks: lightweight edge nodes (ENs, formerly called RRUs — remote radio units) are connected to a central cloud (BBU pool) via high-capacity fronthaul links. The cloud handles baseband processing (coding, precoding); the ENs are thin, radio-only. Pre-caching is added as a sensible extension: put some content at the edge to reduce fronthaul load and delivery latency.

The question: what is the optimal tradeoff between cache size and fronthaul capacity? A cloud-heavy architecture has large CC and small MM; a cache-heavy one has large MM and small CC. The Simeone group's NDT framework characterizes this tradeoff information-theoretically. This chapter is the CommIT-adjacent deep dive into that framework.

Although the NDT framework was initially developed by Simeone- Sengupta et al., the CommIT group has extended it in several directions: mixed-traffic C-RAN (Park-Caire), fog-based massive MIMO (Lampiris-Caire), and privacy-constrained C-RAN (Wan-Caire). We treat the unified framework here.

Definition:

Cloud-RAN with Edge Caching

The cache-aided cloud-RAN consists of:

  • A central cloud with the full library W={W1,…,WN}\mathcal{W} = \{W_1, \ldots, W_N\} and infinite compute.
  • NENN_\text{EN} edge nodes (ENs), each with a cache of size MM files.
  • A fronthaul link connecting the cloud to each EN, of capacity CFC_F files per channel use on the wireless downlink.
  • KK single-antenna users, each served by the ENs.
  • A wireless downlink from ENs to users (modeled as MIMO BC with the NENN_\text{EN} ENs as cooperating transmitters).

The placement phase populates EN caches off-peak. In the delivery phase, with demand vector d∈[N]K\mathbf{d} \in [N]^K: (i) ENs serve cached content directly; (ii) the cloud transmits non-cached content to ENs via fronthaul, at rate ≤C\leq C per EN per channel use; (iii) ENs forward received content to users over the downlink.

The fronthaul is the "slow" link. In practice, CPRI fronthaul of a 5G mid-band system handles 10-25 Gbps per RRU; user-plane data typically utilizes 1-5 Gbps. The C/R ratio is 2-5x; caching reduces the required ratio further.

Cloud-RAN topology with edge caching

Cloud-RAN topology with edge caching
Central cloud (with full library) connected via fronthaul of capacity CC to NENN_\text{EN} edge nodes. Each EN has a local cache of size MM and serves KK users over a shared wireless downlink. Cache substitutes for fronthaul; the NDT framework quantifies the tradeoff.

Cloud-RAN Topology with Edge Caching

Cloud at the top with the full library; three edge nodes with local caches Zi\mathcal{Z}_i; fronthaul of capacity CC files per channel use connecting cloud to ENs; users served by the ENs' shared wireless downlink. NDT measures delivery time normalized to the infinite-fronthaul baseline.

Definition:

Aggregate Caching Gain

In the cloud-RAN model, the aggregate caching gain is t  =  NEN⋅MN.t \;=\; \frac{N_\text{EN} \cdot M}{N}. This plays the same role as KM/NK M/N in the shared-link model: it measures how many library copies are distributed across the EN caches. If NENM≥NN_\text{EN} M \geq N, the full library is cached at the edge and no fronthaul is needed.

The distinction from Chapter 2 is that caches are at the ENs, not at individual users. Users can be served by multiple ENs; ENs can serve multiple users. This changes the delivery-phase structure and the converse bounds.

Example: A Netflix-Edge CDN Thought Experiment

A 5G mid-band cell has NEN=4N_\text{EN} = 4 RRUs serving K=50K = 50 users during peak. Library size N=104N = 10^4 titles, per-RRU cache M=103M = 10^3 (10%). Fronthaul capacity C=5C = 5 files/use (asymptotically, at high SNR). Compute the aggregate caching gain and discuss cache-vs-fronthaul sufficiency.

Solution
Aggregate caching gain

t=NEN⋅M/N=4⋅103/104=0.4t = N_\text{EN} \cdot M/N = 4 \cdot 10^3/10^4 = 0.4. Less than 1: most demand must come from fronthaul. Specifically, only 40% of the library is cached at the edge in aggregate (since different ENs may cache different content).

Fronthaul sufficiency

Demand per channel use: K⋅K \cdot (1 file) = 50 files. Without cache: fronthaul carries 50 files/use; C=5C = 5 per-EN × NEN=4N_\text{EN} = 4 = 20 aggregate files/use available. Not enough: 30 files/use shortfall → delivery impossible within one channel use. With cache (assuming worst-case tt alignment): effective fronthaul demand ≈50⋅(1−0.4)/(1+0.4)=21\approx 50 \cdot (1-0.4)/(1+0.4) = 21 files/use. Aggregate fronthaul (20) roughly meets demand — the cache makes the system feasible.

Engineering takeaway

The cache-fronthaul tradeoff is operationally real. A 10% cache per RRU converts an infeasible cloud-only design into a workable system. More cache (or more fronthaul) improves latency further.

Definition:

Delivery Time T(SNR)T(\text{SNR})

The delivery time is the number of channel uses required to deliver the demanded files {Wdk}k=1K\{W_{d_k}\}_{k=1}^K to all users. It depends on SNR: higher SNR allows higher-rate coding, shorter delivery. T(SNR)  =  KFsum-rate at SNR⋅log⁡2SNR channel uses (asymptotically).T(\text{SNR}) \;=\; \frac{KF}{\text{sum-rate at SNR} \cdot \log_2 \text{SNR}} \text{ channel uses (asymptotically)}. For a baseline system (no cache, unicast, C=KC = K fronthaul), the delivery time is Tref(SNR)=K/log⁡2SNRT_{\text{ref}}(\text{SNR}) = K/\log_2 \text{SNR} — the single-user MU-MIMO baseline.

Delivery time is a natural latency metric but is SNR-dependent. The NDT (defined next) normalizes it to remove the SNR dependence and focus on the cache-fronthaul tradeoff.

Why This Matters: From C-RAN to Fog Massive MIMO

The C-RAN model is tightly related to fog massive MIMO, a 6G architecture where many ENs cooperatively serve users with both caching and distributed precoding. The CommIT group's ongoing work (Lampiris-Caire-Bhattacharjee 2022+) treats this as a generalization of Chapter 5's Lampiris-Caire scheme with additional fronthaul constraints. The NDT framework provides the analytical language.

⚠️Engineering Note

C-RAN and Fronthaul in 5G NR

Deployed 5G NR C-RAN systems:

  1. Fronthaul types. CPRI (legacy) is 10-25 Gbps per RRU but rigid. eCPRI (Rel-15+) is more flexible, 25-100 Gbps with IP encapsulation. Open Fronthaul (ORAN) uses eCPRI + O-RU interface.
  2. Functional split. 7.2x split (ORAN standard) keeps iFFT at RU; 6 split keeps MAC at DU; 2 split (PDCP-RLC) is most cloud-heavy.
  3. Caching extensions. 3GPP Rel-17 added cache support at DU/CU levels. Rel-18+ study items include cache-aided multicast.
  4. Fronthaul economy. At C=25C = 25 Gbps per RRU, cache at the DU/RU can reduce backbone load substantially for popular content. Video-heavy traffic (70% of mobile) is the main target.

The NDT framework informs architectural decisions: what fraction of storage should be at RRU (fast access) vs. DU (cheaper, slower) vs. cloud (coldest)?

Practical Constraints
  • •

    5G NR eCPRI fronthaul: 25-100 Gbps per RU

  • •

    ORAN 7.2x split: iFFT at RU, rest in DU

  • •

    Cache at DU levels: O(10 TB) typical

  • •

    Cache at RU levels: O(100 GB) typical (smaller, faster)

Prerequisites & NotationNormalized Delivery Time (NDT)