By definition, an IoT device is accessed via Internet (IoT = Internet of Things). Each IoT application is different, and selection of an appropriate connectivity approach requires consideration of many technical, commercial and strategic aspects. For some projects (e.g. for industrial environments) a cable connection can be used, but a wireless network will be first choice in most cases. But which one, WiFi or cellular network? For both options, many suppliers and service providers are focused on tailored standard products to ease design and deployment of IoT applications. This article is reviewing ready-to-use cellular network modules which are key ingredients for IoT device designers.
WiFi or Cellular ?
The answer to this question requires a clear understanding of deployment scenarios and where IoT devices will be located. WiFi offers higher bandwidth at lower operational cost, but limited range is a potential problem outside buildings. For most open-air or mobile applications WiFi will be no option at all. But even in households or in office buildings or industrial areas WiFi availability is not guaranteed. This is why, for example, nation-wide project to deploy smart power meters in Germany has two versions in mind: one for WiFi connection wherever available, another one with cellular network connectivity for all other customers. In general, cellular network devices are easier to deploy because connectivity depends on network coverage only. The advantage is that no knowledge nor re-configuration of local IT infrastructure (e.g. routers) will be necessary. WiFi offers a couple of advantages for IoT projects with manageable target environments. In all other cases and if all planned IoT device target locations are covered by a cellular wireless network, it should be used.
For IoT projects with cellular network connectivity these IoT device design aspects should be considered:
- max. speed at which an IoT device can deliver data (bandwidth),
- max. distance between an IoT device and nearest access point (range),
- device geo location and mobility,
- delay until data connection to IoT device is being established (latency),
- technical data of network interface, e.g. power consumption, package, robustness,
- cost of network operation (i.e. price for transmitted IoT data),
- cost of network interface (BOM)
GSM Fundamentals
Originally, GSM (= “Global System for Mobile Communications”) has been developed for digital mobile phones – to be used across national borders. International cooperation work started 1982 in Europe, and first GSM networks were implemented from 1992 onwards. Since then, GSM standards have been adopted by national mobile network operators (MNOs) and deployed successfully. In 1995 around 10 million users were using GSM-compliant mobile phones. Standards were evolving from GSM Phase 2 to UMTS/3G, then LTE/4G and now 5G in an effort to improve service at higher data rates and more features. Technical specification work moved from European ETSI to 3GPP (www.3gpp.org) which is representing all relevant standardisation bodies in Europe, Asia and North America. According to GSM Association (www.gsma.org) we now have 5 billion users worldwide. These are mainly mobile phone users, but IoT machine-to-machine number of connections already reached 12 billion in 2019 and supposed to reached 24,6 billion in 2025 (source: GSMA).
GSM utilizes a cellular network, meaning that a cell phone (resp. a GSM module of an IoT device) connects to it by searching for the closest available cell tower. The coverage area of each cell tower depends on cell implementation. The longest distance the GSM specification supports in practical use is 35 kilometres (22 miles). If a mobile device moves out of one cell to another it must be possible to retain the connection. This process is knowns as GSM handover and works fine as long as coverage is maintained by an adjacent cell which will take over data connection.
Cell Coverage and Physical Characteristics
Figure 1: IoT device Internet access via cellular network (© chip-info.com)
Cells are owned and managed by mobile network operators (MNO) who are offering – besides voice communication – user access to Internet for data exchange. Many of them are running networks all over the world (e.g. Vodafone, Telefonica) which might be beneficial for moving IoT devices, e.g. for asset tracking applications. In addition to MNOs we also have “virtual” mobile network operators (MVNO) who do not own the network infrastructure, but have a business agreement with MNOs in place which allows them to offer related services, e.g. a tailored ISP service for IoT applications. In any case, for each IoT device connected via GSM you will need a subscription plan with an MNO or MVNO which is specifying applicable IoT data transmission cost. Besides applicable operation cost, sufficient coverage for all planned IoT locations is certainly a key criteria for selection of an MNO/MVNO partner for a project.
In general, device power consumption correlates with distance to cell tower, i.e. cell size. Closer distance will result in lower power consumption of RF unit. Achievable data rate depends on network transmission frequency are : the higher the frequency, the greater the ability to support high data-transfer speeds. Another physical truth is that high frequencies cannot travel large distances and cannot penetrate solid objects, e.g. walls, trees, cars. New 5G networks are working at frequencies above 24 GHz, consequently cell ranges are small, i.e. tens to hundreds meters. For a distance to cell tower of less than 100m you will need lees than 100mW power. A femtocell has a cell size of around 10 meters. The use of femtocells allows network coverage in places where the signal to the main network cells might be too weak. Some MNOs offer a “femtocell service” allowing business customers to extend 5G coverage according to their needs which might be an interesting option for future indoor IoT projects.
LTE-M and NB-IoT standards
In parallel to improvements for consumer market of mobile phones, smartphones, etc. 3GPP started to incorporate requirements of machine-to-machine (M2M) and IoT applications a couple of years ago. In fact, plain wireless connectivity is not enough to fuel innovative IoT business. So, the ultimate objective of the 3GPP’s IoT work has been to deliver specifications that enable low-cost device implementations with ultra-long battery life and improved indoor coverage for IoT use cases like meters and sensors in buildings, basements or in remote locations while allowing the reuse of the LTE installed base.
As a first result, NB-IoT (= Narrowband IoT) and LTE-M have been defined as an add-on to 4G/LTE in 3GPP Release 13.
PSM and eDRX power saving modes
LTE Cat M and LTE Cat NB networks are aiming at IoT use cases asking for low power consumption rather than permanent and immediate availability. For example a fluid level metering device which is supposed to transmit consumption data only once per day. For these kind of IoT applications new power saving features PSM and eDRX have been specified.
For typical IoT applications, end devices focus on uplink traffic rather than download traffic. Amount of data to be transmitted is quite small, bandwidth requirements are low. In addition, IoT devices typically do not need to be permanently available to external communication partners. Compared to use cases like voice conversation, IoT communication scenarios offer more flexibility and can be adjusted to match higher network latency. 3GPP standardization work has been driven by these IoT-typical characteristics to specify new PSM and eDRX power saving modes. Goal is to enable battery-powered IoT devices with a lifetime of more than 10 years. To achieve this, PSM and eDRX enable different mechanisms to minimise active radio time between the IoT device and the network.
Standard LTE feature DRX (DRX=discontinuous reception) already allows to toggle network interface between listening and idle states within the paging period. According to LTE specification maximum DRX cycle time is limited to 2,56 seconds. Extended DRX (eDRX) feature goes one step further and will extend idle state at the end of each paging period (see Figure 2a), i.e. the IoT device will not listen to control channel for paging messages resp. download traffic until the configured eDRX cycle has ended. eDRX is initiated by the the IoT device using a dedicated AT command and requires prior selection of a compliant network within reach. In fact, a LTE-M or NB-IoT network needs to be able to handle temporary device unavailability and cache requests until next paging window will start. Practically, the IoT device has to negotiate timing parameters with the network during “Attach Request” or “Tracking Area Update TAU” procedures. If accepted, network will return configured PTW and eDRX cycle values to the requesting device. eDRX feature allows to keep the network interface in idle mode to minutes or even hours, i.e. up to approx. 44 min in LTE-M and resp. 3,1 hrs in NB-IoT. Consequently, a latency tolerant IoT application can check for pending commands, for example, every hour and apply a corresponding long eDRX cycle which will decrease average power consumption to a few milliamps.
Figure 2a: eDRX – Extended Discontinued Reception Mechanism (© chip-info.com)
Power saving mode (PSM) is a power saving feature designed for LTE-M/NB-IoT devices which allow to conserve even more battery power. In fact, PSM will switch off the device radio and most of the circuitry which reduces power consumption of the network module to a few microamps. But it still remains registered in the network, meaning that the IoT device closes the connection but keeps the NAS status (NAS – Network Attach Status). An IoT device can initiate PSM and negotiate schedules with the network similar to activation of eDRX feature. Once the paging period is over (PTW, see Figure 2b), the module enters deep sleep mode (PSM mode) and becomes unreachable until next wake-up event occurs. Maximum configurable PSW duration is 413 days (!).
In example illustrated in Figure 2b a periodic “Tracking Area Update (TAU)” has been agreed with network which is reflected by provided timer value T3414 extended. This makes sense for mobile IoT devices which might move from one network cell to another. For IoT applications with fixed device locations a wake-up pin can be used by an external signal, e.g. from a sensor reaching a certain threshold value. This feature is offered by all IoT cellular network modules reviewed in this article.
Figure 2b: PSW – Power Saving Mode (© chip-info.com)
Both PSM and eDRX features can be combined, but enabled and configured separately. For example, a lower T3324 value will result in faster PSW mode switch. Power consumption can be adjusted vs. data transmission and latency requirements according to specific needs of the target IoT application.
Note: Power consumption values for DRX/eDRX scenarios provided in manufacturer spec are based on different timing parameters and do not work well for comparison. This is why in our product table only values for steady IDLE and PSW states are listed.
As explained, both power saving feature require related network support you will have to verify with each MNO/MVNO candidate case-by-case. As starting point you can check actual IoT network deployment maps published by GSMA, see here: https://www.gsma.com/iot/deployment-map/
LTE-M or NB-IoT ?
NB-IoT can be deployed within an LTE carrier with a system bandwidth that can be as narrow as 180 kHz. LTE-M is deployed within an LTE carrier. Two User Equipment (UE) categories were defined: Cat-NB1 (for NB-IoT networks) and Cat-M1 (for LTE-M networks). LTE-M also supports voice functionality via VoLTE which is needed for a several IoT applications, including devices with emergency call functions such as child trackers. It was initially limited to a bandwidth of 1.4 MHz (Cat M1) and some coverage enhancements feature like frequency hopping and subframe repetitions (CE modes A/B). In order to meet the requirement for more data throughput in Release 14, the new Cat M2 was introduced allowing the optional use of 5 MHz bandwidth.
Figure 3: Cellular wireless standards for IoT (© chip-info.com)
In comparison with NB‑IoT, LTE-M is ideal for mobile use cases, because it handles hand‑over between cell towers much like high speed LTE. For example, if a vehicle moves from point A to point B crossing several different network cells, an LTE-M device would behave the same as a cellular phone and never drop the connection. An NB‑IoT device, on the contrary, would have to re‑establish a new connection at some point after a new network cell is reached. This LTE-M feature offers tremendous value for mobile IoT applications or asset tracking applications.
On the other hand, NB-IoT excel in indoor industrial environments. Since they rely on simple waveforms, NB-IoT devices can offer better building and obstacle penetration. This provides businesses with greater range and coverage perfect for IoT projects that have sensors deployed underground or in other hard-to-reach areas with poor signal. But data rates are limited to approx. 150 kBit/s max. whereas LTE-M offers 1MBit/s.
Product Overview
This article is focussing on ready-to-use wireless cellular network modules for IoT devices. A selection of typical products or candidates with outstanding features of all major manufacturers of this product category has beed reviewed. But many more derivatives and country-specific versions are offered. Please browse manufacturer websites for additional products which have not been mentioned here.
For this article, products of the these manufacturers have been reviewed:
Besides product features, power consumption, price, mechanical dimensions, etc. additional product attributes have been selected in an effort to elaborate meaningful comparison results, which have been consolidated in our product table and few final comments. Some basics (AT command interface, eSIM, cloud support, etc.) and additional selection criteria (security, online support, IDE for embedded customer applications, etc.) are explained in following sections.
AT Command Interface
In general, for control of IoT cellular network modules so-called “AT command” language is being used, mainly for historical and backward-compatibility reasons. It has been developed back in 1981 when dial-up modems were in place for data exchange via phone line. At that time, AT control commands have been used by a computer terminal for dialing and hanging up. Modem connection was a 9-pin RS-232 serial interface using ±12V levels which is not common practise any more, but UARTs and RS-232 signals (TxD, RxD, CTS, RTS) are still being used by modern IoT cellular network modules. Standard AT command sets are specified by 3GPP (TS 27.005 and 27.007) and mainly used for module control and configuration as well as network session setup incl. timing parameters. Further evolution of the 3GPP standard is reflected by newer releases and further specifications.
For IoT projects, for example, TS 24.008 (Release 13) is important, because it specifies support for mentioned PSM and eDRX power saving mechanisms of LTE Cat-M and Cat-NB networks. MNOs will have to incorporate related specs and implement corresponding AT commands, otherwise M1/NB modules will not perform as expected.
On top of standardized functions, manufacturers of IoT cellular network modules can add extra AT commands to control proprietary functions or for access to integrated software layers. For example, embedded ready-to-use Internet software stacks and protocols might be offered. In this case, an IoT application can obtain a virtual IP socket from the module which is acting as a TCP/IP endpoint on behalf of the IoT device. In addition, secure end-to-end communication can be handled by the module via embedded SSL/TLS stack. These building blocks are offered by all IoT cellular network modules (see product table) and supported by a proprietary set of AT commands. Also IoT protocols like MQTT or FTP function for data transfer or firmware update are not standard and handled differently by manufacturers.
Figure 4: Virtual IP socket for IoT applications (© chip-info.com)
End-to-End Security
In order to ensure bullet-proof communication and remote control of IoT devices, IoT projects will have to implement an appropriate level of security and protection against potential attacks or attempt to misuse the IoT application. Proper device authentication and encryption of transmitted data are standard requirements which are offered by all IoT cellular network modules in combination with a software layer for TLS protocol. Although if no hardware-based protection for cryptographic material and processes has been implemented, software solutions are good enough in most cases – as long as no specific protection goals and related approval have been declared as mandatory for a project. For example, the German power meter roll-out is asking for a level EAL5+ Common Criteria security certificate for a product to qualify. For ultimate protection so-called secure elements can be used as an extra component – to be controlled via I²C bus which is offered by most IoT cellular network modules reviewed here. For more background information please refer to this dedicated article about “Secure Elements for IoT” at http://www.chip-info.com/articles/iot-secure-elements/
Extra level of security is offered by two candidates: a) For their EXS62/82 modules Thales claims to offer state-of-the-art device protection as well as an integrated eSIM used as a trusted element for mutual authentication and data encryption. In fact, the whole Cinterion product family is originated from daughter company Gemalto, one of the world’s largest SIM card manufacturers. Gemalto has a proven track record as a specialist for embedded security. b) Also u-blox SARA-R510S offers an integrated secure element which is certified according to Common Criteria at level EAL5+. If you are interested in further information you will have to contact both manufacturers and sign an NDA with them. Please see our product table, category “end-to-end security”.
Embedded Applications
“IoT” is an umbrella term for different applications with certain similarities, e.g. they are all connected and perform some kind of edge processing. But most IoT applications require custom IoT devices to be installed in the field. Hardware “customization” very often comes down to selecting suitable components for remote sensing and controlling – to be integrated by a dedicated IoT software application. The core IoT device hardware platform is quite the same for all: you need a general-purpose application processor (MCU), some memory for code/data storage and standard interfaces like I²C, SPI or GPIOs to connect selected peripheral components:
Figure 5: Block diagram of a simple generic IoT device (© chip-info.com)
Interestingly, we have a network module which comes with a powerful MCU and suitable interfaces, which could be used by the IoT application as well, if manufacturers would support this double usage. This would save BOM cost and reduce space, so most module manufacturers are offering options to share module resources with an embedded IoT application. At least, custom AT commands are offered to control GPIOs or I²C interface which can be used to exchange data with IoT peripherals. On top of this, Telit is providing a Eclipse-based IDE called AppZone, for their ME910xx modules for embedded IoT application development. Sierra Wireless WP7700/7702 offers the most comprehensive solution for embedded IoT application which is based on open source Legato™ platform. An IDE for Visual Studio Code and related tool (Leaf) can be used to develop and manage custom application code. Module OS is a fully user-interactive Linux derivative which allows users to load and activate application programs. Please see our product table, category “IDE for embedded applications” and “Custom HW-control AT commands”.
Device Management and Cloud Support
Lightweight M2M (LwM2M) is a standard protocol from the Open Mobile Alliance (OMA) for M2M or remote IoT device management and service enablement. It specifies an application interface (API) between an LwM2M Server and an LwM2M Client which is located on the IoT device. Many industry members incl. module manufacturers and IoT platform vendors are OMA members in an effort to provide interoperability of their products if used in same IoT project. Members include ARM, Gemalto, Microsoft (Azure), Sierra Wireless, Telit and u-blox. LwM2M’s device management capabilities include remote provisioning of security credentials, firmware updates, connectivity management (e.g. for cellular and WiFi), remote device diagnostics and troubleshooting. LwM2M’s service enablement capabilities include sensor and meter readings, remote actuation and configuration of host devices. More information and specifications are available here: https://omaspecworks.org/what-is-oma-specworks/iot/lightweight-m2m-lwm2m/. Please see our product table, category “LwM2M support” indicating if offered for s product or not.
Embedded SIM (eSIM)
Everybody knows that a new mobile phone will not work if no SIM card has been inserted before. A SIM card (SIM = Subscriber Identification Module) is a personalised electronic component which is used to identify the user (and associated subscription plan) and to provide a MNO-specific connection profile to the device. If you change operators, you need to enforce this change by replacing the SIM in each device. This is a logistical challenge esp. for large-scale international IoT projects where you might have different MNO preferences for different locations of installed IoT devices. Roaming might work in some cases, but causes extra transmission fee each time. From a technical point of view, a SIM card is just a tamper-proof 64kByte storage device, but managed exclusively by the MNO, i.e. it was a “holy cow” for a long time. An embedded SIM (eSIM) converts the physical SIM card into a piece of software to be embedded into a secure device MCU. Provisioning of an eSIM can be performed remotely over-the-air and some IoT projects will benefit from this extra flexibility. For less challenging IoT projects, e.g. indoor and fixed-location “Smart City” applications, the old-fashioned SIM card approach might be good enough, as long as competitive prices are offered. eSIM standardization is being facilitated by GSM Association, further information and specifications are available here: https://www.gsma.com/esim/esim-specification/. In the meantime, this standard has been adopted by several mobile phones and also by some IoT cellular network modules reviewed in this article. In fact, eSIM can reduce manufacturing and logistics efforts of IoT device manufacturers. In addition, obsolete SIM connectors will reduce space requirements and will increase security and reliability of IoT devices. Please see our product table, category “eSIM”.
GPRS communication and GPS positioning options
In general, new LTE Cat M and Cat NB standards are good choices for most IoT applications, but fully configured LTE Cat M or NB networks are not available everywhere (yet). This is a problem for projects with mobile IoT devices, e.g. asset tracking or navigation applications. Same applies to applications relying on IoT devices located at various places with different or unpredictable network coverage. In this case, good old GSM/GPRS can be used as a fall-back option because of its global availability even in less populated areas (see maps on https://www.gsma.com/coverage) and for open-air IoT applications like environmental sensing. In order to address both coverage scenarios a tailored IoT device should offer onboard support for both networks – maybe as a PCB assembly option for the IoT device: version 1 for local use with CAT M/NB , version 2 for GPRS. This product strategy would avoid costly integration of all possible network options and might be worthwhile to consider. For this purpose, pin-to-pin compliant M/NB and GPRS modules are offered by some manufacturers which are indicated by our product table in column “GPRS module with same pinout”.
For mobile applications or removable IoT devices it might be necessary to determine their current position, e.g. for tracking purposes. Ultimate precision is offered by satellite positioning systems like GPS or GNSS. Many manufacturers of IoT cellular network modules also provide dedicated positioning modules and combinations of both (“bundles”) – as a hardware option, integrated on same module or via interface (e.g. SPI) plus related software support (e.g. via dedicated AT command extension). Please see our product table, category “GPS/GNSS bundling”.
Price
In general, purchase prices are subject to frequent change (e.g. due to currency exchange rate), and depend on quantities and negotiation. Consequently, in our product overview table we provide a price indication only – based on actual budgetary quotes published by manufacturer and/or distributors at publication date. For a reliable quotation you will have to contact your sales partner anyway. Price range of reviewed sensor products is around 8 to 30 USD for 250 units. Average priced products (12 to 20 USD) are marked “◇”, less expensive products (12 USD or below) are marked “▽” or “◇▽” (around 20 USD), more expensive products are marked “△”.
Online Support
Qualified design support and technical assistance will speed up implementation and improve time-to-market esp. for distribution or online customers who do not enjoy direct access to product experts. First of all, these design engineers expect to have access to a comprehensive set of documentation provided by the manufacturer online, i.e. on their website. In order to support these “mass market” customers, access should be public, download should not require any prior qualification or signed NDA (“Non Disclosure Agreement”). Besides a product specification and application notes, many manufacturers are offering design kits and evaluation boards incl. drivers and libraries for target solutions, sample source code, etc. In addition, decent online support services like a public discussion board or option to submit a one-to-one support case or GitHub space should be standard offers of each manufacturer who wants to qualify as a potential “mass-market” supplier. See “Design Support” category in our product table.
Product Table
Figure 6: Product Overview Table (© chip-info.com)
For better visibility and further use you can download above table as a PDF here:
Conclusion
In our product table we have indicated a couple of potential low-lights (red fields) and high-lights (green fields) which might be relevant for your application. Here are some additional comments:
There is not much public available information about Thales EXS62/82, customers probably first have to sign an NDA with embedded security specialist Thales/Gemalto who claims to offer “state-of-the-art” protection. In addition, Thales EXS62/82 offers LTE-M, LTE-NB2 and GPRS fall-back at a very competitive price. Customers aiming at a secure IoT device design should also consider u-blox SARA-R510S which is offering a related Common Criteria security certificate at level EAL5+.
For battery-powered NB-IoT devices we have 3 candidates on a level playing field: Telit NE310H2, u-blox SARA-N310 and Quectel BC66-NA. Quectel BC66-NA is the overall low-cost leader and a GPRS option with same pinout is available, but unfortunately Quectel does not offer users to control GPIO pins by software.
Sierra Wireless WP7700 platform offers ultimate customizability for customers who are planing to develop a single-chip IoT controller with integrated application MCU. On top of this, Sierra Wireless offers a comprehensive one-stop-shopping experience including cloud support, subscription plans (as a MVNO) and device management. But this part is very expensive and all services are available at extra cost only. Telit is offering a similar comprehensive solution for their ME910 product family, also aiming at customers with a high level of integration in mind. In this product category, Telit ME910G1-W1 offers best price/performance ratio.
