Wireless Technology Selection Guide

Quick Cap

Choosing the right wireless technology is one of the most consequential early decisions in an embedded IoT product design. Each technology occupies a distinct niche defined by range, data rate, power budget, topology, cost, and infrastructure requirements. There is no universal "best" wireless -- only the best fit for your specific constraints. Interviewers frequently present a deployment scenario and ask you to choose and justify a wireless technology, testing whether you can think systematically about trade-offs.

This page provides the comprehensive comparison table and decision flowchart you need to answer those questions confidently.

Key Facts:

• BLE: Short range, lowest power, phone-friendly -- the default for wearables and sensors near smartphones
• WiFi: High throughput, native IP, power-hungry -- the default for mains-powered devices needing cloud access
• LoRa/LoRaWAN: Long range, very low power, very low data rate -- the default for private LPWAN on farms, campuses, and factories
• Cellular IoT: Nationwide coverage, no private infrastructure, recurring cost -- the default for remote deployments without WiFi
• Zigbee/Thread: Mesh topology, moderate range per hop, extended coverage -- the default for smart home and building automation
• UWB: Precise positioning (10 cm), secure ranging -- the default for digital keys, asset tracking, and access control

Deep Dive

At a Glance: The Master Comparison Table

Decision Flowchart

When an interviewer asks "which wireless technology would you choose for this scenario?", walk through these requirements systematically:

Step 1: Do you need precise positioning (under 1 meter accuracy)?

If yes, UWB is the only wireless technology that reliably delivers sub-meter accuracy. BLE AoA/AoD (5.1+) can approach 50 cm in ideal conditions but is less reliable. If you need room-level presence (1-5 m), BLE beacons are sufficient.

Step 2: Do you need internet access from the device?

• Yes, and WiFi infrastructure exists: Use WiFi. It provides direct IP connectivity, high throughput, and zero recurring cost. Make sure the device has reliable power (mains or large battery).
• Yes, but no WiFi infrastructure: Use Cellular IoT (NB-IoT for stationary, LTE-M for mobile). The carrier provides nationwide coverage. Accept the recurring subscription cost.
• No internet needed: Continue to Step 3.

Step 3: What is the range requirement?

• Short range (under 100 m), small deployment: Use BLE. It has the lowest power consumption, direct phone connectivity, and the simplest implementation.
• Medium range, large area with many devices: Use Zigbee/Thread mesh. The mesh extends coverage through relay nodes. Choose Thread for new designs; Zigbee if integrating with legacy.
• Long range (1-15 km): Use LoRaWAN. It provides multi-kilometer range on ISM bands with no recurring cost (private gateway). Data rate is very low -- suitable for small sensor payloads only.

Step 4: What is the data rate requirement?

• High throughput (video, audio, large files): WiFi is the only sub-GHz/2.4 GHz technology with Mbps throughput.
• Moderate (OTA updates, richer telemetry): WiFi or LTE-M.
• Low (sensor readings, small payloads): BLE, LoRaWAN, NB-IoT, or Zigbee/Thread are all suitable. Choose based on range and power constraints.

Step 5: What is the power budget?

• Mains-powered: WiFi is fine. Thread/Zigbee router nodes are fine.
• Battery-powered, months to years: BLE (short range), LoRaWAN Class A (long range), NB-IoT with PSM (cellular), or Thread/Zigbee end device (mesh leaf node).
• Energy harvesting (microamps budget): BLE with very low duty cycle, or LoRaWAN with infrequent uplinks.

Decision Summary Table

Common Multi-Radio Combinations

Modern embedded products frequently combine two or more wireless technologies. Each radio serves a distinct purpose.

BLE + WiFi

The most common combination. Used in products like ESP32-based smart plugs, Google Nest devices, and most consumer IoT.

Why both? WiFi cannot easily provision itself -- a headless device needs a way to receive the WiFi SSID and password. BLE provides a reliable, low-power channel for this initial setup. After provisioning, WiFi handles all data. BLE may remain active for local control (phone app within Bluetooth range).

BLE + Thread

Used in Matter-based smart home devices. Apple HomePod Mini, Google Nest Hub, and many Thread-enabled sensors use this combination.

Why both? Thread does not have a built-in commissioning protocol for consumer use. BLE's universal phone support makes it the natural channel for device setup. After commissioning, BLE may be disabled to save power, and Thread handles all ongoing communication.

BLE + LoRa

Used in agricultural and industrial deployments where a local gateway aggregates sensor data.

Why both? LoRa's low data rate (hundreds of bps) makes firmware updates and detailed diagnostics impractical over the air. BLE allows a technician with a phone to connect locally for configuration, debugging, and firmware updates, while LoRa handles the ongoing low-data telemetry over long distances.

BLE + UWB

Used in digital car keys, Apple AirTag, Samsung SmartTag+.

Why both? UWB has shorter range and higher power than BLE. BLE detects the device's presence and establishes an initial connection. When precision is needed (unlocking the car, precision finding an AirTag), UWB activates for accurate ranging. This saves power by only using UWB when the device is already known to be nearby.

Debugging Story: The Wrong Wireless Choice

A startup built a battery-powered pet tracker using WiFi (ESP32) to report GPS coordinates to a cloud server every 5 minutes. The prototype worked well on the bench, but field testing revealed a battery life of only 18 hours -- unacceptable for a product that needed to last 7 days.

The root cause was WiFi's power profile. Each GPS report required: wake from deep sleep (5 uA), power on GPS (30 mA for 10-30 seconds for a fix), connect to WiFi (120 mA for 2-4 seconds including DHCP), send the GPS data over HTTPS (150 mA for 1-2 seconds), then deep sleep again. The WiFi connection alone consumed more charge per cycle than the GPS fix.

The team evaluated alternatives:

• BLE: Would require the owner's phone to be within 30 meters at all times -- not practical for a pet tracker
• LoRaWAN: 12-byte payload was tight for GPS coordinates + metadata, and required deploying private gateways
• LTE-M: Provided nationwide coverage, mobility handover, and sufficient data rate for GPS payloads. PSM sleep current was 5 uA (similar to ESP32 deep sleep), but the cellular connection overhead was only 200-400 ms (vs WiFi's 2-4 seconds) because the modem maintained network registration through PSM

The redesign used a Quectel BG95 (LTE-M) with PSM, reporting every 15 minutes. Battery life improved to 14 days on the same 800 mAh battery. The monthly cellular cost of $0.75/device was acceptable for the product's subscription model.

Lesson: WiFi's connection overhead (scan, authenticate, DHCP) dominates power consumption for infrequent, short transmissions. If your device is battery-powered and needs wide-area connectivity, cellular IoT with PSM often provides better battery life than WiFi with deep sleep, despite cellular's higher peak current. Always calculate the total charge per communication cycle, not just peak current.

What interviewers want to hear: You can systematically evaluate wireless options against specific requirements -- not just recite specifications. You understand that the "right" wireless technology depends on the deployment constraints: range, power, data rate, cost, infrastructure, and mobility. You know that multi-radio designs are common and can explain why each radio is needed. You can calculate or estimate battery life impact for different wireless choices and identify when a seemingly obvious choice (WiFi for cloud connectivity) is actually the wrong one.

Interview Focus

Classic Interview Questions

Q1: "An interviewer describes a deployment scenario. How do you choose the wireless technology?"

Model Answer Starter: "I start with five questions: Does the device need internet access? What is the range to the nearest infrastructure? What data rate is required? Is it battery-powered, and if so, what is the target battery life? Is there existing infrastructure (WiFi APs, cellular coverage, private gateways)? From there: if it needs internet and has WiFi, use WiFi (if mains-powered) or consider cellular if battery-powered. If it is long-range with small payloads, LoRaWAN. If short-range and battery-critical, BLE. If it needs mesh coverage, Thread or Zigbee. If it needs precise positioning, UWB."

Q2: "Why would a product use both BLE and WiFi?"

Model Answer Starter: "BLE and WiFi complement each other because WiFi cannot easily bootstrap itself on a headless device. BLE provides the provisioning channel -- the user's phone connects via BLE to send WiFi credentials. After provisioning, WiFi handles cloud connectivity and high-throughput data. BLE may remain active for local control when the user's phone is nearby. The ESP32 is the canonical example -- single SoC with both BLE and WiFi radios, supporting BLE-assisted WiFi provisioning natively."

Q3: "Compare LoRaWAN and NB-IoT for a remote sensor deployment."

Model Answer Starter: "The key differentiator is infrastructure. LoRaWAN requires deploying private gateways but has zero recurring cost -- ideal for farms, campuses, or factories where you control the property. NB-IoT uses the carrier's existing network with no infrastructure to deploy, but costs $0.50-3/month per device. For 10,000 sensors over 5 years, LoRaWAN saves hundreds of thousands of dollars in subscription fees. But if the sensors are spread across a city and deploying gateways is impractical, NB-IoT provides nationwide coverage out of the box. Secondary factors: NB-IoT has better deep-indoor penetration (164 dB MCL); LoRaWAN has higher data rate (11 kbps vs NB-IoT's 26 kbps, but LoRaWAN has duty cycle limits)."

Q4: "When is UWB worth the extra cost over BLE for positioning?"

Model Answer Starter: "UWB is worth the premium when you need sub-meter accuracy or secure ranging. For applications like digital car keys, the security advantage alone justifies UWB -- BLE RSSI can be relayed to unlock a car from a distance, but UWB's time-of-flight measurement detects relay attacks because radio cannot travel faster than light. For warehouse bin-level tracking, UWB's 10 cm accuracy tells you which shelf a tool is on, while BLE's 3-5 meter accuracy only tells you which room. But for room-level presence (is someone home?), retail aisle detection, or museum exhibit proximity, BLE beacons at $1-3 each are far more cost-effective than UWB anchors."

Q5: "What is the most common mistake when choosing a wireless technology for a new IoT product?"

Model Answer Starter: "Choosing WiFi for a battery-powered device without calculating the power budget. WiFi's connection overhead -- scanning, authentication, DHCP -- takes 2-4 seconds at 120-240 mA. For a sensor that wakes every 10 minutes to send 50 bytes, the WiFi connection consumes far more energy than the actual data transmission. Cellular IoT with PSM or BLE with a gateway often provides months of battery life where WiFi gives only days. The second most common mistake is underestimating the provisioning problem -- shipping a WiFi device without a robust provisioning flow leads to 10-20% setup failure rates in the field."

Trap Alerts

• Don't say: "WiFi is the best choice because it has the highest throughput" -- throughput is rarely the deciding factor for IoT. Power, range, and infrastructure constraints usually dominate.
• Don't forget: Multi-radio designs are the norm, not the exception. Most products combine BLE with another technology. Explain why each radio exists.
• Don't ignore: Recurring cost for cellular -- it seems small per device but scales linearly. 10,000 devices at $1/month is $120,000/year.

Follow-up Questions

• "How would you estimate battery life for a LoRaWAN sensor vs an NB-IoT sensor with the same reporting interval?"
• "What is the role of BLE in a Matter-over-Thread deployment?"
• "How does WiFi 6 TWT (Target Wake Time) change the WiFi vs BLE trade-off for IoT?"
• "If you could only use one wireless technology for a smart building, which would you choose and why?"

Practice

Real-World Tie-In

Consumer IoT Hub -- A smart home startup initially built a WiFi-only sensor hub, requiring each room sensor to connect to the home WiFi router. Users in large homes reported sensors in far rooms dropping connectivity. The redesign added Thread support: the hub became a Thread border router, and sensors used Thread's mesh to relay through mains-powered smart plugs in each room. BLE was used for initial sensor setup. The three-radio approach (WiFi for cloud, Thread for sensors, BLE for commissioning) increased the effective coverage from one room to the entire house.

Industrial Fleet Management -- A logistics company needed to track 8,000 containers across 15 countries. The evaluation compared LoRaWAN (would require hundreds of gateways at ports and warehouses), WiFi (only available at offices, not docks), and cellular LTE-M (carrier coverage at all locations, eSIM for multi-country roaming). LTE-M with eSIM was selected despite the $0.90/device/month cost ($86,400/year total) because the alternative -- deploying and maintaining LoRaWAN gateways across 15 countries -- would cost more in infrastructure and labor.

Precision Agriculture -- A 2,000-acre farm deployed three wireless technologies in a single system. LoRaWAN sensors (soil moisture, weather) reported every 30 minutes to 5 gateways covering the entire property -- zero recurring cost. BLE beacons on irrigation valves enabled technicians with phones to configure schedules locally. A single LTE-M gateway provided the IP backhaul from the LoRaWAN network server to the cloud platform. Total wireless cost: $800 for LoRaWAN gateways + $50/year for one LTE-M data plan -- serving 400 sensors across 2,000 acres.