11  Choosing NB-IoT or LTE-M

cellular-iot
nbiot
ltem
comparison

Overview: Choose From the Service Contract

NB-IoT and LTE-M are complementary cellular IoT choices. They are not a simple old-versus-new pair, and neither one wins every deployment. The right first test depends on what the device must prove in the field: movement, reachability, payload size, coverage depth, battery model, operator support, subscription behavior, and maintenance traffic.

NB-IoT is usually the first candidate for fixed devices that send compact telemetry, sleep for long periods, and can tolerate delayed downlink where the target operator supports it. LTE-M is usually the first candidate when devices move across cells, need more responsive service, carry richer diagnostics, or need more practical support for updates and interactive operations.

Use the service contract to prevent a false binary decision. Some products should segment the fleet: fixed basement meters can use an NB-IoT profile while mobile service tools or exception-heavy variants use LTE-M. Other products should choose dual-mode hardware but still approve one operating mode per deployment class. The key is to record the requirement that forced the choice, not just the category name.

A defensible comparison also records what would change the answer. New regions, operator feature changes, larger firmware packages, stricter command timing, a new enclosure, or a shift from fixed to mobile use can all reopen the decision. Those retest triggers keep the comparison useful after the first pilot. Include the rejected option and reason, because future teams need to know whether it failed on evidence, cost, operator support, or a requirement that later changed.

If you only need the intuition, start with the service contract. Ask what the device must do before choosing a radio access technology.

NB-IoT vs LTE-M: Cellular IoT Technology Comparison, NB-IoT (Cat-NB1), BANDWIDTH, 180 kHz (1 PRB), DATA RATE, 250 kbps, COVERAGE, 164 dB MCL (+20 dB), MOBILITY
NB-IoT vs LTE-M

First-Pass Fit

Start with NB-IoT

Fixed meters, environmental sensors, parking nodes, and similar compact telemetry devices when downlinks can wait and hard-site coverage is the dominant risk.

Start with LTE-M

Moving assets, wearables, route devices, richer diagnostics, practical update traffic, and products that need more responsive service behavior.

Test both or segment

Mixed fleets, uncertain regional operator support, fixed and mobile product variants, or one SKU that must support several commercial deployments.

Decision Questions

  • Movement: does the device need service continuity while crossing cells?
  • Reachability: can commands wait for the next wake window, or must response be bounded?
  • Payload: are messages compact telemetry, or do diagnostics and update traffic matter?
  • Coverage: is the hardest requirement deep indoor or remote fixed coverage?
  • Power: what does the measured current trace show across registration, transfer, retry, paging, and sleep?
  • Operations: can support staff diagnose failures from device, SIM, operator, cloud, and firmware evidence?

Overview Knowledge Check

Practitioner: Build the Pilot Decision Record

A defensible NB-IoT versus LTE-M decision is not a procurement shortcut. It is a pilot record that ties the selected technology to final hardware, final antenna position, firmware policy, SIM or eSIM profile, operator service, traffic pattern, power mode, and support workflow.

The pilot should test the dominant risk. For fixed sensors, that may be worst-site delivery and current trace behavior. For moving assets, that may be route delivery during cell changes. For mixed fleets, the record may recommend segmented deployment instead of one forced answer.

NB-IoT and LTE-M selection workflow: define the service, check operator support, classify risk, pilot final hardware, and approve a fleet decision.
Selection workflow: define the service, check operator support, classify risk, pilot final hardware, then approve a fleet policy.

Minimum Pilot Record

Field
Question
Evidence
Retest Trigger
Service contract
What must the product promise?
Mobility, command delay, payload size, update plan, regions, lifetime target, and support model.
New product promise, larger payload, tighter delay, or different maintenance plan.
Operator support
Which service is commercially usable?
Target operator, bands, subscription features, roaming policy, SIM or eSIM profile, and escalation path.
New operator, region, profile, subscription, roaming policy, or certification path.
Installed RF path
Does final hardware work where it will be installed?
Module, antenna, enclosure, mounting point, signal metrics, retry logs, and site or route notes.
Antenna change, enclosure change, mounting change, route change, or site class change.
Power behavior
Does the measured cycle match the battery claim?
Current trace across boot, search, registration, transfer, retry, paging, idle, sleep, and recovery.
Timer change, firmware change, retry policy change, coverage change, or battery target change.
Operations
Can support diagnose failures after rollout?
Mode, band, profile result, payload result, cloud result, firmware version, error codes, and owner action.
Support ownership change, cloud route change, diagnostic schema change, or firmware update.

Worked Record: Moving Cold-Chain Tracker

The product must report route exceptions while moving and must upload diagnostic records after a missed delivery. The first pilot should test LTE-M because connected mobility, bounded reachability, and richer support traffic are central to the service. The record should include route delivery, buffering behavior, retry count, power trace, SIM or eSIM profile behavior, and support diagnostics.

If the same hardware is later sold into a fixed warehouse-monitoring deployment, the team should not reuse the tracker decision blindly. The fixed deployment may need a separate NB-IoT or dual-mode pilot if coverage depth and sleep life dominate the requirement.

Practitioner Knowledge Check

Under the Hood: Mobility, Reachability, Power, and Ownership

The deepest decision is not the radio label. It is which boundary owns the risk. Mobility risk belongs to route behavior and cell changes. Reachability risk belongs to sleep state, paging, command delay, and application promise. Coverage risk belongs to final installation, operator service, antenna design, and retry behavior. Power risk belongs to the full current trace, not only sleep current.

These boundaries explain why a lab modem session cannot approve a deployment. A modem can register in the lab and still fail in the final enclosure, with the final SIM profile, at the hardest installation point, or during a moving route.

NB-IoT and LTE-M mobility and coverage comparison showing fixed hard-site coverage, moving assets, reachability, payload, and pilot evidence.
Mobility and coverage boundary: fixed hard-site coverage often points to NB-IoT first; connected movement and more responsive operation often point to LTE-M first.

Boundary Rules

  • Coverage is installed-device evidence. It needs final antenna, enclosure, mounting, firmware, operator profile, and representative worst sites.
  • Mobility is route evidence. It needs delivery logs while moving through the expected routes or cell changes.
  • Reachability is sleep-state evidence. A device in deep sleep is not reachable just because the radio technology supports faster active-mode behavior.
  • Power is cycle evidence. Include boot, search, attach, transfer, retries, paging, idle, sleep, self-discharge, and recovery behavior.
  • Operations is ownership evidence. Support needs enough telemetry to separate radio, SIM, APN, cloud, firmware, battery, and antenna failures.
NB-IoT and LTE-M risk record showing dominant risk, candidate technology, pilot evidence, fallback decision, owner, and retest trigger.
Risk record: the selected first pilot should name the dominant risk, required evidence, fallback decision, owner, and retest trigger.

Retest Signals

  • Retest if payload size, diagnostic upload, firmware-update strategy, command delay, or alert semantics change.
  • Retest if the device becomes mobile, changes route, changes installation class, or changes enclosure or antenna.
  • Retest if operator support, band support, SIM or eSIM profile, roaming policy, or subscription features change.
  • Retest if timers, retry policy, firmware, modem module, cloud protocol, or support diagnostics change.
  • Retest if the selected technology starts failing in field logs, current traces, or support tickets.

Under-the-Hood Knowledge Check

Phoebe the physics guide

Phoebe’s Why

This chapter’s own comparison figure quotes NB-IoT’s coverage target as 164 dB MCL, “+20 dB” over a legacy baseline. That 20 dB is not free lunch and it is not antenna gain – it is bought by repeating the same uplink message and letting the receiver combine the copies, which is a time-domain trick: pay in seconds of extra radio-on time to buy decibels of effective sensitivity. Antenna gain is a completely separate, additive lever on the exact same EIRP budget. Because both levers spend the same currency (decibels of link margin), a design can trade between them: every decibel a directional antenna buys back is a decibel of repetition, and therefore battery, the standard’s own coverage-enhancement mode no longer has to supply.

The Derivation

EIRP folds transmit power and antenna gain into one number:

\[\mathrm{EIRP}(\mathrm{dBm}) = P_t(\mathrm{dBm}) + G(\mathrm{dBi})\]

Repeating an uplink \(R\) times and combining the copies buys an idealized combining gain (an upper bound; real non-coherent NB-IoT combining gains less):

\[\Delta_{repeat}(\mathrm{dB}) \approx 10\log_{10}R\]

If a fixed coverage-margin target \(\Delta_{total}\) is split between antenna gain \(G\) and repetition, adding \(G\) dB of gain shrinks the repetition-based share that must still be found:

\[\Delta_{repeat,needed} = \Delta_{total} - G \;\Rightarrow\; R_{needed} = 10^{\Delta_{repeat,needed}/10}\]

Worked Numbers: Spending the Chapter’s Own 20 dB

Using this chapter’s own figure (\(\Delta_{total} = 20.0\) dB extended coverage) and the standard’s own maximum repetition count (\(R_0 = 128\), whose idealized gain \(10\log_{10}(128) = 21.1\) dB is consistent with the chapter’s “+20 dB” claim):

  • Add a \(G = 4.00\) dBi external antenna and hold the same 164 dB MCL target: the repetition-based share needed drops to \(20.0-4.00 = 16.0\) dB, i.e. \(R_{needed} = 10^{1.60} = 39.8\), rounding up to the next standard step, \(R' = 64\)
  • Repetition cut: \(R_0/R' = 128/64 = 2.00\times\) fewer repeated transmissions for the same coverage target
  • Battery tie: at a fixed per-repetition transmit current and duration, uplink transmit energy scales linearly with repetition count, so this \(4.00\) dBi antenna cuts the radio-dominated share of that uplink’s energy in half – for the price of a beam the device (usually near-isotropic, since it cannot know which way to aim in a basement or cabinet) may not be able to use as reliably as a fixed macro sector can
  • LTE-M’s own coverage-enhancement modes (CE Mode A/B) use the same repetition-and-EIRP arithmetic, just tuned to a shallower target coverage hole than NB-IoT’s 164 dB, because LTE-M is designed around mobility and richer interaction rather than the deepest fixed-site coverage case – the physics does not change between the two radios, only which point on the gain-versus-repetition trade each standard is tuned to spend by default

11.1 Start With the Story

NB-IoT and LTE-M often compete for the same project, but they solve different everyday problems. One favors small, patient messages and reach; the other favors mobility, lower latency, and richer interaction.

Start simple: compare the use case before the radio, using payload size, coverage, battery, mobility, latency, and operator availability.

11.2 Summary

NB-IoT and LTE-M are complementary cellular IoT choices. NB-IoT is often the first pilot for fixed, compact, delay-tolerant telemetry where operator support exists and coverage depth dominates the risk. LTE-M is often the first pilot for connected mobility, bounded response, richer diagnostics, update traffic, or verified voice-capable service. Mixed fleets may need dual-mode hardware, regional variants, or segmented policy. The final decision should come from pilot evidence with final hardware, final antenna, final enclosure, final SIM or eSIM profile, representative sites or routes, measured current traces, and support diagnostics.

11.3 Key Takeaway

Choose NB-IoT or LTE-M from evidence, not from the label: define the service contract, identify the dominant risk, test final hardware under representative conditions, and record what change reopens the decision.

11.4 See Also

Cellular IoT Overview

Use this when the broad role of cellular IoT, SIM/eSIM operations, and deployment fit are still unclear.

Cellular IoT Deployment Planning

Use this to turn a technology choice into site evidence, provisioning checks, pilots, and rollout gates.

NB-IoT Power Saving (PSM/eDRX)

Use this when reachability, granted timers, current traces, and sleep states drive the decision.

eSIM and Global IoT Deployment

Use this when region, profile lifecycle, roaming, or carrier switching affects the fleet policy.