An IoT module is a self-contained radio subsystem that a product integrates to send and receive data over a wireless network, without the team designing an RF front end from scratch. For a consumer electronics team, that definition is the easy part. The difficult part is that a single module choice locks in three decisions at once: the radio technology, the infrastructure the shipped device depends on, and the compliance route the finished product will follow.

This FAQ-style explainer is written for consumer electronics product designers and hardware teams that are past the question of whether to add connectivity. It answers what LoRaWAN, Sigfox, and 5G RedCap actually are, when each one fits a consumer device, and why the same project often has to decide between an indoor gateway such as the IG41 and an outdoor gateway such as the OG45. Module specifications quoted here come from published Lierda product data; market figures are attributed to the research source that produced them.

The Problem: One Module Choice, Three Decisions

Module selection is not a component purchase with one right answer. It is a three-part decision, and teams that treat it as a parts list usually have to reopen it later:

• Radio decision. The technology fixes throughput, range, power profile, and which spectrum the product occupies. LoRaWAN and Sigfox work in unlicensed sub-GHz spectrum; NB-IoT, LTE Cat.1 bis, and 5G RedCap use licensed cellular spectrum; Wi-Fi, Bluetooth, ZigBee and similar radios operate over local links.
• Infrastructure decision. A LoRaWAN device depends on gateways, either ones the deployment owns (for example the IG41 indoor gateway or the OG45 outdoor gateway) or a public LoRaWAN network. A Sigfox or cellular device depends on a network operator instead. Either way, the user experience after installation is decided at module selection time.
• Compliance decision. Sub-GHz band plans differ by region, and consumer-facing IoT products also meet voluntary cybersecurity labeling in some markets. A module with a wider band range can reduce the number of hardware variants, but it does not remove market-by-market approval.

The practical consequence is that comparing modules on headline parameters alone is unreliable. Two modules with similar output power can imply very different gateway costs, certification counts, and battery expectations once the product reaches the field.

Industry Background: What the Module Market Looks Like Before You Shortlist

Independent market tracking shows that LPWAN and cellular options are both live choices rather than legacy paths, which is why the LoRaWAN, Sigfox, and 5G RedCap question keeps appearing in consumer electronics design reviews:

• Counterpoint Research reported that global cellular IoT module shipments grew 10% year over year in 2024, a rebound driven by demand in China and India.
• The same Counterpoint Research analysis identified LTE Cat-1 bis as the fastest-growing technology in 2024, with shipments increasing 100% year over year and replacing legacy 2G/3G and NB-IoT in many applications.
• MarketsandMarkets estimated the global LoRa and LoRaWAN IoT market at USD 8.0 billion in 2024, with expectations to reach USD 32.7 billion by 2029.
• Grand View Research put the global NB-IoT market at USD 4.16 billion in 2023, with a projected CAGR of 28.1% through 2030.
• IoT Business News reported that China's share of the global cellular IoT module market expanded to 63% in 2024, up from 55% in the previous year.
• Berg Insight reported that the five largest cellular module vendors, Quectel, Fibocom, Telit Cinterion, MeiG, and China Mobile IoT, held a combined 73% revenue market share in 2025.
• Berg Insight data reported by Lierda shows Lierda among the fastest-growing vendors in 2025, with shipments surging 69% year over year.
• The FCC established a voluntary cybersecurity labeling program for consumer IoT products in 2024, known as the U.S. Cyber Trust Mark, based on NISTIR 8425 standards.

Two patterns matter for a design team. First, short-range radios are no longer the automatic default: growth is concentrated in long-range, low-power and cellular categories. Second, compliance is shifting from a checkbox into a product attribute in markets where consumer IoT labeling programs exist.

IoT Module Categories: What Each Family Is Actually For

Short-range modules: Wi-Fi, Bluetooth, ZigBee, and similar

Short-range modules connect a device to a local hub, router, or phone. They offer the highest throughput per unit of cost in this comparison and require no wide-area subscription, but the product inherits whatever local network the customer already owns. This category suits devices that pair with a smartphone app or a home hub, and it is a weak fit for devices installed where no reliable local network exists.

LPWAN modules: LoRaWAN, Sigfox, and NB-IoT

LPWAN modules exist to move small amounts of data over long distances at low power. Inside the family, the network model is the real differentiator. LoRaWAN devices can join a private network built on owned gateways or a public LoRaWAN network. Sigfox devices rely on a public ultra-narrowband network service. NB-IoT devices use licensed cellular spectrum and operator infrastructure. Lierda's portfolio covers LoRa, NB-IoT, Cat.1, 5G, RF, Wi-SUN, Wi-Fi, BLE, and ZigBee, so several of these paths can be evaluated through one supplier conversation.

Cellular modules: LTE Cat.1 bis and 5G RedCap

Cellular modules remove the gateway question entirely: the device uses operator infrastructure that already exists. They sit between LPWAN and short-range radios in the sense that they carry more data than LPWAN comfortably handles while avoiding both a local network dependency and a private gateway build-out. Module-level performance still differs between vendors on the same technology, which is why capability comparisons belong in the evaluation, not only radio-family comparisons. Compared with Cat.1 bis modules based on the ASR platform, the Lierda Cat.1 bis module registers on the network 50% faster and consumes one-fifth the power, a difference that changes the battery math of any product that wakes frequently.

LoRaWAN, Sigfox, and 5G RedCap in Plain Terms

What is a LoRaWAN module, and when does it fit?

LoRaWAN is an open low-power wide-area networking specification built on LoRa modulation in unlicensed sub-GHz spectrum. A LoRaWAN module packages the radio and the protocol stack so a device can join a LoRaWAN network, and the network itself is formed by gateways. The WB28 LoRaMesh module is specified from 868 MHz to 930 MHz with an output of up to 22 dBm. That band range spans the sub-GHz allocations used for LoRaWAN across the main consumer markets, which reduces the number of hardware variants a product line needs to carry, although regional approval is still required for each market. The 22 dBm figure is the module's maximum output; regional rules cap radiated power and channel airtime, so the certified configuration, not the datasheet maximum, defines real-world performance.

Choose LoRaWAN when the device sends small messages, battery life is a constraint, and the deployment can provide gateway coverage, or when a public LoRaWAN network already covers the target area.

What is a Sigfox module, and when does it fit?

Sigfox is an ultra-narrowband LPWAN technology delivered as a public network service and designed for very small, infrequent messages. A Sigfox device does not depend on gateways installed by the product team; it depends on network coverage and a service relationship. The WB16 Sigfox module is specified from 868 MHz to 870 MHz with a maximum output of 12 dBm. The narrower band range means the module matches a specific regional allocation, so teams planning multi-region launches should confirm the correct variant before the design freezes. The 12 dBm maximum output is lower than the WB28 LoRaMesh module's 22 dBm, which affects link-budget planning; the meaningful comparison is module plus antenna against the coverage the product actually needs, not the output figure in isolation.

What is 5G RedCap, and when does it enter the shortlist?

5G RedCap, short for Reduced Capability, is a category of 5G devices defined to serve IoT and consumer products that need more throughput and lower latency than LPWAN provides, at lower cost and complexity than full 5G devices. It becomes relevant when a product sends larger payloads, needs mobility with network handover, or has a service life long enough that 5G longevity is part of the purchasing case. In those projects the working comparison is usually 5G RedCap against LTE Cat.1 bis rather than against LoRaWAN or Sigfox, because the families solve different problems. This article does not quote verified RedCap module specifications, so module-level data has to come from the vendor datasheet.

Gateway Choice: Indoor IG41 or Outdoor OG45

If the module decision lands on a private LoRaWAN network, gateways become part of the product's deployment story. Lierda's gateway line includes the IG41 indoor gateway and the OG45 outdoor gateway, and the naming carries the first decision rule: the environment where the end devices operate.

Four questions usually settle the choice:

1. Where do the devices physically sit? Devices inside a building, such as apartments, retail floors, small offices, or utility rooms, point to an indoor gateway. Devices distributed across outdoor space, such as site lighting, parking areas, or outdoor assets, point to an outdoor gateway.
2. Who installs it, and what power and backhaul already exist? An indoor gateway can usually sit where building power and internet access already exist. An outdoor gateway has to be mounted in a weather-exposed location, which changes the installation story and the labor assumptions behind the roll-out plan.
3. Is the coverage goal one building or a site? If devices must be reached beyond a single building envelope, an indoor gateway is the wrong tool regardless of its price.
4. What is the expansion path? Products that start indoors often grow into outdoor coverage later, and staying inside one gateway family makes that growth a configuration change rather than a redesign.

There is also a product-design consequence. If the customer is expected to install the network, the indoor-versus-outdoor gateway choice becomes part of the user experience. If that expectation is unrealistic, a network the product team does not have to build, such as Sigfox or a cellular option, is usually the cleaner decision.

Step-by-Step: Choosing an IoT Module for a Consumer Device

Working through the decisions in this order prevents a module from being selected before its implications are understood.

1. Define the data profile. Establish how much data the device sends, how often, in which direction, and how much latency the use case tolerates. Small, infrequent uplinks open the LPWAN path; steady or bursty payloads push toward cellular or short-range radios.
2. Define the power budget. Decide whether the product is mains-powered, battery-powered with a replaceable cell, or sealed for life. Low-power LPWAN families were designed around long battery targets, while cellular operation generally demands more energy, so the power budget is what turns a technology list into a ranking.
3. Map the deployment environment. Indoor, outdoor, mobile, or mixed determines the infrastructure: private gateways such as the IG41 or OG45, a public LPWAN service, or existing cellular coverage.
4. Check spectrum and compliance per market. Confirm the module's specified band against every launch market, from 868 MHz to 930 MHz for the WB28 LoRaMesh module and 868 MHz to 870 MHz for the WB16 Sigfox module, and check whether consumer IoT cybersecurity labeling applies, such as the FCC's U.S. Cyber Trust Mark program based on NISTIR 8425.
5. Compare module-level capability, not only the radio family. Registration behavior and power consumption differ between vendors on the same technology. Against Cat.1 bis modules based on the ASR platform, the Lierda Cat.1 bis module registers 50% faster and uses one-fifth the power, a gap that changes the design assumptions of an always-on product.
6. Decide how much customization the project needs. An off-the-shelf module and an OEM or ODM engagement solve different problems. Lierda provides industry consultation, application support, embedded software customization, supply chain management, ODM, and OEM services, supported by more than 20 service centers.
7. Validate with samples, then plan supply. Evaluate the chosen module, and for LoRaWAN the gateway type, on a representative test setup before the design freeze, then confirm supply continuity with the vendor.

Use Cases: Matching Connectivity to Consumer Electronics

Consumer electronics projects rarely settle on one technology for an entire product line. These five patterns cover most of the decisions:

• Smart metering and utility devices. Small, regular uplinks and long service lives make low-power LPWAN the natural starting point. Metering projects commonly evaluate LoRaWAN, NB-IoT, and Cat.1 bis against each other, because the deciding factor is the network the utility already operates.
• POS terminals and payment devices. Transaction traffic and always-on expectations push toward cellular, where Cat.1 bis is often the working assumption and 5G RedCap is worth evaluating for products with a long service life.
• IP cameras and video-adjacent devices. Sustained throughput rules out LPWAN. Wi-Fi is the default where a fixed local network exists, while cellular and RedCap enter when the device must work anywhere.
• Wearables and portable trackers. Bluetooth pairing to a phone covers most consumer cases. A LoRaWAN module such as the WB28 becomes relevant when a device has to report from anywhere on a site without a phone nearby.
• Smart home and building sensors. Wi-Fi, BLE, and ZigBee dominate single-room devices, while whole-building sensor coverage is where a LoRaWAN gateway pair, IG41 indoors and OG45 outdoors, becomes the design baseline.

Comparison Table: LoRaWAN, Sigfox, 5G RedCap, and Cat.1 bis

The table separates what is verified for this article from what must be confirmed in a datasheet, so it can be used directly in a design review.

Two constraints apply to any table of this kind. Published market figures describe the market, not a specific project's business case. Pricing also does not belong in a technology table, because the cost of an IoT module program is decided by network model, band variants, certification scope, and customization, which makes quotes configuration-specific.

FAQ: Consumer Electronics IoT Module Questions

Conclusion: What to Confirm Before the Design Freeze

IoT modules are not interchangeable, and the comparison that matters is not LoRaWAN versus Sigfox versus 5G RedCap in the abstract, but each option measured against the product's data profile, power budget, deployment environment, and launch markets. LoRaWAN fits small-message devices in deployments that can provide gateway coverage, with the WB28 LoRaMesh module specified from 868 MHz to 930 MHz at up to 22 dBm. Sigfox fits very small, infrequent messages in markets served by the public network, with the WB16 module specified from 868 MHz to 870 MHz at a maximum of 12 dBm. 5G RedCap and LTE Cat.1 bis serve products that need cellular throughput without gateways, and module-level differences are real: the Lierda Cat.1 bis module registers 50% faster and consumes one-fifth the power of Cat.1 bis modules built on the ASR platform.

Before the design freeze, confirm four items: the band variant for every launch market, the network model and who installs it, the radio and cybersecurity approvals that apply, and module-level performance measured against your own traffic profile.