11 Matching Apps to Cellular Tech

11.1 Start With the Story

Every cellular Internet of Things (IoT) application has a rhythm. A payload is the useful data inside a message. A gateway is a device that passes data between different networks. A utility meter, asset tracker, industrial gateway, and safety monitor each send different payloads. They also tolerate different delays and need different support when a link fails.

Start simple: name the application’s reporting rhythm and consequence of silence before mapping it to a cellular technology.

Phoebe’s Field Notes: Antenna Gain vs. Repetition Count in a Basement Meter

The mathematical gist. An illustrative 8 dBi installed antenna improvement is a 6.31× ideal combining factor. Starting from 128 repeats gives 20.3 ideal repeats. If only power-of-two steps are available, 32 is the conservative next setting and reduces repetition-dominated airtime by 4×; 16 would require 9.03 dB and would underpay the stated 8 dB margin. Installed pattern, EIRP rules, scheduler choices, current, and delivery evidence still govern the field decision.

Math Bridge · guided foundationsHow much repetition can an installed antenna safely buy back?Let Radio Remi connect decibel margin, ideal combining, supported steps, and radio airtime. Learn the maths

11.2 Overview: Match The Application Before Choosing The Modem

Cellular IoT works well across wide areas and for moving devices. It also offers a managed network without gateways owned by the site. The choice still needs evidence about movement, payload size, coverage, reachability, power, the SIM lifecycle, and running cost.

Start by finding the hardest condition. A fixed meter, mobile tracker, camera gateway, and private plant controller put pressure on different parts of the record. Test the deepest cabinet, longest route, largest update, strictest command window, weakest service region, or costliest service visit. That condition becomes the pilot target.

Keep rejected options visible. If LTE-M is rejected for a meter, record that movement and fast downloads were not needed. If NB-IoT is rejected for a tracker, record the route, reachability, and maintenance evidence. These notes stop teams from reopening the choice with only a coverage map or plan price.

Figure 11.1 compares two cellular options before a field claim is accepted. LTE-M suits movement and larger or faster exchanges. NB-IoT suits small, less frequent messages and deep coverage. Read the rows for data rate, movement, and battery life before choosing a modem.

The matrix makes the workload choose the route. It does not treat either modem label as a universal answer. Match the need for movement, data rate, and battery life to the appropriate column.

11.2.1 NB-IoT fit

Stationary meters, bins, valves, and environmental sensors with small payloads, long sleep intervals, and deep coverage needs.

11.3 Practitioner: Review Use Cases As Evidence Patterns

Use cases are not marketing categories. Each one implies a different combination of mobility, payload cadence, downlink reachability, antenna placement, battery service, and operator contract. The examples below show what to prove before selecting a cellular category.

Write each pattern in the same evidence shape so the review can compare them. Start with the service promise, then record the installed location, traffic pattern, battery assumption, connectivity lifecycle, failure owner, and retest trigger. A table of use cases is useful only when every row can point to the evidence that would approve, reject, or segment that use case.

LTE also solves two coverage-boundary problems that are easy to miss in a category table. A monitored building security or alarm controller can use a public 4G/LTE data service when suitable fixed telecommunications cabling is unavailable. A remote mining operation can instead operate a private 4G/LTE service where public cellular service is not commercially available and the site needs better performance and range than its traditional Wi-Fi solution. In both cases, the decision starts from who owns coverage and operations, not from the word "private" or "public" alone.

Figure 11.2 is the checkpoint for practitioner: review use cases as evidence patterns; its purpose is to show asset tracking architecture with GPS, LTE-M cellular module, sensors, battery, cell tower, and cloud platform before a field claim is accepted. Inspect GNSS + modem beside GNSS or cell ID before the next claim.

Use Asset Tracking Architecture, GNSS + modem, and GNSS or cell ID as three architecture checkpoints in Figure 11.2. Their interfaces embody asset tracking architecture with GPS, LTE-M cellular module, sensors, battery, cell tower, and cloud platform. For practitioner: review use cases as evidence patterns, the evidence packet must join those checkpoints with one observed transaction.

Why pause at Figure 11.3? Its labelled evidence shows smart metering architecture with utility meter, MCU, NB-IoT module, cellular network, and utility backend, the distinction that anchors practitioner: review use cases as evidence patterns. Inspect daily reading beside battery state before the next claim.

Inspect the boundary between Smart Metering Over NB-IoT and Utility Meter in Figure 11.3, then see where tamper event enters the path. Those labels make smart metering architecture with utility meter, MCU, NB-IoT module, cellular network, and utility backend concrete. The chapter connects them to practitioner: review use cases as evidence patterns through cross-layer acceptance evidence.

Inspect Figure 11.4 because practitioner: review use cases as evidence patterns depends on the concrete path it labels—fleet management architecture with GPS, OBD-II, driver identity, LTE-M module, and fleet management platform.

In Figure 11.4, the architecture begins with Fleet Telematics Evidence Flow, crosses Telematics, and depends on Platform for the next service function. That labelled structure is fleet management architecture with GPS, OBD-II, driver identity, LTE-M module, and fleet management platform. The running practitioner: review use cases as evidence patterns decision must name the owner and measurement at each crossing.

To decide practitioner: review use cases as evidence patterns, inspect Figure 11.5 now: it makes smart agriculture architecture with field sensors, weather station, MCU, solar power, NB-IoT module, and farm management platform visible before the prose turns that evidence into a release choice.

Figure 11.5 assigns separate roles to Smart agriculture architecture, weather station, and NB-IoT module. Reading those roles together reveals smart agriculture architecture with field sensors, weather station, MCU, solar power, NB-IoT module, and farm management platform. The practical consequence for practitioner: review use cases as evidence patterns is that a local pass cannot validate the unmeasured remainder of the architecture.

11.4 Under The Hood: Keep The Operations Evidence Visible

The modem is only one part of the decision. A cellular IoT release also depends on operator configuration, SIM or eSIM lifecycle, private APN or internet egress, sleep and reachability behavior, firmware update path, certification, and the support model after deployment.

Keep the record cross-functional. Firmware owns modem state, retry limits, and update behavior; network operations owns APN, routing, and operator escalation; product operations owns provisioning, decommissioning, and support response. When those owners are not named, a small field failure can move between teams without resolution. Under-the-hood review therefore asks which log or record each owner will use when a device attaches, fails to deliver, drains its battery, roams unexpectedly, or misses a queued command.

Use Figure 11.6 to ground under the hood: keep the operations evidence visible in observable evidence. It presents cellular IoT service-selection record that shortlists deployed NB-IoT and LTE-M profiles against coverage, mobility, latency, payload, power, operator, and lifecycle requirements, then records field evidence and retest triggers rather than an unsupported feature promise. Inspect Requirement lane beside Static small telemetry before the next claim.

Enter Figure 11.6 at Cellular IoT selection:, answer the condition at Requirement lane, and inspect the outcome Static small telemetry before taking another branch. The tree encodes cellular IoT service-selection record that shortlists deployed NB-IoT and LTE-M profiles against coverage, mobility, latency, payload, power, operator, and lifecycle requirements, then records field evidence and retest triggers. For under the hood: keep the operations evidence visible, each branch is a requirement test that must be recorded, not an automatic product recommendation.

11.5 Separate a Meter Reading from a Tamper Alarm

Assume a metering payload of 24 bytes sent once each hour. There are 24 readings in a day, so useful reading data totals 24 × 24 bytes = 576 bytes per day. A tamper event adds a 32-byte record. These counts cover application data only. They exclude cellular signalling, security, transport headers and retransmissions, which may dominate a small exchange.

Now suppose the meter stores readings during a 6-hour outage. Six records need 6 × 24 bytes = 144 bytes of local space before metadata. When service returns, the oldest reading is already about 6 hours old. The platform should preserve the measurement time so that a late upload does not look like a fresh change in water use. A daily billing total may tolerate this delay; a tamper workflow may not.

The battery calculation also changes with the alarm promise. A modem that sleeps for long intervals can save energy, but a pending command cannot be assumed to reach it at once. Test the actual wake and retry behaviour with the installed antenna and selected operator profile. A phone showing service outside the building does not demonstrate that a sealed pit provides the same link.

Predict which application fails first when the outage lasts beyond the chosen reporting window. The stored meter totals can still be useful after recovery if their timestamps survive. The alarm service has already missed its prompt notification target, even if the same bytes eventually arrive. Check that the backend marks this as delayed delivery instead of silently declaring the alarm path healthy.

A moving asset tracker adds another boundary: the fleet crosses service areas while a utility meter stays still. The selection record should therefore distinguish stationary coverage evidence from route evidence. This module’s application mapping is useful because it turns labels such as metering and tracking into measurable payload, timing and energy needs. It does not turn a radio category into a guarantee. The worked byte counts are illustrative; operator support and the modem’s measured current profile decide the deployed behaviour.

11.6 Summary

Start with the application’s promise, not a modem category. NB-IoT, LTE-M, broadband cellular, and private 5G fit different needs. Compare movement, payload, coverage, power, reachability, and operating ownership.

Before wider use, record installed coverage and how often each payload is sent. Add the power mode, SIM lifecycle, cost model, support owner, and reason to test again.

11.7 Key Takeaway

Choose cellular IoT by matching the application evidence to the radio and service profile; do not treat coverage maps, phone tests, or generic cellular branding as release evidence.

11.8 See Also

Start by Cellular IoT Overview introduces the cellular IoT family and its main deployment boundaries. Then NB-IoT vs LTE-M Comparison compares the two main LPWAN cellular categories. Next Cellular IoT Deployment Planning expands coverage, operator, rollout, and support evidence. Finally Cellular IoT Power Optimization explains PSM, eDRX, reporting cadence, and measured current profiles.