Toward Real-Time Mirrors Intelligence: System-Level Latency and Computation Evaluation in Internet of Mirrors (IoM)

This paper presents the first physical testbed evaluation of the Internet of Mirrors (IoM), demonstrating that while offloading computation to higher-tier nodes reduces local latency and resource load, the optimal task placement strategy depends on a dynamic trade-off between network conditions, payload size, and concurrent user load.

The Gist

Imagine you have a Magic Mirror in your home. It's not just a mirror; it's a smart device that can look at your smile, analyze your teeth, and tell you if you need to see a dentist. This is the "Internet of Mirrors" (IoM)—a network of these smart mirrors connecting to each other and to big servers to give you personalized health advice.

But here's the big question: Where should the "thinking" happen?

Should the mirror do all the heavy lifting itself? Should it send the picture to a nearby clinic computer? Or should it send it all the way to a massive central hospital server?

This paper is like a race track experiment where the researchers built a real-life version of this system to see which method is the fastest and most efficient. They tested four different "delivery routes" for the mirror's brainpower under two different internet connections: standard Wi-Fi and super-fast 5G.

Here is the breakdown of their findings, using some everyday analogies:

The Four Delivery Routes (Strategies)

Think of the mirror's job as delivering a package (the analysis of your smile) to the customer. The "package" is the data, and the "delivery truck" is the network.

1. The "Do-It-Yourself" Mirror (Consumer-Only)

   • How it works: The mirror tries to solve the puzzle all by itself. It takes the photo, analyzes it, and gives the answer without asking for help.
   • The Analogy: Imagine you are trying to bake a complex cake, but you only have a tiny toaster oven (the mirror's weak processor). You have to do everything yourself. It takes a long time, and you get exhausted (high resource usage).
   • Result: It's slow because the mirror is weak. It doesn't matter if you have fast internet (5G) or slow internet (Wi-Fi) because the mirror is the bottleneck, not the road.

2. The "Neighborhood Helper" (Professional-Offload)

   • How it works: The mirror takes the photo, does a little bit of prep work, and sends it to a computer in the nearby clinic (the "Professional" node). That computer does the heavy math and sends the answer back.
   • The Analogy: You bake the cake batter at home, but you drive it 5 minutes to a friend's house who has a professional oven. They bake it and drive it back.
   • Result: This was the fastest method on Wi-Fi. It's a great balance. The mirror doesn't get tired, and the trip to the neighbor is short.

3. The "Central Command" (Hub-Offload)

   • How it works: The mirror sends the entire raw photo straight to a massive central server (the "Hub") far away. The central server does everything and sends the result back.
   • The Analogy: You mail your raw ingredients to a giant factory across the country. They bake the cake and ship it back.
   • Result: This is slow on Wi-Fi because mailing a heavy package takes time. However, on 5G, it becomes the fastest option. Why? Because 5G is like a high-speed train that can carry heavy loads (big photos) incredibly fast, making the long trip worth it.

4. The "Relay Race" (Tiered-Distributed)

   • How it works: The mirror sends the photo to the clinic, the clinic passes it to the central server, the server does the work, and sends it back through the clinic to the mirror.
   • The Analogy: You pass the cake batter to a neighbor, who passes it to a friend, who bakes it, and then it has to come all the way back through the chain.
   • Result: This has the most stops. It creates a lot of traffic on the road. It's useful if you need to keep detailed records at every stop, but it's usually the slowest because of all the "hand-offs."

The Big Discoveries

The researchers found that there is no single "best" way. It depends entirely on the situation:

• The "Heavy Load" Rule: If you are sending a tiny note (just a log file), 5G is actually slower than Wi-Fi because the phone has to wake up and connect to the cell tower. But if you are sending a giant photo (like the raw image), 5G shines because it can move that heavy data much faster than Wi-Fi.
• The "Crowded Room" Problem: When many people use the mirrors at the same time, the "Do-It-Yourself" mirror crashes and gets very slow. The "Neighborhood Helper" and "Central Command" handle the crowd much better because they have stronger computers.
• The Trade-Off: You can't have everything.
  • If you want to save your mirror's battery and processing power, you must send data over the network (which costs time).
  • If you want to save network time, you have to make your mirror work harder.

The Bottom Line

The Internet of Mirrors is like a team sport. You don't want the weakest player (the home mirror) trying to carry the whole team. But you also don't want to run a marathon just to get a glass of water.

The paper concludes that we need smart, adaptive systems. Imagine a traffic controller that looks at the weather (network speed), the size of the package (data size), and how many people are waiting (concurrent users) to decide: "Okay, today we'll send this to the neighbor. Tomorrow, we'll send it to the central server."

This research proves that for smart mirrors to work perfectly in the real world, they need to be flexible, changing their strategy based on the conditions, rather than sticking to one rigid rule.

Technical Summary

Here is a detailed technical summary of the paper "Toward Real-Time Mirrors Intelligence: System-Level Latency and Computation Evaluation in Internet of Mirrors (IoM)."

1. Problem Statement

The Internet of Mirrors (IoM) is an emerging IoT ecosystem consisting of interconnected smart mirrors organized into a three-tier hierarchy: Consumer (personal/home), Professional (clinics/salons), and Hub (centralized enterprise). A critical design challenge for IoM is determining the optimal computational placement strategy (i.e., where to execute tasks like image processing and AI inference).

• The Trade-off: Placing computation locally (Consumer tier) minimizes network latency but overloads resource-constrained edge devices. Offloading to higher tiers (Professional/Hub) reduces local load but introduces network latency and overhead.
• The Gap: Prior research relied on simulations or single-node models. There was no empirical data on how different placement strategies perform across a physical, multi-tier IoM hierarchy under real-world network conditions (specifically comparing Wi-Fi and 5G).
• The Goal: To empirically characterize the computation-communication trade-off space and identify optimal strategies for varying deployment scenarios.

2. Methodology

The authors conducted the first physical testbed study of the IoM architecture.

A. System Architecture & Hardware

• Three-Tier Hierarchy:
  • Consumer Tier: 3x Raspberry Pi 4 Model B (4GB RAM, Cortex-A72 CPU) representing resource-constrained smart mirrors.
  • Professional & Hub Tiers: 2x NVIDIA Jetson Xavier NX (8GB RAM, 6-core ARM CPU, 384-core Volta GPU) representing clinical workstations and central servers.
• Network: Connectivity provided via local Wi-Fi and public 5G CPE (Customer Premises Equipment).

B. Application Workload

The study utilized a Dental Smile Analysis Pipeline as a representative workload, consisting of four stages:

1. Capture: 600×600 JPEG image acquisition.
2. Pre-processing: Segmentation and normalization.
3. Classification: CNN inference (MobileNetV2) – the most computationally intensive stage.
4. Result Delivery: JSON return to the consumer interface.

C. Experimental Design

Four distinct Computational Placement Strategies were evaluated:

1. Consumer-only: All stages (1–4) executed locally.
2. Professional-offload: Capture/Pre-processing at Consumer; Classification at Professional; Results returned.
3. Hub-offload: Capture at Consumer; Pre-processing/Classification at Hub; Results returned.
4. Tiered-distributed: Capture/Pre-processing at Consumer; Classification at Professional; Logging at Hub.

Variables:

• Strategies: 4 types.
• Network: Wi-Fi vs. 5G.
• Concurrency: 1, 2, and 3 simultaneous consumer nodes.
• Trials: 600 total trials (4 strategies × 2 networks × 3 concurrency levels × 25 repetitions).

D. Metrics

• End-to-End (E2E) Latency: Total time from capture to display.
• Per-Stage Latency: Breakdown of processing vs. transfer time.
• Resource Utilization: CPU/GPU usage across tiers.
• Scalability: Latency degradation and variance under concurrent load.

3. Key Results

A. End-to-End Latency & Bottlenecks

• Consumer-only: Highest latency (~1.5s) because CNN inference on the Raspberry Pi CPU is the bottleneck. Network type (Wi-Fi/5G) had negligible impact as the device was compute-bound.
• Offloading Benefits: Offloading classification significantly reduced latency.
  • Professional-offload was fastest on Wi-Fi (826 ms).
  • Hub-offload was fastest on 5G (810 ms), benefiting from 5G's ability to handle large raw image transfers (2–3 MB) faster than Wi-Fi.
• Tiered-distributed: Incurred the highest network overhead due to multi-hop routing, though it balanced load effectively.

B. Network Transfer Analysis

• Payload Sensitivity: 5G's advantage is payload-dependent.
  • For small payloads (Consumer-only logs), 5G had a slight penalty (+22 ms) due to cellular access overhead.
  • For large payloads (Raw images in Hub-offload), 5G provided a massive reduction (40% lower latency than Wi-Fi).
• Hop Count: Network overhead scales with the number of hops and payload size.

C. Resource Utilization

• Consumer-only: Consumed 68.8% of consumer CPU resources, leaving little headroom for concurrent tasks.
• Offloading: Reduced consumer load to 22–39%, shifting the burden to the more powerful Professional/Hub nodes.
• Distribution: The Tiered-distributed strategy spread load most evenly across all three tiers (Consumer 24%, Professional 37%, Hub 60%).

D. Scalability Under Load

• Consumer-only: Showed the steepest latency degradation under concurrent load (190 ms increase per additional user) and high variance due to CPU saturation.
• Offloading Strategies: Showed much flatter degradation curves. Professional-offload utilized GPU capabilities to handle concurrency with minimal variance.
• 5G Variability: While 5G reduced mean latency growth for heavy-transfer strategies, it introduced higher trial-to-trial variance compared to the more deterministic Wi-Fi environment.

4. Key Contributions

1. First Physical IoM Testbed: The first implementation and evaluation of a three-tier IoM hierarchy on real hardware (Raspberry Pi and Jetson) under live network conditions.
2. Systematic Strategy Comparison: A comprehensive empirical comparison of four placement strategies, moving beyond theoretical models.
3. Computation-Communication Trade-off Characterization: Quantified how network technology (Wi-Fi vs. 5G) and payload size interact with placement decisions.
4. Context-Aware Findings: Demonstrated that no single strategy is universally optimal; the best choice depends on network availability, node proximity, and concurrent user load.

5. Significance and Deployment Implications

The study concludes that intelligent, adaptive task placement is required for IoM systems rather than fixed policies. The findings provide specific guidance for different scenarios:

• Home/Offline (Consumer-only): Suitable for private, single-user scenarios where network independence is prioritized over speed, but unsuitable for multi-user environments due to hardware limits.
• Clinics/Pharmacies (Professional-offload): The recommended strategy for Wi-Fi environments with co-located professional nodes. It offers the best balance of low latency and stable variance.
• Large Multi-Room Clinics (Hub-offload): Optimal for 5G environments with centralized servers. It leverages 5G's bandwidth to handle large image transfers efficiently.
• Longitudinal Tracking (Tiered-distributed): Best for large-scale deployments requiring data logging at the Hub and analysis at the Professional tier, provided 5G is available to mitigate high network overhead.

Final Takeaway: The IoM ecosystem cannot be served by a "one-size-fits-all" approach. Future system designs must employ dynamic optimization algorithms that respond to real-time application requirements, network conditions, and resource availability.