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:

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 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.

How LoRaWAN Works

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 collapseDiagram of LoRaWAN gateway communication

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 Classes A, B, & C

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.

Chirp Rate, Processing Gain, & Orthogonality

Chirp Rate of LoRaWAN system

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.

Barriers To Building Private Networks With LoRaWAN

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 does not guarantee message receipt.LoRaWAN is an asynchronous, ALOHA-based protocol packet error rates (PER) of more than 50 percent are common. These errors are ok 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. 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. Most likely, you will 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 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 limitation 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. 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.


 

Join the AirFinder Difference!

  • Innovation. Organizations can be freed up to innovate and bring more impactful products and services to market.
  • Profitability. Increased profitability provides new opportunities to innovate and improve valuation.
  • Digital Transformation. Discover competitive advantages, new revenue opportunities, improved customer relationships, and increased efficiency.

 


An Alternative Solution: Symphony Link

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.

      • A bidirectional link for 100 percent guaranteed message receipt. Nodes and gateways can communicate reliably both up and down.
      • It uses a dynamic channel mask controlled by the gateway, allowing multiple gateways to coexist with as few collisions as possible. Up to 48 gateways can coexist without affecting performance.
      • There’s no duty cycle limit because in Europe, Symphony Link uses the 900 MHz Band.
      • Symphony Link has a higher capacity than LoRaWAN, with a fixed MTU of 256 bytes. It handles all the subpackets and retries message-sending when necessary to ensure delivery.
      • Symphony Link is a complete end-to-end IoT solution that works right out of the box. You can get your application up and running faster than with LoRaWAN.

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.

Bluetooth Low Energy plus LoRaWAN of asset tracking

Written by Mark Bloechl

Mark is the Chief Hardware Engineer at Link Labs. He designs and builds all of Link Labs’ hardware—radios, devices, modules… you name it, he creates it.

Before Link Labs, Mark worked for TMC Design building GPS jammers at Holloman Air Force Base in New Mexico. He also worked at the John Hopkins Applied Physics lab for eight years. Mark graduated with a Bachelor’s in Electrical Engineering from the University of Florida and a Master’s Degree in Electrical Engineering from John Hopkins University.

Related Blogs

Asset Tracking, BLE Asset Management Election Integrity, RTLS, asset tracking system, automation, Elections, legal concerns, chain of custody, mail-in ballot

How Counties Can Avoid Public Scrutiny During Elections

Asset Tracking, BLE Asset Management RTLS, supply chain, remote assets, gps, satellite, automation, Satellite GPS tracker

How Satellites Optimize Supply Chains and Logistics

Asset Tracking, BLE Asset Management Asset Tracking, RTLS Solution, RTLS, asset monitoring, rtls asset tracking, Utilization, process efficiencies, manufacturing, Downtime, historic data, predictive data

Why Monitoring Utilization Improves Process Efficiencies

Subscribe to Link Labs' blog weekly update!

Subscribe

Subscribe to Link Labs' blog weekly update!