BLE Mesh Lost-Item Tracking Protocol

ISEF Category: Embedded Systems

Subcategory: Networking and Data Communications  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

A lost backpack tag does not need to shout all day to get found. It only needs to speak at the right moment, near the right phone. That timing problem can save most of the battery. Your project asks how to predict those moments well enough to keep the tag alive longer.

What Is It?

This project studies a Bluetooth Low Energy, or BLE, mesh protocol for lost-item tracking. BLE uses very small bursts of radio energy, so a tag can last much longer than a normal always-on tracker. The challenge is simple to say and hard to solve: the tag must know when to wake up and when to sleep.

Think of it like a friend waiting outside a building for a ride. If they stand there all day, they waste time. If they check the door at the right times, they catch the ride and save effort. Your protocol tries to do the same thing by predicting when a nearby phone or node is likely to pass by, then scheduling a rendezvous only when the odds look good.

The mobility prediction part uses data about how people move through a city or campus. You can test whether those patterns help the tag choose better wake-up times than a fixed schedule or random polling. The ns-3 simulator lets you model network behavior, and nRF52 dongles can help you build a real hardware demo.

Why This Is a Good Topic

This is a strong science fair topic because you can measure clear tradeoffs. You can compare battery cost, discovery delay, packet delivery, and rendezvous success across different scheduling rules. The real-world problem is easy to explain, since lost-item trackers, smart tags, and low-power IoT devices all face the same energy problem. You can also learn network modeling, data analysis, and hardware validation in one project.

Research Questions

• How does mobility-prediction-based rendezvous scheduling change average battery use compared with a fixed wake-up schedule?
• What is the effect of encounter-frequency thresholds on item discovery delay?
• Does using cellphone mobility datasets improve rendezvous success compared with random encounter models?
• To what extent does node density affect the tradeoff between battery life and recovery time?
• Which prediction window gives the best balance between false wake-ups and missed encounters?
• How does protocol performance change when you test urban, campus, and transit-style mobility traces?

Basic Materials

• Laptop or desktop computer with enough memory for ns-3 simulations.
• ns-3 simulator installed on a Linux system.
• Public cellphone mobility dataset from a university or government source.
• Spreadsheet software for organizing results.
• Digital notebook for protocol design decisions.
• BLE development board or nRF52 dongle for a small hardware proof of concept.
• USB cable compatible with the development board.
• Basic solderless breadboard and jumper wires for simple signaling tests.

Advanced Materials

• University lab computer with Linux and admin access for ns-3 builds.
• Multiple nRF52 dongles or BLE development boards for multi-node testing.
• Logic analyzer for timing checks.
• USB power meter for measuring device draw.
• Smartphone test devices for encounter emulation.
• Packet capture tool or BLE sniffer hardware.
• Access to cleaned mobility traces from a research group or public dataset.
• Statistical software for comparing protocol variants.

Software & Tools

• ns-3: Simulates wireless networks and lets you compare rendezvous rules under different mobility traces.
• Python: Cleans mobility data, runs analysis, and makes plots for battery and delay metrics.
• R: Tests whether differences between protocol versions look statistically meaningful.
• Wireshark: Inspects packet timing and message flow in Bluetooth-related experiments.
• ImageJ: Not needed for the core protocol, so skip it unless you create visual signal maps for a poster.

Experiment Steps

1. Define the exact problem you want to optimize, such as battery use, discovery delay, or both.
2. Choose one baseline protocol so you can measure improvement against a simple reference.
3. Select a mobility dataset and decide how you will turn encounter history into predictions.
4. Design the simulation inputs, outputs, and success metrics before you write any code.
5. Build a hardware demo plan that checks whether the simulation logic still works on nRF52 dongles.
6. Plan your analysis so you can compare protocols with clear graphs and statistical tests.

Common Pitfalls

• Using a mobility dataset without checking whether its movement patterns match your test setting, which can make your predictions misleading.
• Comparing protocols with different message sizes or scan intervals, which confounds battery results.
• Treating simulation success as proof that the hardware will behave the same way, which hides radio timing limits.
• Measuring only average delay and ignoring tail cases, which can hide rare but important missed rendezvous events.
• Changing the prediction rule and the network density at the same time, which makes it hard to tell what caused the result.

What Makes This Competitive

A strong version of this project goes past a simple simulation. You would define a clear baseline, test several mobility models, and report both average performance and worst-case behavior. You could also validate the simulator with a real BLE demo, even if the hardware setup stays small. Careful statistics and a clean explanation of the energy tradeoff can make the work look much more mature.

Project Variations

• Test the same rendezvous idea on campus walking traces instead of city mobility data.
• Compare BLE mesh scheduling against a plain periodic beacon design with the same hardware.
• Change the analysis from battery use to fairness, and ask whether some tags get found much faster than others.

Learn More

• NS-3 Manual: Search the official ns-3 project documentation for wireless and mobility models.
• Bluetooth Core Specification: Find the Bluetooth SIG specifications for BLE advertising, scanning, and connection timing.
• PubMed: Search for review articles on Bluetooth Low Energy in wearable and IoT systems.
• IEEE Xplore: Search for papers on mobility prediction and encounter-based networking, then filter for review or survey articles.
• NASA Earthdata: Use public data portals as an example of how large real-world datasets are documented and shared.
• MIT OpenCourseWare: Search for networking and wireless systems course notes to review packet timing and network performance basics.