Having read the Regional Parameters 1.0.4 and LoRaWAN Specification 1.0.4 in more detail, I have discovered the following:
Lines 975 to 978 (as quoted in my original post):
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:
- MHDR - 1 byte
- JoinEUI - 8 bytes
- DevEUI - 8 bytes
- DevNonce - 2 bytes
- MIC - 4 bytes
23 bytes is equal to 184 bits.
Inputting this into Airtime calculator for LoRaWAN gives 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.
A few relevant links:
- TxParamSetupReq missing with AU915?.
- AS923 dwell time limitation for Australia - #9 by arjanvanb
- Frame Option bytes sent by server are too long and are rejected. Work-around please - #7 by mluis1
- Record if UplinkDwellTime is enabled on boot · Issue #725 · TheThingsNetwork/lorawan-stack · GitHub
- Dwell Time and TxParamSetupReq for AS923 in New Zealand
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?