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.

Channel	Frequency
0	902.300.000 Hz
1	902.500.000 Hz
…	…
63	914.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.