Is that only applicable to European band? As far as I know, US has different uplink and downlink bands?
I don’t know what you’re referring to, but I don’t see anything region-specific in the specification I linked to. (Apart from the applicable frequencies and data rates.)
Why do you want to configure the downlink frequency, rather than having the network do that?
The frequency for downlink data is specified by the back-end in the data packet to the gateway. There is no configuration parameter on the gateway for this.
According to LoRaWAN specification, US has uplink channels between 902.3 - 914.2 MHz and downlink channels between 923.3 - 927.5 MHz. I can’t seem to understand because if both uplink and downlink channels are two different bands, then how is the first receive window RX1 uses the same frequency channel as the uplink? I guess I have missed some important points here.
Weird, but you’re right. Despite my earlier quote,
The first receive window RX1 uses the same frequency channel as the uplink and a data rate that is a function of the data rate used for the uplink.
…section 7.2.7 states for US 902-928MHz:
The RX1 receive channel is a function of the upstream channel used to initiate the data exchange. The RX1 receive channel can be determined as follows.
- RX1 Channel Number = Transmit Channel Number modulo 8
Still then, all that should be set correctly by the network, and the gateway should just follow what the network dictates.
Thanks! This means there is no way to configure the DL channel since this is the duty of a backend/network server.
The reason that I asked this is because we have been allocated 918-920 MHz band for LoRa which doesn’t fall into the DL band of US, i.e. 923.3 - 927.5 MHz. So, I am thinking if it is possible to set the DL frequency explicitly.
In that case we’ll just have to wait for the LoRa Alliance to publish a specification for your specific region. You can use uplink as usual, but you might want to avoid downlink as that could be illegal.
@htdvisser, you’re not saying downlink in the US is not specified, or are you?
For the US I interpreted the above “RX1 Channel Number = Transmit Channel Number modulo 8” to refer to the 3rd bullet in:
7.2.2 US902-928 Channel Frequencies
The 915 MHz ISM Band shall be divided into the following channel plans.
- Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from DR0 to DR3 starting at 902.3 MHz and incrementing linearly by 200 kHz to 914.9 MHz
- Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR4 starting at 903.0 MHz and incrementing linearly by 1.6 MHz to 914.2 MHz
- Downstream – 8 channels numbered 0 to 7 utilizing LoRa 500 kHz BW at DR10 to DR13) starting at 923.3 MHz and incrementing linearly by 600 kHz to 927.5 MHz
But I’ve no idea who @nwilliam is referring to with “we”, in “we have been allocated 918-920 MHz band”.
Nope, didn’t say that
Regarding: “RX1 Channel Number = Transmit Channel Number modulo 8” for US 915:
If I’m understanding this right, wouldn’t this burden channels 0-7 with all RX1 traffic for all 64 channels?
Also, I thought I read somewhere that TTN “prefers”(?) to use subband 2 (channel 8-15), this means that the RX1 frequencies would be on sub-band 1. I’m not sure present gateways can support that.
The number of downlinks should really be only a fraction of the uplinks (at most 10 per day for TTN, including confirmed uplinks). And for the US the downlink frequencies 923.3 - 927.5 MHz do not seem to overlap with any of the uplink frequencies. So, no problem whatsoever?
This is quite vague. Any details to worry about?
A fraction? Including confirmed packets? I’ll take a closer at TTN guidelines. I was under the impression that I could elect all my packets to be confirmed packets, hence a downlink ACK should occur after every transmission.
Thanks for clarifying those downlink channels. I think I see how they work. Those 8 non-overlapping downlink channels are used for RX1 and RX2 for all 64 uplink channels (modulo 8). These 8 downlink channels could be busier than any particular sub-band if multiple sub-bands are used in the same area. Two different gateways using different sub-band could have conflicts on the same 8 downlink channels. Thanks!
Arjan is right, you are allowed 10 downlink messages a day when using TTN and a confirmation packet counts as a downlink packet. See this message where he summarizes the limitations. You can find the limits confirmed in this WIKI article authored by one of the TTN core team members. (Search for fair access policy on the page)
Is there also an algorithm involved in determining which slot to use rx1 or rx2?
For instance, use SNR/RSSI from uplink message to determine to send in rx1 (because of good reception) or in rx2 because of bad reception?
I think it’s only determined by the duty cycle of the gateway, and the SF of the uplink:
RX2 will probably only be used when the uplink is using a low data rate:
I can confirm this behavior in my setup. When using higher lower DRs the gateway tends to use RX2. When using lower DRs (DR>SF9BW125) the gateway primarily uses RX1. However, I had hoped a deterministic algorithm which was used to determine which rx window to use.
No, this algorithm is very dynamic. In general the algorithm tries to minimize channel utilization by using efficient data rates on quiet channels. The choice depends on the channel and data rate of the uplink, uplink and downlink utilization of the channels, the number of gateways that received the uplink message, the uplink and downlink utilization of those gateways and the signal quality of each gateway.
I do believe that the algorithm can be made more efficient in the future, if you have any ideas about that, please share them.
1 Like
If an application is too slow to get its downlink ready before RX1, might it still be sent in RX2 if it’s in time for that? Or is it always postponed until the next uplink if it was too late for RX1?
The application has a fixed time to respond to uplink messages directly, regardless of the selected RX window. If the application is too slow for that, the response is scheduled for the next opportunity.
1 Like
The same to me…