Since LoraWAN is running in ISM band, which means that interference will be a big topic for the future massive deployment. Also, how to deal with the collision when the devices are increasing is another hot topic. It is clear that LoraWAN has become the most important IoT protocol around the world, even Telecomunication companies like Orange and Swiss Telecom are developing the Lora network in their countries. Here comes the question: (1) How many nodes can send and receive simutaneously? (2) How to eliminate the blind spots when the network is formed.
To answer the question, let's take a look at the ISM band allocation to LoraWAN in different regions:
Acutally we can divide the topic into three different categories: The first is 868Mhz, second is 915Mhz, the thrid is 490Mhz. They represent the regulations in several or one region, correspondingly. Unfortunately, we just have the official explanation and regulation for US/EU about the Sub-GHz IoT applications, the other countries don't have specific regulations about time on air and the frequency hop, but they do have the limitation about the output power.
ETSI committe has release a technical document about the detailed regulation on each 868 frequency band:
There are just few of the bands can be used in 868Mhz in Europe. Most of them have the requirement on the specturm access, which means the time on air can not exceed 0.1%-10%. The following table shows the "time on air" for different spreading facor.
In real experiments, we got the time interval between two send for SF7, which is about 6 seconds. And for SF12, it is about 146 seconds between two sendings. It is tested on g1. This greatly reduces the collision due to the duty cycle for Lora sensors are limited to 0.1% to 1%, this enables the devices to adapt the algorithms similar to the CSMA/CD, and hence increase the network capacity.
On the gateway side, we have to implement the LBT+AFA, which means Listen Before Talk and can break the 1% duty cycle limitation. This is extremely useful when a lot of Lora Sensors request to authenticate. A normal Lora gateway or its competitors fail to response in such a situation. Our MatchBox introduces this LBT+AFA, and the MatchSticks can choose Spreading factors adaptively for the maxium network capacity.
The ISM band for North America is from 902-928MHz. LoRaWAN™ defines 64, 125kHz uplink channels from 902.3 to 914.9MHz in 200kHz increments. There are an additional eight 500KHz uplink channels in 1.6MHz increments from 903MHz to 914.9MHz. The eight downlink channels are 500kHz wide starting from 923.3MHz to 927.5MHz. The maximum output power in North America 902-928MHz band is +30dBm but for most devices +20dBm is sufficient. Under FCC there are no duty cycle limitations but there is a 400msec max dwell time per channel. And they introduced a hybrid mode for our MatchBox and MatchSticks in case of we can't achieve 64 channels.
Semtech SX1301 can only achieve 8 channels for uplink and downlink, so we have to use hybrid model for both the Lora gateway and sensors.
From the FCC: “A hybrid system uses both digital modulation and frequency hopping techniques at the same time on the same carrier. As shown in Section 15.247(f), a hybrid system must comply with the power density standard of 8 dBm in any 3 kHz band when the frequency hopping function is turned off. The transmission also must comply with a 0.4 second / channel maximum dwell time when the hopping function is turned on. There is no requirement for this type of hybrid system to comply with the 500 kHz minimum bandwidth normally associated with a DTS transmission; and, there is no minimum number of hopping channels associated with this type of hybrid system.”
When we have 8 channels to hop, the possibility that about collision will be less if we listen to the channel and change to an empty one instead.
The network capacity is largely depended on the density of the MatchBox Lora gateway and the performance of the SX1301 chip. The SX1301 is a smart baseband processor for long range ISM communication. In the receiver part, it receives I and Q digitized bit stream for one or two receivers (SX1257), demodulates these signals using several demodulators, adapting the demodulators settings to the received signal and stores the received demodulated packets in a FIFO to be retrieved from a host system (PC, MCU). In the transmitter part, the packets are modulated using a programmable (G)FSK/LoRa modulator and sent to one transmitter (SX1257). Received packets can be time-stamped using a GPS PPS input.
Several packets using different data rates (different spreading factors) may be demodulated simultaneously even on the same channel. Those channels are intended to be used for a massive asynchronous star network of 10000’s of sensor nodes. Each sensor may use a random channel (amongst IF0 to IF7) and a different data rate for any transmission. Sensors located near the gateway will typically use the highest possible data rate in the fixed 125 kHz channel bandwidth (e.g. 6 kbit/s) while sensors located far away will use a lower data rate down to 300 bit/s (minimum LoRa data rate in a 125 kHz channel).
Since LoRa® is a spread spectrum based modulation, the signals are practically orthogonal to each other when different spreading factors are utilized. As the spreading factor changes, the effective data rate also changes. The gateway takes advantage of this property by being able to receive multiple different data rates on the same channel at the same time.
The SX1301 digital base band chip scans the 8 channels (IF0 to IF7) for preambles of all data rates at all times. The chip is able to demodulate simultaneously up to 8 packets. Any combination of spreading factor and intermediate frequency for up to 8 packets is possible (e.g. one SF7 packet on IF0, one SF12 packet on IF7 and one SF9 packet on IF1 simultaneously). The SX1301 can detect simultaneously preambles corresponding to all data rates on all IF0 to IF7 channels. However, it cannot demodulate more than 8 packets simultaneously. This is because the SX1301 architecture separates the preamble detection and signal acquisition task from the demodulation process. The number of simultaneously demodulated packets (in this case 8) is an arbitrary system parameter and may be set to other values for a customer specific circuit.
How to increase the network capacity
We proposed mainly two ways of enlarging the network capacity:
- The first is to put more SX1301 and SX125x on the MatchBox for the later Pro Version.
- The second is to adopt anti-collision algorithm for the Lora sensors like MatchSticks before sending a packet to the server.
How to optimize the network coverage
The preliminary requirement for the full network coverage should be the Lora Gateway and Sensors have the same or similar sensitivity. Since the LoraWAN uses star network, which is exactly the same as GSM/UMTS/LTE base stations, and the gateways are transparent to the sensors, we should adopt the cellular topology that has been proved the optimized network topology for star network.
However, there are several discrepancies between a cellular network and LoraWAN:
- The Lora sensors are not accessing to the network all the time, so there is no real hand-off issue for constant data transfer
- The Lora sensors are mostly stationary
- The moving sensors should be classified as a different category
It is relatively easy to optimize the network coverage for the stationary MatchSticks, which is to increase the output power of the sensors first to inform the network, then decrease to the acceptable level.
And for the moving sensors, we need to register this type of sensor to the backend, then detect it using the highest power from the gateway.