Cellular IoT: NB-IoT, Cat-M1 and 5G RedCap for Low-Power Wide-Area

Cellular IoT has finally moved past the promise phase. After years of deploying NB-IoT and Cat-M1 devices in metering, asset tracking, and industrial monitoring, and now prototyping with 5G RedCap silicon, the trade-offs are much clearer than the marketing slides suggest. Choosing between NB-IoT, Cat-M1, and RedCap is not about picking the "newest" technology; it is about matching link budget, mobility, latency, and current consumption to the reality of your application and the networks actually available where you will deploy. In my experience, most field failures come not from the radio standard itself, but from mismatched expectations around power saving modes, operator support, and firmware handling of network quirks. This article shares what I've learned implementing all three on Nordic, Quectel, and Sony-based modules with Zephyr and FreeRTOS.

Why NB-IoT, Cat-M1 and RedCap Solve Different Power and Throughput Problems

The core confusion I see in LPWAN selection is treating these three as successive generations. They are not. NB-IoT and Cat-M1 were both introduced in 3GPP Release 13 as LTE-based Low Power Wide Area (LPWA) technologies, but they were optimized for divergent goals. NB-IoT strips the LTE carrier down to a single 180 kHz physical resource block, sacrificing mobility and throughput for extreme coverage and battery life. Cat-M1 (LTE-M) keeps a 1.4 MHz channel (6 PRBs), supports higher data rates and connected-mode mobility, at the cost of slightly higher peak current and modem complexity. RedCap, defined in Release 17 as NR-Light, is a different animal entirely: it brings 5G Standalone (SA) capabilities down to a reduced-complexity NR device, targeting 10-150 Mbps with much lower latency and better capacity than either LPWA option, but with a power budget that sits between Cat-M1 and full 5G eMBB.

If your device sends 32 bytes every six hours from a basement water meter and needs ten years on a primary cell, NB-IoT is the logical fit. If it is a vehicle tracker that reports GPS every two minutes while moving at 60 km/h and needs to handle a firmware update over the air, Cat-M1 will survive where NB-IoT drops. If you are building a wearable video monitor, an industrial gateway aggregating PLC data, or a battery-powered camera that needs 5G network slicing and sub-100 ms latency without the cost and power of a Qualcomm X65-class modem, RedCap is where you should be looking. I've found that mapping requirements to throughput, latency, mobility, and link budget first avoids months of wasted certification effort later.

Where LoRaWAN and Short-Range Radios Fit in the Decision

Cellular is not always the answer. For private deployments where you control gateway placement, LoRaWAN Network Architecture: Gateways, Network Server and Join Procedures often wins on total cost of ownership, especially for large sensor counts in a campus or agricultural setting. Cellular pays off when you need ubiquitous public coverage, managed QoS, or operation across regions without maintaining your own network. I typically recommend cellular when devices are geographically dispersed, when SLA-backed delivery matters, or when customers explicitly require SIM-based identity and billing.

NB-IoT Deep Dive: PSM, eDRX and the Reality of 180 kHz Operation

On paper, NB-IoT is unbeatable for stationary, low-throughput devices. The 180 kHz narrowband carrier gives a link budget of up to 164 dB when using single-tone uplink and repetitions, roughly 20 dB better than GPRS. This is why NB-IoT can connect from deep indoor locations and underground pits where Cat-M1 struggles. The transport block size is small (up to ~1600 bytes without pre-Release 14 enhancements), peak rates are around 20-30 kbps uplink in half-duplex, and latency can swing from 1.5 seconds to over 10 seconds depending on coverage enhancement level (ECL) and repetitions.

The real power story is not the idle current, it is how you use Power Saving Mode (PSM) and extended Discontinuous Reception (eDRX). With PSM, the device negotiates two timers with the network: T3324 (Active Time) and T3412 (Extended TAU). After releasing the RRC connection, the module stays reachable for T3324 (e.g., 16 seconds), then enters deep sleep where the modem is essentially off. It only wakes for the next Tracking Area Update (TAU) or an uplink-triggered wake. Current drops to 3-8 uA on a well-designed board with a Quectel BG95 or u-blox NORA-W10. eDRX, by contrast, allows longer paging cycles - up to 174 minutes for NB-IoT - so the device can remain registered and reachable with infrequent paging, drawing tens of microamps on average.

The trap I have seen teams fall into is assuming PSM and eDRX are always honored. They are requested by the device but granted by the network, and operator implementations vary wildly. In my experience deploying across Germany, Sweden, and the US, some operators cap T3412 at 4 hours despite requesting 24 hours, and others disable eDRX entirely for NB-IoT. You must read the negotiated timers back after attach and adapt. Also, NB-IoT re-entry from PSM is not instant; expect 2-5 seconds for RRC connection re-establishment in good coverage, and 10-30 seconds in ECL 2 with repetitions.

// Configuring PSM and eDRX on Quectel BG95/BG77 via AT commands
// Request PSM with TAU 24h (01000111) and Active Time 16s (00100001)
AT+CPSMS=1,,,"01000111","00100001"

// Enable eDRX for NB-IoT: mode 2 = enable, RAT 5 = NB-IoT, value 0010 = 20.48s cycle
AT+CEDRXS=2,5,"0010"

// Request eDRX PTW 15.36s and ED RX cycle, and verify granted values
AT+CEDRXRDP
+CEDRXRDP: 5,"0010","0010","0101"

// Check granted PSM timers after attach (network may override)
AT+CEREG=5
AT+CEREG?
+CEREG: 5,1,"1A2B","00C12345",9,,,"01000111","00100001"

OK

NB-IoT Mobility and Cell Reselection Constraints

NB-IoT does not support handover in connected mode - only idle-mode cell reselection. If your device moves faster than pedestrian speed while transmitting, you will see radio link failures and repeated attach attempts that destroy battery life. I've found NB-IoT works reliably only for nomadic or fully stationary devices. If the datasheet says "tracking assets in transit," that is a Cat-M1 workload.

Cat-M1 Mobility and VoLTE: When You Need More Than Static Sensing

Cat-M1 retains much more of LTE's legacy. With 1.4 MHz bandwidth, it supports up to ~1 Mbps downlink and ~375 kbps uplink in half-duplex FDD (Cat-M1 HD-FDD is the most common for low-cost modules), and full-duplex variants push that to 1 Mbps both ways (or ~588 kbps UL with CE Mode A). More importantly, it supports connected-mode handover, essential for vehicles, wearables on the move, and any device that cannot afford to drop a TCP session during cell changes. Latency is also substantially better than NB-IoT: 50-100 ms in good coverage versus 1-10 seconds.

Cat-M1 also inherits VoLTE and SMS support, which NB-IoT does not guarantee. While VoLTE on an IoT sensor seems odd, I have used it for elevator emergency phones and wearable SOS devices where a single SKU must handle both data and voice fallback. The other underappreciated advantage is throughput for firmware updates. On a Cat-M1 module with a 400 kB FOTA image and decent signal (RSRP > -100 dBm), I can reliably complete a delta update over MQTT or LWM2M in under 3 minutes. On NB-IoT, the same update can take 30-45 minutes and may exceed operator fair-use policies.

Power is where nuance matters. Cat-M1 peak current during transmission is higher (~300-400 mA at 23 dBm) than NB-IoT (~200-300 mA) due to wider bandwidth and higher data rates, but because it finishes transmissions faster, the energy per bit is often lower. For infrequent small messages, NB-IoT still wins. For frequent or larger payloads (e.g., 1 kB every 10 minutes), Cat-M1 can be more efficient overall. Both support PSM and eDRX, but Cat-M1 eDRX cycles are shorter (up to ~43 minutes) than NB-IoT, reflecting the expectation of more responsive devices.

/* Zephyr RTOS: Configuring Cat-M1 with PSM/eDRX via modem_chat and power manager
 * Based on Zephyr's cellular modem sample; see Zephyr Project Documentation
 * for modem power management details. */

#include <zephyr/modem/chat.h>
#include <zephyr/modem/cellular.h>

static void configure_lte_m(struct modem_cellular *mdm)
{
    /* Set RAT preference to Cat-M1 only, disable NB-IoT scan */
    modem_chat_cmd_send(&mdm->chat, "AT+QCFG=\"iotopmode\",0,1");
    modem_chat_cmd_send(&mdm->chat, "AT+QCFG=\"nwscanmode\",3,1"); /* LTE only */

    /* Request PSM: TAU 12h, Active 20s - network may negotiate shorter */
    modem_chat_cmd_send(&mdm->chat, "AT+CPSMS=1,,,\"00101001\",\"00101100\"");

    /* configure eDRX: Cat-M1 RAT=4, 81.92s cycle for balanced reachability */
    modem_chat_cmd_send(&mdm->chat, "AT+CEDRXS=1,4,\"0101\"");

    /* Enable Power Saving Mode indication URC */
    modem_chat_cmd_send(&mdm->chat, "AT+CEREG=5");
}

/* Application sleep hook: enter PSM only after MQTT publish ACK */
void app_enter_psm(struct k_work *work)
{
    if (mqtt_publish_acked()) {
        modem_cellular_release(mdm); /* triggers RRC release, then T3324 */
        k_sleep(K_SECONDS(1));
        pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});
    }
}

CoAP and MQTT Session Handling Over Sleepy Links

Application protocol choice interacts directly with PSM. MQTT persistent sessions and keep-alives can conflict with long PSM cycles. If you negotiate a 24-hour TAU and set MQTT keep-alive to 10 minutes, the broker will disconnect you while you sleep. For extremely sleepy NB-IoT or Cat-M1 devices, CoAP vs MQTT: Choosing the Right IoT Protocol for Constrained Devices is essential reading - CoAP with confirmable messages and block-wise transfers maps more naturally to uplink-triggered PSM wake-ups. If you must use MQTT, raise keep-alive above your TAU, use clean session = 0, and rely on the publish that wakes you to re-establish the TCP/TLS session. I cover QoS and session restoration patterns in depth in MQTT Protocol Deep Dive: QoS Levels, Retained Messages and Session Management.

5G RedCap (NR-Light): Bridging the Gap Between LPWAN and Full 5G eMBB

RedCap was not designed to replace NB-IoT or Cat-M1; it replaces underutilized LTE Cat-4 for mid-rate applications now that operators want to sunset LTE capacity. A RedCap device reduces complexity aggressively compared to eMBB: 20 MHz max bandwidth in sub-6 GHz (100 MHz in mmWave, rarely used for RedCap), single RX antenna (or 2 for some variants), 16QAM uplink optional vs mandatory 64QAM, and support for half-duplex FDD. Resulting peak rates are ~150 Mbps DL / 50 Mbps UL in FR1 with a single antenna, and 10-20 Mbps with the most constrained configurations. Latency can reach sub-10 ms on a standalone 5G core with URLLC-like scheduling, and RedCap inherits full mobility, carrier aggregation limited, and network slicing.

Power consumption is the critical discussion. RedCap modems such as Sony Altair ALT1350 and Qualcomm 315 draw more than Cat-M1 - expect idle connected DRX currents of 15-30 mA and active transmission at 600-900 mA - but they are roughly 60-70% lower than full 5G NR modems. eDRX and PSM concepts carry over, but RedCap also leverages 5G's Release 16/17 power savings: Wake-Up Signal (WUS), extended DRX for RRC_INACTIVE, and Bandwidth Part (BWP) adaptation where the device falls back to a narrow BWP when idle. In practice, for a battery-powered 2K camera sending 5-second clips on motion, RedCap offers a viable middle ground: you get 5G SA features without needing a 30 W gateway.

The deployment caveat is network readiness. As of late 2024-2025, RedCap support is rolling out on 5G SA cores, not NSA. If your target operator is still on 5G NSA (which anchors on LTE), RedCap will not attach. I've found that field trials in the US and Middle East on T-Mobile SA and e& networks succeed, but many European operators only offer RedCap in limited zones. Always confirm SA availability, required bands (n77/n78 and n28 are common for RedCap), and core support for RedCap UE capability signaling. Also verify your module's support for 5G reduced bandwidth - some early "RedCap-ready" modules are simply Cat-4 LTE in a new casing.

Hardware Implications: Antennas and Power Architecture for NR

RedCap still requires a competent 5G antenna system, even with single-antenna receive. Antenna efficiency below -3 dBi in bands n77/n78 will cripple throughput and trigger retransmissions that wipe out any power advantage. For battery devices, I recommend a dedicated DCDC for the modem rail (3.3-4.3 V with 2 A peak capability) separate from the MCU rail, plus a large low-ESR bulk capacitor (220-470 uF) within millimeters of the modem VBAT pins. This prevents brownout on NR transmission bursts, a failure mode I have debugged more than once.

Antenna, SIM and Network Registration Pitfalls Across Cellular IoT Variants

All three technologies share a surprisingly similar set of integration pitfalls that have nothing to do with 3GPP releases. Antenna matching, SIM provisioning, and registration sequencing cause more returns than any protocol bug.

For antennas, NB-IoT and Cat-M1 typically use 698-960 MHz and 1710-2170 MHz. Many low-cost "combo" PIFA antennas claim full bandwidth but deliver return loss worse than -6 dB at 700 MHz. On NB-IoT at ECL 2, that poor efficiency translates directly into more repetitions, longer TX time, and 2-3x energy per message. I measure total radiated power (TRP) early and tune matching with a VNA loaded in the actual enclosure, not free space. For Cat-M1 trackers with GNSS, isolate the cellular and GNSS antennas by at least 30 dB; harmonics from the cellular PA can desense the GNSS LNA and lengthen time-to-first-fix by minutes.

SIM and eSIM bring operator dependencies. If you plan to use eSIM or iSIM for global deployment, verify the bootstrap profile and SM-DP+ support for your target operators. A device that attaches fine on Operator A with NB-IoT may be rejected on Operator B due to missing NB-IoT roaming agreements. Cat-M1 roaming is generally more mature, but NB-IoT roaming remains patchy. RedCap roaming is essentially non-existent in 2025 - plan single-operator trials first. Also check whether your operator requires a specific APN or non-IP data delivery (NIDD) for NB-IoT; some use SCEF/NIDD without an IP PDP context, which breaks standard socket code.

Finally, registration sequencing matters. Do not block firmware for 90 seconds waiting for CEREG. Use the modem's URCs. The FreeRTOS Documentation cellular interface and Zephyr's modem_chat both expose asynchronous registration callbacks - use them. In my firmware, I implement a state machine: reset modem -> wait for SIM ready -> send RAT preference -> enable registration URC -> wait for CEREG/CREG with timeout -> query CEDRX and CPSMS granted values -> open PDP context. Retry with exponential backoff and RAT fallback only after 3 consecutive failures. Aggressive fallback scanning between NB-IoT and Cat-M1 can keep the modem in high-power search for minutes.

/* FreeRTOS Cellular: robust attach with timeout and granted PSM readback */
#include "cellular_config.h"
#include "cellular_common.h"

CellularError_t cellular_attach_with_psm(CellularHandle_t h)
{
    CellularPsmSettings_t psmReq = { .mode = 1, .tauSecs = 86400, .activeSecs = 16 };
    CellularEidrxSettings_t edrxReq = { .mode = 1, .rat = CELLULAR_RAT_CATM1, .cycleSecs = 81.92 };

    Cellular_SetPsmSettings(h, &psmReq);
    Cellular_SetEidrxSettings(h, &edrxReq);

    /* Non-blocking registration: 60s timeout, poll CEREG URC */
    CellularError_t ret = Cellular_Register(h, 60000);
    if (ret != CELLULAR_SUCCESS) {
        LOG_WARN("CEREG timeout, RSRP=%d dBm", cellular_get_rsrp(h));
        return ret;
    }

    /* Read back what network actually granted - CRITICAL */
    CellularPsmSettings_t psmGranted;
    Cellular_GetPsmSettings(h, &psmGranted);
    LOG_INFO("PSM granted: TAU %u s, Active %u s", psmGranted.tauSecs, psmGranted.activeSecs);

    /* Adjust MQTT keepalive to exceed granted TAU, avoid broker disconnect */
    mqtt_configure_keepalive(psmGranted.tauSecs + 600);

    Cellular_PdpContext_t ctx = { .apn = "iot.operator.com", .pdpType = CELLULAR_PDP_TYPE_IP };
    return Cellular_ActivatePdp(h, 0, &ctx);
}

Firmware Architecture for Multi-Mode Cellular Stacks on Constrained MCUs

Supporting two or three RATs in one firmware image adds complexity that strains constrained MCUs. A common pattern is to use a single wideband module that supports both Cat-M1 and NB-IoT (e.g., Quectel BG95, Murata Type1SC, Nordic nRF9161) or a RedCap plus LTE fallback module. The application must abstract RAT selection, power policy, and backoff without duplicating modem logic.

I structure firmware with three layers. The modem driver layer handles AT chat, URC parsing, and synchronous error translation, preferably via Zephyr's modem subsystem or FreeRTOS Cellular Library. Above that, a connectivity manager owns RAT policy: it reads a configuration from non-volatile memory or LwM2M that specifies preferred RAT order, PSM/eDRX targets, and per-RAT retry counts. At the top, the application scheduler decides when to connect based on sensor or event triggers, never polling blindly. This separation prevents application code from embedding AT strings for each operator variant.

For multi-mode operation, probe in priority order but cache band and carrier history. If Cat-M1 attach succeeds in 4 seconds, do not waste energy scanning NB-IoT for 30 seconds on the next wake. Store the serving EARFCN and attempt it first. In Zephyr, this can be enabled with AT+QCFG band locks after an initial scan, documented in the Zephyr Project Documentation modem samples. For RedCap modules with LTE fallback, treat LTE fallback as Cat-4, not Cat-M1: power is higher and PSM parameters differ, so reuse the same PSM readback logic before deciding sleep duration.

Security is often overlooked on LPWA links. Always use TLS 1.2 or 1.3 with PSK or certificate mutual auth for MQTT/CoAP, and validate server certificates with time obtained from the network (NITZ) or a prior NTP sync during the same RRC connection. On an NB-IoT device in PSM for 24 hours, the RTC can drift tens of seconds, causing TLS handshake failures if you do not re-sync. I store NTP time in retained RAM and re-validate only when drift exceeds 60 seconds, saving a round trip. For FOTA, use LwM2M or a block-wise CoAP transfer with resume; downloading a 500 kB image over a lossy NB-IoT link without resume is a recipe for corrupted flashes.

Comparative Capabilities: Choosing Your Cellular IoT Access Technology

No single table makes the decision for you, but aligning quantitative differences clarifies which technology deserves prototyping. The values below reflect 3GPP targets and my measured ranges on commercial networks; real-world throughput and latency vary strongly with coverage level and operator configuration.

Use this table to narrow to two candidates, then validate with a field test on the actual operator and modem you plan to certify. Lab performance on a shielded box with a network simulator rarely matches street-level behavior with real eNodeB/gNodeB paging cycles.

Frequently Asked Questions