NB-IoT and LTE Cat-M1 for Industrial IoT: A Complete Guide

Technical Considerations for NB-IoT and LTE-M Deployment

Network Coverage and Frequency Compatibility

A normal mobile coverage map is a starting point, not confirmation that an NB-IoT or LTE-M device will work. Operators may support different technologies in different parts of their network, and a subscription may not provide access to every available service. The device must also support the frequency bands used at the intended location. These factors should be checked together because a mismatch in any one of them can prevent communication.

A common source of confusion is testing with a smartphone. A phone may connect successfully using a different radio technology or band from the industrial device. It may also have different antenna performance and access permissions. A successful phone call or mobile-data session therefore cannot replace testing with the intended sensor and SIM. Commissioning should verify the actual equipment under the physical and network conditions it will face. For projects covering multiple regions, prepare a compatibility record before procurement. Include the countries, proposed operators, supported technologies, required bands and relevant hardware variants. This reduces the risk of ordering a device that works in one location but cannot access the intended service elsewhere. It also creates a useful reference for future replacements, expansion and technical support.

Indoor and Underground Communication

NB-IoT and LTE-M can support installations with more difficult reception than an unobstructed outdoor location, but indoor and underground performance remains dependent on the physical environment. Building materials, soil, water, metalwork and the depth of installation can all affect the radio path. A basement, a utility chamber and a tank interior may each present very different conditions, even when they are close to the same cellular base station.

The location of the sensing element and the location of the radio equipment should be considered separately. A probe may need to be submerged or inserted into a process, while the transmitter or antenna may need a more favourable position. Product construction determines which arrangements are possible. Moving a radio head above ground or placing an approved external antenna outside a metal enclosure can be worth evaluating where the installation permits it. Testing must reflect the final operating arrangement. A device that reports successfully while a chamber is open may behave differently after the cover is closed. Likewise, a tank’s contents or surrounding equipment may affect reception compared with an initial bench test. Record performance in the completed installation and assess more than a single successful message, especially when the location is expected to experience seasonal or operational changes.

​

International Use and Roaming

International deployment requires compatibility between the device, its subscription and the networks available in each destination. A product described as globally capable may support many frequency bands, but this does not mean every operator will accept it or that every SIM can use all available services. The intended countries and network technologies should be checked explicitly before devices are deployed across borders.

Roaming adds another layer to this assessment. Access depends on commercial and technical arrangements between the subscription provider and the visited network. An international data plan may offer extensive conventional mobile coverage without providing equivalent NB-IoT or LTE-M access. Ask the provider for technology-specific coverage and confirm any restrictions that could affect the expected duration or pattern of use. A pilot in each materially different deployment environment is valuable. Devices may encounter different bands, network settings, registration behaviour and power-saving support in different countries. Record those differences and determine whether one hardware and configuration combination can serve the entire project. Where it cannot, using clearly identified regional variants is generally easier to manage than discovering compatibility problems after installation.

​

SIM Cards, Subscriptions and APN Configuration

A public cellular IoT service normally requires an active subscription and a compatible SIM implementation. The SIM provides the credentials used to identify the subscription to the network, while the commercial plan determines matters such as permitted service access and data usage. Depending on the device, the SIM may be removable or embedded. Embedded construction alone does not guarantee remote profile switching; that requires compatible hardware, provisioning and service support.

The Access Point Name, or APN, is another important part of the connection configuration. It identifies the data-network access arrangement used by the subscription. Some products obtain suitable settings automatically, while others need information supplied by the connectivity provider. Additional requirements can include authentication settings, roaming permissions or access to a private application network. Configuration values should come from the provider rather than being guessed from a consumer mobile plan. When comparing subscriptions, look beyond the headline data allowance. Confirm which countries and technologies are supported, how data is charged and whether the package includes monitoring software. Platform access, notifications, historical retention, API access and support may be separate services. Clear documentation of what is included helps avoid a situation where the device can connect successfully but the organisation has not arranged the application services needed to use the data.

​

Understanding Battery Life and the Device Power Budget

Battery life is the result of the device’s complete operating cycle. That cycle may include waking the processor, powering a sensor, waiting for a measurement to stabilise, reading the value, establishing communication, transferring data and returning to sleep. Each activity consumes energy, and the relative contribution varies between products. A simple pressure sensor may have a different power profile from a device that powers a more demanding external probe.

Communication conditions can change that profile substantially. A device with a reliable link may complete its work quickly, while one that repeatedly searches for service or retries transmissions may spend much longer with its radio active. The reporting schedule is also important because energy use accumulates across repeated events. Increasing the reporting frequency can reduce operating life even if the individual messages are small and the device sleeps efficiently between them. Battery planning should therefore use application-specific assumptions. Include temperature, expected reporting frequency, sensor workload, positioning activity and the possibility of unsuccessful communication attempts. Consider how the organisation will identify declining battery condition and schedule replacement before data collection is disrupted. Field measurements and operating records provide a stronger basis for maintenance planning than extrapolating from battery capacity alone.

​

Power Saving Mode: What PSM Does

Power Saving Mode, or PSM, allows a modem to reduce its energy use between communication events while retaining network registration context. During PSM, the modem is not available for incoming network communication. It can become active again when the application needs to transmit or when a scheduled network procedure requires it. The purpose is to avoid unnecessary radio activity during periods when the application does not need to exchange data.

For a periodic monitoring application, this behaviour can be a good fit. A tank sensor may need to report its level at defined intervals and otherwise remain inactive from a communications perspective. However, a user should not expect a remote command to reach that device immediately while it is in PSM. The command workflow needs to account for when the device next becomes reachable and what the application does with pending instructions. PSM configuration should be selected alongside the reporting and maintenance requirements. The device may request certain settings, but the network determines what it grants. Test the resulting behaviour rather than assuming that a configured value has been accepted exactly. A useful commissioning record includes both normal reporting performance and the observed time required for supported remote commands to take effect.

​

Extended Discontinuous Reception: What eDRX Does

Extended Discontinuous Reception, or eDRX, reduces the frequency with which a modem checks for incoming network communication. Instead of listening as often, the device follows a longer cycle with defined opportunities to receive paging. This provides another way to manage the balance between energy consumption and availability. It is particularly relevant when a device needs to remain periodically reachable but does not require immediate communication at every moment.

The practical trade-off is delay. A command sent while the device is between listening opportunities may have to wait. A longer interval can reduce listening activity but may increase the time before an instruction is received. Whether that is acceptable depends on the task. Updating a routine reporting interval may tolerate a delay, while an application expecting a rapid operational response may require a different configuration. Evaluate eDRX through the user workflow rather than as an isolated modem setting. Determine how long an operator can reasonably wait for a command, how the platform indicates pending changes and how successful execution is confirmed. Network support and granted settings need to be checked in practice. Clear communication about expected response times helps prevent normal power-saving behaviour from being mistaken for a device fault.

​

Measurement Frequency and Transmission Frequency

Measurement frequency describes how often a device reads its sensor, while transmission frequency describes how often it sends information to the platform. These settings may be the same, but they do not have to be. A device with suitable firmware and storage may take multiple measurements between communication events and later upload them together. This can provide a more detailed record without requiring a separate cellular session for every reading.

The distinction matters when defining what the monitoring system must detect. A sensor that reads infrequently may miss a short-lived event regardless of how quickly it transmits afterwards. Conversely, a device may detect an event locally but delay its appearance on the platform until the next scheduled report. The measurement schedule and communication schedule should therefore be selected from the behaviour of the asset, rather than from a generic preference for frequent updates. When configuring the system, define both the required historical detail and the acceptable notification delay. A storage application may mainly need a trend, while a rapidly changing process may require a different sensing and reporting arrangement. Confirm which combinations the product supports and how they affect battery life and data storage. More frequent measurement or reporting should have a clear operational purpose.

​

Scheduled Reporting, Event Detection and Alerts

Scheduled reporting creates a regular flow of measurements that can be used to understand trends and confirm that a device remains operational. It is useful for applications such as consumption analysis, gradual level changes and environmental observation. A consistent schedule also helps the platform identify missing communication, provided its rules account for the expected reporting interval and any normal delivery variation.

Event-based reporting works differently. A compatible device may evaluate a condition locally and initiate a transmission when a configured threshold is crossed. Alternatively, the platform may evaluate thresholds only after receiving scheduled data. These are different behaviours with different implications for response time. A cloud platform cannot evaluate a measurement that has not yet reached it, even if the sensor has already observed the condition.

A useful alert design defines the threshold, the persistence needed before notification, the recipients and the required response. It should also address repeated messages, recovery notifications and periods when the asset is intentionally out of service. Test the whole process from a representative measurement through to the responsible person receiving the notification. The objective is actionable information, rather than generating a large number of messages that users learn to ignore.

​

Data Usage and Connectivity Allowances

Industrial sensor messages are often small, but application payload size is only one part of cellular data usage. The overall traffic can include protocol headers, security exchanges, acknowledgements, keep-alive messages, retransmissions and configuration traffic. Firmware downloads can add a much larger amount of data than routine reporting. A realistic subscription estimate should therefore reflect how the complete application communicates.

As a simple example, a device that sends 100 bytes of application data every hour produces approximately 72,000 bytes over a 30-day period. This is about 72 kB using decimal units, before overhead or additional traffic. The calculation is useful as a starting point, but it should not be treated as the expected billed amount. Providers may apply minimum charging increments or other accounting rules that change the total.During a pilot, compare the expected usage with the provider’s recorded usage over a representative period. Include normal reports, remote configuration and any planned maintenance activity. Also consider what happens if a device starts retrying more frequently or a firmware update is required across the fleet. Selecting a plan with knowledge of these patterns is more reliable than basing it only on the number of sensor readings.

​

Latency and the Meaning of Real-Time Monitoring

Latency is often discussed as if it were a single radio specification, but users experience the delay across the entire monitoring chain. A condition must be measured, processed, transmitted, received and evaluated before it appears on a dashboard or triggers an alert. Waiting for the next measurement or reporting interval may contribute more delay than the actual transfer across the network.

For this reason, “real-time” should be defined in practical terms for each project. A tank-replenishment application may consider updates every hour sufficient for daily operations, while a different process may require notification within a much shorter period. Both users may describe their system as live monitoring, but their requirements are not equivalent. An explicit maximum acceptable delay is more useful than an undefined marketing term. NB-IoT and LTE-M should not be assumed to provide deterministic control timing. Public-network behaviour, power saving and device configuration can affect response. Where an application requires tightly bounded control or protective action, those functions need an architecture designed and validated for that purpose. Remote monitoring can still provide useful visibility around the process, but its role should be clearly defined.

​

Security in NB-IoT and LTE-M Systems

Security in cellular IoT involves more than the radio connection. The subscription credentials support access to the mobile network, but the system also needs to protect communication with the application and control who can access the resulting information. Device identity, application authentication, data protection and user permissions all contribute to the final security posture. These responsibilities should be considered together rather than assigned entirely to the cellular operator.

Application communication can use appropriate encrypted transport, such as TLS or DTLS, where supported by the implementation. The device must also authenticate the intended endpoint correctly and protect the credentials it relies on. A private APN can influence traffic routing and access arrangements, but it is not by itself proof that data is encrypted from the device to the application. Product capabilities should be verified against the organisation’s actual requirements.

Operational practices remain important after installation. Define who can change device settings, how access is removed when responsibilities change and how software updates are evaluated and applied. Keep an inventory of deployed equipment and its configuration so that issues can be investigated efficiently. Security is maintained through the device lifecycle, including commissioning, normal use, servicing and retirement.

​

Cloud Platforms, Protocols and Integration

NB-IoT and LTE-M provide connectivity, while the device application determines how measurements are packaged and exchanged. Depending on the product, communication may use MQTT, CoAP, HTTP or another supported application protocol. These options have different operating characteristics, but they should not be assumed to be available on every device. A product may be designed for a particular platform or offer configuration and integration options under a defined service arrangement.

MQTT, for example, uses a broker to distribute published messages to interested subscribers. This can suit applications in which devices send measurements and software services consume them. However, successful integration involves more than selecting a protocol. The receiving system needs to understand the payload structure, measurement units, timestamps and device identity. It must also handle duplicates, delayed messages and changes in data format where applicable. Before deployment, agree on where integration occurs. It may be a direct device connection to the customer’s server or an API connection from an existing monitoring platform. Clarify authentication, data retention, ownership of configuration and support responsibilities. Testing the complete route with real messages is essential because a network connection can be healthy while the application still displays incorrect values or fails to associate readings with the intended asset.

​