Hello everyone. My name is Eduardo and I’m having a beginner’s question. I know LoRa through the LoRaSIM simulator, which I did several tests and simulations. However, I do not know the LoRa source code documentation.
We propose an assignment of SF and CF parameters to the LoRa nodes, which proved to be efficient through LoRaSIM simulations. The algorithm and description of the algorithm can be found here:
How can I theoretically implement this optimization on the LoRA server? At what point does the LoRa server transmit the parameters to the LoRa nodes? I searched the source code of the LoRa Server through Notepad++, but I could not find it for sure.
Are you thinking about this in terms of LoRa or Lorawan?
I don’t know in which country you’re planning to test this, but in some jurisdictions you’re legally required to abide by duty cycle regulation. Each node will have counters that will switch between sub bands in order to abide by those restrictions.
I could see that playing havoc with the above algorithm, especially if it starts assigning nodes to the higher SF values. Do note, again, this may not apply to you.
In regards to your question specifically, if we are talking a typical Lorawan sensor network with class A nodes, loraserver will only transmit an uplink to a node when a node sends a downlink message. You can queue messages to a node using the http integration or the tx mqtt topic.
I’m thinking in terms of LoRaWan. The proposed algorithm uses as a parameter the use of each subband, which is limited to max duty cycle of 1% (bands g0 and g1). It starts by assigning from the lowest SF to the largest. I am considering European jurisdiction and class A devices. I should have mentioned those things.
At the application level, this algorithm returns to the network designer the vector of all nodes with the respective pairs of {SF, CF}.
However, in the real world, the network designer can not manually specify which nodes will have, for example, {SF7, CF1} when configuring a LoRa network. Unless it changes the programming code of the LoRa server.
So I am trying to find a way to put this optimization on the LoRa server to evaluate what the overhead impact of: CPU, memory, network and power.
As I noted, it would be easier to run this as an application on top of loraserver and the nodes. This way you wouldn’t have to mess with things like ADR and you would have you nodes configure themselves “manually” i.e. not the MAC layer configuring the SF and CF but rather the application layer doing that.
You should look at the documentation pertaining to sending uplink messages.
Effectively, loraserver would talk to your application which would be implementing the algorithm and telling loraserver what to send to the nodes on an uplink.
The nodes would then run a corresponding application that configures the parameters on the node.
Alternatively you could look into making some special MAC layer commands to do that (but you’d have implement them on loraserver and on Lorawan stack the nodes are running).
At first, the gateway through the server transmits to all nodes a fixed configuration of SF and CF, am I right?
Can I apply this algorithm at this time? Instead of transmitting a fixed value of CF and SF to the nodes, it transmits to each node the pairs of CF and SF according to the proposed algorithm.
Following this logic, do I need to modify or add programming code in the gateway and End-devices, guaranteeing protocol backwards compatibility? If so, will this generate Network Overhead due to increased network traffic? And cpu and memory overhead on end-devices?
If the End-device is physically moved and the ADR is set to true, when any node requests a lower value of SF, the proposed algorithm will have to verify if it is possible to assign to that node a lower value of SF according to the use of each SF, in order not to exceed the maximum duty cycle. If this is not possible, have to redo the vector of pairs of {SF, CF} for all nodes and retransmit.
I don’t think so. The server only responds to the node at the same frequency and SF as the node’s downlink packet (barring the rx2 window).
It is up to the node to change its parameters to reach the gateway. This can be aided with ADR messages, but I don’t think the server has any formal mechanisms to do that.
