Frame Option bytes sent by server are too long and are rejected. Work-around please

mluis1 · March 31, 2022, 7:59am

This is a quite complex subject and several discussion have been held concerning this.

The regional parameters specifications RP1 versions did not specify the default dwell time values for AU915 and AS923 regions.

Starting at RP2 versions the default dwell time for these regions is specified in order to avoid as much as possible potential issues.

On LoRaMac-node project when we have added support for AS923 regions we decided that the end-device should enforce the most restrictive limitations in order to ensure that it would always comply with countries national regulations. It was maybe not the best decision however we had to make one as it was not specified.

An end-device is only responsible to ensure that the uplink dwell time restrictions are respected. For downlinks it is the Network Server responsibility to ensure the respect of the downlink dwell time.
This is the reason why starting at RP2 specifications an uplink-dwell-time=1 and downlink-dwell-time=0 has been specified.

It has to be noted that potential issues may still happen in case a network server changes the Rx1DrOffset sent under the JoinAccept message. In case of AU915 and AS923 regions a network server shouldn’t do it as the first Rx window could become unusable.

In order to solve this issue I would recommend to update the LoRaMac stack to the latest version 4.6.0 which implements LoRaWAN 1.0.4 + RP2-1.0.1 specifications.
Version v4.4.4 is now quite old (May 26, 2020) and a lot of fixes have been done since. Please refer to the CHANGELOG.md file for further details.

github.com

Lora-net/LoRaMac-node/blob/master/CHANGELOG.md

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## LoRaWAN pre-certification results

Please refer to [Releases pre-certification-results](https://github.com/Lora-net/LoRaMac-node/wiki/releases-pre-certification-results) document for further information.

## [Unreleased]

## [4.6.0] - 2022-01-11

### General

- Release based on "LoRaWAN specification 1.0.4" and "LoRaWAN specification 1.1.0 + FCntDwn ERRATA" with "LoRaWAN Regional Parameters 2-1.0.1"
- GitHub reported issues corrections.

This file has been truncated. show original

Under v4.4.4 version the best way to solve the issue is to modify the AS923_DEFAULT_DOWNLINK_DWELL_TIME definition from 1 to 0.

github.com

Lora-net/LoRaMac-node/blob/ba17382bd5109513937afad07f068a781a503ef6/src/mac/region/RegionAS923.h#L128-L131

      
        
            /*!

             * Default downlink dwell time configuration

             */

            #define AS923_DEFAULT_DOWNLINK_DWELL_TIME           1

There were some recent discussions on this subject between my self and TTN and the outcome can be seen at following TheThingsNetwork/lorawan-stack issue: Maximum downlink payload size exceeded when dwell time is activated · Issue #4971 · TheThingsNetwork/lorawan-stack · GitHub

The following issues/PR are also related to the same subject:

github.com/TheThingsNetwork/lorawan-stack

Record if UplinkDwellTime is enabled on boot

opened 03:40PM - 21 May 19 UTC

closed 04:28PM - 04 Feb 22 UTC

rvolosatovs

c/network server s/in progress

#### Summary Record if `UplinkDwellTime` is enabled after device boot in band structure. Refs #709 #### Why do we need this? Network Server can avoid sending a redundant `TxParamSetupReq`, in cases, where `UplinkDownlinkTime` is set on boot and required by the frequency plan. #### What is already there? What do you see now?  Not this #### What is missing? What do you want to see? A field indicating whether the `UplinkDwellTime` is enabled after device boot, if such information is recorded in the spec. E.g. in `1.0.3` AU915: ![2019-05-21-17:18:12-screenshot](https://user-images.githubusercontent.com/12877905/58109788-88427380-7bee-11e9-8980-fcf74b75306d.png) Network Server should use this value to construct the MAC state of device on reset. #### How do you propose to implement this? `UplinkDwellTimeOnBoot *bool` on `band.Band` (nicer naming is welcome) Update `newMACState` in NS #### Can you do this yourself and submit a Pull Request? yes

github.com/TheThingsNetwork/lorawan-stack

Dwell time boot configuration

TheThingsNetwork:v3.18 ← TheThingsNetwork:feature/4971-dwell-time-config

opened 08:23PM - 24 Jan 22 UTC

adriansmares

+1298 -344

#### Summary  Closes https://github.com/TheThingsNetwork/lorawan-stack/issues/4971 Closes https://github.com/TheThingsNetwork/lorawan-stack/issues/725 #### Changes - Add the boot dwell time configuration options to `MACSettings` - Use the boot dwell time configuration in order to determine the current parameters of the end device after join/reset - Desired parameters are unchanged, only a bit of styling added - Add the boot dwell time configuration to specific versions of the ~AS923 and~ AU915 bands - ~I've added these only to the ones which have a LoRaMAC node release~ #### Testing Unit testing. ##### Regressions I'm a bit uncomfortable about the AS923 having default uplink dwell time enabled at boot time. Per spec, the device is not forced to have this dwell time enabled, so we may reject uplinks which have dwell time disabled at boot time. Are we sure we want to have these boot time options available in that band ? #### Checklist - [x] Scope: The referenced issue is addressed, there are no unrelated changes. - [x] Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in `README.md` for the chosen target branch. - [ ] Documentation: Relevant documentation is added or updated. - [ ] Changelog: Significant features, behavior changes, deprecations and fixes are added to `CHANGELOG.md`. - [x] Commits: Commit messages follow guidelines in `CONTRIBUTING.md`, there are no fixup commits left.