I work in a project thats explore relay functionalities and I got some little issues.
The first one is the relay message at port 226 after to be relayed. The meta data in ED page shows relayRXInfo attributes WorChannel, Dr and Frequency accordily as we hoped. However Snr value is not ok. It seems the snr value is not computed as defined in ts011 specification. As an example, I have a snr value of 8dB that was read from sx1262 . So I set the UplinkSNR field as 28(11100b) and the Chirpstack show the value as -4.
The second question is about ForwardListReq mac command. I didn’t undestant how this list should be set. Does this command available?
The ED that i am calling “Ed relay ready” and Relay are under develop. I work on that right now.
The Gw is a picocell board. I believe these detailed informations are not important. The payload from relay is arriving to the ChirpStack server. Just the snr value seems wrong.
And about ForwardListReq is not clear how to send to check on my Relay device.
In the list of your devices you can select the devices by the checkboxes, so in the button “selected devices” on the right side you can assign this ED to a relay.
After that, the relay will receive the Join EUI and Dev EUI of the all ED that was chosen as a thursted ED trusted list and Join-Request list.
I just don’t know yet how I manage the Join-Request forwarding list, and how I create a rule with Join EUI/ Dev EUI groups.
Your comment was useful! I did not see that menu before. I believe that it is too hide.
Now I received the ForwardListReq Mac Command. But I cant able to choose the filter pattern as shown in TS011 Apendix 3. I would like define only JoinEUI of my devices to foward JoinRequests.
I can confirm that Chirpstack is currently functioning optimally. It holds the distinction of being the sole platform offering support for the relay extension. While minor issues have been identified, I am confident they will be addressed shortly.
Thank you. To test the experiment, I think I need to have a LoRa sensor, LoRa Relay (sensor), and a Gateway. Am I right?
Is it possible to check virtually without any hardware at this moment? Although my plan is to implement using hardware. Now, I am in United States at North Carolina. Can you please tell me what versions usually u have used or I have to use (Sensor, Relay and Gateway)? Thank you.
We didn’t have the opportunity to test simulations. Our goal was to have the relay hardware ready for use. I can’t tell you the best way to simulate this scenario.
We built both hardware first (End-device Relayable, End-device Relay), since we knew that the LoRaWAN technology at the time had no implementation challenges.
If you want more details about our devices, search Google for Iterum and Addere. You will probably find the first version of them.
They were used by a major player in the European LoRaWAN scene at Enlit 2023 to do a live demo of their server’s features.
He tried to do this with other relays on the market, but was unsuccessful. Iterum and Addere were the only ones that were 100% compatible.
A bit of our strategy so far regarding LoRaWAN Relay:
We started developing our own LoRaWAN stack (based on git LoraNet v1.0.4) with relay support shortly after the release of the TS011 standard in October 2022. When the experimental LBM was released, with a number of limitations, we already had a pair of functional devices with all commands validated. In the meantime, Chirpstack released its V4 server. This gave a rapid growth in the development of details that were not clear with the standard alone.
Today, our devices are a reference for other LoRaWAN players in the world. The most important players in the world want us to validate their Relay implementations in their LNS.
We have made our LoRaWAN products to operate in the US902, AU915 and EU868 regions.
Dumb question here, but what is the issue with using a typical RF Relay to just pick up and retransmit the signal?
I understand that there are potential timing issues with the end-devices receive window, but I don’t see how a single relay would delay the signal much more than a gateway with simply more range.
Also it would obviously disrupt ADR but if you knew your devices would remain stationary that wouldn’t be a big issue.
Are there other problems I am missing with using a RF relay in a LoRaWAN deployment, or are those enough to prevent its use? Any insight would be much appreciated
The issue is that you would need to listen on all channels simultaneously. The Relay protocol defined by the LoRa Alliance scans one or two channels for the WOR frame from the device, in which the device tells the relay on which channel and data-rate it is going to send an uplink. The Relay then switches to that channel at the time of the uplink.
As the WOR frame uses a long preamble, the Relay does not have to listen continuously and with that saving power.
As well the Relay is aware about the devices for which it needs to Relay, and thus it can filter traffic based on session-keys. This can be an advantage or disadvantage (I believe this is less ideal for moving devices, as it would require constant syncing between the LNS and Relay when a device moves between on Relay to the other).
If you are interested in a simpler RF Relay solution, then stay tuned. Together with some other companies I am working on a Gateway Relay solution
Hi,
Why are there two channels (default and second channel) in LoRaWAN® Relay Specification TS011-1.0.0? Are both channels used by a relay and a end node?
By default, each region defines 2 channels for WOR frames. The Relay must set one of them to operate. If you have only one relay in a scenario with up to 16 devices, in the worst case, you may have occasional collisions of WOR frames and uplinks may not be passed on correctly. And this actually happens. If EndDevices have enough randomness to perform uplinks, it may not be noticeable.
In a second scenario, you can have 2 Relays, one configured for W0 configuration and another for W1 configuration. For convenience, you can define which EndDevices will go through which Relay by the MAC END_DEVICE_CONF_REQ command, in which you force the operating channel. This way you can group EndDevices and Relays of interest.
Now, a third scenario where you want to use 3 Relays in same area? You will need a new option different from W0 and W1. That’s where the 2nd channel comes in. The idea is the same. The Relay will still need one of the default W0 or W1 configurations, but can scan a second channel with a different configuration from those defined in the region at CAD periodicity/2 intervals.
The second channel helped us to verify the stability of our Iterum project. We had about 6 Relays working at the same time and with a certain amount of EndDevices. It was possible to migrate an EndDevice to a specific Relay just by changing the second channel.
Another problem that the second channel solves is the possibility of changing the WOR frame frequency where the W0 and W1 frequencies are already saturated or being targeted by jamming attacks, without having any relation to the number of Relays.
Thank you. Which bandwidths have you used for those two channels like 125kHz, 256 kHz to differentiate channels? I found that default channel is used for sensing the end device and the second channel is for forwarding the message to the gateway. Is it correct?
This is not correct. The Standard Channel and Second Channel refer just to the WOR frame. The modulation of forwarded messages must respect the region settings, like a regular device node.
Second channel settings are limited to the DRs available in the region.
An end device that does not have WOR frame capabilities will not be able to send messages through a Relay.
