4.1 Overview of Mainstream IoT Communication Technologies

Author: Zhang Hongyuan · © 2016–2026 · All Rights Reserved · Copyright & License

4.1.1 Narrowband IoT (NB-IoT): Characteristics and Application Scenarios

Imagine this scene: a municipal department needs to monitor several hundred thousand smart water meters across a city. The meters sit deep inside building riser shafts or even basements, so a remote meter-reading system must penetrate multiple layers of concrete while keeping the devices running on batteries for years. Traditional cellular networks? They do not reach below the manhole cover, and their modules are power-hungry and expensive. The telecom industry's answer was direct: carve an extremely narrow band out of the regular cellular spectrum, then design an air interface specifically for devices that "report a number and go back to sleep." That line of technical development eventually evolved into Narrowband IoT (NB-IoT).

NB-IoT is an LPWA (Low-Power Wide-Area) cellular technology defined by 3GPP in its early releases; together with eMTC (enhanced Machine-Type Communication) it forms the standard connectivity solution for mobile operators serving massive fleets of IoT terminals. It runs in licensed spectrum, which gives it an inherent advantage in network reliability, security, and quality-of-service guarantees — an advantage that alternatives operating in unlicensed spectrum, such as LoRa, cannot simply replicate under the same regulatory conditions. In later releases, chip and module vendors released Cat-NB2 (Category NB2) products, raising peak rates to higher levels through improved uplink resource allocation and modulation while preserving backward compatibility.

Figure 4-1 NB-IoT Network Architecture

The two most prominent engineering metrics in NB-IoT's design are coverage enhancement and ultra-low power consumption. The 3GPP standard defines several coverage enhancement (CE) levels, each increasing the number of downlink repetitions. Through repeated transmissions, the system can raise the link budget high enough to penetrate basements or even sealed manhole covers — at the cost of longer airtime and lower peak rates. A typical measurement scenario: a smart water meter on the second basement level sends a small 200-byte packet at a high coverage level, and the base station must receive several repetitions before decoding successfully; the air-interface time of a single transmission can stretch from tens of milliseconds to hundreds of milliseconds.

Terminal power saving relies on two complementary mechanisms:

• Power Saving Mode (PSM): after reporting data, the device immediately enters deep sleep while the core network retains its session context and IP address; when the device wakes on a preset timer or an external trigger, it resumes the connection directly without re-attaching to the network. PSM sleep duration can be extended significantly.
• Extended Discontinuous Reception (eDRX): the device briefly listens to the paging channel on a long cycle (up to several hours) and keeps its radio asleep the rest of the time. It suits scenarios that require passive wake-up (for example, a platform proactively pushing configuration down to an electricity meter).

Combined, these two mechanisms can push typical standby current down to extremely low levels. One example: a smart water meter powered by two AA alkaline batteries, reporting once a day at a medium coverage level — from a circuit-board design perspective, the battery life can support several years. Real-world battery life, however, is affected by many factors — reporting frequency, battery capacity, ambient temperature, silicon process, and the power-saving parameters the module vendor supplies (such as eDRX cycle settings) — and figures differ noticeably across datasheets, so vendor measurements should be taken as authoritative. Table 4-1 summarizes the key standard parameters of NB-IoT.

Parameter	Standard value / order of magnitude	Notes
Carrier bandwidth	180 kHz	Fixed occupation of one LTE resource block, not dynamically allocated — the direct source of the "narrowband" name
Downlink/uplink peak rate (Cat-NB1)	Approx. 26 / 66 kbps	Carrier peak rates as specified in Rel-13
Downlink/uplink peak rate (Cat-NB2)	Approx. 127 / 159 kbps	Introduced in Rel-14, backward compatible with Cat-NB1
Coverage levels (CE level)	Multiple	Higher levels mean more repetitions — deeper coverage, but greater latency and power consumption
Maximum coupling loss (MCL)	164 dB	About 20 dB over baseline LTE — the quantitative source of the "penetrate manhole covers/basements" capability
PSM sleep duration	Hours to tens of days, standard ceiling about 413 days	Controlled by the periodic TAU timer (T3412 extended)
eDRX paging cycle	Seconds to about 2.91 hours	The NB-IoT idle-mode standard ceiling is about 2.91 hours; longer settings save more power but respond more slowly to downlink
Standby current (PSM/eDRX enabled)	Microamp level (typical values in module datasheets)	Depends on chip implementation, system clock design, and whether an RTC is retained
Operating bands	Multiple LTE bands	Operators can prefer low bands for deployment

Table 4-1 Key NB-IoT parameters at a glance

Note: the peak rates, MCL, and PSM/eDRX ceilings in the table are 3GPP standard values or orders of magnitude derived from standard parameters (carrier peak-rate definitions per TS 36.306 and related specifications; timer ceilings per TS 24.008/TS 23.682); the network capabilities operators actually provision, tariff throttling, and measured values should be viewed separately from these standard values.

For device categories, 3GPP defines two: Cat-NB1 and Cat-NB2. Cat-NB2 introduces more flexible uplink resource allocation and adjusts the upper limit on repetitions. Module vendors can now offer Pin2Pin-compatible multi-mode products (NB-IoT + GSM or NB-IoT + LTE-M), so the same circuit board can switch network standards quickly by mounting a different module. The problem is that modules from different vendors still differ in power management, AT command sets, and firmware-upgrade interfaces — developers still need to adapt when switching module suppliers — so fragmentation has not gone away. This foreshadows the unified access layer design discussed in Section 4.2.

NB-IoT's most mature application is asset monitoring at fixed locations with low-frequency reporting. "Smart metering" has become almost synonymous with the technology — water, gas, and electricity meters report consumption over NB-IoT daily or hourly, the operator guarantees network reachability, and the platform handles billing and anomaly alarms. The other mainstream direction is municipal facility monitoring: smart manhole covers (monitoring open/close state and tilt), standalone smoke detectors (reporting immediately upon fire detection), and trash-bin overflow detection (triggering collection dispatch). These three scenario classes share a common trait: once installed, the devices barely move, real-time requirements are modest (second- to minute-level response is enough), but operator network coverage must exist as the baseline guarantee.

Seen more broadly, NB-IoT is a trump card in operators' expansion from "connecting people" to "connecting things." It does not chase high throughput or tens-of-milliseconds ultra-low latency; instead, using the narrowest RF pipe and extremely low power, it hangs massive fleets of low-frequency, power-frugal terminals onto the operator's cellular system. This "less is more" design philosophy is 3GPP's standard answer for the LPWA direction.

4.1.2 LoRa and LoRaWAN: The Unlicensed-Band LPWAN Route

NB-IoT, discussed in the previous section, is bound to operator-licensed spectrum, which means every device must carry a SIM card and pay for traffic. In real projects, though, many scenarios call for something else: hundreds to thousands of sensors spread over a wide area (kilometers or more), batteries lasting years, and a network entirely under the user's own control with no monthly fees. That is exactly the ecological niche LoRa and LoRaWAN occupy: they bypass the operators and hand control of the network back to the project owner.

The LoRa physical layer (PHY) was originally invented by Semtech and remains Semtech's proprietary technology to this day; what the LoRa Alliance standardizes and maintains is the LoRaWAN specification layered on top of it. One clarification: "unlicensed band" on this route does not mean "private and closed" — LoRaWAN is an open alliance specification; any vendor may implement compliant devices according to it, and interoperability certification within the ecosystem is handled by the alliance. It operates in unlicensed sub-GHz bands — allocations differ by country but generally fall between 400–900 MHz. Its core technique is spread-spectrum modulation: the transmitter "spreads" a narrowband signal across a wider spectrum, and the receiver "compresses" it back with the same spreading code. The direct effect: other narrowband signals in the same band are not correctly despread and are simply filtered out as background noise, so interference immunity is markedly stronger than that of a narrowband FSK (frequency-shift keying) signal at the same power.

By tuning the spreading factor (SF), engineers can trade flexibly between data rate and coverage distance. The higher the SF, the larger the link budget and the farther the reach — but the lower the effective data rate. This mechanism lets LoRa achieve kilometer-scale coverage in unlicensed spectrum, spanning suburbs, farms, and even open countryside. In engineering terms, it reproduces NB-IoT-class coverage in license-free bands, entirely without operator infrastructure.

The LoRa physical layer solves modulation; what actually makes devices interoperate is the network protocol on top of it — LoRaWAN (Long Range Wide Area Network). LoRaWAN uses a star topology and defines four roles: end nodes, gateways, a network server, and (optionally) an application server. End nodes communicate with one or more gateways over single-hop LoRa radio; a gateway only converts LoRa RF packets into IP packets — it parses no business logic and simply forwards them to the cloud-based network server; all protocol processing (deduplication, integrity checking, acknowledgment, downlink scheduling) is concentrated in the network server. This "dumb gateway" design markedly reduces gateway hardware cost and operational complexity, and a single gateway can in theory serve a large number of end nodes. The architecture is shown below.

Figure 4-2 LoRaWAN Network Architecture

Another key LoRaWAN design is its three end-device operating classes:

• Class A (bidirectional, uplink initiated by the end device): the end device may send an uplink at any time and, right after sending, opens two short receive windows for downlink traffic. This is the most power-efficient class, because downlink must wait for the device to transmit first.
• Class B (scheduled downlink slots): on top of Class A, the device additionally opens receive windows at predetermined times synchronized by network-server beacons, allowing the server to deliver commands at deterministic moments; power consumption falls between A and C.
• Class C (continuous receive): the device listens almost continuously, closing reception only for the instant it transmits — lowest downlink latency but highest power consumption.

This lets developers mix device classes within one network: most sensors on Class A, valves or actuators on Class C — chosen as needed.

Typical LoRaWAN applications concentrate where users need to build their own wide-coverage, low-rate networks: smart agriculture (soil-moisture monitoring, weather stations), asset tracking (containers, livestock), remote metering (water, gas), and environmental monitoring (forest-fire early warning, air quality). These terminals are often deployed in areas with no operator cellular coverage, or where users prefer not to pay monthly fees.

Compared with NB-IoT from the previous section, both belong to the LPWA camp, but their design philosophies and cost structures differ markedly; the table below is a qualitative comparison:

Dimension	NB-IoT	LoRa / LoRaWAN
Spectrum	Licensed (operator-assigned)	Unlicensed sub-GHz (allocations vary notably by region)
Peak rate	Low	Extremely low, varies with SF
Typical power consumption	Low	Extremely low (Class A standby can reach the microamp level)
Deployment model	Must join an operator network	Self-built gateways or public gateway services
Cost structure	Module cost + operator tariffs	Module cost + gateway and server build-out, no recurring fees

In practice, the choice hinges on whether the business depends on operators, whether global roaming is needed, and how tariff budgets trade off against building your own network. For projects that want full control of the network, run hundreds to thousands of terminals, and want no monthly fees, LoRa is usually more flexible. Conversely, where operator coverage already exists, a high-reliability SLA is required, and gateway operations should be spared, NB-IoT is the worry-free option. Many projects adopt a dual-mode strategy — NB-IoT in well-covered areas, LoRaWAN in remote ones, unified at the application layer — a well-established practice.

4.1.3 5G URLLC and mMTC: Cellular Enhancements for IoT

LoRaWAN, from the previous section, suits self-built networks with extremely low data rates. But when the engineering scenario stretches from "sending a temperature reading over a few kilometers" to "controlling a robotic arm at millisecond level," the demands on rate and latency climb sharply — while still relying on operator wide-area coverage to spare the maintenance burden of a self-built network. 5G's answer is not merely "a faster phone network": it carves out two entirely new service dimensions specifically for IoT.

5G defines two families of application scenarios for the IoT — URLLC (Ultra-Reliable Low-Latency Communication) and mMTC (massive Machine Type Communication). Together with enhanced Mobile Broadband (eMBB), they form the three scenario directions of IMT-2020 — a taxonomy put forward by ITU-R in its IMT-2020 vision and then carried into the 5G standards by 3GPP. In the IoT context, they represent two sharply different trade-offs: one raises the probability that a radio link delivers successfully within a strict deadline, while the other pursues massive connection counts and long battery life. A boundary is essential: URLLC metrics primarily constrain radio access and its service capabilities; merely "using 5G" does not give a control loop end-to-end determinism. The end-to-end result also depends on the latency and reliability budgets across the terminal, radio access, backhaul, core network, edge computing, field network, and controller.

URLLC: The Engineering Cost of Ultra-Low Latency and High Reliability

URLLC's core objective is to complete transmission with high probability within a given deadline. In the 5G New Radio (NR) design, mechanisms enabling URLLC include flexible slots and mini-slots. LTE uses the subframe as an important scheduling time unit; a 5G NR mini-slot can schedule with fewer OFDM (orthogonal frequency-division multiplexing) symbols, reducing radio-interface waiting time. From a controller issuing a command to an actuator moving, however, the budget still has to include backhaul, the core network, edge applications, the fieldbus, and actuator response. Safety functions such as e-stops should be carried by certified local loops; a public network or ordinary 5G slice must not be the only protection channel.

The costs are equally visible: URLLC generally requires denser coverage, guaranteed radio resources, strict synchronization, and joint design across terminals and the whole network path. Candidate uses include low-latency, high-reliability communication for robot coordination, motion-control assistance, and vehicle-road coordination; whether it may enter a closed control loop must be decided from field measurements, failure analysis, and safety-level requirements. A factory deployment may also isolate the URLLC network from IT traffic and combine it with edge computing, industrial Ethernet, or TSN in an end-to-end design.

mMTC: Massive Connectivity Under Deep Coverage

mMTC goes to the other extreme: not fast, but many and frugal. Its core is connection density — supporting an extremely high number of devices per unit area. In this scenario, what 5G offers is not big bandwidth but an exceptionally strong link budget and deep-coverage capability — letting environmental-monitoring nodes hidden under manhole covers or in basement corners report data reliably.

mMTC's engineering implementation did not start from zero — it directly inherits the design legacy of LTE-M (eMTC) and NB-IoT. In the 5G standard, both are absorbed as supporting technologies of mMTC and continue to evolve in NR-compatible modes. NB-IoT and eMTC already support extremely high connection density. 5G NR further lowers terminal standby current through narrower bandwidth configurations and extended discontinuous reception (eDRX), delivering longer battery life. So when we say "5G connects the water meter," the mechanism in use is still NB-IoT's — merely admitted and managed uniformly as part of the 5G network. This inheritance means devices already using NB-IoT modules can connect directly to an mMTC slice after adapting to the 5G core-network slice, with no hardware replacement.

One Network, Many Slices: The Converged Architecture of 5G IoT

URLLC and mMTC do not run in isolation. With the 5G core network's network slicing capability, one physical network can be virtualized into multiple logical networks: one slice for the factory's industrial robots (URLLC), one for the city's smart streetlights (mMTC), and another for high-throughput video surveillance (eMBB). This architecture means an IoT platform no longer needs "two networks" — it converges vastly different device types through a unified 5G access layer and core network. From the platform's perspective, though, each slice may report data in a different format, so the platform side still needs a unified protocol adaptation layer to normalize this heterogeneous data.

Figure 4-3 5G Network Slicing for IoT

---

URLLC engineering checklist: confirm the following before deploying high-reliability applications —

• [ ] Whether the end-to-end latency budget includes air interface, backhaul, and core-network processing time
• [ ] Whether the terminals support ultra-short feedback (such as fast HARQ retransmission)
• [ ] Whether network slicing is exposed by the operator on the core-network side (some operators require an additional contract)
• [ ] Whether high-reliability scenarios additionally adopt redundant coding or dual-link backup

mMTC engineering checklist: confirm the following before deploying massive connectivity —

• [ ] Whether the terminals come pre-integrated with NB-IoT/eMTC drivers
• [ ] Whether the write pressure of concurrent reporting on gateways/platforms has been assessed for massive-connectivity scenarios
• [ ] Whether the module's power-consumption model fits the reporting cycle of the target scenario
• [ ] Whether NB-IoT/eMTC devices need firmware upgrades to attach to a 5G mMTC slice

4.1.4 WiFi/BLE/Zigbee: Choosing Indoor Short-Range Communication

The previous sections covered kilometer-scale wide-area networks. Move the scene indoors — smart homes, office desktops, factory floors, wearables — and communication distance shrinks back to tens of meters while the business demands immediately diversify. Some devices must survive a year on a coin cell; some need to stream video in real time; others require dozens of nodes to self-organize and relay for one another. "Far" is no longer the requirement; how to trade off "frugal, fast, stable, easy to network" becomes the unavoidable core of every technology choice.

WiFi, BLE (Bluetooth Low Energy), and Zigbee are the three mainstream indoor short-range candidates, each betting on a different trade-off among power, rate, and networking capability. None covers every scenario, but a judgment framework can help engineers filter out wrong options before the design is locked.

Protocol Stack Depth: Natively Online vs. Mandatory Gateway

The three candidates differ fundamentally in protocol stack depth. WiFi is the only one of the three that runs a full TCP/IP stack and lets devices access the internet directly — once powered on, the device can talk to the cloud. The BLE physical layer follows its own GFSK (Gaussian Frequency Shift Keying) modulation specification, and Zigbee reuses the IEEE 802.15.4 standard underneath; both were designed around tiny-packet transport and generally lack direct IP addressing, so their devices must pass through a gateway for protocol conversion before reaching the cloud.

The first step of engineering selection is therefore to judge: does your scenario need a device that connects to the network on its own, or can it accept a solution that must ship with a gateway? The former adds module cost and power; the latter introduces the gateway as an extra failure point and maintenance overhead.

WiFi: The Installed Base and the Price in Power

When phones and home appliances are already on WiFi, developers naturally think, "why not just use WiFi?" Whether that choice pays off depends on three things: the power budget, the node count, and mesh networking needs.

WiFi (the 802.11 family) is designed for high rates: single-stream throughput spans tens to hundreds of Mbps, fitting video surveillance, large-screen interaction, and OTA upgrades. The price is high power consumption — a module transmitting continuously draws far more current than the other two options, so engineering practice rarely uses it for battery-powered devices. Its topology is a classic star: every terminal connects directly to the AP, with no relaying between nodes.

WiFi HaLow (IEEE 802.11ah, approved by IEEE in 2016 and published in 2017; later standardized by the WiFi Alliance), operates in the sub-1 GHz band, trading peak rate for longer coverage and lower power — though its terminal ecosystem and chip supply are still not as mature as products for the main bands. In another direction, newer versions of the standard introduced Orthogonal Frequency Division Multiple Access (OFDMA) and Target Wake Time (TWT); the latter lets devices schedule sleep windows, reducing light-sleep power while remaining standards-compatible — genuinely valuable for battery-powered cameras and door locks, though still a wide gulf from BLE-class ultra-low power.

From an engineering standpoint, WiFi's core advantage indoors lies not in power saving or self-organization but in the installed base: nearly every home and office has a WiFi router, and phones support WiFi natively. If a project's devices are mains-powered, bandwidth-hungry items (such as security cameras or smart speakers), WiFi's "plug-and-connect" character eliminates the cost of gateway procurement and configuration.

BLE: Ultra-Low Power and Mesh Scaling

BLE complements WiFi sharply. It pushes power consumption to an extremely low level: at typical advertising intervals, a coin cell can support months to a year of scheduled reporting or event triggering (typical range) — engineering-attractive for scenarios that must run maintenance-free over long periods. The price is limited rate — BLE 5.x physical-layer peak rates are typically on the order of Mbps, with an indoor communication range on the ten-meter scale (typical line of sight; with no obstruction it can extend to tens of meters, and the long-range coded PHY in the specification adds one more step). Ranging is another matter: the Channel Sounding mechanism introduced in Bluetooth 6.0 (released September 2024) lets two BLE devices perform secure distance measurement with centimeter-level accuracy, and applications such as digital car keys and presence detection are already commercial — but that is "measuring accurately," not "reaching far"; the regular communication range remains on the ten-meter scale. BLE's traditional role is point-to-point devices (a phone connecting to a wristband), but after the BLE SIG introduced the BLE Mesh specification, nodes can relay for one another through "managed flooding," forming mesh networks that cover larger areas.

BLE Mesh's greatest engineering value is that it preserves BLE's ultra-low power: relay nodes, too, can run on batteries. The engineering cost is that mesh topology pushes end-to-end latency up to tens or hundreds of milliseconds — unsuitable for latency-sensitive control scenarios (such as interlocks between devices on an industrial floor). Typical applications include smart lighting control, sensor networks, and wearables.

Zigbee: Standardized Interoperability and a Mature Mesh Ecosystem

Zigbee is a short-range, low-rate mesh protocol designed for smart homes and building automation. Nodes take three roles: the coordinator builds and maintains the network, routers relay, and end devices do not relay in order to save power. The Zigbee Alliance later unified its previously fragmented application-layer specifications (such as ZHA and ZLL), letting devices from different vendors interoperate on the same network. The ZCL (Zigbee Cluster Library) defines the standard functions a device exposes (such as "on/off," "dimming," "temperature measurement"), so application-layer development need not concern itself with protocol-stack details.

Compared with BLE Mesh, Zigbee's large-scale mesh reaches hundreds to a thousand nodes in industrial-grade deployments — on the same order of magnitude as BLE Mesh — while its ZCL definitions are more detailed and its cross-vendor interoperability more mature. The bottleneck is that almost every Zigbee device must reach the internet through a coordinator — the gateway is not optional; it is an intrinsic feature of the architecture.

Engineering Selection: Start from the Scenario, Not the Protocol

The table below compares the three technologies across key engineering dimensions. Parameters are typical ranges, based on orders of magnitude common in chip datasheets and alliance specifications; exact values vary with the actual product.

Parameter	WiFi (802.11 family)	BLE (5.x family)	Zigbee (3.0)
Operating band	2.4/5/6 GHz unlicensed	2.4 GHz unlicensed	2.4 GHz unlicensed, optional sub-GHz
Physical-layer standard	IEEE 802.11	Proprietary (defined by BLE SIG)	IEEE 802.15.4
Typical peak rate	Tens to hundreds of Mbps	On the order of Mbps	250 kbps
Range (indoor)	Tens of meters	Ten-meter scale (typical line of sight)	Ten to a hundred meters
Power level	High	Extremely low	Low
Typical nodes per network	Tens to hundreds (limited by AP capacity)	Thousands (mesh mode)	Hundreds to thousands (mesh mode)
Topology	Star (AP-centered)	Point-to-point, broadcast, mesh	Tree/mesh (coordinator–router–end device)
Device module cost	Medium	Low	Low to medium

Beyond the table above stands one unavoidable real-world constraint: band coexistence. The 2.4 GHz band is unlicensed spectrum shared by Wi-Fi, BLE, and Zigbee, with no priority among them — a single heavy Wi-Fi transfer can push a co-band Zigbee link into retransmissions or even disconnection, and BLE's adaptive frequency hopping likewise collides periodically with Zigbee channels. Each alliance defines coexistence mechanisms (such as BLE's adaptive frequency hopping avoiding occupied channels), but what actually works in engineering is channel planning, antenna isolation, and throughput budgeting. In device-dense environments (one building holding both hundreds of Wi-Fi terminals and fields of sensors), coexistence should enter the selection checklist alongside power and bandwidth — not be patched up after go-live.

Engineering selection checklist:

1. Power budget: is the device battery-powered or mains-powered? Battery power rules out WiFi outright (BLE is the first choice, Zigbee the second).
2. Bandwidth needs: must the device carry video, large-file OTA, or latency-sensitive traffic on board? If so, only WiFi qualifies.
3. Node scale and interoperability: beyond a certain node count, with multi-vendor devices expected to interoperate, Zigbee — backed by the maturity of the ZCL specification — is the steadier choice.
4. Gateway acceptance: can a gateway device be introduced? If not, WiFi is the only option; if yes, both BLE and Zigbee are candidates.
5. Bulk OTA frequency: will devices need frequent remote upgrades? WiFi wins in this scenario; BLE upgrades slowly; and with too-frequent OTA, Zigbee's network load crowds out business traffic.

Scenarios that clear all three filters — dozens of battery-powered sensors, no dense OTA requirement, a gateway accepted as a failure point — usually land on Zigbee as the lowest long-term operations cost. In practice, though, the three are not mutually exclusive. Many premium smart-home gateways integrate a Zigbee coordinator, BLE Mesh, and WiFi side by side, letting the devices of different scenarios land on the best-fitting protocol. The unified-access problem behind this is expanded on in the sections below.

4.1.5 Technology Comparison and Selection Guidance

From NB-IoT to Zigbee, every physical layer and MAC mechanism corresponds to a specific set of engineering constraints. Faced with a real project, the five dimensions — distance, rate, power, cost, and deployment convenience — conflict so strongly that satisfying them all at once is nearly impossible. Higher rates mean higher signal-to-noise requirements and module power consumption; longer distance needs a bigger link budget, usually paid for in rate. The essence of selection is "ranking the weights for the scenario at hand."

The radar chart below uses five axes to show how the six technologies relatively emphasize the five constraints. Note that this is a qualitative framework distilled from engineering practice — it reflects neither measured benchmarks nor standardized data; the scores on each axis are qualitative comparisons and must not be used for precise selection decisions.

Figure 4-4 IoT Wireless Technology Selection Radar (Illustrative)

Translating the radar chart's relative strengths into engineering decisions breaks down into three typical scenario classes.

Class 1: wide coverage, low-frequency reporting. Remote metering, agricultural environmental monitoring, manhole-cover tilt alarms. Devices run on batteries, report once every few months or even years, and often sit in signal dead zones. The LPWA camp (NB-IoT and LoRa) is the only realistic choice. NB-IoT's advantage is ready-made operator infrastructure: insert a SIM card into the module and connect the platform to the core network — no self-built network elements. LoRa fits signal blind spots, border areas, or cases where the business wants full control of the network — at the cost of erecting your own gateways and connecting to a network server over LoRaWAN. Note also a regulatory hard constraint on unlicensed bands: the duty cycle. For example, the EU 868 MHz band caps each device's cumulative transmit time share at 1%, so the uplink data a single terminal can emit per unit time has a hard ceiling — reporting intervals, packet lengths, and acknowledgment strategies must all be designed around this red line; a terminal may not simply transmit whenever it pleases. The channel and transmit-time limits of China's 470–510 MHz band likewise call for checking the local radio administration's rules at the design stage. The decision rule: with existing operator coverage and acceptance of traffic fees, NB-IoT is the default candidate; to control long-term operating costs or avoid operator dependence, LoRa is more flexible.

Class 2: indoor high bandwidth and real-time interaction. Video surveillance, large-screen interaction, smart speakers. Only WiFi can reliably carry HD video streams and support online firmware upgrades, but its high power consumption dictates mains supply. BLE and Zigbee take the power-frugal route and dominate among battery-powered devices. BLE, backed by the mature phone ecosystem, wins in wearables and near-field provisioning; Zigbee, with its mature self-organizing mesh protocol stack, is steadier in building automation (lighting, sensor networks). A typical hybrid: cameras on WiFi, curtain motors on Zigbee, door locks on BLE — three networks converging at the same smart-home gateway. Multi-protocol coexistence is the engineering norm.

Class 3: high mobility, latency-sensitive. AGV scheduling, remote control, and industrial robot coordination. 5G URLLC can provide a low-latency, high-reliability wireless bearer for the mobile segment, but end-to-end determinism still depends on the field network, edge computing, and control system together. If a device follows a fixed path and can be wired, industrial Ethernet is often more direct. A common misreading of mMTC also deserves clearing up: mMTC is a scenario category defined by ITU in the IMT-2020 vision, not an independent new-radio technology; within 3GPP it is carried primarily by technologies such as NB-IoT and eMTC. There is therefore no simple "5G mMTC versus NB-IoT" choice.

Multi-protocol coexistence is not an ideal — it is the norm. The same smart park may simultaneously contain door locks (BLE), streetlights (LoRa), cameras (WiFi), and water-pipe pressure sensors (NB-IoT). Each device runs a single protocol, but the engineered system is often a patchwork of three to five. The real difficulty lies not in the protocols themselves but in how the platform side unifies data from these different links into a single device model and business interface. The last row of any selection table should read: whichever protocol a device uses to join the network, everything must converge at the platform layer.

4.1.6 The 2026 View of Connectivity Evolution: RedCap, NTN, Wi-Fi 7, Matter/Thread, and TSN

The earlier taxonomy no longer captures the reality that "5G-Advanced/RedCap, satellite NTN, Wi-Fi 6/6E/7, Matter over Thread, and industrial TSN" are developing in parallel (a qualitative summary; refer to standards-body announcements for exact timelines). They are not a "next generation" replacing existing LPWAN or Wi-Fi — they are complementary options under specific constraints. When selecting, map requirement constraints onto the decision paths:

Low power, low data rate, wide-area coverage
  → LoRaWAN / NB-IoT

Medium bandwidth, existing 5G coverage, mobility or high reliability
  → 5G RedCap / eRedCap (3GPP Release 17/18)

No terrestrial network, ocean-going/remote, larger latency acceptable
  → 3GPP NTN (IoT NTN or NR NTN)

Interoperable home and commercial devices, low-power mesh
  → Matter over Thread / Wi-Fi

High-density office / HD video / AR
  → Wi-Fi 6E / Wi-Fi 7

Industrial real-time control, sub-millisecond latency and deterministic scheduling
  → Industrial Ethernet + TSN (IEEE 802.1)

A few additional notes:

• RedCap and eRedCap: as 5G NR's "mid-speed IoT" category, aimed at cameras, wearables, and industrial wireless sensing — scenarios where NB-IoT is too narrow and 5G eMBB is too heavy. During selection, confirm the target operator's commercial footprint and module supply; never equate the existence of a 3GPP specification with commercial availability.
• China's cellular IoT landscape: the 2G/3G sunset is entering its final stage; the installed base of mid-speed IoT connections is being taken over by LTE Cat.1, while NB-IoT continues to evolve for low-bandwidth, small-data scenarios. 5G-Advanced (3GPP Rel-19, frozen in December 2025) brings batteryless terminals such as Ambient IoT into the scope of standardization. This evolution line likewise follows "standards first, commercialization later"; the actual pace should be judged by operators' in-network capabilities.
• NTN: satellite-cellular convergence suits ocean shipping, oil and gas, forestry, and cross-border asset tracking. Link budgets and round-trip latency are far larger than in terrestrial networks, so the business side must be designed around hourly heartbeats rather than second-level telemetry.
• Wi-Fi 7: MLO, 320 MHz channel width, and 4K-QAM improve indoor high density and low latency, but they do not change the endpoint power structure; coin-cell devices should still stay on BLE/Zigbee/Thread.
• Matter and Thread: Matter defines the application-layer device model and commissioning flow; Thread is merely one bearer. The current version anchors are Matter 1.5 (2025-11) and Thread 1.4 (2024-09); when selecting, first confirm which version the target device's certification is based on. If the goal is interoperability with consumer ecosystems, Matter is a workable entry point; industrial protocol interoperability still rests mainly on OPC UA and Modbus.
• TSN: it solves "network determinism," letting Ethernet carry real-time synchronization between PLCs; it is not a wireless technology, nor a replacement for 5G URLLC — the two can cooperate within the same factory (URLLC covering the mobile segments, TSN the fixed backbone).

As an engineering practice, keep the structure of "one primary link per device + normalization at the platform side": new technologies stack on top of the original six rather than replacing them wholesale; the platform's device model, authentication, audit, and OTA should reuse one set of interfaces for every new link, instead of copying a new backend each time a new protocol is introduced.

← 3.8 Sensing-Layer Engineering Summary4.2 The Challenge of Protocol Fragmentation and the Need for Unified Access →