MatchX - Blog

LoraWAN in Europe, US, Korea, Australia, India and New Zealand

There are different regulations all around the world, which specify how people can use LoraWAN with ISM bands in their countries. In this article we are going to explore the detailed deployment of LoraWAN in these different regions. Accoring to LoRaWAN Regional Parameters V1.0, we categorize these regions into four sectors: EU, US, China and World.

 LoraWAN regulations in EU

Currently there are several channels can be used in Europe to both transmit and receive. The specific channel lists are detailed in this document ETSI EN 300 220-2 V3.1.0 : As we mentioned in our previous blog posts, the channels are listed in the following picture:

eu

 

Now LoraWAN protocol enforces the use of g1, and the other channels can be defined by the network operator. There are three channels in g1 for bandwidth 125kHz:

  • 868.1MHz
  • 868.3MHz
  • 868.5MHz

In Europe, there is a optional field in the join response, in which the server can let the end device to know the rest of five channel frequency list. Once it is provided by the server ,the end device will update this five channel frequency list that it will use. Along with the pre-defined three channels in g1, it can use more channels to avoid collision.


 In India there is no clear statment about which channels to use, but LoraWAN specified the following channels for India between 865-867MHz:

Channel  Frequency(MHz) 
 0  865.4
 1  865.6
 2  865.8
 3  866.0
 4   866.2
 5  866.4
 6  866.6
 7  866.8

 

 The join channels of the end device is not standarized in India, it is expected that there will be a regulation document about the default join channels that all the network operators should support.

 

The data rate that can be used in EU and India are listed in the following table:

 

Data Rate  Spreading Factor& Bandwidth 
 0  SF12 & BW125kHZ
 1  SF11 & BW125kHZ
 2  SF10 & BW125kHZ
 3  SF9 & BW125kHZ
 4   SF8 & BW125kHZ
 5  SF7 & BW125kHZ
 6  SF7 & BW250kHZ
 7  GFSK: 50kbps

 

 

 LoraWAN regulations in US

The most important topic in US is the hybrid mode that speficied by FCC, which regulates how ISM band devices in 915MHz can send packets. There are 64 channels are used by BW125 and the rest 8 channels for uplink are used by BW500. The downlink channels can use BW500 to send packets to nodes.

us

The maximum output power for the BW125 is +30dBm, and the maximum output power for BW500 is +26dBm.

The data rate that can be used is less than EU, SF12 can only be used with BW500. This is because that FCC has a regulation on the time on air, which is 400ms.

Data Rate  Spreading Factor& Bandwidth 
 0  SF10 & BW125kHZ
 1  SF9 & BW125kHZ
 2  SF8 & BW125kHZ
 3  SF7 & BW125kHZ
 4   SF8 & BW500kHZ
 8  SF12 & BW500kHZ
 9  SF11 & BW500kHZ
 10  SF10 & BW500kHZ
 11  SF9 & BW500kHZ
 12  SF8 & BW500kHZ
 13  SF7 & BW500kHZ

 

 

FCC regulation requires hopping over at least 50 channels when using maximum output power. It is possible to have end-devices with less channels (at least six 125 kHz channels) when limiting the end device transmit power to 21 dBm.

The maximum MACpayload size of Data Rate 0 is limited to 19 bytes.

The RX1 window is not identical to the TX channel in this region! There is a formular to calculate the RX window channel:

RX1 channel number = TX channel number mod 8

And the data rate of the RX1 is depended on the TX data rate, take DR0 as an example: When TX is sent through DR0, the RX1 should use DR10 to receive the data. If TX is DR3 or DR4, the RX1 should both be DR13.

US ED

 

 LoraWAN regulations over the world

 Firstly let's take a look at Australia 915-928 MHz band, which uses similar deployment as US 902-928. The uplink channels are 64+8 as well, and the downlink channels are 8, which overlaps with the uplink channels and starts from DR4.

AU

 

The output power is limited to 30dBm. When BW125 is used, the frequency hop should have minimal 20 channels to perform. The end device should change channel for every transmission.

The data rate that can be used in Australia is listed below:

Data Rate  Spreading Factor& Bandwidth 
 0  SF10 & BW125kHZ
 1  SF9 & BW125kHZ
 2  SF8 & BW125kHZ
 3  SF7 & BW125kHZ
 4   SF8 & BW500kHZ
 8  SF12 & BW500kHZ
 9  SF11 & BW500kHZ
 10  SF10 & BW500kHZ
 11  SF9 & BW500kHZ
 12  SF8 & BW500kHZ
 13  SF7 & BW500kHZ

 

The maxiumum payload size for DR0 is limited to 19 bytes. The receive window configuration is the same as the US regulations, namly:

The RX1 window is not identical to the TX channel in this region! There is a formular to calculate the RX window channel:

RX1 channel number = TX channel number mod 8

And the data rate of the RX1 is depended on the TX data rate, take DR0 as an example: When TX is sent through DR0, the RX1 should use DR10 to receive the data. If TX is DR3 or DR4, the RX1 should both be DR13.

US ED


South Korea uses 920-923MHz for LoraWAN, it supports 16 channels, and the RX window channels are identical to the TX channel, the datarate is calculated based on the RX offset.

The most important difference is South Korea supports Listen-Before-Talk AFA, so it can supports more nodes.

 

LoraWAN also defined the AS923, which can be used in the following countries with the specific frequencies:

 

Frequency(MHz)  Country 
 923-925  Brunei
 923-925  Cambodia
 920-925  HongKong
 923-925  Indonesia
 920-925  Japan
 923-925  Laos
 915-928  New Zealand
 920-925  Singapore
 922-928  Taiwan
 920-925  Thailand
 920-925  Vietnam

 

They define two compulsory channels in these regions: 923.2 and 923.4 MHz, which can only use 1% of the duty cycle to join the network. And the rest of the channels can be distributed freely by the operators.

The output power is limited to 14dBm. Since there is 400ms time on air in these regions, the end devices can only use SF10BW125 to join the network, which is DR2.

The data rate that are allowed in these regions are:

Data Rate  Spreading Factor& Bandwidth 
 0  SF12 & BW125kHZ
 1  SF11 & BW125kHZ
 2  SF10 & BW125kHZ
 3  SF9 & BW125kHZ
 4   SF8 & BW125kHZ
 5  SF7 & BW125kHZ
 6  SF7 & BW250kHZ
 7  GFSK: 50kbps

 

There is also a channel frequency list in the join response to the end devices, which sepcifies five extra channels that the network is currently using.

The size of the maximum payload size is 59 bytes for DR0.

The uplink and downlink channels are identical while the data rate should be calculated based on the time on air (dwell time).

 


LoraWAN regulations in China

 There are two bands in China that can be used for LPWAN, Semtech adopted 470-510MHz for LoraWAN.

In total there are 96 channels are used in uplink with BW125 and 48 channels in downlink with BW125.

CHN

 

Chinese radio committe regulates the output power to 17dBm and the end devices should use the 14dBm default power setting.

The datarate that can be used in China are:

 

Data Rate  Spreading Factor& Bandwidth 
 0  SF12 & BW125kHZ
 1  SF11 & BW125kHZ
 2  SF10 & BW125kHZ
 3  SF9 & BW125kHZ
 4   SF8 & BW125kHZ
 5  SF7 & BW125kHZ

 The channel mask and the payload size are similar to the EU band and US band.

And the RX window channel is different from the TX channel due to the different channels are used. The fomular is :

 RX1 channel number = TX channel number mod 48

 

RX window 2 is fixed at 505.3 MHz with DR0.

 For example, an end device sending DR0 packet with channel 50 wil listen to channel 2 for RX.

CHN ED

LoraWAN interference, anti-collision and coverage

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.

 Introduction

To answer the question, let's take a look at the ISM band allocation to LoraWAN in different regions:

ISM

 

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.

 

EU Regulations

 

ETSI committe has release a technical document about the detailed regulation on each 868 frequency band:

eu

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.

toa

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.

 

US Regulations

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.

us

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.

 

Network Capacity

 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.

 

sx1301

 

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.

cellular

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.

 

 

LoraWAN network roaming

When we use the sensor devices in the IoT network, it is neccessary that the devices are roaming witin the network, or sometimes it can roam to other operator's network. LoraWAN protocol V1.0 has not yet done any thing about roaming but it is in plan. In this blog post, we are going to explore the possible scenarios and solutions of LoraWAN roaming.

 

 What is LoraWAN roaming?

To answer the question, let's take a look at the network architecture:

Roaming Page 1

In a single network, where all the gateways are connected to one or multiple lora-server instances, the gateway just forwards the data bidrectionally. Hence there is no really handover in the backend that specifies the protocol between the gateways. In this case, roaming within a signal network is quite easy, no extra efforts are required. That is basically how LoraWAN 1.0 works.

When it comes to another scenario, which involves multiple networks, the architecture is illustrated below:

 

 Roaming between loraWAN

Two loraWAN network may deploy in the adjacent or the same regions, in this case, whether the network operator can provision the other vendor's end device is also relevant to roaming. What information is needed from one network from another to trust the end devices? Who pays who in this situation?

 The information needed for inter-network roaming

In theory, LoraWAN end devices won't know which gateway it is connected. The main jobs of end devices are sending, receiving, ADR query and checking wheather the link is alive. With unconfirmed sending and receiving, the end devices have no idea about the success of delivery. More importantly, with link checking and ADR query, roaming devices need to receive downlink packets from the original lora server.

When the roaming devices lost connection or reset, it will also need to join the network again with its own credentials. The MAC commands from the original network will also need to reach the roaming devices. Hence we need to share some information between the networks to make this happen.

In Lora packets, there are some fields are not encrypted:

lora packet

Fields in FHDR, like DevAddr and FCtrl are not encrypted and can be read directly from the gateways that belongs to other network, in which DevAddr contains the identification of the end device. It is assumed to use DevAddr as a credential to forward the data bidirectionally.

Both networks should reach a consensus that who pays who for the forwarded packets between the network, and provide some APIs for query the device address from the other network and then forward.

 Necessary steps for inter-network roaming

To enable the inter-network roaming, we need a clean house in between the network that can negotiate and reply queries. The steps could be:

  1. Gateway receive the packets which include not-local DevAddr
  2. Query the DevAddr and register in the backend as a roaming device
  3. Based on the billing agreement, start to forward data bidirectionally
  4. Original lora server receives the packet and register in the backend as a roaming device
  5. When data is needed to be sent from the original lora server, use the roaming protocol to send to another network
  6. If the device is offline or goes back to the original network, terminate the roaming and delete entries in both network.