By the end of this chapter, you will be able to:
Before diving into this chapter, you should be familiar with:
The table below shows how cloudlets relate to other key IoT and edge computing concepts:
| Concept | Relationship to Cloudlets | Key Distinction | Why It Matters |
|---|---|---|---|
| Cloud Computing | Cloudlets are small-scale cloud deployed at the edge | Cloudlet: 1-5ms LAN latency, Cloud: 50-200ms WAN latency | Cloudlets enable real-time mobile applications impossible with cloud (AR, cognitive assistance requiring <50ms response) |
| Fog Nodes | Cloudlets are specialized fog nodes with VM synthesis | Cloudlet: Full VM support via overlay synthesis, Fog: Often containers only | VM synthesis enables rapid personalized compute environments (69 sec vs 21 min full VM transfer) |
| Edge Devices | Cloudlets offload computation from resource-constrained edge devices | Cloudlet: Mains-powered infrastructure, Edge: Battery-constrained | Cloudlets provide ~4x battery life extension for mobile AR by offloading GPU compute to mains-powered infrastructure |
| Virtual Machines | Cloudlets use VM overlays for rapid provisioning | Cloudlet: 100-200 MB overlay (40-80x smaller), VM: 8 GB full image | Overlay efficiency makes mobile offloading practical (1-3 min setup vs 21-107 min) |
| Soft-State Model | Cloudlets destroy VMs when users depart (no persistent state) | Cloudlet: Ephemeral VMs, Cloud: Hard-state persistence | Soft-state enables scalability across hundreds of sites without per-user infrastructure costs |
| Mobile Offloading | Cloudlets provide nearby compute for mobile device offloading | Cloudlet: Local proximity (LAN speed), Cloud: Remote (Internet speed) | Proximity enables bandwidth-intensive applications (100+ Mbps AR rendering) without Internet bottleneck |
| Service Discovery | Cloudlets use mDNS for zero-configuration discovery | Cloudlet: Avahi/mDNS auto-discovery, Cloud: Manual configuration | Auto-discovery enables seamless mobile experience (users don’t configure cloudlet addresses) |
If you know what “the cloud” is but haven’t heard of cloudlets, this section explains the idea in simple terms.
The Problem: Imagine you are playing an augmented reality game on your phone. Your phone’s camera sees a park bench, and the game needs to instantly recognize it and place a virtual dragon on top of it. This requires serious computing power.
Option A – Do it on your phone: Your phone heats up, the battery drains in 30 minutes, and the game stutters.
Option B – Send it to the cloud: The image travels across the internet to a data center hundreds of miles away. By the time the answer comes back (200ms later), you have already walked past the bench. The dragon appears in the wrong place.
Option C – Use a cloudlet nearby: A small computer sitting in the building next to you processes the image in 5ms. The dragon appears exactly on the bench, your phone stays cool, and the battery lasts all day.
That nearby computer is a cloudlet – a mini data center, about the size of a pizza box, placed where people actually are (cafes, libraries, shopping malls, hospitals).
Key Analogy: If cloud computing is like ordering food delivery from across town (slow but huge menu), a cloudlet is like having a personal chef in the building next door (fast, limited menu, but exactly what you need right now).
Sammy the Sound Sensor says: “Imagine you have a homework question, but your teacher is really far away. You could mail the question and wait days for the answer (that is like the cloud!). Or, your smart older sibling sitting right next to you could help – they do not know everything the teacher knows, but they can answer most questions super fast. That sibling is a cloudlet!”
Lila the Light Sensor adds: “Cloudlets are like mini libraries in every neighborhood. You do not have to drive downtown to the big library for every book. Your neighborhood mini library has the books you need most, right around the corner!”
Max the Motion Sensor explains: “When I play my favorite running game, I need the game to react the instant I move. If the game computer is in another city, there is a delay and I crash into walls! But if there is a small game computer right in my school, it reacts so fast I can dodge everything. That small game computer is a cloudlet – it is close by so everything feels instant!”
Bella the Button Sensor asks: “But what happens when you leave the school? The cloudlet just cleans up after you – like erasing a whiteboard after class. The next kid gets a fresh, clean board. Nothing is saved, nothing is messy. That way, the cloudlet is always ready for whoever comes next!”
Cloudlets represent a specialized fog computing architecture designed for mobile-enhanced applications, providing “datacenter in a box” capabilities at the network edge. Originally proposed by Mahadev Satyanarayanan at Carnegie Mellon University, cloudlets address the fundamental mismatch between mobile device capabilities and the computational demands of emerging applications like augmented reality, cognitive assistance, and real-time video analytics.
Definition: A cloudlet is a mobility-enhanced small-scale cloud datacenter located at the edge of the Internet, providing low-latency computing resources to nearby mobile devices. Unlike general fog nodes (which may be simple gateways), cloudlets specifically support virtual machine synthesis for rapid, personalized compute provisioning.
Key Characteristics:
| Aspect | Cloudlet | Fog Node (General) | Cloud |
|---|---|---|---|
| State Management | Soft-state (ephemeral) | Mixed | Hard-state (persistent) |
| Management | Self-managed | Vendor-managed | Professionally-administered |
| Physical Form | Datacenter-in-a-box | Gateway/appliance | Machine room |
| Ownership Model | Decentralized (local entities) | Varies | Centralized (Amazon/Google) |
| Network Latency | LAN speeds (1-5ms) | 1-50ms | Internet latency (50-200ms) |
| Scale | 10-100 VMs per site | 1-10 containers | 10,000+ VMs per datacenter |
| Power/Space | Single rack (1-5 kW) | Single device (5-50W) | Warehouse-sized facility (MW) |
| VM Support | Full VM synthesis | Typically containers only | Full VM + containers |
| Typical Hardware | Multi-core server + GPU | ARM/x86 gateway | Thousands of servers |
A typical cloudlet deployment includes several key components working together to provide seamless mobile device offloading:
Component Roles:
This variant shows when to deploy cloudlets versus cloud from an architect’s decision-making perspective.
Decision Summary: Cloudlet deployment is driven by latency (< 50ms), privacy (sensitive data), connectivity (unreliable), or bandwidth (> 10 GB/day). Cloud is preferred for batch workloads with reliable connectivity and low data volumes.
The cloudlet’s most innovative feature is VM synthesis – rapidly creating personalized VMs from compact overlays rather than transferring full VM images. This is what distinguishes cloudlets from simply “putting a server nearby.”
Understanding how cloudlets synthesize a personalized VM in under 90 seconds requires following the data flow and state transitions:
Step 1: Discovery (5-10 seconds)
_cloudlet._tcp.local service requestsStep 2: Negotiation (2-5 seconds)
Step 3: Overlay Transfer (15-30 seconds for 150 MB @ 50 Mbps Wi-Fi)
Step 4: VM Synthesis (30-60 seconds)
base-ubuntu-22.04-cuda-v2.3.1.qcow2patch base.qcow2 overlay.patch → personalized.qcow2Step 5: VM Boot and Connection (5-10 seconds)
Step 6: Execution (variable duration)
Step 7: Cleanup (1-5 seconds)
End-to-End Timeline Example:
What Makes This Fast Compared to Full VM Transfer?
The Six Phases of VM Synthesis:
The key innovation enabling rapid VM synthesis is the VM overlay – a differential representation of a personalized VM. Think of it like a “save file” in a video game: instead of copying the entire game (base VM), you only carry your save file (overlay) and load it into any copy of the game.
Efficiency Metrics:
| Metric | Full VM Transfer | VM Overlay | Improvement |
|---|---|---|---|
| Size | 8 GB | 100-200 MB | 40-80x smaller |
| Transfer Time (10 Mbps) | 106 minutes | 1.3-2.7 minutes | 40-80x faster |
| Transfer Time (Wi-Fi, 50 Mbps) | 21 minutes | 16-32 seconds | 40-80x faster |
| Percentage of Full VM | 100% | 1.2-2.5% | Order of magnitude reduction |
| Synthesis Time | N/A | 30-60 seconds | Practical for mobile use |
| Total Time (Wi-Fi) | 21+ minutes | 46-92 seconds | 14-27x faster |
Calculate the total time to provision a personalized VM using overlay synthesis versus full VM transfer over typical mobile Wi-Fi:
Full VM Transfer Over 50 Mbps Wi-Fi:
\[T_{\text{full}} = \frac{\text{VM Size}}{\text{Bandwidth}} = \frac{8 \text{ GB} \times 8 \text{ bits/byte}}{50 \times 10^6 \text{ bits/s}} = \frac{64 \times 10^9}{50 \times 10^6} = 1,280 \text{ seconds} = 21.3 \text{ minutes}\]
Overlay-Based Synthesis (150 MB overlay):
\[T_{\text{transfer}} = \frac{150 \text{ MB} \times 8}{50 \text{ Mbps}} = \frac{1,200 \text{ Mb}}{50 \text{ Mbps}} = 24 \text{ seconds}\]
\[T_{\text{synthesis}} = 45 \text{ seconds (binary differencing + validation)}\]
\[T_{\text{boot}} = 8 \text{ seconds (VM startup with snapshot optimization)}\]
\[T_{\text{total}} = 24 + 45 + 8 = 77 \text{ seconds} = 1.28 \text{ minutes}\]
Speedup Factor:
\[\text{Speedup} = \frac{1,280}{77} = 16.6\times \text{ faster}\]
Mobile Battery Impact:
The 16.6x speedup makes the difference between “user waits impatiently and gives up” versus “seamless experience while walking to their destination.”
Explore how overlay size, network bandwidth, and synthesis time affect total cloudlet setup time compared to full VM transfer.
How Overlays Work:
Scenario: A visually impaired user enters a museum. Their smart glasses need real-time object recognition to describe artworks.
| Component | Content | Size |
|---|---|---|
| Base VM | Ubuntu 22.04 + OpenCV + CUDA + TensorFlow Lite | 8 GB (pre-cached on cloudlet) |
| Overlay | Museum-specific recognition model + user preferences + accessibility settings | 150 MB |
| Transfer | 150 MB over Wi-Fi (50 Mbps) | 24 seconds |
| Synthesis | Apply overlay to cached base | 45 seconds |
| Total setup | Discovery + negotiation + transfer + synthesis | ~72 seconds |
| Result | Object recognition at 30 fps with <10ms latency | Battery savings: 8x vs local processing |
Without cloudlet: Full VM transfer would take 21 minutes (user has left the museum), or local processing drains battery in 45 minutes.
Understanding when to use cloudlets versus traditional cloud is critical for mobile application design:
Cloudlet Advantages:
Cloud Advantages:
Hybrid Cloudlet-Cloud Architecture:
Most production systems use both – this is the recommended pattern:
Example 1: Carnegie Mellon AR Navigation (Gabriel Platform)
Example 2: Emergency Response Drones
Example 3: Multi-Player Mobile Gaming
Cloudlets are particularly valuable for AR applications that require:
Without cloudlets, these computations either drain mobile battery rapidly (local processing) or suffer from unacceptable latency (cloud processing). The table below quantifies the trade-off:
| Processing Location | Latency | Battery Impact | Quality |
|---|---|---|---|
| Mobile (local) | <5ms | 4-8x drain | Limited by mobile GPU |
| Cloudlet (nearby) | 5-15ms | Minimal (offloaded) | Full GPU quality |
| Cloud (remote) | 80-250ms | Moderate (radio) | Full GPU quality but laggy |
Calculate battery life for a mobile AR application running object recognition at 30 fps under three scenarios: local processing, cloudlet offloading, and cloud offloading.
Scenario Parameters:
Local Processing (Mobile GPU):
\[P_{\text{GPU}} = 8 \text{ W (mobile GPU at full load)}\]
\[P_{\text{baseline}} = 1.5 \text{ W (display + radios + CPU baseline)}\]
\[P_{\text{total}} = 8 + 1.5 = 9.5 \text{ W}\]
\[T_{\text{battery}} = \frac{11.1 \text{ Wh}}{9.5 \text{ W}} = 1.17 \text{ hours} = 70 \text{ minutes}\]
Cloudlet Offloading (Wi-Fi + VNC):
\[P_{\text{Wi-Fi}} = 0.8 \text{ W (active transmission)}\]
\[P_{\text{decode}} = 0.2 \text{ W (VNC frame decode)}\]
\[P_{\text{total}} = 1.5 + 0.8 + 0.2 = 2.5 \text{ W}\]
\[T_{\text{battery}} = \frac{11.1 \text{ Wh}}{2.5 \text{ W}} = 4.44 \text{ hours} = 266 \text{ minutes}\]
Cloud Offloading (LTE + HTTP):
\[P_{\text{LTE}} = 2.5 \text{ W (cellular modem active)}\]
\[P_{\text{decode}} = 0.2 \text{ W}\]
\[P_{\text{total}} = 1.5 + 2.5 + 0.2 = 4.2 \text{ W}\]
\[T_{\text{battery}} = \frac{11.1 \text{ Wh}}{4.2 \text{ W}} = 2.64 \text{ hours} = 158 \text{ minutes}\]
Battery Life Comparison:
\[\text{Cloudlet vs Local} = \frac{266}{70} = 3.8\times \text{ longer battery life}\]
\[\text{Cloudlet vs Cloud} = \frac{266}{158} = 1.68\times \text{ longer (Wi-Fi more efficient than LTE)}\]
Cloudlet offloading extends battery life by nearly 4x compared to local processing, making all-day AR use practical (8 hours with a 6,000 mAh battery).
Wearable devices for cognitive assistance (e.g., smart glasses for face recognition, real-time translation, task guidance) benefit from cloudlets because:
A factory deploys cloudlets on each floor to assist assembly workers wearing smart glasses. The glasses recognize parts, display step-by-step assembly instructions overlaid on the physical workspace, and alert workers to errors in real-time. Key metrics:
Mobile gaming and VR require cloudlet-level latency for:
Beyond mobile applications, cloudlets can serve as intelligent IoT gateways:
Mistake: Designing cloudlet applications the same way you would design cloud applications – with persistent state, horizontal scaling, and always-on assumptions.
Reality: Cloudlets use a soft-state model. VMs are ephemeral. When a user leaves, their VM is destroyed. Do not store important data only on a cloudlet.
Fix: Always design with the assumption that the cloudlet VM will be destroyed. Sync critical state to cloud periodically. Use the cloudlet for computation, not storage.
Mistake: Deploying cloudlets without a strategy for keeping base VM images updated across dozens or hundreds of locations.
Reality: If a cloudlet has an outdated base VM (e.g., missing a security patch or library update), overlay synthesis will fail or produce a broken VM.
Fix: Implement automated base VM update pipelines. Cloud pushes updated base images to cloudlets during off-peak hours. Version-match overlays to specific base VM versions.
Mistake: Designing cloudlet discovery and overlay transfer to work only over Wi-Fi.
Reality: In many deployment scenarios (outdoor events, disaster sites, moving vehicles), Wi-Fi may be unavailable or unreliable.
Fix: Support multiple discovery and transfer mechanisms – Wi-Fi Direct, Bluetooth handshake then Wi-Fi transfer, or even pre-cached overlays for known locations.
Mistake: Assuming VM overlays will stay at 100-200 MB as applications evolve. Teams add ML models, datasets, and dependencies to the overlay without tracking size.
Reality: An overlay that grew to 1.5 GB over six months of feature additions takes 4 minutes to transfer on 50 Mbps Wi-Fi, pushing total setup time past 5 minutes – users abandon the experience. At 10 Mbps (common in crowded venues), transfer alone takes 20 minutes.
Fix: Enforce overlay size budgets (e.g., maximum 250 MB). Move large ML models into the base VM image instead. Monitor overlay sizes in CI/CD pipelines and fail builds that exceed the threshold.
Mistake: Building applications that hard-depend on cloudlet availability, with no fallback path when the cloudlet is offline, overloaded, or out of range.
Reality: Cloudlets are single points of failure at each location. Hardware failures, power outages, or capacity exhaustion (e.g., 50 users competing for 10 VM slots) leave users with a non-functional application.
Fix: Implement a three-tier fallback: (1) try cloudlet first for best latency, (2) fall back to a degraded local mode on the mobile device with reduced quality or frame rate, (3) fall back to cloud if Internet is available. Design the application so each tier provides a usable (if diminished) experience.
Scenario: Calculate the total time required to synthesize a VM for a mobile AR application using cloudlet vs transferring a full VM.
Given:
Step 1: Calculate full VM transfer time
Wi-Fi (50 Mbps):
8 GB = 8,000 MB = 64,000 Mb
Transfer time = 64,000 Mb / 50 Mbps = 1,280 seconds = 21.3 minutesLTE (10 Mbps):
Transfer time = 64,000 Mb / 10 Mbps = 6,400 seconds = 106.7 minutesStep 2: Calculate overlay transfer time
Wi-Fi (50 Mbps):
150 MB = 1,200 Mb
Transfer time = 1,200 Mb / 50 Mbps = 24 secondsLTE (10 Mbps):
Transfer time = 1,200 Mb / 10 Mbps = 120 seconds = 2 minutesStep 3: Calculate total cloudlet setup time
Total = Transfer + Synthesis
Wi-Fi: 24s + 45s = 69 seconds = 1.15 minutes
LTE: 120s + 45s = 165 seconds = 2.75 minutesStep 4: Compare approaches
| Metric | Full VM (Wi-Fi) | Full VM (LTE) | Cloudlet Overlay (Wi-Fi) | Cloudlet Overlay (LTE) |
|---|---|---|---|---|
| Transfer time | 21.3 min | 106.7 min | 24 sec | 2 min |
| Synthesis time | 0 | 0 | 45 sec | 45 sec |
| Total time | 21.3 min | 106.7 min | 1.15 min | 2.75 min |
| Speedup | 1× | 1× | 18.5× | 38.8× |
Key insight: VM overlay approach reduces setup time from 21-107 minutes to 1-3 minutes - making mobile cloudlet offloading practical for users who arrive at a location and need to start working quickly. The 40-80× reduction in data transfer volume is the primary driver.
| Criterion | Traditional Fog Gateway | Cloudlet | Decision Rule |
|---|---|---|---|
| Use case | IoT sensor aggregation | Mobile compute offloading | Use cloudlets when users need personalized compute environments |
| State management | Persistent (hours/days) | Ephemeral (session-based) | Cloudlets for transient user sessions |
| User mobility | Fixed devices | Mobile devices (phones, AR glasses) | Cloudlets when users move between locations |
| Compute model | Containers or bare metal | Full VM synthesis | Cloudlets when users need OS-level isolation |
| Latency requirement | 10-100ms | 1-10ms | Cloudlets when sub-10ms critical (AR, VR, gaming) |
| Deployment locations | Factory floors, buildings | Cafes, malls, transit hubs | Cloudlets in public spaces with transient users |
Example scenarios:
Scenario A: Factory vibration monitoring
Scenario B: AR museum tour
Scenario C: Autonomous vehicle coordination
Rule of thumb: Use cloudlets when you have mobile users requiring personalized compute sessions with sub-10ms latency. Use traditional fog for persistent IoT workloads with stationary devices.
The mistake: Designing applications that store critical user data inside cloudlet VMs without syncing to cloud, assuming VMs persist indefinitely.
Why it fails:
Scenario: AR annotation app for construction workers
Developer implements:
# Store user's work annotations locally on cloudlet VM
def save_annotations(annotations):
with open('/local/annotations.db', 'w') as f:
f.write(annotations) # Only stored on VM
# User completes 4-hour work session, disconnects
# Cloudlet destroys VM to free resources (soft-state model)
# All 4 hours of annotations LOSTWhat actually happens:
How to design correctly:
Cloud-syncing architecture:
def save_annotations(annotations):
# 1. Store locally for performance (immediate writes)
local_db.save(annotations)
# 2. Sync to cloud in background (eventual consistency)
try:
cloud_api.sync(annotations)
except NetworkError:
# 3. Queue for retry when connectivity improves
sync_queue.append(annotations)
# 4. On VM shutdown signal, force final sync
# (cloudlet sends SIGTERM before destroying VM)
# Result: Local performance + cloud durabilityDesign principles for cloudlet applications:
Rule of thumb: Cloudlet VMs are for computation acceleration, not data persistence. All critical state must sync to cloud within 60 seconds.
Exercise 1: VM Overlay Size Calculator
Calculate VM overlay transfer times for different network conditions:
# VM overlay transfer time calculator
def calculate_transfer_time(overlay_mb, bandwidth_mbps):
"""
Calculate transfer time for VM overlay
overlay_mb: Overlay size in megabytes
bandwidth_mbps: Network bandwidth in Mbps
Returns: Transfer time in seconds
"""
overlay_bits = overlay_mb * 8 # Convert MB to Mb
transfer_seconds = overlay_bits / bandwidth_mbps
return transfer_seconds
# Scenario: AR museum app overlay
overlay_size = 150 # MB
# Different network conditions
networks = {
"Wi-Fi 6 (1 Gbps)": 1000,
"Wi-Fi 5 (50 Mbps)": 50,
"Wi-Fi 4 (10 Mbps)": 10,
"LTE (10 Mbps)": 10,
"3G (2 Mbps)": 2
}
print("VM Overlay Transfer Times:")
print(f"Overlay size: {overlay_size} MB\n")
for network, bandwidth in networks.items():
transfer_time = calculate_transfer_time(overlay_size, bandwidth)
print(f"{network:20s}: {transfer_time:6.1f} seconds ({transfer_time/60:5.2f} minutes)")
# Total synthesis time (add 45 seconds for synthesis)
synthesis_overhead = 45
print(f"\nTotal setup time (including {synthesis_overhead}s synthesis):")
for network, bandwidth in networks.items():
transfer_time = calculate_transfer_time(overlay_size, bandwidth)
total_time = transfer_time + synthesis_overhead
print(f"{network:20s}: {total_time:6.1f} seconds ({total_time/60:5.2f} minutes)")What to observe:
Exercise 2: Cloudlet Decision Calculator
Determine when to use cloudlet vs cloud based on application requirements:
def recommend_architecture(latency_ms, data_gb, sensitive, offline):
"""Score cloudlet vs cloud on four weighted criteria."""
cl, co = 0, 0
if latency_ms < 50: cl += 3 # Must be local
elif latency_ms < 100: cl += 1 # Helps but not required
else: co += 1 # Cloud acceptable
if data_gb > 10: cl += 2 # High bandwidth favors local
else: co += 1
if sensitive: cl += 2 # Privacy / compliance
if offline: cl += 3 # Connectivity not guaranteed
winner = "Cloudlet" if cl > co else "Cloud"
return winner, cl, co
# Test scenarios
for name, lat, data, sens, off in [
("AR Museum Tour", 15, 0.5, True, False),
("Video Analytics", 500, 50, False, False),
("Emergency Drone", 30, 5, True, True),
("Smart Home", 200, 0.1, False, False),
("Factory QC", 20, 10, False, False),
]:
rec, sc, cc = recommend_architecture(lat, data, sens, off)
print(f"{name:20s} -> {rec} (cloudlet {sc} / cloud {cc})")What to observe:
Exercise 3: Cloudlet Energy Savings Estimator
Compare battery life when using cloudlet offloading vs local processing:
def battery_days(battery_wh, active_w, usage_h, standby_w=0.1):
"""Days of battery life given active power and daily usage hours."""
daily_wh = active_w * usage_h + standby_w * (24 - usage_h)
return battery_wh / daily_wh
# Smart glasses: 15 Wh battery, 3 h daily AR use
local = battery_days(15, active_w=4.0, usage_h=3) # GPU + CPU
offload = battery_days(15, active_w=0.5, usage_h=3) # Wi-Fi only
print(f"Local: {local:.1f} days")
print(f"Cloudlet: {offload:.1f} days ({offload/local:.1f}x improvement)")What to observe:
Challenge Exercise: Multi-User Cloudlet Capacity Planning
A cafe wants to deploy a cloudlet to support AR applications for customers. Calculate how many concurrent users can be supported:
Given:
Calculate:
Hint: The limiting resource determines capacity: min(cpu_limit, ram_limit, gpu_limit)
This chapter covered cloudlets as specialized fog computing infrastructure for mobile-enhanced applications:
| Question | Answer |
|---|---|
| What is a cloudlet? | Small-scale datacenter at network edge with VM synthesis |
| How big is a VM overlay? | 100-200 MB (1-2.5% of full VM) |
| How fast is VM synthesis? | 30-60 seconds after overlay transfer |
| When to use cloudlet? | Latency <50ms, sensitive data, unreliable connectivity |
| When to use cloud? | Batch processing, ML training, global analytics |
| State model? | Soft-state (ephemeral VMs, no persistent per-user state) |
| Discovery mechanism? | mDNS via Avahi (zero-configuration) |
Core Fog Architecture:
Edge and Cloud Computing:
Mobile and Offloading:
Architecture:
Cloud and Edge Computing:
Networking:
| Topic | Chapter | Description |
|---|---|---|
| Fog Challenges | Fog Challenges and Failure Scenarios | Resource management, security considerations, and real-world deployment failures to avoid |
| Edge AI | Edge AI and ML | Machine learning inference at the edge, often deployed on cloudlets for GPU acceleration |
| Fog Resource Allocation | Fog Resource Allocation | Game-theoretic approaches to sharing limited cloudlet resources among competing users |