Thinking about using LoRaWAN to deploy your IoT solution? Lately there’s been some momentum building for this protocol (case in point: machineQ), which works well for simple applications deployed on public networks. However, if you’re developing a private network solution for industrial or enterprise use, there are some limitations to this technology you need to be aware of (and alternative protocols that will, in many cases, serve you better).
See example LoRaWAN Gateway for developers.
In this article, we’ll take an in-depth look at:
-
- The Difference Between LoRa & LoRaWAN
- How LoRaWAN Works
- LoRaWAN Classes A, B, & C
- Chirp Rate, Processing Gain, & Orthogonality
- Barriers To Building Private Networks With LoRaWAN
- An Alternative Solution: Symphony Link
The Difference Between LoRa & LoRaWAN
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 uses a chirped, multi-symbol format to encode information. It’s a proprietary system made by chip manufacturer Semtech; its LoRa IP is also licensed to other chip manufacturers. Essentially, these chips are standard ISM band radio chips that can use LoRa (or other modulation types like FSK) to convert radio frequency to bits, without any need to write code to implement the radio system. LoRa is a lower-level physical layer technology that can be used in all sorts of applications outside of wide area.
LoRaWAN is a point-to-multipoint networking protocol that uses Semtech’s LoRa modulation scheme. It’s 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. LoRaWAN is rarely used for industrial (private network) applications due to its limitations.
How LoRaWAN Works
At the most fundamental level, radio protocols like LoRaWAN are fairly simple. The way star networks converse is similar to a professor and students in a lecture. The gateway (the professor) speaks to end nodes (the class), and vice versa. This is an asymmetric relationship in terms of communication. Everyone in the class could be trying to communicate with the professor at the same time, 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.
Here’s what that looks like in practice: Let’s say, for example, 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. It’s possible that all four gateways might hear that message and send it. (The one advantage to this: Messages can still be transmitted despite very weak links. If a node transmits five messages and only one makes it, your message has still gone through.)
Once a message has been delivered, there is no acknowledgement of receipt. However, nodes in LoRaWAN can request acknowledgements. If acknowledgement is requested and all four gateways pick up the same message, the cloud chooses one gateway to respond at a fixed time, usually a couple of seconds later. 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 acknowledgements, it will very likely spend more time transmitting acknowledgements 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’s orange, it’s transmitting; if it’s blue, it’s not.) 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, across any number of frequency channels.
LoRaWAN Classes A, B, & C
LoRaWAN has three classes that operate simultaneously. Class A is purely asynchronous, which is what 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 gaps in communication, the theoretical maximum capacity of a pure aloha network is about 18.4% of this maximum. This is due largely to collisions, because if one node is transmitting and another wakes up and decides to transmit in the same frequency channel with the same radio settings, they’re going to collide.
Class B allow for messages to be sent down to 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 transmit beacon messages at the exact same time, as they are slave to 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 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 a downlink message can be sent any time. This is used primarily for AC-powered applications, because it takes a lot of energy to keep a node actively awake running the receiver at all times.
Chirp Rate, Processing Gain, & Orthogonality
Note: In LoRaWAN, Spreading Factor (SF) refers to chirp rate. This graph shows the LoRa Chirp Modulation over time. Different SFs can be decoded in the same frequency channel at the same time.
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, which 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 in order to encode a symbol. The fact that LoRa transmissions jump from one place to another at a particular time might mean one bit string vs. another. It’s 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 was stationary for some time and then jumped to somewhere else for a while, you would see different lines, or tones. This is called 2-ary FSK, which denotes two frequency symbols. M-ary FSK has multiple frequency tones which can represent even more symbols. LoRa has taken this concept, but it does everything on a chirp. So, it’s getting processing gain. Because it has a very distinct pattern, the LoRa receiver can detect quieter chirps, i.e., below the noise floor. If you have another transmission happening in the same channel at a different chirp rate, it is orthogonal—meaning it could be detected at the same time. All that said, there is a lot of capacity on the receiving side.
Barriers To Building Private Networks With LoRaWAN
LoRaWAN works well for some applications, but it’s 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. With LoRaWAN, all gateways—no matter who owns or operates them—are tuned to the same frequencies. That means your LoRaWAN network sees all my traffic and vice versa. It’s better to have only one network operating in a single area in order 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 amount of downlink in their networks from the server side to ensure low priority endpoints don’t “clog” the network with downlink traffic.
-
-
- It does not guarantee message receipt. LoRaWAN is an asynchronous, ALOHA-based protocol where packet error rates (PER) of more than 50 percent are common. This is fine for some meter-reading applications, but for industrial or enterprise sensor networks or control systems, 0 percent PER is a requirement. The “spray-and-pray” method of message delivery is not appropriate for most industrial use cases, which is why LoRaWAN is best suited for uplink-focused networks.
-
- It requires a fair amount of development work. Another challenge our customers have faced is that LoRaWAN is primarily a data link (MAC) layer (OSI Layer 2), with only some elements of a network layer (OSI Layer 3). As of today, no vendor provides an end-to-end LoRaWAN solution. Instead, you need to work with multiple vendors to acquire nodes, gateways, a backend server, and every other part of the ecosystem separately. While this allows for a lot of flexibility in applications, it leaves application developers with a good amount of work to produce a complete product offering. This includes packetization, downlink control, multicast, etc.
-
- There are duty cycle limitations. There are some limitations inherent with 868 MHz bands in public networks. In Europe, the main limitation is the one percent duty cycle (in most cases). This means if you measure the average length of time the gateway is transmitting over time, it cannot exceed one percent. Because of this, the gateway is pretty limited in how much it can transmit. In the U.S., FCC regulations for the ISM band have no such limitation.
-
-
It has a variable maximum transmission unit (MTU) payload size. Another big limitation of LoRaWAN is that the MTU payload size is variable 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, but if you’re close it’s much bigger; you simply can’t know that ahead of time. Therefore, the node firmware or application has to 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 alterations that would be required to handle these changing MTU values.
-
LoRaWAN is fine if you want to build on carrier-owned and operated public networks. There are many hardware and network server providers competing in this space, so there is a lot of choice. And for simple applications, where you don’t have a lot of nodes and don’t need a lot of acknowledgement, LoRaWAN works. But if your needs are more complex, you will inevitably hit serious roadblocks. Many LoRaWAN users haven’t experienced those roadblocks yet simply 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. One of the reasons we wrote this article is because we have customers approach us who are under the impression that LoRaWAN “works out of the box” like some WiFi or cellular modems might. You’ll want to be sure you understand all the architecture and have a good grasp on how the system works before you decide it’s the best route for you.
via www.link-labs.com
