28  Bluetooth Review: Advanced Scenarios

28.1 Learning Objectives

After completing this chapter, you should be able to:

• Analyze BLE security requirements for medical devices and recommend appropriate pairing and authorization mechanisms
• Diagnose BLE battery drain issues caused by continuous scanning and apply GATT notification-based solutions
• Design reliable smart lock communication using Write With Response and application-level acknowledgement
• Evaluate real-world BLE failure scenarios and propose corrective design changes

For Beginners: Bluetooth Scenarios

This chapter presents advanced Bluetooth scenarios that test your ability to apply what you have learned. Each scenario describes a real-world situation – like designing a BLE-based asset tracking system or troubleshooting connection issues – and asks you to think through the solution like a wireless engineer.

In 60 Seconds

BLE design decisions have real-world consequences: medical devices require LE Secure Connections with application-layer authorization, phone battery drain is solved by switching from continuous scanning to GATT notifications, and smart lock reliability depends on Write With Response plus application-level acknowledgement rather than RSSI-based heuristics.

Key Concepts

• BLE Scenario Analysis Framework: Evaluate each scenario across four dimensions: connectivity (range, topology), power (duty cycle, battery capacity), security (pairing, encryption), and data (rate, latency)
• Asset Tracking Scenario: Typically uses BLE beacons + fixed receivers; key parameters are beacon interval (100 ms–10 s), TX power (for range vs power), and RSSI accuracy (±2–4 dB typical)
• Medical Device Scenario: Requires authenticated pairing (Passkey/OOB), encrypted transport, and connection reliability >99.9%; regulatory compliance (FDA, CE) mandates specific security levels
• Industrial Sensor Scenario: Prioritizes interference resilience, coexistence with Wi-Fi/Zigbee, and deterministic data delivery; BLE Mesh or star topology with redundant paths
• Consumer Wearable Scenario: Balances battery life (>7 days target), fast reconnection (<3 s), and BLE profile compatibility with iOS and Android
• Smart Home Gateway Scenario: Requires simultaneous connections to many peripherals (10–50 devices), OTA update capability, and cloud connectivity bridge
• Retail Beacon Scenario: Uses connectionless BLE advertising (Eddystone-URL, iBeacon) for maximum device density; critical parameters are UUID uniqueness and TX power calibration
• BLE Scenario Trade-off Matrix: Each design decision (interval, PHY, security, topology) creates trade-offs between power, range, throughput, latency, and cost

Minimum Viable Understanding

BLE design decisions have major real-world consequences: medical devices require LE Secure Connections with application-layer authorization (not just pairing), phone battery drain is solved by switching from continuous advertising scanning to GATT connections with notifications, and smart lock reliability depends on Write With Response plus application-level acknowledgement rather than RSSI-based heuristics.

Series Navigation

This is Part 2 of the Bluetooth Comprehensive Review series:

1. Overview and Visualizations - Protocol stacks, state machines, initial scenarios
2. Advanced Scenarios (this chapter) - Medical security, battery drain, smart locks
3. GATT Pitfalls - Common implementation mistakes
4. Assessment - Visual gallery and understanding checks

28.2 Scenario 3: Medical Device Security (Regulated Data)

Real-World Deployment: You’re developing a Continuous Glucose Monitor (CGM) that transmits patient blood sugar readings via BLE to a smartphone app. Healthcare products often require strong security and careful data handling; regulatory obligations vary by region and intended use.

Figure 28.1: Source: University of Edinburgh IoT Security Course - BLE Pairing Phases

Figure 28.2: Source: University of Edinburgh IoT Security Course - Key Generation Methods

Security Level Comparison:

For sensitive health data, treat Bluetooth security as one layer of a broader security architecture.

Recommended approach (high level):

1. Use LE Secure Connections (ECDH-based key agreement) and require an encrypted link for any characteristic that carries sensitive measurements.
2. Choose an authenticated pairing method:
   • Prefer Numeric Comparison or OOB when the product has the UI/commissioning channel.
   • Use Passkey Entry when only one side can display/enter a code.
   • Avoid Just Works for sensitive data because it provides no MITM protection during pairing.
3. Add application-layer authorization even after pairing (e.g., require an authenticated app session before reading data or changing settings).
4. Protect keys at rest: store bonding keys in secure storage where available; provide a way to revoke bonds when phones are replaced or lost.
5. Session management: after inactivity, disconnect or lock sensitive operations and require user re-authentication in the app before resuming.
6. Device lifecycle security: secure boot + signed firmware updates; log security-relevant events as needed.

Implementation sketch (pseudocode):

requireEncryptedLink(true);
requireMitmIfAvailable(true);
setInactivityTimeoutMs(300000);        // 5 minutes
lockSensitiveReadsUntilAppAuth(true);  // app-layer authorization

Verification Questions:

1. What does LE Secure Connections add compared to Legacy pairing?
2. Why is “Just Works” risky in a public pairing environment?
3. Where do you enforce authorization: BLE pairing, GATT permissions, or the application protocol?
4. How do you handle lost phones (bond revocation) without bricking the device?

Scenario 4: Smartphone Battery Drain from BLE Scanning

Real-World Deployment: Your BLE temperature sensor advertises every 1 second with 31-byte payload. After deploying to 100 users, reports flood in: “App drains phone battery in 8 hours instead of 24+ hours.” The sensor battery lasts fine, but smartphones die quickly.

Root Cause Analysis:

Current Implementation (Advertising-Based):

Figure 28.3: Advertising-Based Implementation - Root Cause of Phone Battery Drain

Optimization Comparison:

Figure 28.4: Suboptimal Solutions - None Solve the Fundamental Problem

Option D: GATT Connection (Correct Solution)

Figure 28.5: GATT Connection - The Correct Solution for Phone Battery Life

Power Comparison (24-Hour Period):

Method	Phone Power	Phone Battery	Sensor Power	Sensor Battery
Continuous Advertising Scan	40mA	8 hours ❌	0.032mA	365 days ✅
GATT Connection	2mA	52 days ✅	0.037mA	320 days ✅
Improvement	20× better	156× longer	15% overhead	Acceptable

Production Implementation (Sensor Side):

// ESP32 BLE peripheral -- Environmental Sensing Service
BLECharacteristic tempChar("2A6E", BLERead | BLENotify, 32);

void loop() {
    if (BLE.connected()) {
        tempChar.writeValue(readTemperature());
        tempChar.notify();  // Push update to phone
        delay(1000);
    } else {
        BLE.advertise();    // Wait for connection
        delay(1000);
    }
}

Phone Side (Central):

void onDeviceDiscovered(BLEDevice device) {
    centralManager.stopScan();           // Stop scanning immediately
    device.connect();                     // Establish GATT connection
    device.getCharacteristic("2A6E")
          .enableNotifications(onTempUpdate); // Subscribe
}

Key Metrics:

• Phone battery: continuous scanning can dominate power use; connect/notify can reduce radio active time (platform-dependent)
• Latency: depends on connection interval and update rate
• Sensor battery: advertising/connection parameters trade discovery, latency, and energy

Verification Questions:

1. Why can continuous scanning be more power-hungry than maintaining a connection?
2. When should you use advertising vs GATT connections?
3. How would you handle multiple sensors (10+ devices)?

When to Use Each Approach:

Advertising (Beacons):

• ✅ Broadcasting to MANY receivers (museum exhibit info)
• ✅ Presence detection (AirTag tracking)
• ✅ No pairing needed (public information)
• ✅ One-way data flow (sensor → environment)

GATT Connection (Sensors):

• ✅ Bidirectional communication (phone controls sensor)
• ✅ Frequent data updates (1-10 Hz)
• ✅ Battery-powered phone apps
• ✅ Real-time monitoring (fitness trackers, medical devices)

Production Insights: Many BLE products use: - Advertising for discovery, then connect on demand - GATT notifications for periodic sensor updates - Disconnect on idle and return to advertising - Connection parameter tuning based on latency vs battery goals

Scenario 5: BLE Smart Lock Reliability Issues

Situation: Your BLE smart lock works reliably when the phone is close, but users report occasional failed unlock attempts at longer range or in RF-noisy environments. Connection establishment often succeeds, but the user isn’t sure whether the lock received and processed the unlock request.

What’s happening:

• Links near the edge of range can experience more retransmissions, latency, and occasional disconnects.
• If you use Write Without Response, the client does not get an application-visible confirmation that the lock processed the command.
• RSSI is a noisy heuristic, not a distance sensor. Use it for UI guidance (e.g., “move closer”), not for security decisions.

Putting Numbers to It

RSSI-based distance estimation uses the path loss formula:

\[d = 10^{\frac{RSSI_{measured} - RSSI_{1m} - X_{\sigma}}{10 \times n}}\]

where \(RSSI_{1m}\) is the reference RSSI at 1 meter, \(n\) is the path loss exponent (2.0-4.0 for indoor), and \(X_{\sigma}\) is a zero-mean Gaussian random variable representing multipath fading.

Example: Smart lock with \(RSSI_{1m} = -59\) dBm, \(n = 3.0\) (indoor with obstacles): - Measured RSSI = -75 dBm → \(d = 10^{\frac{-75 - (-59)}{30}} = 10^{-16/30} = 10^{-0.533} \approx 0.29\) m - But with ±10 dBm variance: RSSI could be -65 to -85 dBm → distance estimates 0.10m to 0.83m (8× range!)

This variance explains why RSSI cannot reliably distinguish “at door” (0.3m) from “across room” (2m). Use Write With Response and explicit acknowledgement instead.

Better pattern for critical actions (lock/unlock):

1. Use Write With Response for commands so the client gets an explicit error on failure.
2. Add a separate acknowledgement/state signal from the lock (e.g., a Lock State characteristic that notifies/indicates after the actuator moves).
3. Make commands idempotent and include a nonce/sequence number to prevent replay.
4. Implement timeouts + retries + user feedback, and always provide a fallback (PIN pad, physical key).

Minimal GATT design sketch:

• Lock Control Point (write-with-response): LOCK, UNLOCK, SET_AUTOLOCK(...)
• Lock State (notify/indicate): LOCKED, UNLOCKED, JAMMED, LOW_BATTERY
• Event Log (optional): recent actions for debugging/audit

Verification Questions:

1. Why is application-level confirmation important even though the BLE link layer already retransmits?
2. How would you design the acknowledgement so it is resistant to replay?
3. What UX would you show when RSSI is low or the connection drops mid-command?

Question 13: Compare Bluetooth Classic vs BLE characteristics. Match each feature to the correct technology.

Feature	Classic Bluetooth	BLE
Best for continuous audio streaming
Lower power (when duty-cycled)
Optimized for short, intermittent data bursts
Uses 79 channels @ 1 MHz
Ideal for battery-powered sensors

💡 Explanation: Classic Bluetooth excels at continuous streaming (audio via A2DP and some legacy profiles). BLE is designed for sensors and intermittent data using GATT, advertising-based discovery, and aggressive sleep/duty-cycling. In practice, the right choice depends on throughput, latency, power budget, and device ecosystem support.

Question 15: Match each Bluetooth profile/service to its typical IoT application.

HID Profile

A2DP Profile

SPP Profile

GATT Heart Rate Service

Wireless keyboard/mouse

Stereo audio streaming

Serial UART replacement

Fitness tracker sensor

Explanation: HID (Human Interface Device) profile enables wireless input devices (keyboards, mice, game controllers) with low latency <10ms for responsive input, based on USB HID spec. A2DP (Advanced Audio Distribution) profile streams high-quality stereo audio to headphones/speakers using SBC/AAC/aptX codecs, Classic Bluetooth only (BLE doesn’t support streaming audio until LE Audio/LC3). SPP (Serial Port Profile) emulates RS-232 serial cable for wireless UART communication, used in Bluetooth-to-serial adapters, Arduino HC-05/HC-06 modules, industrial sensors. GATT Heart Rate Service (0x180D) is BLE-only standard profile for fitness trackers with Heart Rate Measurement characteristic (0x2A37), includes BPM + RR intervals + energy expenditure, works with any BLE central supporting standard services. Classic vs BLE profiles: Classic uses SDP (Service Discovery Protocol) with predefined profiles (HID, A2DP, SPP), BLE uses GATT services with 16-bit UUIDs (Heart Rate 0x180D, Battery 0x180F, Environmental Sensing 0x181A).

Question 16: Evaluate these statements about Bluetooth networking concepts. Mark each as True or False.

• A piconet can have one master and up to 7 active slaves
• Scatternet is a BLE-only feature not supported in Classic Bluetooth
• Adaptive Frequency Hopping (AFH) helps Bluetooth coexist with Wi-Fi on 2.4 GHz
• BLE Mesh uses managed flooding with TTL (Time-To-Live) for message propagation

Explanation: (1) TRUE: Classic Bluetooth piconets allow 1 master with up to 7 active slaves; additional devices can be parked and cycled. (2) FALSE: Scatternet is a Classic Bluetooth concept; BLE typically uses star-like connections or mesh networking, not scatternets. (3) TRUE: AFH helps Bluetooth coexist with Wi-Fi by avoiding persistently congested channels. (4) TRUE: BLE Mesh uses managed flooding and TTL to limit how far messages propagate through relays.

Question 17: A BLE temperature sensor advertises every 1000ms (1 second) using non-connectable advertising with 20-byte payload. Advertising consumes 15mA for 2ms per advertisement. Sleep mode consumes 2µA. The device uses a CR2032 battery (220mAh capacity). Calculate the estimated battery life in days.

days

Explanation: Energy consumption calculation: (1) Advertising duty cycle: Active 2ms every 1000ms = 0.002/1 = 0.2% duty cycle. (2) Average current: I_avg = (15mA x 0.002s + 0.002mA x 0.998s) / 1s = 0.03mA + 0.002mA = 0.032mA. (3) Battery life: Battery capacity / average current = 220mAh / 0.032mA = 6875 hours = 286 days, approximately 365 days (1 year) accounting for battery self-discharge (~15% per year for CR2032) and temperature variations.

Question 18: Rank these Bluetooth technologies by maximum range (longest to shortest).

BLE 5.0 Long Range (LE Coded PHY)

Bluetooth Classic Class 1 (+20dBm)

BLE 5.0 Standard (1 Mbps PHY)

Bluetooth Classic Class 2 (+4dBm)

Explanation: Range ranking (longest to shortest): (1) BLE 5.0 Long Range (LE Coded PHY): Up to 1000m (1 km) line-of-sight using S=8 FEC coding, +8dBm TX power, improved receiver sensitivity -103dBm (vs -70dBm for standard BLE). Trades data rate (125 kbps) for 4x range. (2) Bluetooth Classic Class 1: 100m with +20dBm (100mW) TX power. (3) BLE 5.0 Standard (1 Mbps PHY): 30-50m typical indoor range. (4) Bluetooth Classic Class 2: 10m typical with +4dBm TX power.

Sensor Squad: Real-World Bluetooth Scenarios

Sammy the Sensor has three stories from the real world!

Story 1: The Hospital Monitor. Imagine a glucose monitor strapped to a patient’s arm that sends blood sugar readings to a nurse’s tablet via BLE. This is super-sensitive health data! You need multiple locks on the door: first, the devices prove they know each other (pairing with a displayed number). Then the data is scrambled (encrypted). And even after that, the nurse’s app has to log in before it can see the readings. It is like a bank vault with three different keys.

Story 2: The Battery-Draining App. A developer builds a phone app that constantly scans for BLE sensors, like a person standing on the street yelling “IS ANYONE THERE?” every second. The phone’s battery dies in hours! The fix is simple: instead of constantly shouting, just exchange phone numbers (connect once) and say “Text me when something changes” (use notifications). The phone can now sleep peacefully and wake only when a message arrives.

Bella the Battery explains Story 3: “A smart lock that uses BLE needs to be SUPER reliable. If you send an ‘unlock’ command and it gets lost, you are locked out! The trick is to use ‘Write With Response’ – like sending a certified letter where you get a receipt. And always have a physical key backup, just in case.”

28.3 Worked Example: BLE Advertising Interval vs Battery Life

Energy Calculation: How Advertising Interval Affects Battery Life

Device: BLE beacon with CR2032 coin cell (220 mAh, 3V). Radio: nRF52832 (TX at 0 dBm: 5.3 mA for 1.2 ms per advertisement on 3 channels).

Per advertisement event (3 channels):

TX duration: 3 channels x 0.376 ms = 1.128 ms
TX current:  5.3 mA
TX energy:   1.128 ms x 5.3 mA = 5.978 uAs = 0.00166 uAh

Processing overhead: 0.3 ms x 3.0 mA = 0.900 uAs = 0.00025 uAh
Total per event: 0.00191 uAh

Impact of advertising interval:

Interval	Events/sec	Active energy (uAh/day)	Sleep energy (uAh/day)	Total (mAh/day)	Battery life
100 ms	10.0	458	48	0.506	435 days
250 ms	4.0	183	48	0.231	952 days
1000 ms	1.0	45.8	48	0.094	2,340 days (6.4 yr)
2000 ms	0.5	22.9	48	0.071	3,098 days (8.5 yr)
10 s	0.1	4.6	48	0.053	4,190 days (11.5 yr)

Sleep current: 2.0 uA (nRF52832 System OFF with RAM retention).

Key insight: Going from 100 ms to 1000 ms advertising interval extends battery life from 1.2 years to 6.4 years – a 5x improvement. The trade-off: discovery latency increases from ~0.3s to ~3s (phones typically scan in 3-second windows).

Connection interval tuning (after GATT connection established):

Connection interval affects both latency and power:

  7.5 ms interval:  ~1.5 mA avg (fastest response, highest power)
  30 ms interval:   ~0.6 mA avg (good balance for real-time sensors)
  100 ms interval:  ~0.2 mA avg (acceptable for periodic updates)
  500 ms interval:  ~0.05 mA avg (best battery, 0.5s latency OK)
  4000 ms interval: ~0.01 mA avg (near-sleep, for infrequent alerts)

Rule of thumb: double the connection interval = halve the power.

ESP32 BLE connection parameter request:

#include <BLEDevice.h>

// After connection established, request optimized parameters
void onConnect(BLEServer* pServer) {
    // Request 100ms connection interval for periodic sensor data
    // Parameters: min_interval, max_interval, latency, timeout
    // Units: 1.25ms per unit, supervision timeout in 10ms units
    pServer->updateConnParams(
        pServer->getConnId(),
        80,    // min_interval = 80 x 1.25ms = 100ms
        100,   // max_interval = 100 x 1.25ms = 125ms
        4,     // slave_latency = skip 4 events (save power)
        600    // supervision_timeout = 600 x 10ms = 6 seconds
    );
    // With slave_latency=4, sensor can skip 4 connection events
    // and only wake every 500ms (100ms x 5) -- saves ~80% power
    // vs waking every connection event.
}

Interactive Quiz: Match BLE Scenario Concepts

Interactive Quiz: Sequence the Steps

🏷️ Label the Diagram

💻 Code Challenge

28.4 Summary

• Medical BLE security requires LE Secure Connections with authenticated pairing (Numeric Comparison or OOB), encrypted link for sensitive characteristics, and application-layer authorization beyond BLE pairing
• Phone battery drain from BLE sensors is caused by continuous advertising scanning (40mA); switching to GATT connections with notifications reduces average phone power to approximately 2mA – a 20x improvement
• Smart lock reliability depends on Write With Response for critical commands, a separate Lock State notification characteristic for acknowledgement, idempotent commands with nonces, and always providing a physical fallback
• Use standard GATT services (Environmental Sensing 0x181A, Heart Rate 0x180D) for interoperability with generic BLE apps; reserve custom UUIDs for proprietary functionality only
• Test on both iOS and Android early in development – platform-specific BLE security implementations cause silent pairing failures if not handled correctly
• Bluetooth Mesh uses managed flooding with TTL; insufficient TTL causes inconsistent command delivery across the network, not firmware bugs or node limits

Common Pitfalls

1. Applying Wrong Topology for High-Node-Count Scenarios

A star topology with 50 BLE sensor nodes connecting to one gateway creates scheduling bottlenecks — a single BLE controller can support ~10–20 simultaneous connections at reasonable intervals. For 50+ nodes, use connectionless BLE beacons (advertising-only) for read-only telemetry, or implement multiple gateway devices with load-balanced connection assignments.

2. Ignoring Regulatory Constraints in Scenario Planning

BLE medical device scenarios must comply with IEC 60601-1-2 (EMC), FDA 21 CFR Part 11 (electronic records), and potentially HIPAA (data security). Industrial scenarios may require ATEX/IECEx certification for explosive environments. Assuming standard commercial BLE is acceptable for all scenarios leads to expensive late-stage redesigns. Always identify regulatory constraints at the beginning of scenario analysis.

3. Using RSSI-Only Ranging in High-Accuracy Scenarios

RSSI-based BLE ranging has ±2–3 m accuracy in typical indoor environments. For centimeter-accurate asset tracking, use BLE 5.1 Direction Finding (AoA/AoD with antenna arrays) or combine BLE RSSI with UWB ranging for sub-10 cm accuracy. Document the positioning accuracy requirements upfront and select the technology that meets them, rather than defaulting to RSSI and discovering accuracy issues during testing.

4. Neglecting OTA Update Architecture in Scenario Reviews

Scenario analyses that focus on initial deployment without planning for firmware updates leave deployed devices permanently vulnerable to security flaws discovered after launch. The 2021 SWEYNOOTH vulnerability required OTA patches for 480 million BLE devices. Every production BLE scenario must include: update trigger mechanism, differential or compressed firmware delivery, rollback capability, and update verification (signature checking).

28.5 What’s Next

If you want to…	Read this
Understand BLE advertising in depth	Bluetooth Connection Establishment
Implement GATT services on ESP32	BLE Code Examples and Simulators
Secure BLE communications	Bluetooth Security
Deploy BLE in large sensor networks	Bluetooth Network Architecture
Test BLE implementations	Bluetooth Hands-On Lab