If you are reading this blog post, you are likely in the business of selling devices or applications that haven’t had wireless connectivity before, or you are having trouble with your existing wireless solution. If the Internet of Things (IoT) is going to connect billions of devices in the next decade, there has to be a simple way to do this. Chances are, you have not yet found this “simple” connectivity option, which is why you are still looking for alternatives.
First, it would be prudent to determine whether connecting your previously unconnected device provides value to you or your customers. If it doesn’t, it is probably worth questioning device connectivity. (After all, you’re not an underpants gnome.)
If you decide that connecting your device does provide value, you have to determine which class of connectivity works for you. There are Personal Area Networks (PANs) like Bluetooth and Bluetooth Low Energy (BLE); local area networks (LANs) like WiFi and ZigBee; cellular networks like 3G and 4G; and low power, wide-area networks (LPWANs) like, SIGFOX, Ingenu, Weightless, LoRaWAN™, and Symphony Link (also built on the LoRa™ PHY). The network class you choose should depend upon what your application is and what the requirements to connect your application to the Internet are.
At this point, you’ve likely come across a number of options that could meet your needs. It seems that a low power, wide-area network could do the trick—and you might be looking at LoRa™ as an option.
Below, we’ll walk through details about what LoRa™ is, some common issues you might face when using LoRa, what the LoRa™ market looks like right now, the issue of standardization, and more.
What Is LoRa™?
LoRa™ is a modulation format generated by Semtech LoRa™ components, including the SX1272 and SX1276 transceiver chips, and SX1301 baseband processor. The modulation format is best described as a “frequency modulated (FM) chirp.” The ability to generate a stable chirp using a frac-N phase lock loop (PLL) is the core IP that enables LoRa™. Other modulation formats include frequency shift keying (FSK), phase shift keying (PSK), and others. It is important to remember that LoRa™ itself does not describe system functionality above the physical (RF medium) layer.
To learn more about the technical specifications of LoRa, visit our What Is LoRa? page.
Sensitivity, Range, & Data Rate
In determining if LoRa™ is the right technology for you, you’ll want to look at potential receiver sensitivity. There are different ways to get the sensitivity you need, but they all require different compromises.
One of the strengths of LoRa™ is that it has a lot of processing gain—and that processing gain increases receiver sensitivity. LoRa™ has a wider band than some of the narrowband technologies like SigFox. The wider band causes it to hear more noise, but the processing gain allows it to listen below the noise floor and hear weaker signals.
LoRa™ isn’t ideal for high data rate applications, like anything that may need to transmit photo, video, or voice—but it does work well for multipath environments, like those in buildings and on campuses.
Network Planning & Deployment
If you don’t have much expertise or experience with RF protocols or wireless systems and planning, it’s going to be harder to implement an LPWAN system. Wireless is relatively hard in terms of deployment, because things don’t always work the same way—even if they have the same orientation. After all, how many articles have you seen about how to make your home WiFi work better? Even the President has this problem! If you’re trying to get miles of coverage on a college campus, you’re going to deal with a more complex issue than covering parts of a building.
Here’s our big disclaimer: Be very skeptical of anyone in this space who tells you your deployment will be easy. You need to understand the reality of what you’re getting into. There are some aspects of deployment that may be easier than others, but deployment is a difficult thing to do no matter what.
On The LoRa™ Market
LoRa™ is a relatively emerging market, and new people in the space are contributing to making it better. Part of the reason the LoRa™ Alliance and LoRaWAN™ exists is to make it easier for companies without embedded RF protocol experience to use the LoRaTM physical layer. This is a great step forward, because many companies will have a difficult time developing their own over-the-air protocol.
Because it’s fairly new, there are still many changes to be rolled out. So if you’re considering LoRa™, you’ll either have to be along for the ride and willing to wait for some features that haven’t yet been implemented, or you’ll have to build the protocol yourself (like Iotera and Finsecur). Take acknowledgements for example. You can easily request discrete one-to-one acknowledgments with LoRaWAN™, but if you want to handle a large number of messages, you’ll have to build this into your application yourself.
Our thoughts on standardization diverge from many others in the LoRa™ world, because our business is predicated on solving customer issues today. We know that standardization is important to market adoption and is a noble goal, and we hope LoRaWAN™ continues to gain more traction and continues to build more features.
It’s also important to note that just because something is standardized doesn’t mean that it will actually work. LoRaWAN™ is a common language, but using that language effectively is left up to the application developer either at the end point, network server, or in most cases, both.
On The Protocol Level
As you’re exploring the protocols around LoRa™, you need to choose what works for you and your application. If you want to build, or be on a public network LoRaWAN™ or SIGFOX may be good options for you. If you think you can build a public network and you are not and MNO or willing to hire network infrastructure consultants, building a municipal LPWAN is probably not a good choice. If you are OK with someone else deploying the network and handling the planning while you pay a service fee—then this is may also be a good approach for you. Bear in mind that only some markets are putting up LPWAN public networks, though. If history is any indication, the timelines of these network deployments don’t always match early press releases.
You’ll also need to think through whether deploying a LoRaWAN™ network will meet your needs at the protocol level. In some cases, it could be better to use a custom protocol where all you have to do is send data to a node and it’s already written to connect to the cloud. If you use Symphony Link, for example, we have already done this work for you.
A Piece Of Advice
If we had to offer one piece of advice in determining which low power, wide-area network is right for you, it would be this: Don’t get caught up in a name, technology, hype, catch phrase, or future capability. It’s all just a matter of what you want to do. If you have a sensor and a SIGFOX network exists in your area and it meets your technical needs, then build a SIGFOX sensor. If a LoRaWAN™ network exists that you can build on, then do that. If no network exists, look at your business case and determine what is best for you. There’s room in the market for all of these things—and you can focus instead on what is going to work best for your application.