MEC Architecture: Deploying Cachee at the 5G Edge

Multi-access Edge Computing (MEC) moves computation from centralized clouds to the network edge—right inside the carrier infrastructure, meters from the cell tower. Cachee deploys natively in this environment as a containerized service within carrier MEC Kubernetes, sitting between the User Plane Function (UPF) and application servers.

Zero changes to the 5G core. Zero disruption to existing traffic flows. Under 30 seconds to deploy.

The Four-Layer Architecture

Cachee slots into the existing 5G MEC stack without requiring modifications to any layer above or below it. Here is how each layer fits together.

Architecture Diagram

                        5G MEC Architecture with Cachee
    ============================================================

    LAYER 1: USER PLANE
    +----------+     +-----------+     +-------+
    |    UE    | --> |  gNodeB   | --> |  UPF  |
    | Devices  |     | (5G RAN)  |     |       |
    +----------+     +-----------+     +---+---+
                                           |
                          traffic steering  |
                                           v
    ----------------------------------------+-------------------
    LAYER 2: CACHEE MEC (Kubernetes)        |
    +---------------------------------------+----------------+
    |                                                        |
    |  +------------------+    +------------------------+    |
    |  | AI Prediction    |    | L1 In-Process Cache    |    |
    |  | Engine           |--->| (1.21ns latency)       |    |
    |  | LSTM+Trans.+RL   |    +----------+-------------+    |
    |  +------------------+               |                  |
    |                           HIT (94-98%) | MISS (2-6%)   |
    |                                v       v               |
    |  +------------------+    +------------------------+    |
    |  | Compliance       |    | Edge Proxy             |    |
    |  | Engine (30+ regs)|    | (NVMe backing)         |    |
    |  +------------------+    +----------+-------------+    |
    |                                     |                  |
    +-------------------------------------+------------------+
                                          |
    --------------------------------------+------------------
    LAYER 3: CARRIER CORE                 |
    +-------------+  +-----------+        |
    |  AMF / SMF  |  | Network   |        |
    | (unchanged) |  | Slicing   |        |
    +-------------+  +-----------+        |
                                          |
    --------------------------------------+------------------
    LAYER 4: ORIGIN / CLOUD              |
    +----------+  +----------+  +---------+------+
    | AWS/GCP/ |  | Content  |  | API            |
    | Azure    |  | Origins  |  | Backends       |
    +----------+  +----------+  +----------------+

Request Flow: Cache Hit (94-98% of Requests)

The vast majority of requests never leave the MEC boundary. Here is the timing breakdown for a cache hit:

Request Flow: Cache Miss (2-6% of Requests)

When the AI engine does not have a prediction and the L1 cache does not contain the requested content, the request falls through to origin:

Even on a miss, Cachee is still faster than a traditional architecture because the edge proxy maintains persistent connection pools to origin servers. And critically, the fetched content is now cached—every subsequent request for the same content hits the 10.5ms path.

AI-Powered Predictive Pre-Fetching

The most powerful component of the Cachee MEC layer is the AI Prediction Engine. Rather than waiting for a cache miss to occur, Cachee predicts what content will be requested up to 30 minutes ahead and pre-fetches it into the L1 cache.

The engine combines three models:

• LSTM (Long Short-Term Memory) — Learns temporal access patterns. If users in a cell typically stream certain content at 6pm, the model pre-fetches it by 5:30pm.
• Transformer — Captures cross-content correlations. When a user loads a game lobby page, the model pre-fetches the most probable next assets (match data, player profiles, map textures).
• Reinforcement Learning — Continuously optimizes cache eviction and pre-fetch decisions based on real hit/miss feedback. The model improves with every request.

Network Slice Integration

5G network slicing allows carriers to create dedicated virtual networks for different traffic types. Cachee integrates with the slicing architecture to provide differentiated caching behavior:

Carriers can dedicate a low-latency slice specifically for Cachee-optimized traffic. Requests on this slice get priority UPF steering to the MEC layer, bypassing the carrier core entirely for cached content. The result is the lowest possible latency path: radio to cache to radio, with nothing in between.

Deployment: Under 30 Seconds

Cachee ships as a set of container images that deploy into any Kubernetes-based MEC platform. The deployment manifest is straightforward:

# cachee-mec-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cachee-mec
  namespace: edge-services
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cachee-mec
  template:
    spec:
      containers:
      - name: cachee-ai-engine
        image: cachee/mec-ai:latest
        resources:
          requests: { cpu: "4", memory: "8Gi" }
          limits:   { cpu: "8", memory: "16Gi" }
        env:
        - name: PREDICTION_WINDOW_MIN
          value: "30"
        - name: L1_CACHE_MAX_ENTRIES
          value: "10000000"
      - name: cachee-edge-proxy
        image: cachee/mec-proxy:latest
        resources:
          requests: { cpu: "2", memory: "4Gi" }
        volumeMounts:
        - name: nvme-cache
          mountPath: /cache
      - name: cachee-compliance
        image: cachee/mec-compliance:latest
        env:
        - name: REGULATIONS
          value: "gdpr,hipaa,pci-dss,ccpa"
      volumes:
      - name: nvme-cache
        hostPath:
          path: /mnt/nvme0

Three kubectl apply commands and Cachee is live at the edge. Container orchestration handles rolling updates, health checks, and auto-scaling. No carrier network engineer needs to touch the 5G core configuration.

Why MEC Instead of Central Cloud?

The physics are simple. A centralized cloud cache sits 20-50ms away from the user (through the 5G core, transport network, and cloud ingress). A MEC-deployed cache sits 3-7ms away (just the radio hop). Cachee's L1 cache at the MEC edge adds effectively zero latency on top of that radio hop.

For applications that need sub-15ms response times—cloud gaming, AR overlays, real-time collaboration—the difference between 50ms and 10.5ms is the difference between usable and unusable. MEC is the only deployment model that gets there.

What Cachee Does Not Replace

Cachee is not a CDN, not a 5G core component, and not a replacement for origin servers. It is a predictive caching layer that:

• Sits transparently in the data path
• Reduces origin load by 94-98%
• Adds AI-driven intelligence to content delivery at the edge
• Enforces compliance before data crosses network boundaries

The 5G core, carrier CDN, and cloud backends all continue to function exactly as they do today. Cachee simply intercepts the requests it can serve faster and lets everything else pass through unchanged.