Project Overview
This project introduces a closed-loop orchestration framework to solve the dynamic Cache Placement Problem in a fog computing environment. It uses a parallel genetic algorithm to continuously adapt its caching strategy in response to real-time changes in content popularity.
Project Aims
- Design and develop a dynamic, closed-loop orchestration framework.
- Implement a parallel genetic algorithm for optimization.
- Simulate a heterogeneous fog computing environment.
- Continuously adapt to real-time changes in content popularity.
- Goal 1: Maximize system-wide cache hit ratio.
- Goal 2: Minimize average data retrieval latency.
Problem Statement
Traditional cloud computing struggles with latency for real-time IoT applications. Fog computing solves this by moving resources to the network edge, but these "fog nodes" have limited capacity.
The challenge is deciding which data items to cache at which specific fog nodes to optimize performance. This "Cache Placement Problem" is NP-hard.
Furthermore, content popularity changes over time ("concept drift"), requiring a dynamic, online optimization approach, not a static one.
The Problem: Cloud Latency
The core problem stems from the physical distance between a user and a centralized cloud. For real-time applications like IoT, this delay (latency) is unacceptable. Fog computing introduces an intermediate layer to solve this.
Data Retrieval Path
1. Traditional Cloud Model
High Latency Request
High Latency Response
High Delay
2. Fog Computing Model
Low Latency Request
Low Latency Response
Low Delay (Cache Hit)
Conceptual Latency Comparison
Fog nodes serve content from the edge, drastically reducing the data travel time compared to a round-trip to a distant cloud data center.
System Architecture
The proposed solution is a closed-loop orchestration framework composed of three logical layers. This design separates the data-serving functions (Edge) from the centralized intelligence (Control and Data).
Edge Layer
Fog Nodes
Monitoring Agents
Control Layer
Orchestrator
Optimization Engine (GA)
Data Layer
Trace Database
Cache Plan Database
Edge Layer
This is the distributed front-end, consisting of Fog Nodes. Each node has two functions:
- Data Plane: Services data requests from IoT clients and maintains a local cache.
- Control Plane: Acts as a monitoring agent, logging content requests and sending performance data.
Control Layer
This is the centralized intelligence of the system, containing two key components:
- Orchestrator: The master controller. It analyzes aggregated data to detect popularity shifts.
- Optimization Engine: A high-performance module that runs the Genetic Algorithm to generate a new, optimal Cache Plan when triggered.
Data Layer
This is the state-keeping persistence layer of the system.
- Trace Database: A time-series database that stores historical and current performance trace data from all Fog Nodes.
- Cache Plan Database: A key-value store that holds the current and historical Cache Plan outputs from the Optimization Engine.
Core Logic: The Online Optimization Cycle
The system operates in a continuous, autonomous loop to ensure the caching strategy remains optimal as content popularity changes over time. Click each step to learn more.
1. Monitor
Each Fog Node locally logs all incoming content requests over a defined time window (e.g., 15 minutes).
The Algorithm: Parallel Genetic Algorithm
To solve the NP-hard Cache Placement Problem, we use a Genetic Algorithm (GA), a method inspired by natural selection. It starts with a random group of solutions and "evolves" them over generations to find a high-quality, near-optimal result.
How it Works
-
1. Initialization
The algorithm starts by creating a random group of initial solutions (a "population"). Each solution is a complete, random plan of what data is stored on which fog node.
-
2. Fitness Evaluation
Each solution is tested and given a "fitness" score. In this project, fitness is measured by how well the plan reduces the average data retrieval latency.
-
3. Selection
The "fittest" solutions are chosen to be "parents" for the next generation, ensuring their good qualities are carried forward.
-
4. Reproduction (Crossover & Mutation)
New "offspring" solutions are created by combining parts of two parents (Crossover) and applying small, random changes (Mutation) to add variety.
-
5. Termination
This cycle repeats until a set number of generations is reached or the solution's quality stops improving, yielding a near-perfect cache placement plan.
Conceptual Fitness Improvement
The GA iteratively improves the quality (fitness) of the cache plan, finding better solutions with each new generation.
Project Plan & Requirements
Development Schedule
The project is executed in 5 iterations. Click each iteration to see its key activities.
Iteration 1: Foundational Simulation Core (Weeks 10-12)
Build the "skeleton" of the simulation world. Implement basic C++ classes (IoTDevice, FogNode, Cloud) and model time and network communication.
Iteration 2: Baseline Caching & Monitoring (Weeks 13-15)
Implement the benchmark Hybrid Cache Management (LRU) and the monitoring function in the FogNode to generate PerformanceTrace data.
Iteration 3: Core Optimization Engine (Parallel GA) (Weeks 16-18)
Build the standalone optimization engine in C++. Implement the Parallel GA structure (island model), chromosome representation, and genetic operators.
Iteration 4: Integration & Full-Loop Orchestration (Weeks 19-20)
Connect all components. Implement the Orchestrator logic, integrate the C++ Optimization Engine, and enable the full DEPLOY/ADAPT cycle.
Iteration 5: Experimentation & Analysis (Weeks 21-22)
Run a comprehensive suite of experiments to compare the adaptive system against the baseline. Fine-tune GA parameters and generate final results.
System Requirements
Functional Requirements
- FR-1: Fog Node must monitor and log all content requests.
- FR-2: Fog Node must report performance trace data to the Control Layer.
- FR-3: Orchestrator must analyze aggregated data for content popularity.
- FR-4: Orchestrator must detect significant changes ("concept drift").
- FR-5: Orchestrator must trigger the Optimization Engine upon drift detection.
- FR-6: Optimization Engine must generate a new, optimized cache plan.
- FR-7: Orchestrator must distribute the new plan to all Fog Nodes.
- FR-8: Fog Node must apply the new cache plan without interruption.
Non-Functional Requirements
- NFR-1: Performance: The Optimization Engine must generate a plan within a predefined time limit.
- NFR-2: Scalability: The framework must be scalable to at least 20 Fog Nodes and 500 content items.
- NFR-3: Usability: Performance metrics (cache hit ratio, latency) must be logged in a clear format (e.g., CSV).
- NFR-4: Modularity: The architecture must allow the Optimization Engine to be updated or replaced.