Note: Link Labs is a proud member of the LoRa Alliance, which was created to further develop LoRa and LoRaWAN technology. We suggest you look to them for additional information and resources, as well as the most recent specification.
There are 2 different protocol stacks available for LoRa: LoRaWAN and Symphony Link. Symphony Link is for industrial and enterprise users who need advanced features. LoRaWAN is for mobile networks based on LoRaWAN, primarily in Europe.
LoRaWAN is a media access control (MAC) layer protocol designed for large-scale public networks with a single operator. It is built using Semtech’s LoRa modulation scheme. Within this article, we will take an in-depth look at:
You may have heard that LoRaWAN isn’t a great fit for customer-deployed (aka private network) solutions, which is true today. (Take a look at this for a customer-deployed solution.) It is a better fit for public, wide-area networks, because with LoRaWAN, all of the channels are tuned to the same frequencies, and it’s better to have only one network operating in a single area in order to avoid collision problems.
Because all of the gateways in a network are tied back to the same server, it’s the server’s job to decide which gateway should respond to a transmission. In a large network, any given transmission is typically heard by multiple receivers, and the server then tells one gateway to respond and the others to ignore the transmission. This process helps to avoid downlink and uplink collisions, because a single gateway is transmitting, and the gateways that are overlapping can simply listen for other transmissions. (We will talk more about downlink and uplink capabilities of LoRaWAN below.)
Additionally, it is possible to work through the LoRa Alliance to have specific channels set aside for specific uses. This is more appropriate in the U.S. than in Europe, where there is much more license-free spectrum than other ETSI-like regulatory schemes. 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.
Finally, a roaming framework is under development to allow private LoRaWAN applications on public LoRaWAN networks (available mid to late 2016).
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). While this allows for a lot of flexibility in applications, it leaves application developers a fair amount of work to have a complete product offering. This includes packetization, downlink control, multicast, etc.
As of today, no vendor provides an end-to-end LoRaWAN solution. Several companies (including Link Labs) are working on partnering to provide an end-to-end solution, but there is still a fair amount of friction in application development working with multiple vendors. For this reason, there is a lot of value to be generated by innovative application developers who are comfortable working with multiple elements of the stack.
Several LoRaWAN Network Server vendors, such as Actility and OrbiWise, are also providing Application Server services, which may help speed application development on the server side. On the end-point side, some module manufacturers (including Link Labs) are providing some common features as part of their development environment.
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 (everyone in 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.
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 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.
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 of this said, there is a lot of capacity on the receiving side.
If an acknowledgement or an actual downlink message needs to happen in a LoRaWAN system, it happens at a fixed offset from the uplink message: the message is transmitted up, the gateway receives it, and then it waits a fixed interval (either 1 or 2 seconds) before it transmits back down. (You can see this demonstrated by the gray horizontal line in the gateway receiver graph above.)
Like all radio systems, the gateway cannot hear anything when it’s transmitting. So, when the gateway transmits a message, it shuts down the receivers and is temporarily off the air. Talking to a single node takes the whole receiver out of the picture. For this reason, transmissions and downlinks do not happen often in LoRaWAN. Because of this, LoRaWAN is best suited for uplink-focused networks.
There are some limitations inherent with 868 MHz bands in public networks. In Europe, the main limitation is the 1% duty cycle (in most cases). This means if you measure the average length of time the gateway is transmitting over time, it cannot exceed 1%. 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. In the Symphony Link system at 915 MHz, the gateway is transmitting about 15% of the time.
LoRaWAN is a great choice for protocol 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—which is a great benefit.
But make no mistake, developing and deploying a system around LoRaWAN is quite complex. 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. While this is a goal for all members of the LoRa Alliance, it is still in its early days, and you’ll want to be sure you understand all of the architecture and have a good grasp on how the system works before you decide it’s the best route for you.
We help customers develop systems for LoRaWAN every day, and if you’re interested in learning more, we’d love to talk.