Are you thinking about using LoRaWAN to deploy your IoT solution? Lately, there have been some momentum-building protocols for simple applications deployed on public networks. If you are developing a private network solution for industrial or enterprise use cases, you need to understand the limitations. It also helps to know about alternative protocols that will, in many cases, serve you better.
In this article, we’ll take an in-depth look at:
Sometimes people think the terms LoRa and LoRaWAN mean the same thing, but they are different. LoRa is a method for transmitting radio signals that use a chirped, multi-symbol format to encode information. It is a proprietary system made by chip manufacturer Semtech. Other manufacturers can license the LoRa IP. These standard ISM band radio chips can use LoRa (or modulation types like FSK) to convert radio frequency to bits. This modulation means no one needs to write code to implement the radio system. This lower-level physical layer technology can help applications outside of a wide area.
LoRaWAN is a point-to-multipoint networking protocol that uses Semtech’s LoRa modulation scheme. It is not just about the radio waves; it’s about how the radio waves communicate with LoRaWAN gateways to do things like encryption and identification. It also includes a cloud component, which multiple gateways connect to. Due to limitations, most companies do not use LoRaWAN for industrial (private network) applications.
At the most fundamental level, radio protocols like LoRaWAN are simple. The way star networks converse is like a professor and students in a lecture. The gateway (the professor) speaks to end nodes (the class) and vice versa. This communication is an asymmetric relationship in terms of communication. Everyone (in the class) could be trying to communicate with the professor simultaneously, but the professor would not be able to hear or understand them all at once. Albeit extremely oversimplified, many elements of star topologies go back to this analogy.
See example LoRaWAN Gateway for developers.
Now let us walk away from the analogy a study practical examples. Let us say you have four gateways and one node. The node transmits into the radio spectrum blindly, and any gateway lucky enough to hear the transmission can take it and send it up to the cloud. All four gateways might receive the message. (The one advantage to this: Messages can still transmit despite weak links. If a node transmits five messages and only one makes it, your message still goes through.)
Once a message has been delivered, there is no acknowledgment of receipt. However, nodes in LoRaWAN can request acknowledgments. If the acknowledgment is requested and all four gateways pick up the same message, the cloud chooses one gateway to respond at a fixed time. The problem then is this: When that gateway is transmitting back to the node, it stops listening to everything else. So, if your application needs a lot of acknowledgments, it will very likely spend more time transmitting acknowledgments than listening, which will eventually lead to a network collapse
The above diagram shows how LoRaWAN operates. The top bar indicates if the gateway is transmitting or not. (If it is orange, that means it is transmitting. If it is blue, that means it is not transmitting.) The bar at the bottom demonstrates the receiver channels. Nearly all LPWAN systems, including LoRaWAN, have multiple receive channels, and most LoRaWAN systems can receive eight messages simultaneously. They can receive across any number of frequency channels.
LoRaWAN has three classes that operate simultaneously. Class A is purely asynchronous, which we call a pure ALOHA system. This means the end nodes don’t wait for a particular time to speak to the gateway—they simply transmit whenever they need to and lie dormant until then. If you have a perfectly coordinated system over eight channels, you could fill every time slot with a message. As soon as one node completes its transmission, another starts immediately. Without any communication gaps, the theoretical maximum capacity of a pure aloha network is about 18.4% of this maximum. This capacity is due to collisions. If two nodes transmit at the same frequency channel with the same radio settings, they will collide.
Class B systems work with battery-powered nodes. Every 128 seconds, the gateway transmits a beacon. (See the time slots across the top of the diagram.) All LoRaWAN base stations simultaneously transmit beacon messages at one pulse-per-second (1PPS). This means that every GPS satellite in orbit transmits a message at the beginning of every second, allowing time to be synchronized around the world. All Class B nodes are assigned a time slot within the 128-second cycle and are told when to listen. You can, for instance, tell a node to listen to every tenth-time slot, and when this comes up, it allows for a downlink message to be transmitted (see above diagram).
Class C allows nodes to listen constantly and send downlink messages at any time. This system is used primarily for AC-powered applications because it takes a lot of energy to keep a node actively running.
Note: In LoRaWAN, Spreading Factor (SF) refers to the chirp rate. This graph shows the LoRa Chirp Modulation over time. Different SFs can be decoded in the same frequency channel simultaneously.
LoRa works by moving an RF tone around over time in a very linear way. This graph shows the chirps in a reverse waterfall— the newest data is at the top is called an up chirp. You can see how this frequency of the tone is increasing over time. LoRa transmissions work by chirping, breaking the chips in different places in terms of time and frequency to encode a symbol. Because LoRa transmissions jump from one place to another at a particular time might mean one-bit string vs. another. It is not just simply binary—it has a lot of information you can convey (high symbol depth).
Think, for a moment, of pure frequency shift keying (FSK). If a tone is stationary for some time and then jumps to somewhere else for a while, you would see different lines. This tone is called 2-ary FSK, which denotes two frequency symbols. M-ary FSK has multiple frequency tones and can represent even more symbols. LoRa has taken this concept, but it does everything on a chirp. So, it is getting processing gain. Because it has a very distinct pattern, the LoRa receiver can detect quieter chirps, i.e., below the noise floor. All that said, there is a lot of capacity on the receiving side.
LoRaWAN works well for some applications, but it is not the best fit for customer-deployed (also known as private network) solutions. The main reasons for that are:
The coexistence of multiple gateways allows for interference. All LoRaWAN gateways tune to the same frequency. No matter who owns or operates them. That means your LoRaWAN network sees all my traffic and vice versa. It is better to have only one network operating in a single area to avoid collision problems.
However, it is possible to work through the LoRa Alliance to have specific channels set aside for specific uses. It is also possible for network operators to limit the number of downlinks in their networks from the server side to ensure low priority endpoints don't "clog" the network with downlink traffic.
It has a variable maximum transmission unit (MTU) payload size. The MTU payload size is based on the spreading factor the network assigns to the node. In other words—if you’re far away from the gateway, the number of bytes you can transmit is small. However, if you are close, it is much bigger. You simply cannot know that ahead of time. Therefore, the node firmware or application must be able to accommodate changes in the payload side at the application layer, which is very challenging when you’re developing firmware.
Most developers solve this problem by selecting the smallest available MTU at the highest spreading factor the network could assign, which in most cases is very small, often less than 12 bytes. So LoRaWAN nodes that need to send larger amounts of data, for example, 300 bytes would have to send it in 30 10-byte messages because they may face a situation where they are assigned a small MTU. As a result, those nodes transmit much more than necessary due to the complex software to handle these changing MTU values.
LoRaWAN is fine if you want to build on carrier-owned and operated public networks. Service providers like to compete in this space, so there are many choices. And for simple applications, where you don’t have a lot of nodes and don’t need a lot of acknowledgment, LoRaWAN works. But if your needs are more complex, you will inevitably hit serious roadblocks. Many LoRaWAN users have not experienced those roadblocks because their networks are still fairly small. Try using LoRaWAN to operate a public network with thousands of users doing different things, and the difficulties will most certainly skyrocket.
Also, developing and deploying a system around LoRaWAN is a complex process. We wrote this article because customers approach under the impression that LoRaWAN “works out of the box” like some Wi-Fi or cellular modems might. You will want to be sure you understand all the architecture and have a good grasp of how the system works before you decide it’s the best route for you.
Symphony Link is an alternative LoRa protocol stack developed by Link Labs. To address the limitations of LoRaWAN and provide the advanced functionality that most organizations need, we built our software on top of Semtech’s chips.
There are lots of other reasons why companies choose Symphony Link. You can read more about it on our website. We can show you how to set up a gateway and a dev kit in Symphony Conductor; and review integration steps, power budgets, and range. Or, if you have any questions about the technology, book a demo.