LoRa® and LoRaWAN®: Differences and Implementations
Let's look at the differences between LoRa implemented with proprietary networking layers and LoRa implemented with LoRaWAN.
There is often confusion among equipment manufactures and network deployers about the differences between LoRaWAN devices and devices that featuring LoRa devices that have a proprietary networking layer. This section describes the technical differences between these, and the pros and cons of each.
As described previously “LoRa” is
the physical radio layer chip set developed by Semtech, known as Layer 1 in the
Open Systems Interconnection model (OSI) seven-layer stack. However, to make
this into usable devices and networks Layer 2 of this stack is required. This
can either be separately developed as proprietary networking layer, or you can use
the LoRaWAN Layer 2 specification developed by the LoRa Alliance, along with the
open-source software that available to implement it.
As the LoRaWAN specification and compliant source code implement all of the following LoRaWAN features, which are included by default:
- Adaptive Date Rate (ADR) control, where data rate and powea re are individually and dynamically set for the device. The data rate setting depends on the distance of the device from the Gateway.
- Secure joining of the network via Over-The-Air Activation.
- All of the security features of LoRaWAN. You can set the frequencies to be used by the end device.
- End-to-End security, using AES 128 Secure Payload for control and application data.
- Cryptography checks on all messages.
- Use of unique up and down counters.
- Setting Confirmed and Unconfirmed packets (both uplink and downlink) and automatically transmitting missed messages.
- Different classes of operation, depending on the use case (i.e. Class A, B, or C).
- Configuration of the device for specific countries or regions to be compliant with the Regulatory requirements.
All of these features could be developed with a proprietary networking layer. However, this would require extensive development time and debug effort. Typically, proprietary solutions only implement the basic networking features and, as a result, there is very little—if any—security included, and there is no secure process for an end device to join a network. Also, ADR is typically not included, so devices are set up for the maximum transmission distance and therefore use the lowest data rate. This setup requires the longest time on air for transmitting and receiving message, which has a significant impact on the power used by the device. In the worst case scenario, this can be 1000 times less efficient, and can cause premature device failure. Excessively long transmission times can also cause significant pollution in the air, especially as the devices are set to transmit for the maximum distance.
Another major drawback of using a proprietary networking layer is that it will not interoperate with the very large volume of LoRaWAN-compliant networks and cannot make use of the large LoRa Alliance® ecosystem that already exists. Furthermore, it will not be possible for the proprietary device to roam other LoRaWAN networks, be they public or private.
Some developers may start building devices with LoRa and a proprietary networking layer but as their network deployments build, end up switching to LoRa and LoRaWAN due to the readily available LoRaWAN devices which have security, reliability and interoperability built in.