What's changed: Initial version
6.1IoT and wireless communication
Covers BLE (Bluetooth Low Energy) for short-range low-power connections, Wi-Fi for home/office LANs and mesh-capable Zigbee, LPWA (LoRa, NB-IoT, the 920MHz band) linking wide areas at low power, edge computing that processes data near the sensor before aggregating to the cloud, and secure boot guaranteeing startup integrity plus OTA (Over-The-Air) updates in the field.
Selecting a wireless technology for an IoT device is not simply a matter of "just use Wi-Fi." Range, data volume, power consumption, and installation cost (wiring or not) trade off against each other, and the core of the practice is for an embedded designer to choose the wireless standard best suited to the use case. Because the device is network-connected, design decisions around embedded security—detecting tampering at boot and safely updating firmware in the field—are also unavoidable.
6.1.1Short-range wireless: BLE, Wi-Fi, Zigbee
- BLE (Bluetooth Low Energy) links devices over a range of a few to a few tens of meters at extremely low power consumption. It suits wearables and beacons that must run on a coin-cell battery for years, but its data rate is low and it is unsuited to large transfers such as file uploads.
- Wi-Fi delivers high-speed, high-volume communication over a range of tens of meters. It has the advantage of connecting directly to an existing home or office LAN, but its power consumption is high, making it unsuited to battery-powered sensor nodes meant to run for years (it fits mains-powered devices instead).
- Zigbee is a short-range, low-power standard similar in scale to BLE, but its distinguishing feature is that it can form a mesh network. Because each node can also relay traffic, many sensor nodes can be spread across a wide area beyond the reach of a single radio, suiting multi-point sensing inside a factory or building.
6.1.2Wide-area wireless: LPWA (LoRa, NB-IoT, 920MHz band)
- LPWA (Low Power Wide Area) is the umbrella term for a family of wireless standards that link kilometers to tens of kilometers at low power and low data rate. It suits periodic transmission of small amounts of data from installations that are widely scattered, where neither wiring nor Wi-Fi relaying is practical—gas meters, farmland sensors, river water-level gauges.
- LoRa is an LPWA option that lets you build your own private network. It uses the license-free 920MHz band (sub-GHz), so you can install and operate your own gateway without depending on a carrier network. It requires upfront investment but keeps ongoing communication (carrier) costs low, suiting mountainous areas or factory premises where you can place your own gateway.
- NB-IoT is an LPWA option that rides on a carrier's existing cellular (LTE-family) network. Because it uses the existing base-station infrastructure as-is, it requires no gateway of your own and can immediately cover widely scattered sites, but it incurs ongoing carrier subscription and communication costs.
Most-tested contrasts: "BLE = very short range, multi-year battery operation", "Wi-Fi = fast and high-volume but power-hungry", "Zigbee = short range plus mesh networking", "LoRa = 920MHz band, can build a private network, upfront-investment model", and "NB-IoT = carrier cellular network, no gateway of your own needed, ongoing-subscription model". Questions test the ability to work backward from use case (range, data volume, battery life, installation environment) to the right standard.
6.1.3Edge computing and embedded security
- Edge computing performs pre-processing, filtering, and first-pass decisions on the device near the sensor (a gateway or edge device), reducing the volume and frequency of data sent to the cloud. Beyond cutting communication cost, it shortens the latency to a decision and lets local control continue even in environments without a constant cloud connection.
- Secure boot verifies the digital signature of the bootloader and firmware at startup, refusing to boot tampered code. OTA (Over-The-Air) updates update firmware wirelessly without a field visit, allowing vulnerability fixes to be distributed quickly—but if the update package itself is not signature-verified, the OTA channel can become a vector for distributing malicious firmware.
Suppose an embedded designer is building a system that installs several hundred soil-moisture sensors across a vast farmland area, each sending readings to the cloud a few times a day. Each sensor must run on a coin cell or small solar cell, wiring is not practical, and the farmland extends into mountainous terrain where cellular coverage is weak. Short-range wireless (BLE, Zigbee, Wi-Fi) is ruled out first, since covering the whole area would require installing large numbers of relay gateways at a cost that does not pay off. Among wide-area options, NB-IoT, which depends on a carrier's cellular network, has spots in the mountainous terrain with no coverage, and the ongoing subscription cost for several hundred units would add up—making it a second-best fit for this installation. The designer chooses LoRa, building a private network with one or two of the company's own gateways placed on high ground at the center of the farmland where radio reach is good—using the license-free 920MHz band. This requires upfront investment (gateway installation cost) but sharply reduces ongoing communication costs, and mountainous dead zones can be addressed by how the gateways are placed. Anticipating that future vulnerability fixes will be needed, the designer also builds in an OTA update mechanism, but designs it so every update package must carry a digital signature verified before boot (secure-boot-style verification), closing off the path a malicious third party could use to distribute forged firmware. Weighing the installation environment (wiring feasibility, radio reach, node count) against operating cost (upfront vs. ongoing), and folding security design in from the start, is the essence of this practice.
| Standard | Range | Power use | Typical use |
|---|---|---|---|
| BLE | A few to tens of meters | Very low (years on a battery) | Wearables, beacons |
| Wi-Fi | Tens of meters | High (suits mains power) | Fast, high-volume home/office links |
| Zigbee | A few to tens of meters (extended via mesh) | Low | Multi-point sensing in a factory/building |
| LoRa | Kilometers to tens of kilometers | Low | Private network, wide-area low-frequency data |
| NB-IoT | Cellular network coverage | Low | Wide-area IoT without your own gateway |
Trap: "Just always use BLE for IoT sensor wireless" is wrong—BLE excels at short range and low power but cannot reach wide areas and is unsuited to high-data-volume use cases. Also wrong: "LoRa has no communication cost since you just transmit radio waves"—a private network still requires upfront investment (gateway installation); the accurate statement is that no carrier subscription fee is incurred, not that there is no cost at all. Also a dangerous misconception: "OTA updates do not need signature verification"—skipping verification opens a path for distributing malicious firmware.
6.1.4Section summary
- BLE = very short range, multi-year battery life, Wi-Fi = fast/high-volume but power-hungry, Zigbee = short range plus mesh networking
- LoRa = 920MHz band, private network (upfront-investment model), NB-IoT = carrier cellular network (no own gateway, ongoing-subscription model)
- Reduce data volume and latency with edge computing; prevent tampering and forged-firmware distribution with secure boot plus OTA signature verification
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You are distributing several hundred sensors across vast farmland that includes mountainous terrain, sending small amounts of data to the cloud a few times a day. Some spots lack carrier coverage, and you want to minimize ongoing subscription costs. Which wireless approach is most appropriate?
Q2. You want to deploy several dozen temperature/vibration sensors across a factory floor without wiring, with each node also relaying for others so the network covers a wide equipment area. Which standard is most appropriate?
Q3. You made an IoT device's firmware updatable via OTA without a field visit, but later an incident occurred where an unverified, forged firmware image was distributed and devices were hijacked. Which design response is most appropriate to prevent recurrence?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.