Thinking about utilizing Narrowband IoT (NB-IoT) to deploy your Internet of Things data collection device? Here’s what designers and engineers need to know about NB-IoT architecture to create a product that not only works, but also adds value for the customer.
NB-IoT Architecture As It Compares To LTE-M
As you’ve probably already noticed, any discussion of NB-IoT usually includes some mention of LTE-M. Both are cellular low power, wide-area (LPWA) technologies developed for IoT applications; both are gaining traction in different places geographically. (If you’re hoping to utilize NB-IoT for your product, make sure you’ve taken the potential obstacles into consideration.) The discussion of how to structure your NB-IoT device sometimes refers to LTE-M for context, in part because NB-IoT architecture is very similar to that of LTE-M.
The main difference between NB-IoT and LTE-M is this: NB-IoT requires a narrower bandwidth channel (200 kHz vs. 1.4 MHz), and devices can be deployed in non-traditional bands, including LTE guard bands (the bands that are not currently used that are adjacent to the main LTE bands), as well as IoT-specific bands. Many NB-IoT deployments are being put into guard bands because it’s a good way for cell companies to monetize that unused spectrum. NB-IoT devices can also be deployed in standalone bands using any available spectrum, provided regulators approve it, or within the LTE spectrum allocation. We have discussed other differences in a previous post.
While this provides massive flexibility for cellular operators and other network providers for implementing an NB-IoT network, it poses some significant problems for a device designer that have to do with roaming. People use the term roaming to mean different things, but for the purposes of this article, it means the ability to “send and receive data …when travelling outside the geographical coverage area of their home network.” Roaming is on the long-term roadmap for NB-IoT, but the flexibility of the NB-IoT standard, combined with the limitations of the constrained device likely to be accessing an NB-IoT network, make roaming nearly impossible at the time of this writing, for all practical purposes. So, building a device that can be used on different networks is actually a lot harder with NB than LTE-M (which is, itself, no small feat), because NB-IoT devices must be configured to use specific bands from the start. There’s no module currently available that will let you choose which band you support at run time, so you’re basically stuck selecting the desired bands at manufacturing. While this may provide some minor operational efficiencies, in practice you will have different SKUs even if the devices look the same, and you will have to know where exactly you’ll be using the device when you’re building it.
This problem does not apply to all (or even most) applications, but it is definitely worth highlighting. The applications that would most likely use NB-IoT are things like water and gas meters, or sensors in a fixed location—static assets that are designed to have a sensor that talks once a day for 10 years, and that’s it. In nearly all those cases you know where that device will be placed and you have no plans to change its location. (To some degree, this is also an issue for LTE-M, but it is amplified in NB-IoT.)
Essential Parts of NB-IoT Architecture
NB-IoT architecture is similar to that of LTE-M. The building blocks, which are the same, are as follows:
ANTENNA
In most cases you’ll be working with a cell company to deploy your device; the company will deploy it in or adjacent to an LTE band, so you need to use an antenna that works for that band.
Antennas are designed for specific frequencies. You can’t always have just one antenna that supports all the possible NB-IoT bands out there, though there are multi-band antennas that support all the major ones. You will pay for these antennas in dollars and size though, which are both critical to most NB-IoT applications. If your NB-IoT network falls within a standard GSM or LTE band, you can use a regular antenna, but for nontraditional bands, it’s something to keep on your radar. (The band you’ll have to use is determined by a combination of factors, including the regulatory structure of the country you’re in, the spectrum assets the cellular company or network provider owns, and how they choose to deploy NB-IoT. For LTE-M, typically a cellular operator will use an existing LTE resource block. But for NB-IoT, network operators might put the network in the licensed spectrum they own, which falls outside of traditional cellular band assignments.)
NB-IOT MODEM (OR MODULE)
Next, choose a modem (also called a module). The NB-IoT chipset is typically built into the module, which you would then design into your product.
The module you choose should be certified by the PTCRB (for operating in North America) or the GCF (Global Certification Forum for global use). Ideally, it should also be certified by a cell company or carrier, like AT&T or Verizon, which reduces your certification burden. If you’re using modules from Gemalto, u-blox, or Sierra, for example, you’ll need to get carrier certification yourself. In contrast, a pre-certified platform like Link Labs sells greatly simplifies the deployment process. (It’s basically the same as our LTE-M device, but with different firmware and a slightly different internal hardware configuration that does not impact our customers.)
HOST
The host is the device board that very literally hosts your application. It’s the microcontroller or microprocessor that runs your application as well as the interface to all the peripherals, like different sensors; it also controls the module, or, in our case, the hardware platform.
The host is as important to consider as anything else (probably more so since it’s actually what your customers are paying you for). You have to control the power consumption of your application, so a low power host application design is as important as the low power features in any of the radios. Our platform makes it easier to interact with the radio part by abstracting many of the difficult settings around low power modes. Our platform is low power by default—there’s very little additional work for you to do on the host side to make the radio any lower power. If you were to use a traditional module, like u-blox or Sierra, you would have to do a lot more work on the power management of the radio using AT commands.
CELLULAR NETWORK
Because your IoT device is only sending small bits of data, it’s generally better to use a non-IP-based device communication protocol, which is different than the way most modems interact with a cellular network, over standard TCP/IP. (You could use TCP/IP with NB-IoT, but you’d be paying for a lot of data overhead, which is a bit contrary to what NB-IoT was designed for.)
So you have two choices: Use traditional TCP/IP and pay for the overhead, or design a separate communication protocol that strips out all those additional layers. For option two, you’ll typically need your own private network routing within the cell network, as well as your own device management server that supports this alternate protocol, similar to what Link Labs offers. Our own private APN and VPN (virtual private network) allows us to route traffic the way we want, using non-TCP/IP communication. This element is a big part of the suggested architecture for NB-IoT.
Need honest advice on your IoT project?
Talk to us. We have the expertise and the technology to help bring your device to fruition, whether you’re using NB-IoT, LTE-M, or considering some other LPWA option. If you’re ready to deploy now, ask us about our LTE Cat-M1 pre-certified hardware platform, which could accelerate your device’s time to market. We’ll also soon have an NB-IoT platform available based on the same hardware design that could make the design and building of your NB-IoT device easier.
Getting your IoT device off the ground is more complicated than simply buying a chip, but there’s no reason for it to get stalled over details. Tell us about your project and we’ll help you design a solution that works.