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.

One mature NB-IoT application is fixed-location asset monitoring with low-frequency reporting. Smart metering is a typical example: water, gas, and electricity meters report consumption daily or hourly, the operator provides access within its coverage and service conditions, and the platform handles billing and anomaly alarms. Another common category is municipal-facility monitoring: smart manhole covers, standalone smoke detectors, and trash-bin overflow sensors. These scenarios usually share several traits: devices rarely move after installation, second- to minute-level response is often sufficient, and coverage, penetration loss, retransmissions, and power consumption must be measured before deployment.

More broadly, NB-IoT is a standardized cellular option for low-data-rate, massive-connection, low-power terminals. It does not target high throughput or tens-of-milliseconds ultra-low latency; narrowband transmission, coverage enhancement, and power-saving mechanisms serve low-frequency reporting instead. Actual coverage and battery life still depend on the band, base-station configuration, installation location, reporting interval, and retransmission count.

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: IP Access and Gateway Roles

The three candidates commonly use different upper-layer access paths. WiFi usually carries IP directly: a terminal joins a LAN through an access point, after which network policy determines whether it may reach the cloud. Merely joining WiFi does not grant internet access. BLE and Zigbee more often use their own application profiles and networking mechanisms, with a phone, edge gateway, or coordinator carrying data into an IP network. That gateway is a common deployment choice, not a physical-layer law: BLE has adaptation mechanisms for IPv6, and IEEE 802.15.4 can also carry IPv6 stacks such as Thread, although Thread and Zigbee are different upper-layer protocols. Selection must name the complete stack instead of inferring network capability from the radio alone.

The first selection question is whether the terminal must join the existing IP network directly or may connect through a phone, edge gateway, coordinator, or border router. The first path affects module cost, power, and certificate management; the second introduces additional availability, upgrade, and maintenance boundaries.

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? Continuously connected video loads rarely suit ordinary battery terminals; low-duty-cycle WiFi, WiFi HaLow, BLE, and Zigbee still require measurement against chipset sleep current, wake frequency, and message volume.
2. Bandwidth and latency: must the device carry video, large-file OTA, or latency-sensitive traffic? WiFi is often the leading candidate among these three, but coverage, concurrency, interference, and power still need validation.
3. Node scale and interoperability: define the topology, node density, and required application profiles first, then test capacity and interoperability with the target vendor combination; protocol names alone do not establish stability.
4. Access architecture: can the design include a phone, gateway, coordinator, or border router? If not, choose a complete stack that can join the existing network and satisfy its security policy rather than mechanically limiting the answer to one radio technology.
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. For remote metering, agricultural monitoring, or manhole-cover alarms, battery power, infrequent reports, and deep-indoor locations often put LPWAN options such as NB-IoT and LoRaWAN on the shortlist. Satellite IoT, cellular Cat-1 bis, private radio, or wired links may also qualify depending on mobility, coverage, bandwidth, and site conditions. NB-IoT can reuse operator infrastructure, but deployment still requires coverage tests and review of tariffs, roaming, and sunset policy. A private LoRaWAN network offers more control at the cost of operating gateways, a network server, and the supporting service. Unlicensed bands are also subject to regional rules: reporting intervals, packet lengths, and acknowledgment strategies must be calculated against local frequency, transmit-power, duty-cycle, or channel-access requirements rather than generalizing one sub-band's limit worldwide. The question is not which option is uniquely viable, but which meets the target site's link budget, battery life, capacity, compliance, and lifecycle cost.

Class 2: indoor high bandwidth and real-time interaction. For video surveillance, large-screen interaction, and smart speakers, WiFi is usually the best of these three candidates for sustained video and larger OTA payloads, but power, coverage, concurrency, and interference must be evaluated together. Some low-duty-cycle devices can still run on batteries, so mains power is not a universal requirement. BLE and Zigbee favor lower-rate, lower-power workloads. BLE is common in wearables and near-field provisioning because of the phone ecosystem; Zigbee's mesh and application profiles are common in building automation. A typical hybrid places cameras on WiFi, curtain motors on Zigbee, and door locks on BLE, then converges at the application or edge layer. 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.