The Constant Factor Improvement

How Big Is the Constant?

The scaling is the same. But how much does the constant improve? Is it worth the implementation complexity of synchronized MAN-style placement across clusters? This section derives the explicit constant-factor improvement and identifies the regimes where it matters.

Theorem: Constant-Factor Improvement of Coded D2D

In a coded D2D network with cluster size KgK_g, the per-user throughput constant ratio is ccodedcuncoded  =  Θ ⁣(1+Kgμ1+μ)≈1+Kgμ for small μ.\frac{c_{\text{coded}}}{c_{\text{uncoded}}} \;=\; \Theta\!\left(\frac{1 + K_g \mu}{1 + \mu}\right) \approx 1 + K_g \mu \text{ for small } \mu. For KgμK_g \mu moderate (e.g., KgM/N=3K_g M/N = 3-1010), the coded scheme achieves a 3-10× constant-factor improvement.

Within each cluster, MAN gives a factor (1+KgM/N)(1 + K_g M/N) gain over uncoded delivery. This is a per-cluster benefit. When averaged across clusters, the improvement is preserved as a constant factor (not further amplified by cluster count, but also not diminished).

Proof
Per-cluster comparison

Uncoded: KgK_g delivery slots per cluster. Coded (MAN): Kg/(1+KgM/N)K_g/(1 + K_g M/N) slots per cluster. Ratio: (1+KgM/N)(1 + K_g M/N).

Aggregate throughput

With the same number of clusters and spatial reuse pattern, aggregate throughput ratio = per-cluster ratio = (1+KgM/N)(1 + K_g M/N).

Per-user

Normalizing by nn (user count, unchanged between schemes): ccoded/cuncoded=1+KgM/Nc_{\text{coded}}/c_{\text{uncoded}} = 1 + K_g M/N. For KgM/N=5K_g M/N = 5: 6× improvement. For KgM/N=0.1K_g M/N = 0.1: 1.1× improvement. ■\blacksquare

Coded D2D: Clustered Delivery with Spatial Reuse

Three D2D clusters running coded MAN-style delivery in parallel. Within each cluster: MAN XOR broadcast. Across clusters: spatial reuse — they transmit concurrently. Per-user throughput still Θ(M/N)\Theta(M/N) (same order), but constant factor improves by ∼(1+KgM/N)\sim (1 + K_g M/N) over uncoded D2D.

Coded D2D Constant Factor vs Memory Ratio

The coded-caching constant ccoded(μ)/cuncodedc_{\text{coded}}(μ)/c_{\text{uncoded}} grows with the cluster size and memory ratio. Useful guidance for choosing cluster size in practical deployments.

Parameters
50

Example: Realistic Deployment Numbers

For a 6G D2D deployment with Kg=20K_g = 20 users per cluster, μ=0.1\mu = 0.1, compute the coded-D2D constant improvement.

Solution
Compute

KgM/N=20⋅0.1=2K_g M/N = 20 \cdot 0.1 = 2. Constant ratio: (1+2)/(1+0.1)≈2.73(1 + 2)/(1 + 0.1) \approx 2.73.

Interpretation

Coded D2D delivers ~2.73× the per-user throughput of uncoded D2D at these parameters. Substantial but not order-of-magnitude.

Cost of coding

Extra subpacketization: (203)=1140\binom{20}{3} = 1140 vs uncoded's 1. For a 1 GB file, each subfile is 1/1140 GB = 1 MB. Still practical.

Decision

At these parameters, coded D2D is worthwhile: 2.7× throughput gain for modest subpacketization overhead. At larger KgK_g (say 100), subpacketization becomes prohibitive; diminishing returns set in.

Spatial Reuse Factor

Number of concurrent non-interfering D2D links as a function of the interference radius. For small radius, many concurrent links possible. The n/r2n/r^2 law governs.

Parameters
100
10

Key Takeaway

Coded D2D provides a 2-10× constant-factor gain over uncoded D2D in practical regimes. While not an order-of-magnitude scaling improvement, this is substantial and often worth the added complexity of MAN-style placement. System designers should choose cluster size KgK_g to balance the gain factor (1+KgM/N)(1 + K_g M/N) against the subpacketization cost (KgKgM/N)\binom{K_g}{K_g M/N}.

Cluster Size as Design Lever

Cluster size KgK_g is the main design knob for coded D2D. The choice involves three competing effects:

  1. Gain factor (1+KgM/N)(1 + K_g M/N). Increases linearly in KgK_g.
  2. Subpacketization (KgKgM/N)\binom{K_g}{K_g M/N}. Grows exponentially in KgK_g.
  3. Synchronization cost. Larger clusters need tighter coordination across users.

Optimal cluster size maximizes (gain)/(complexity cost). For typical parameters, this is Kg≈5-30K_g \approx 5\text{-}30.

Larger clusters are infeasible due to subpacketization, as in the single-server MAN case. Chapter 14's polynomial- subpacketization schemes can relax this, enabling larger effective clusters.

⚠️Engineering Note

Cluster Formation in 6G D2D

Real deployment of coded D2D needs a cluster-formation protocol:

  1. Static clustering. Geographic regions pre-defined (e.g., rooms in a building, platforms in a stadium). Simple; doesn't adapt to user density.
  2. Dynamic clustering. Users within D2D range form clusters on demand. More efficient; requires discovery protocol.
  3. Overlapping clusters. Users can belong to multiple clusters simultaneously; MAN delivery overlaps. Complex scheduling, but best per-user throughput.

3GPP standards (ProSe Rel-12+) support cluster discovery. Full coded-D2D orchestration is not yet standardized. Research prototypes (Caire-Molisch labs, others) have demonstrated feasibility at scale of ~20 users.

The CommIT group has explored dynamic clustering in the context of 6G fog massive MIMO; see Lampiris-Caire-Bhattacharjee 2023.

Practical Constraints
  • •

    5G NR Sidelink supports group discovery

  • •

    Cluster coordination latency: ~ 5-10 ms typical

  • •

    Practical KgK_g: 5-20 users per cluster

  • •

    Subpacketization budget: ~ 10^4 per file

Common Mistake: Don't Push Cluster Size Beyond Subpacketization Budget

Mistake:

Configuring Kg=50K_g = 50 to "maximize gain" without checking subpacketization feasibility.

Correction:

Subpacketization = (KgKgM/N)\binom{K_g}{K_g M/N}. For Kg=50K_g = 50, M/N=0.1M/N = 0.1: (505)≈2×106\binom{50}{5} \approx 2 \times 10^6. A 1 GB file would have subfiles of 0.5 KB — headers dominate. Practical limit: (Kgt)≤104\binom{K_g}{t} \leq 10^4 roughly, giving Kg≤25K_g \leq 25 at t=2t = 2-33. Beyond that, Chapter 14's polynomial- subpacketization schemes are needed.

Why the Gains Do Not CumulatePractical Implications for 6G D2D