If using the over-the-air activation procedure, the end-device SHALL broadcast the Join Request message alternatively on a random 125 kHz channel amongst the 64 channels defined using DR2 (SF10 uplink) and on a 500 kHz channel amongst the 8 channels defined using DR6 (SF8 downlink). The end-device SHOULD change channel for every transmission.
If a device were to have its payloads successfully received when transmitting on SF11 or SF12 but not when on SF10, does this mean such a device would never connect?
Why is DR6 defined if it is the same as DR12, both being SF8 at 500 kHz with bit rate of 12,500 bits per second?
Why does the downlink get transmitted at SF8 if the uplink is transmitted at SF10? Is there not a 1:1 correlation between downlink and uplink SF?
That is what is called a design decision. Apparently the decision was to define a separate set of DRs for downlinks. Why? Ask the committee members that worked on the design.
The default Join-Request Data Rate SHALL be DR2 (SF10/125 kHz); this setting ensures that end-devices are compatible with the 400ms dwell time limitation until the actual dwell time limit is notified to the end-device by the Network Server via the MAC command TxParamSetupReq.
Lines 979 to 980:
AU915-928 end-devices SHALL consider UplinkDwellTime = 1 during boot stage until reception of the TxParamSetupReq command.
The “Indicative Physical Bit Rate” of AU915 spreading factors (SFs) are as follows:
SF10 (DR2) 125 kHz - 980 bit/sec
SF11 (DR1) 125 kHz - 440 bit/sec
SF12 (DR0) 125 kHz - 250 bit/sec
The Join-Request PHYPayload is 23 bytes long, made up of the following:
I used the calculator as it accounts for the preamble and PHDR, which results in the actual airtime being greater than that required for 23 bytes.
Now my question is, when and how does TTN transmit the TxParamSetupReq MAC command via a downlink, setting UplinkDwellTime = 0? Is this an automated process or must you schedule the command? If it’s manual, how do I do it. I can’t seem to find a setting within the console that enables or disables the dwell time.
I appreciate that transmitting the Join-Request on SF10 means devices remain compliant in regions where dwell time is enforced, but couldn’t this be a setting on the device itself? This appears to make SF11 and SF12 redundant as described in my original post.
It also remains unclear to me why the downlink is transmitted at SF8 if the uplink is transmitted at SF10 (question 3 in my original post)?
@johan, I appreciate you’re a busy person, but is this something you can comment on?
Yes, so join-requests may not be sent at DR0 and DR1, like you quoted from the spec. To answer your first question, if SF11 and SF12 would work and SF10 doesn’t, then indeed it can’t join.
This is automatic.
The Things Stack has settings on multiple layers, but two are relevant: the band and the frequency plan. Some bands do not define whether dwell time is enabled at boot (like AS923). Some bands do define whether dwell time is enabled (like US915 and AU915). Then, the frequency plan can have an override setting whether to enable or disable dwell time (and other settings, like max EIRP). This is because there’s no 1:1 relationship between a band and a region. For instance, AS923 can be used in many, many countries. Also (parts of) AU915 can be used in South America. So, yes, there may or may not be band defaults, and there may or may not be frequency plan overrides. The frequency plan takes precedence and is therefore more local to a country or other regulatory region (ETSI, FCC).
It can still be used for smaller payloads.
For fixed channel plans there’s no 1:1 correlation between uplink and downlink, neither channels nor data rates.
Mind you it is SF8 at 500 kHz. This is two bandwidth steps higher than 125 kHz, just like SF8 is two spreading factor steps lower spreading factor than SF10. That is not equivalent, but to some extent, it is.
The Things Stack only knows frequency plans. Frequency plans refer to bands. I don’t think we have a (public) frequency plan for a South America country that uses the AU915 band. However, there is at least one Japanese frequency plan that refers to a AS923 band and sets some custom settings, at least maximum EIRP, maybe dwell time.
The relevant part for Australia and New Zealand is that you can use AS923, but the frequency plan would have to explicitly define whether dwell time should be enabled, because AS923 end-devices may or may not enable dwell time on boot, that is end-device specific.
Thanks! Just to confirm—am I right in understanding that a frequency plan, while technically permitted in multiple countries, may still be configured in The Things Stack (TTS) to comply with the specific regulations of one country, potentially making that configuration non-compliant in others?
For example, Australia doesn’t impose dwell time restrictions, so the AU915 frequency plan in TTS is configured to disable them. However, in another country where AU915 is allowed but dwell time restrictions do apply, using the default TTS configuration could be non-compliant. Is that correct?
Sure, I can select AU915 but I’m in the UK which uses the EU plan, but I can’t say I’m in the EU, oh dear, have I committed an offence by choosing the EU plan even though I’m not in it. Or am I?
My car’s speedo indicates I could potentially go faster than the national speed limit.
And your question is phrased borderline “have you stopped beating your significant other yet” and in a world run on physics we have many things available to use that may breach societal norms.
I’ll clarify my previous comment I’m seeking confirmation on:
Even if a frequency plan (like AU915) is legally permitted in multiple countries, that doesn’t mean the way it’s implemented in The Things Stack (TTS) will comply with all of them.
TTS configures each frequency plan based on the specific regulatory requirements of the country or region listed next to the plan name in the Console. That means the configuration is tailored to that particular country’s or region’s rules, not a generic or globally safe version.
For example, AU915 in TTS is configured to match Australian regulations, which do not impose dwell time limits. However, in another country where AU915 is also allowed but dwell time restrictions do apply, using the TTS configuration for AU915 (intended for Australia) could result in non-compliant behavior.
So, to ensure compliance, only use a frequency plan in TTS when your country or region is explicitly listed alongside it in the Console.
To ensure compliance you should verify the TTS frequency plan adheres to your local regulations. Specifically for emerging regions this allows you to start with LoRaWAN without having to wait for a regional parameter specification to be released (by the Lora Alliance) and it to be implemented in TTS. Only drawback could be that you’re not 100% aligned with the formal specification once it gets released.
