Challenges

Broadly speaking, IoT devices draw power from:

1. the sun (solar cells)
2. internal batteries of fixed capacity
3. external power without capacity limitation

Obviously, solar powered devices can only operate during the day. Batteries may be able to power ultra low-power devices for years but, of course, the more power a device consumes the sooner the battery will become depleted. Sometimes (1) and (2) are combined, so solar cells top up the battery when the sun shines.

Without external power it is impractical to use powerful processors or operating systems or perform fast, voluminous data transfer. However, for devices connected to reliable power (e.g. a vehicle's electrical system) a primary limitation on IoT becomes connectivity. Even with unlimited power, an IoT device cannot transfer data over a cellular network if it cannot establish a cellular connection and maintain a minimal level of reliability.

At the hardware level, cellular communication in IoT devices is built around an electronic component called a cellular communication module (CCM). You may design a CCM into the PCB of your IoT device, or your IoT device may connect (via USB or UART) to an off-the-shelf cellular modem. Every cellular modem is built around a CCM. The manufacturer of the cellular modem is not very important. The CCM is what matters most. There are only a handful or two of CCM manufacturers in the world. Each manufacturer produces families of CCMs with individual CCMs aimed at different market segments based on considerations like:

1. geographic region (different cellular frequency bands are used in North America, Europe, Asia)
2. data transfer speed (NB-IoT/Cat-M, Cat 1, Cat 4, …)
3. power consumption

CCMs are wildly sophisticated electronically, and they include very complex and sophisticated firmware.

Each CCM responds to hundreds of software commands and has its own quirks. Those quirks are most often discovered through bitter experience. One or another is sure to bite you. When you run into peculiar behavior, there is no substitute for technical support from the manufacturer. Some CCM manufacturers are notorious for their poor technical support. Others are revered for theirs.

You'll also benefit immeasurable from quality technical support if your electrical engineers are incorporating a CCM into your own PCB. Some CCM manufacturers will gladly review your electrical design and even perform preliminary RF testing in their anechoic chamber. Some offer services to manage your FCC and/or network certifications. Others won't give you the time of day unless and until you purchase $1 million worth of their CCMs.

Once you select a CCM (or a cellular modem containing a CCM), only the antenna(s) and its placement (along with your software) will further affect communication between your IoT device and the cellular towers with which it communicates. If your IoT device is operating in a locale with strong signals most any antenna will do. If, however, the signal from the tower is weak, the antenna can make all the difference. One antenna may deliver a signal 3 - 10 dBm stronger than a different antenna of similar price and size. Antenna placement can make similar or even bigger differences.

Many cellular modems include traces on their PCBs to serve as antennas. These are generally the smallest and least efficient antennas. They are inexpensive and compact and may be a good choice for IoT devices that encounter only strong signals.

External antennas may be affixed directly to a cellular modem or custom PCB (via U.FL or SMA connectors). They are more cumbersome than PCB antennas, but can offer much better performance and may cost only a couple of dollars. When even better performance is required, antennas may be placed atop vehicles or on poles, though such placements are most cumbersome and expensive. Also, CCMs (and cellular modems) operating at higher speeds (Cat-4 and faster) require multiple antennas.

When not operating on solar or battery power, using a powerful operating system like Linux, full file system, powerful processors and plenty of memory are practical. You might design a processor and memory into your own PCB or include a single-board computer (Raspberry Pi, Beagle Board, etc.) in your IoT device.

A more powerful platform not only supports more complex software (e.g. multi-threading), but also supports more powerful development and debugging tools.

It is generally well-understood that different CCM technologies can achieve different data throughput rates:

	Max Upload	Max Download	Multiple Antennas
NB-IoT	< 100 kb/s	< 100 kb/s	No
Cat M	1 mb/s	1 mb/s	No
Cat 1	5 mb/s	10 mb/s	No
Cat 4	50 mb/s	150 mb/s	Yes

The operative word is can, not will.

The lowest cost CCMs generally support both NB-IoT and Cat M. Cat 1 and Cat 4 CCMs are more expensive. Not all cell towers support Cat M. Cat 1 and Cat 4 support is ubiquitous.

NB-IoT is not widely deployed by cellular providers, and they frequently impose severe limits on connection frequency and data volume. NB-IoT remains an immature technology.

Simply selecting a high-speed CCM does ensure high speed. In a region where you can't establish and maintain a connection the throughput is 0 bits/second. When signals are weak, throughput is greatly reduced from its theoretical maximum. All of the factors affecting connectivity also affect throughput.

Many IoT devices, even stationary ones, need access to accurate location and time information. Many CMMs include GNSS receivers for that purpose. There are pros and cons to using GNSS functionality included in CMMs.

The GNSS and cellular connectivity functionality of a CMM are generally separated to some degree. Some allow access to the GNSS receiver and the cellular functionality simultaneously. Other CMMs allow only one or the other to be active at a time. If your IoT device is stationary, or you only need occasional access to the GNSS functionality, the degree of separation probably doesn't matter. If, however, you need more or less continuous access to both, then you must take additional care when selecting a CMM.

There is also one special case to consider. GNSS receivers tend to be quite stable, well-behaved, and inexpensive. If you use a dedicated GNSS receiver, separate from the CMM, it will always be there for you. If you use the GNSS functionality in the CMM, every time you perform a reset (hardware or software) on the CMM you will be shutting down and restarting both the cellular network functionality and also the GNSS functionality. During the period of the reset, and the subsequent time it takes for the GNSS receiver to re-obtain a fix, you will have no GNSS data.

How likely is it that you will want to perform a software reset on your CMM? Well, an IoT device operating in a region with strong signals, may never need to issue a software reset. If, however, the device is in an area with weak signals, as a practical matter it can be difficult or impossible for the communication software to determine why it cannot obtain a connection, and a reasonable course of action is sometimes to perform a software reset on the CMM and then re-attempt a connection. This will interrupt GNSS location acquisition for from 15 seconds to a couple of minutes. Maybe this doesn't matter in your use case, or maybe it does.

Keep in mind, too, that you will need an additional antenna for GNSS.

If you are unable to update the firmware/software in your IoT devices over the air (OTA), then they must be updated in the field or returned to your facility for updating. Those are both expensive operations. Developing a reliable and relatively efficient mechanism for OTA updates should always be considered.

Here again, all of the problems of cellular connectivity come into play. When should the updates be done? Should updates be allowed while the device is moving (and the connection might drop) or only when stationary? If an update begins and fails because the connection dropped the device must be able to recover, rather than becoming bricked. Portions of the update may interfere with the running system if allowed to overwrite actively running code of the application or operating system. OTA updating is a complex problem but should not be overlooked.

Mobile network operators (MNOs) are the companies that own and operates the hardware of a cellular network. In the US, the biggest, nationwide MNOs are:

• ATT
• Sprint (acquired by T-Mobile in 2020)
• T-Mobile
• Verizon

A mobile virtual network operator (MVNO) does not own any cellular network equipment. Rather, they make deals with MNOs to let their customers access the cellular network through the equipment of one or more MNOs. If you need connectivity in more than one country, no MNO can help you. That is entirely the province of MVNOs who may strike deals with 100 or more MNOs across many countries. Across a country or region some sections may be better served by one MNO or another. An MVNO may strike deals with combinations of MNOs and thereby provide better coverage than any individual MNO.

A SIM card is needed to establish a cellular connection. SIM cards are usually small “cards” that slide into a spring-loaded holder. The new eSIM technology—a SIM card on a chip—is becoming available, though not yet widely adopted. The cost per SIM card varies from around $1.50/card to $4.00/card.

SIM cards are issued by MNOs and MVNOs. If you purchase connectivity services from an MNO you’ll get “native” SIM cards that only work on the MNO’s network. The SIMs provided by MVNOs are often “multi” SIMs that can achieve cellular connectivity via multiple MNOs.

You might expect MVNO SIM cards and connectivity costs to be higher than from MNOs, but exactly the opposite is usually the case. In the US, all MNOs—except Verizon—are happy to strike deals with MVNOs. So, if you require connectivity through Verizon then you probably cannot benefit from using a MVNO. If ATT, T-Mobile and Sprint can satisfy your needs, an MVNO probably provides the best value.

NOTE: in 2023, Verizon began striking deals with MVNOs, so at last is possible to find some MVNOs providing connectivity on all of ATT, T-Mobile and Verizon.

In addition to acquiring one SIM card for each IoT device, you must also purchase data service. Cellular data is metered. The MNO or the MVNO keeps track (via the SIM) of exactly how much Internet data gets transferred between cell towers and each IoT device each month. If you have N devices, with N SIM cards, you can purchase M megabytes of data transfer per SIM per month. The data is usually pooled, so if one device uses more than M megabytes in a month, but others use commensurately less, then it’s a wash. Thus,with N devices and M megabytes per month, as long as all the devices, collectively, use no more than N*M megabytes in the month there are no additional data charges. If you exceed your pooled data limit, the cost/megabyte for the overage is usually pretty steep, but buying more data than needed wastes money each month. Consider your data consumption needs carefully and purchase accordingly.

The cost/megabyte/device/month starts at around $1 when purchasing just one megabyte/device/month. The cost/megabyte/month declines dramatically as the number of megabytes/device/month increases. The cost for 1,000 megabytes (1 gigabyte) per month is about $10: $0.01/megabyte/month.

For engineers and system architects it can take a while to stop and think deeply about connectivity as they move from the wired world to the unwired world of IoT connectivity. Whether the computer is connected via Ethernet cable or a nearby Wi-Fi router makes no difference. Ethernet uses a super-reliable copper cable, and Wi-Fi uses super-reliable, short-range RF. Both types are almost perfectly reliable. Yes, outages can occur, but they are so infrequent they are reasonably ignored while developing software for wired devices.

Bringing the assumption of an always-available, high-speed Internet connection into the world of IoT and cellular connectivity guarantees poor results or worse. Even for stationary IoT devices, signal strength may be high at some deployment locations, but low, spotty, or absent at others. For mobile IoT devices the challenge is greatest when geographical, topological, and other important characteristics (more later) vary greatly as devices move from cell to cell, into and out of cellular dead zones, from rural to suburban locales, and around and through hills, valleys and mountains.

Establishing and maintaining a connection, as well as possible under the prevailing conditions, is a challenging problem. The only reasonable assumption for mobile IoT devices is they will sometimes or often be without Internet access for seconds, minutes or more at a time. Effective IoT software must be designed to delay data transfers when connectivity is not available and to recover from data transfers interrupted when a cellular connection drops.

One of the terrible surprises for the uninitiated is to deploy an IoT device with a connectivity solution developed and working reliably in one locale to other locales—often far away and troublesome to visit—and find the IoT device struggling to achieve and maintain connectivity. The very device that worked more or less flawlessly in and around the development lab, also works well in some distant locales, but is flatly unsatisfactory in yet other ones. It disappoints your customers, embarrasses you, and can ruin the reputation of your product. Worst of all, it's not an installation problem that can be fixed by a small tweak to a process; it's a fundamental problem baked into the nature of cellular connectivity.

Geography and Topology

A key characteristic of the portions of the radio spectrum used by cell towers to communicate with IoT devices makes it a line of sight technology. Buildings, hills and mountains, and even dense foliage on trees all attenuate cellular radio signals. Tower placement and height in and around hills, tall building, tree cover and little valleys can affect signal strength as much or more than mere distance between a cell tower and an IoT device.

In regions with many hills, valleys, and dense foliage more towers are needed to achieve good cell coverage, and they are placed to minimize locations from which no tower is in line of sight. Increasing tower height reduces dead zones and placing towers directly on hill peaks provides best coverage all the way around the hill.

Population Density

Cellular networks are comprised of cells. A cell is a small geographical region with a base station (cell tower) at its center. That base station manages all cellular devices (phones and IoT devices) within the region of the cell. In the case of cell phones, the cellular network needs to know exactly which cell contains each cell phone for the entire network. When a call is made to a cell phone, the call is routed over land-lines to the base station managing the cell containing the called phone, and then the base station manages the radio connections between the tower and cell phone. If the cellular network didn't keep track of the cell location of each phone, it would not know which cell to route a call to at the moment the call was made. This is also true for IoT devices. While IoT devices do not generally receive phone calls, many receive text messages so, again, the network must know which cell contains each IoT device.

In order for a base station to know which devices (cell phones and IoT devices) are inside its cell, the devices must register with the base station. Of course, a single registration is not sufficient, because after a device registers with a base station it might leave that cell and enter another one. Therefore, devices must “check-in” periodically with the base station to let it know it's still there, or register with a different cell if it moves into one.

In any one cell, at any given time, the great majority of devices will be inactive (phones not participating in a call or surfing the web, and IoT devices not engaged in data transfers) and a small portion will be active. There are two fundamental technological limitations on a cell tower: maximum number of devices that can be registered (active and inactive) and the number of devices that can be active simultaneously. These are not fixed values, but vary according to certain factors. The important point is the limits are modest and the active and registration limits are the most important factor in determining the size of each cell.

The base station transmitters need more power to create a larger cell and less to create a smaller cell. Fundamentally, cell size (radius around the cell tower) is managed by controlling the amount of power applied during transmission. It would be nice to just crank up the power and increase the cell size, but that can only be done when the population density (of cell devices) is low. In sparsely populated, flat regions without many trees, the towers are tall, the power output is high, and the cell size is large. However, in a big city, the population density is very high, so for any given base station the maximum registration limit will be surpassed unless the transmission power is turned way down to limit the size of the cell. Where population density is low, cells might be 10 miles across. In a big city, cells might be only a few blocks across.

So, population density dictates maximum cell size, but difficult geography and topology can require additional towers given the line of sight nature of the technology. Also, in sparsely populated regions with difficult terrain, MNOs usually trade off fewer base stations for more dead zones to contain costs.

singularIoT was first to recognize and classify locales in terms of connectivity characteristics. These are the seven fundamental categories,

• Rural
• Rural Town
• Flat Farmland/Flat Arid
• Mountainous
• Suburban
• Dense City
• Interstate Highway
• Uninhabited

and a brief description of each follows.

Rural

Low population density, hilly, plenty of foliage. Because of the difficult geography and topology cells cannot be large without creating many dead zones. Yet, the cost of installing cell towers is high, so a balance must be struck. The inevitable result is many regions with weak signals and plenty of dead zones.

Rural Town

The small towns in rural regions will certainly contain one or more towers, but again the high cost of installing cell towers will usually result in some areas around town with weak signals that may fade in and out and some dead zones too. The main difference between Rural and Rural Town is the areas with weak signals and dead zones will likely be much larger in Rural regions.

Flat Farmland/Flat Arid

The main elements captured in this cataegory are low population density, flat terrain, few tall trees, and no tall buildings. It is the flatness and absence of obstructions that distinguish these regions from Rural regions. In Flat Farmland/Flat Arid regions the cell towers are tall, and the cells are as big as they get. Many parts of Virginia and Pennsylvania, for example, are rural and filled with farms on rolling hills. They are not Flat Farmland regions, they are Rural.

Large, flat, arid areas of low population density are too dry for tall trees or crops to grow so, in terms of connectivity, these areas are just like Flat Farmland with low building and few trees.

Flat Farmland/Flat Arid seems like the perfect setting for cellular connectivity. Threre is, however, a peculiar connectivity problem that occurs with some regularity in Flat Farmland/Flat Arid and Mountainous regions and almost nowhere else (see “Thin Air,” below).

Mountainous

Mountainous regions, outside of towns, are generally the most difficult connectivity environments. MNOs can't economically justify installing enough base stations (cell towers) to provide good coverage, because of the low population density and the high cost and difficulty of installing base stations in mountainous terrain. The regions are filled with weak signals and cellular dead zones. Signal strength often oscillates back and forth from adequate to terrible passing between and around mountains and thin air is abundant.

Suburban

Achieving and maintaining connectivity in Suburban regions is generally easy. There are plenty of cell customers, so towers are plentiful along with good signal strength. There may be occasional, small dead zones.

Dense City

The cells are very small, but there are also large buildings to block signals and plenty of multipath to reduce signal quality. In cities like New York, streets (in Manhattan) are surrounded by tall buildings on both sides creating “urban canyons” which can create cellular dead zones. Still, the transmitters are so closely spaced that even when dead zones do arise they tend to be very small.

Note that urban canyons can block so much of the sky that obtaining a GNSS fix may not be possible. There is also so much multipath in urban canyons that GNSS location accuracy may suffer.

Interstate Highway

The Interstate Highways are an oasis of connectivity, whether cutting through cities or crossing vast Rural and even Mountainous regions. Of all the regions identified, Interstate Highway provides by far the most complete and reliable coverage, but why?

MNOs derive nearly all their revenue from cell phone users, so decisions about cell tower placement is entirely driven by trade-offs between network coverage for cell phones and costs. MNO revenue from IoT is tiny, and has no impact on tower placement decisions.

One consequence of industrialization in the US has been a steady migration of rural populations to urban/city living. More than 100 years ago the balance tipped away from rural living, and today more than 82% of Americans (270+ million) are urban/city dwellers. Virtually all of them get cell service in their homes and around town. Many of them spend no time in rural regions, except as they pass through driving along the nation's Interstate Highway system. So many people travel the Interstates that MNOs put up many towers to ensure coverage along those highways. A city dweller can drive all around the country on Interstate Highways and experience few, if any, cellular dead zones, unaware there may be many large dead zones just a few miles away from the Interstate.

Where signals are very weak, dead spots are common and large, and there is no town nearby, the best bet for getting a connection may be to head for the nearest Interstate Highway. In Rural regions with hills and dense foliage you may actually need to get onto the Interstate to find a connection.

Uninhabited

What distinguishes these regions is the absolute certainty there is no cellular connectivity. Rural and mountainous regions include many, sometimes large, dead zones. Uninhabited regions area all dead zone.

One does not need a helicopter or a long trek into the wild to find such places. I was in Lake Elsinore, California, located 70 miles north of San Diego, alongside Interstate 15. Driving southwest on Ortega-Highway (Route 74) there is a 30 mile stretch passing through Cleveland National Forrest which may be full of wildlife, but is uninhabited by people. There are no towns, no homes, no power or telephone lines. The road winds around and between countless hills rising hundreds of feet above. Because cellular connections are line-of-sight, every one of those hills will block signals from many directions at any particular position on the road, so a great many towers would be required to achieve adequate coverage for a phone call. Even if the region was flat and the entire stretch could be covered by only a few towers, getting power to those towers would be prohibitively expensive, so there are no cell towers, and no connectivity at all.

When using a wired connection that is unmetered there is no practical cost to moving more data when you can achieve the same result by moving less. If you're moving data so wastefully that it makes a program laggy and unresponsive then, of course, closer attention to data transfer efficiency is merited. Programs running on desktop and laptop computers and on cell phones (with unlimited data plans) make extensive of the HTTP protocol and JSON data format, because they're easy, reliable and convenient. However, if your data is metered and cost is important, paying close attention to your protocol choices and data representation can drastically reduce data consumption, data costs and power consumption.

Suppose, for example, you want to send a bit of telematics information a few times a minute to track a vehicle (latitude, longitude, time, speed, heading and a little status information). If you design your data packets carefully, you can encode that information in about 20 bytes. If you send the data using HTTP it will generally be accompanied by so many HTTP headers the total packet size will likely be hundreds of bytes per data packet. If you ditch HTTP, and go down to the socket level, you can send exactly the 20 bytes you want. You'll still need a TCP header (20 more bytes) and an IP header (20 more bytes) for a total of 60 bytes.

TCP also verifies delivery of packets by having the recipient server acknowledge packet receipt. If the packet doesn't arrive or is damaged en-route, TCP ensures re-transmission as needed. The back and forth of TCP consumes addition data and may become a source of excessive data consumption for an IoT device in a region with weak signals. Maybe you don't care if an occasional location packet gets lost. In that case you might consider using UDP (instead of TCP). UDP has a smaller packet header (8 bytes), and doesn't send acknowledgment packets or retry packet transmission.

Also, representing the location information in JSON, instead of sending a carefully constructed sequence of raw bytes, will increase the size of the data payload in the packet by a factor of 10 or more.

Maybe data consumption costs don't matter very much in your business model. Maybe minimizing data costs is essential to the success of your product. It's certainly more work to limit your data consumption by carefully crafting your data transfers. Don't waste your time if it doesn't matter, but don't waste your money if it does.

This discussion of cellular connectivity shall end with testing, and that is really where you should begin. If you ignore testing until after developing and implementing a connectivity solution, you run the risk of traveling a long and costly connectivity path without any certainty the solution is reliable. Desgining testing into your development plan can catch software design flaws early when they are more easily fixed than later when design changes are more costly.

If you don't plan for your testing from the very beginning you will also miss a great opportunity to think about hardware and software features to build into your IoT device to facilitate your testing. Please feel free to contact us to discuss testing as your first step, rather than your last one.

Though Flat Farmland/Flat Arid regions seem perfect for cellular connectivity there is a problem that arises almost uniquely in those regions. We, at singularIoT, were first to identify and name it. We call it “thin air.” It is unrecognized in the literature and little known among practitioners even as it impairs their connectivity. It creates the illusion for CCMs they are registered on a cellular network when they are not. At singularIoT we have developed algorithms and a unique IoT device-to-server protocol for detecting and managing thin air conditions. Our solution minimizes connectivity down-time in regions of thin air.