5G RedCap for embedded IoT: useful 5G without full 5G complexity

#iot #embedded #5g #security

5G RedCap is becoming one of the more interesting connectivity options for embedded products that sit between classic cellular IoT and full 5G.

It is not meant to replace NB-IoT or LTE-M in tiny low-power sensors. It is also not meant to replace full 5G NR in high-throughput routers or eMBB devices.

The useful space is the middle: industrial gateways, connected cameras, mobile HMIs, richer asset trackers, smart grid equipment and edge devices that need more than LPWA but less than a full 5G modem.

What RedCap actually changes

RedCap means Reduced Capability. It was introduced in 3GPP Release 17 as a lighter 5G NR device category. The basic idea is to reduce device complexity by limiting capabilities such as maximum bandwidth, antenna configuration, carrier aggregation and processing requirements.

That matters in embedded systems because the modem is never isolated. It affects:

BOM and module availability
antenna design and enclosure constraints
peak current and sleep strategy
carrier certification
Linux integration
OTA behavior
diagnostics and field support
product security lifecycle

In other words, RedCap is not just a radio choice. It changes the system architecture.

Where it fits

RedCap can make sense when a device needs:

more bandwidth than NB-IoT or LTE-M
better alignment with 5G Standalone roadmaps
medium-size telemetry or diagnostic payloads
OTA updates that are too heavy for very low-power links
remote access, VPN or backend integration
private 5G or industrial network support
a longer product lifecycle than an LTE-only design may suggest

It is especially interesting for embedded Linux gateways, industrial routers, edge AI cameras, utility equipment and professional mobile devices.

Where it does not fit

RedCap is not automatically the best answer.

If a device sends a few bytes per day and must run for years on a small battery, NB-IoT or LTE-M may still be better.

If the product needs continuous high-bitrate video, heavy uplink or CPE-class performance, full 5G NR may be the right tool.

If the installation always has reliable local infrastructure, Wi-Fi or wired Ethernet may be simpler and cheaper.

The point is to compare technologies against the product behavior, not against the marketing label.

Embedded Linux integration checklist

For a Linux gateway, treat the RedCap modem as a critical subsystem.

redcap_linux_integration:
  modem_interface:
    qmi_or_mbim_selected: true
    modemmanager_profile_tested: true
    networkmanager_policy_defined: true
    hardware_reset_gpio_available: true
  connectivity:
    lte_fallback_tested: true
    roaming_policy_defined: true
    apn_profiles_versioned: true
    vpn_or_private_apn_evaluated: true
  operations:
    modem_firmware_update_process_defined: true
    logs_persisted_for_field_debug: true
    watchdog_recovery_flow_tested: true
    remote_diagnostics_enabled: true

The important details are usually boring and very practical:

Can the host reset the modem without a power cycle?
Are QMI, MBIM or AT flows deterministic enough for recovery?
Are network state transitions logged persistently?
Is LTE fallback validated in the target countries?
Can field support see RSSI, operator, APN, roaming and attach failures?
Is modem firmware update part of the maintenance process?

Security and OTA are part of the decision

A RedCap device is often remotely reachable, updateable and connected to cloud services. That makes secure boot, signed OTA, credential handling and vulnerability management part of the connectivity decision.

For new connected products in Europe, this also intersects with the Cyber Resilience Act lifecycle mindset: products need to be maintainable, updateable and designed with cybersecurity in mind from the beginning.

At minimum, I would verify:

signed firmware artifacts
downgrade prevention
rollback or recovery path
device identity model
TLS certificate lifecycle
hardened credential storage
debug access policy
vulnerability handling process
remote logs for update and modem failures

The modem gives the product reach. The security architecture decides whether that reach is acceptable.

Power and RF can make or break the project

RedCap reduces complexity compared with full 5G, but it should not be confused with ultra-low-power LPWA.

Measure on the real target:

attach peak current
idle current
sleep behavior
consumption during OTA
behavior with weak signal
reconnect and retry patterns
thermal behavior in enclosure
antenna performance in final mechanics

Many cellular product failures do not come from the selected standard. They come from optimistic power assumptions, weak antenna integration or recovery flows that were never tested outside the lab.

A practical adoption roadmap

flowchart TD
  A["Use-case analysis"] --> B["Compare NB-IoT, LTE-M, LTE Cat-1/4, RedCap and full 5G"]
  B --> C["Select module and target bands"]
  C --> D["PoC on real hardware"]
  D --> E["Measure power, attach, uplink, fallback and recovery"]
  E --> F["Integrate Linux, firmware, OTA and secure boot"]
  F --> G["Operator testing, certifications and field trial"]
  G --> H["Controlled rollout and lifecycle monitoring"]

The best time to evaluate RedCap is before the PCB, enclosure, antenna, power tree and update strategy are frozen.

Final takeaway

5G RedCap is not simply "slower 5G". It is a useful middle tier for connected embedded products that need more than LPWA, less than full 5G and a clearer path toward 5G-era networks.

For the right product, it can improve longevity, remote maintenance and industrial connectivity. For the wrong product, it can add unnecessary module cost, certification effort and power complexity.

So the question is not "should we use RedCap?". The better question is: