LoRaWan in US915 zone

I’m living in RCZ1 (EU868) area and our zone have some specific rules for using the free radio frequencies like duty-cycle to comply regulation I already shared in the linked post. I was little experienced with the US zone regulations. Thanks to a project made for a North American customer I started working on it and I’ve surprised of the differences and how it impacts the LoRaWan developments.

First of all, I’m not an expert of US915 area and I did not yet read the regulation reference documents. So all what you are goin to read is my current understanding of the way it works. It means some consideration could be missing and some wrong assumption could be part of my post. So to ensure you comply with regulation, I recommend you to verify for other sources.

At least you can find detailed information in this document from TI.

How LoRaWan works in EU868 in two words

To understand the differences between EU868 and US915, let see how the first one is working. When joining the LoRaWan network in Europe, the sensor uses one of the 3 standard channels all the gateways are listening to. Then the sensors will communicate on up to 5 other channels for a total of 8. These channels can be setup in the device configuration (static configuration) or setup dynamically during the join process. The sensors will respect a duty cycle during the communication phases restricting the communications for a percentage of the overall time per frequency bands. You can get the details in my post about the ETSI / EU868 regulation. The 868 bands starts

The following diagram from ebds.eu website shows the different sub-bands existing in the 868MHz ISM band:

The bandwidth is about 2MHz used by LPWAn (even if the band could start at 863 to 870Mhz and some operator are using the 867Mhz area). The channels are really closed to each others.

The US915 ISM band

The ISM band

The US915 band is in reality a large frequency band starting at 902MHz and going to 928MHz. So the band is 26Mhz available for transmission. The way a kind of duty-cycle is implemented is different: The sensors needs to transmit data with channel hoping.

LoRaWan US915 defines 64 channels starting from 902.3Mhz (each 125KHz large), separated by 200KHz each.

ChannelFrequency
0902.300.000 Hz
1902.500.000 Hz
63914.900.000 Hz

On the downlink side, 8 different channels will be used, starting at 923.3Mhz, separated by 600KHz from each others.

There are also 8 more channels starting at 903Mhz with a width of 500Khz, separated from each other with 1.6MHz. They are channels 64 to 72.

Time on the air consideration

There is no duty-cycle in US915 but a maximum transmission time over the same channel of 400ms within a 20s period of time. For this reason the minimum spread factor can be 10 and not 12.

A SF10 frame with 1 byte airtime is 200ms, SF11 is over 400ms. The maximum payload size at SF10 is 24 bytes (371ms). For a SF7 frame the maximum payload size is 256 bytes. (from loratools.nl)

Channel hopping

The channel is selected randomly on every transmission over the 64+8 defined channels. To comply with US915 regulation LoRaWan as a “system” needs to implement > 50 channels. At first I understood you need to use a expensive LoRaWan gateway to operate in US915 but it seems to no be the case.

The 64 channels are divided into 8 groups of 8 channels. It seems a gateway able to run on one of the sub-band may comply.

I assume you need to ensure to not reuse one of these channel in a 20s time frame corresponding to a transmission rate > 2,5 s as there is no duty cycle implemented in the LoRaWan stack for US915. You can also take a look of this post from The Things Network forum.

This have a larger impact on the way your sensor will manage its join procedure.

It’s also possible to jump on less channels with a reduced power transmission (-21dBm) according to LoRaWan documentation (but I don’t know what “less” means exactly and if 8 channel is accepted). This is the best approach to avoid 3/4 of frame loss.

Join procedure on LoRaWan US915

When designing a sensor, for US915, compared to EU868, you never know if a gateway will listen to you join request. There is no join channel defined and any of the 64 channels can be used for joining.

If the network is composed of 64 channels gateways, there is nothing specific but if the network is composed of 8 channels gateways the deal will be different.

The sensor will select randomly one of the 64 channels and will send the join request. This can fail until you select one of the listen channels. Statistically speaking you have 1/8 chance to select the right channel. Considering the non-chance and the frame loss rate, having 16 join try before succeeding will not be something strange.

The LoRaWan 1.0.2 norm (commonly implemented currently / and the one TTN is implementing) includes a CFList field in the Join Accept message. This field is supposed to configure the channels. Unfortunately the 1.0.2 version of the norm does not defines the content of CFList field for US915 (oups !) As a consequence it can’t be used for channel configuration.

As a consequence you are connected but not ready for speaking. You need to get your sensor configured for the available channels on your network. If not any of the transmission will also have only 1/8 chance to be heard.

The sensor channel configuration is requested by the network when activating ADR. So in US915, most of the device have to activate ADR mode to ensure they receive the correct channel configuration from the network server.

The LinkAdrReq command are received for a standard frame with ack flag enable. It contains the needed channel’s mask.

As a consequence, as part of the Join procedure, after having joined the network, you need to have a following standard/ack transmission to get the channel configuration. This means you need another 5-16 transmissions flow until getting success.

This could be optimized as the available channels should be part of the same sub-band as the one used when the device succeeded to join. Unfortunately the LoRaWan stacks does not implement such optimizations and make modification on the LoRaWan stack is not what I recommend to do.

Once done, your sensors is connected to network (it has negotiated the session keys) and configured to use the right channels.

Then you can normally communicate: only the listen channels will be used by the sensor during the communication.

Downlink impact

The RX1 channel is not the same as TX but determined from the TX channel. The rules applied is RX1 channel = TX channel % 8. As a consequence, if your have consecutive TX channels, all the RX channels will be used. The gateway needs to be able to manage this.

The RX2 channel is fixed : 923.3Mhz / DR8

Conclusion

The deployment of a full-band LoRaWan network in US915 area is more expensive than in EU868 due to the use of 64 channels gateways. You can deploy a partial-band LoRaWan network with 8 channels gateways for the price of longer and more complex device connection procedure.

From a device maker point of view, you need to consider the different possible cases: 64 channels gateways and 8 channels gateways. As a consequence you have to manage the specific join procedure with a high loss rate and the energy over-consumption during join phase.

The LoRaWan regional documentation is a good reading for getting more details.

7 thoughts on “LoRaWan in US915 zone

  1. Or you could change your software to be a bit smarter…

    To join you could use requests in each of the channels groups as suggested by https://lora-alliance.org/sites/default/files/2018-05/lorawan_regional_parameters_v1.0.2_final_1944_1.pdf on page 13. Once you get a reply you know the gateway listens to to at least that channel group so limiting the next transmission to that group will greatly improve the chances of it being received.

    And if you know a provider limits gateways to a single channel group you can of course limit the node to the same group, making OTAA requests hit the gateway at the first attempt.

    • And regarding 8 channel gateways, check the remark regarding hybrid mode in the mentioned specification. It seems the use of at least 4 channels is sufficient.

      • The Hybrid remark is not really clear to me and the main issue is that with 4 channels and the standard LoRaWan stack implementation you can be sure you will respect the 400ms over 20s. You need to add a duty cycle for this. It seems also you have some transmission power restriction in that case. But as said this is unclear so if you can detail your position with the legal & technical elements I would be happy to understand it better.

    • This is an interesting approach but it is not the one implemented in the different LoRaWan stacks. I assume it is because the regulation requires to have a random access to the frequencies.
      Modify the lorawan stack is not a good idea for certification and later updates.
      Basically it was my first approach to statically being able to configure the channels to map the right one as for TTN we know what they are. But this approach has been rejected on LoRaNode stack for good reasons in my point of view.
      https://github.com/Lora-net/LoRaMac-node/issues/745#issuecomment-495591821

  2. I have a question
    I am equipped with a Lora gateway (Dragino LG01 P 915Mhz) and I would like to highlight the Lora network with a dht11 temperature sensor on an arduino uno + lora module .. I have trouble finding the code on IDE arduino to communicate my sensor with my gateway !! Help please

  3. Pingback: What is Amazon sidewalk? - disk91.com - technology blogdisk91.com – technology blog

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.