MatchBox and MatchStick

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


    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.


    EU Regulations


    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.


    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.


    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.




    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.



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