Does IoT Really Need 5G? Comparing 2G, 4G, LTE-M, NB-IoT and 5G RedCap

Short answer: many IoT devices do not need a full-capability 5G modem. A meter sending occasional readings, a moving tracker and a video camera have very different requirements. NB-IoT, LTE-M and conventional LTE can each be appropriate. 5G RedCap adds a reduced-complexity 5G option for applications between low-throughput sensors and demanding broadband devices. The right choice depends on the workload, energy budget, available networks and service arrangements throughout the device’s intended life.

The practical question is: which technology can deliver the required service, in the intended locations, at an acceptable whole-life cost?

This guide distinguishes technical capability from deployable service. Standards describe what is possible; a specific combination of module, firmware, antenna, subscription and network determines what a product can actually use.

Start with the device, not the generation number

Before requesting a connectivity quotation, describe the application in terms that can be tested.

• How much data does each transaction contain, including protocol overhead?
• How often does the device transmit during normal operation and during an incident?
• How quickly must a command reach it?
• Does it move while exchanging data?
• Is it powered from the mains, a vehicle, a rechargeable battery or a sealed battery?
• Where will it operate, including indoor locations and cross-border routes?
• How large are firmware updates and diagnostic uploads?
• How long must it remain serviceable without a physical visit?

Keep normal traffic and exceptional traffic separate. A device that normally reports a few measurements may still need substantial downloads when its firmware changes. An alarm may send almost nothing most of the time but have a strict delivery requirement when an event occurs.

Write an acceptance statement before selecting hardware. For example: “The device must deliver an alarm within the agreed deadline from the worst representative installation location, including after recovery from a network outage.” That gives the engineering team something more useful than “must support 5G”.

What the technology names actually mean

2G: a legacy dependency to manage

2G remains relevant to existing equipment, but its continued availability must be checked country by country and operator by operator. There is no single worldwide shutdown date.

For example, Ofcom’s current UK guidance reports completed 3G shutdowns and a continuing transition away from 2G. It also highlights risks for IoT equipment using international roaming SIMs. This is a UK example, not a timetable for other markets. [1]

For a new long-life product, a 2G-only design creates a difficult dependency. For an installed fleet, the immediate task is to discover exactly which functions still require it. Data, SMS, voice calls and remote configuration may have different migration requirements.

4G LTE: a family of device capabilities

“4G” does not describe one fixed modem specification. LTE Cat-1 and Cat-1 bis serve different design priorities from higher-throughput categories such as Cat-4. Cat-1 bis permits a single receive antenna, which can simplify hardware design, but antenna and coverage performance still need testing.

Conventional LTE is an important candidate where the application needs more data capacity than a low-power sensor link, or where the intended service has more suitable LTE access. Operator Telenor’s comparison includes Cat-1, Cat-1 bis and higher LTE categories alongside the specialised IoT technologies. [2]

Do not interpret this as universal access: a particular subscription still needs permission to use the intended networks, and the module must support their bands.

LTE-M: low-power cellular connectivity with mobility support

LTE-M is an LTE-based low-power wide-area technology. It is often associated with Cat-M1 devices, although capabilities vary by release and implementation. It is a candidate for modest data workloads where mobility and energy consumption both matter.

NB-IoT and LTE-M are complementary technologies introduced in 3GPP Release 13 and developed in subsequent releases. They are not simply interchangeable labels for a generic IoT SIM. [3]

For a moving asset, evaluate LTE-M against the required route, reporting interval and battery target. Support in the modem alone does not establish roaming access or the network settings needed for the intended energy performance.

NB-IoT: narrowband connectivity for small data exchanges

NB-IoT is another LTE-based low-power wide-area option. Small, infrequent reports from stationary equipment are a common reason to evaluate it. Enhanced coverage techniques can help challenging installations, but they do not guarantee reception in every basement, cabinet or underground enclosure.

The technology is generally less suitable for applications needing sustained data transfer or continuous connected mobility than alternatives designed around those requirements. Treat that as a selection starting point, not a substitute for a product-specific trial. [3, 4]

5G RedCap: a reduced-capability NR device category

RedCap means Reduced Capability. Introduced in 3GPP Release 17, it reduces aspects of 5G New Radio device complexity, including bandwidth and antenna requirements, compared with higher-capability NR devices. Its intended applications include industrial sensors, wearables and some video use cases. [5]

RedCap is not another name for LTE-M, and it does not automatically provide NB-IoT-like battery performance. A network offering ordinary smartphone 5G service is not sufficient evidence of RedCap service availability.

Full-capability 5G: justify it through the workload

Some applications need substantial throughput, a suitable 5G architecture or capabilities associated with a carefully engineered industrial network. Those requirements may justify a higher-capability 5G device.

However, public mobile connectivity labelled “5G” should not be treated as a guarantee of deterministic latency, a private network, network slicing or an industrial service-level agreement. Specify the actual service requirement and ask how it will be delivered.

A practical comparison

The table below is an editorial selection framework. It is not a performance guarantee or a SIM24.biz product availability statement.

A maximum modem speed is not an application throughput commitment. Record measured performance under the intended operating conditions, including the slower cases.

LTE-M and NB-IoT are not made obsolete by the term “5G”

The relationship between generations is more nuanced than a replacement ladder. LTE-M and NB-IoT contribute to the massive machine-type communications part of the 5G ecosystem, while remaining LTE-based radio technologies. They are distinct from 5G NR RedCap. Ericsson’s technical overview explains this positioning. [6]

Consequently, “we need a 5G IoT strategy” does not necessarily mean “every sensor needs an NR modem”. It may mean managing several technology families according to their application requirements.

For procurement, request the exact radio technologies and device categories. A broad “5G-ready” claim leaves too many questions unanswered.

RedCap and eRedCap: promising options, with specific dependencies

Release 18 extends the reduced-capability approach through eRedCap, with further complexity reductions. RedCap and eRedCap should be assessed as distinct device capabilities. A Release 17 device does not acquire every Release 18 capability merely through a commercial label. [7]

Before selecting a RedCap product, obtain written confirmation of:

1. The exact module, firmware and supported radio bands.
2. The operator’s compatible 5G standalone and RedCap support.
3. Access for the proposed subscription, including roaming where required.
4. Supported LTE fallback, if the product needs it.
5. Behaviour when RedCap service is unavailable.
6. Required certifications and their status for the intended markets.

This is a qualification checklist, not a claim that every implementation supports each item. Dual-mode hardware may provide useful flexibility, but fallback must be designed and tested. [7]

Avoid building a launch schedule around an announced network capability until a representative device has used the intended commercial service successfully.

Coverage is specific to the technology and subscription

A country appearing on a provider’s coverage list does not establish that all radio technologies are available there.

Separate five questions:

• Does the operator deploy the required technology?
• Does it cover the actual installation or route?
• Does the module support the relevant bands?
• Is this SIM or eSIM subscription allowed to use it?
• Are the required service features supported for that subscription?

GSMA’s deployment map is useful for identifying announced LTE-M and NB-IoT launches. It is a discovery tool, not proof of service at a particular address or under a particular wholesale agreement. [8]

Build a verification matrix containing country, operator, radio technology, module variant, subscription and test result. Put unresolved cells in the trial plan rather than treating them as covered.

For an international fleet, include its actual border crossings and installation environments. A successful office demonstration in one country does not qualify a product for a warehouse, vehicle or basement elsewhere.

Roaming requires more than ordinary mobile-data access

GSMA’s Mobile IoT guidance addresses interoperability and roaming across LTE-M and NB-IoT deployments. Configuration differences, supported features and network architecture can affect the end-to-end service. [9]

Ask the provider for technology-specific access, rather than just a country count. Where devices stay abroad for long periods, also request confirmation that the proposed deployment is permitted under the applicable service arrangements.

Record the intended behaviour if access is rejected. Will the device retry, select another permitted network, use another supported radio mode or wait? Who can change those settings, and how will an offline device recover?

These are operational design decisions. A SIM management dashboard cannot compensate for firmware that endlessly retries an unavailable service.

Battery life depends on the complete operating cycle

Power-saving features such as Power Saving Mode (PSM) and extended Discontinuous Reception (eDRX) can reduce energy consumption. They also affect reachability: a deeply sleeping device cannot be treated as continuously available for immediate downlink commands. GSMA’s roaming material discusses buffering and related feature support. [10]

For the product’s energy budget, measure an entire operating cycle:

1. Wake-up and local sensor processing.
2. Network search and registration when needed.
3. Connection establishment and security exchanges.
4. Transmission, acknowledgement and retries.
5. Any receive window and subsequent return to sleep.

Add scenarios for weak signal, unavailable networks and repeated failures. Include the energy used by positioning, displays, sensors and the processor, not just the modem.

An illustrative engineering model is:

Daily energy = sleep energy + normal reporting energy + expected retry energy + allocated maintenance energy.

Use measured values for the actual device. Then allow for battery ageing, temperature and usable capacity. This model is a planning method, not a claim that a particular radio will achieve a specific number of years.

A useful supplier question is: “Under which reporting interval, signal conditions, firmware version and downlink requirements was the battery estimate measured?”

Response time is an end-to-end requirement

For a command sent from an application to a device, the radio link is only part of the path. The device may be asleep, traffic may travel through a remote network exit, and the application may introduce its own queueing or retry delay.

Measure separate milestones: command submitted, accepted by the backend, received by the device, executed and acknowledged. A network connection succeeding is not proof that the business action completed.

For a safety-related or time-critical product, the engineering and assurance process must define appropriate failure behaviour and validation. A generic commercial 5G connection is not evidence that those requirements have been met.

Five practical selection examples

The examples below are hypothetical design exercises, not customer case studies or guarantees of SIM24.biz capabilities.

1. A basement water meter

The meter sends small readings and must operate from a sealed battery. Shortlist NB-IoT and, where appropriate, LTE-M. Test the actual enclosure in representative installation positions.

The decisive trial is not a speed test. It is whether reports arrive reliably, retries remain within the energy budget and maintenance can be completed without an unplanned visit. If remote commands are required, define how long they may wait.

2. A tracker crossing several countries

The tracker reports while moving and changes networks during its working life. LTE-M and LTE Cat-1/Cat-1 bis are candidates for evaluation, depending on power requirements and accessible networks.

Test border crossings, temporary loss of service and recovery after a prolonged outage. Check whether queued positions are uploaded correctly and whether retry activity drains the battery. Do not qualify it only by leaving it stationary near an office window.

3. A payment or vending terminal

Transaction data may be small, but predictable response and recovery matter. Evaluate conventional LTE alongside other suitable options. Make the complete transaction, including security handshakes and application acknowledgement, the acceptance unit.

Include software updates, remote diagnostics and the device’s longest expected idle period. A successful ping is not a successful sale.

4. A remotely monitored camera

Estimate the required uplink using the chosen image quality, frame rate, codec and recording policy. A camera sending occasional still images has a different requirement from continuous video.

Compare suitable LTE categories, RedCap and higher-capability 5G against measured traffic. Test sustained upload, congestion and recovery, and calculate the data allowance from the actual stream. Do not select the plan from a nominal modem download speed.

5. An industrial gateway

A gateway aggregating many machines may need more capacity than each individual sensor. It may also need local buffering so a connectivity interruption does not immediately become data loss.

Define which functions continue locally, which can wait and which require a bounded response time. If a specialised private network is necessary, evaluate that architecture explicitly. The radio generation alone does not define the industrial solution.

SIM, eSIM and radio technology are separate choices

A physical SIM or an eSIM profile supplies subscription credentials. The modem, radio design and firmware determine which radio technologies the device can use.

Changing an eSIM profile cannot add an unsupported frequency band or turn a 2G-only modem into a 4G or 5G device. Remote provisioning can provide subscription flexibility when the device, provisioning architecture and commercial arrangements support it. It cannot replace missing radio hardware.

Keep the following workstreams separate in the design review:

• Radio hardware and certification.
• Subscription access and commercial terms.
• SIM or eUICC implementation and profile management.
• Application behaviour and remote device maintenance.

For the underlying concepts, see eSIM, Physical SIM, eUICC and iSIM: What Is the Difference? and the related architecture article below.

Compare whole-life cost, not just the monthly SIM fee

Build the business case around the intended service life. Include hardware, engineering, testing, connectivity, backend operations, support, battery replacement and field visits.

Use scenarios rather than invented market prices. For example, compare a lower-cost module requiring more frequent maintenance with a more expensive design that reduces visits. Insert actual supplier quotations and your own operational costs.

An internal cost model can use:

Fleet cost = devices and installation + development and qualification + connectivity and operations + maintenance + migration and retirement.

Avoid double-counting items already included in a provider’s fee. Document assumptions such as failure rates and battery replacement intervals, then vary them to see which assumptions drive the decision.

The result may favour different technologies for different products. Standardising every device on one modem is useful only if the operational benefits outweigh the added costs and constraints.

A migration plan for legacy fleets

Inventory what is installed

Record module model, firmware, supported technologies and bands, SIM provider, installation country and actual usage. Identify devices that appear to be 4G-capable but still rely on older networks for a particular function.

Match the risk to the location

Obtain operator-specific service information and reassess it periodically. Distinguish a national shutdown announcement from the loss of access relevant to a roaming subscription.

Test the replacement as a complete product

Validate antennas, power supply, enclosure, configuration and backend compatibility. Test loss and restoration of service, not just normal operation.

Roll out in controlled batches

Start with representative sites, define acceptance criteria and monitor failures before expanding. Keep a recovery procedure for equipment that does not reconnect. Close the migration only when the required business functions work on the replacement service.

Pre-deployment checklist

• □Normal, peak and maintenance traffic are measured.
• □Delivery deadlines and acceptable outage behaviour are defined.
• □The exact module, firmware, bands and antenna design are documented.
• □Technology-specific network and subscription access is confirmed.
• □Required roaming and long-term deployment arrangements are checked.
• □Power-saving settings and downlink reachability are tested together.
• □Representative indoor, moving and weak-signal cases are covered.
• □Network rejection, retry and recovery behaviour is verified.
• □Firmware updates and rollback are tested under realistic conditions.
• □Device logs can be correlated with application delivery records.
• □The support owner and escalation path are agreed.
• □Lifecycle and migration assumptions have a review date.

Questions to ask a connectivity provider

1. Which named networks support the required technology for this subscription?
2. Which module and firmware combinations have been tested?
3. What access differs between domestic service and roaming?
4. Which power-saving features are supported, and what settings can change?
5. What happens when the preferred network or technology is unavailable?
6. What evidence can you provide from a pilot using our actual hardware?
7. How are changes to coverage or service eligibility communicated?
8. Which diagnostics are available when registration succeeds but data delivery fails?
9. Which support responsibilities belong to you, the hardware vendor and our team?
10. What contractual and technical options exist if the deployment needs to migrate?

For a broader commercial evaluation, read How to Choose a White-Label SIM and eSIM Provider.

Frequently asked questions

Does every IoT device need 5G?

No. Select against workload, power, coverage, response time and service life. Many applications can be served by suitable LTE-based technologies; demanding applications may justify 5G.

Is LTE-M the same as ordinary 4G data?

LTE-M belongs to the LTE family but has specific device and network support requirements. An ordinary LTE roaming agreement should not be assumed to include it.

Is NB-IoT always the best option for battery-powered devices?

No. The answer depends on traffic, installation conditions, reachability and implementation. Compare measured energy use and application delivery, including retries and maintenance.

Can NB-IoT be used for a moving device?

Assess the movement pattern and implementation carefully. Occasional reporting from an asset that changes location is different from maintaining service during continuous movement. Evaluate alternatives where connected mobility is important.

Does 5G coverage mean RedCap will work?

No. Confirm compatible RedCap network support, bands, device certification and subscription eligibility. Ordinary 5G coverage is not enough evidence.

Will RedCap replace LTE-M and NB-IoT?

It should not be treated as a universal replacement. The technologies address different combinations of throughput, complexity and energy requirements. Future availability must be assessed through actual operator and device roadmaps.

Can eSIM solve a network shutdown?

It may help a compatible device move to another available subscription. It cannot add radio capabilities to obsolete hardware, and another accessible network must still exist.

Is multi-network access sufficient for resilience?

It can provide options, but the device must support and successfully use them. Test failure detection, selection, recovery time and application behaviour. The number of listed networks is not a resilience measurement.

Should a new product wait for eRedCap?

Only if its requirements and delivery schedule justify that dependency. Compare a deployable option today with the engineering, commercial and scheduling uncertainty of waiting. Obtain evidence for the exact markets involved.

How should we choose between LTE Cat-1 and LTE-M?

Compare the actual hardware and service against power targets, data transfers, mobility, accessible networks and maintenance requirements. Run a representative pilot before committing to fleet quantities.

Discuss your IoT connectivity requirements with SIM24.biz

Preparing an IoT product or a branded connectivity offer? Bring SIM24.biz your target countries, device and module details, expected traffic, power constraints and deployment timescale.

These details provide the basis for discussing an appropriate SIM or eSIM service and identifying what needs technical validation. Availability of LTE-M, NB-IoT, RedCap, roaming and specific management functions must be confirmed for the proposed service and deployment.

Contact SIM24.biz to discuss the requirements and next steps.

Sources and further reading

Sources checked on 20 October 2026. Operator coverage, access and retirement plans can change. Standards documents and technical explainers describe capabilities; they are not evidence of a specific SIM24.biz service commitment. The selection framework, hypothetical examples, cost model and checklists are editorial guidance rather than measured customer results.

1. Ofcom: Switching off 2G and 3G networks, advice for IoT and third-party device suppliers.
2. Telenor IoT: IoT connectivity comparison. Operator perspective; used for category comparison, not as a universal coverage guarantee.
3. GSMA: Mobile IoT Deployment Guide, October 2022.
4. GSMA: NB-IoT Deployment Guide, Release 2.
5. 3GPP: A Glimpse into RedCap NR devices and How to find RedCap in 3GPP.
6. Ericsson: RedCap, expanding the 5G device ecosystem for consumers and industries.
7. Ericsson: RedCap/eRedCap, standardising simplified 5G IoT devices.
8. GSMA: Mobile IoT Deployment Map.
9. GSMA: Mobile IoT Deployment Guidelines for interoperability and smooth roaming.
10. GSMA: Mobile IoT roaming.