Add channel configurations for US / Australia / China

[DvdMgr]

This is a low hanging fruit: since we already have a system in LoraHelper to set up channels, it should be enough to modify some of the code and create methods for new regions. If anyone is interested in developing this, we can use this issue to keep track of the task.

[EduLima7]

Hello! I am a Brazilian computer engineering student and I am interested in solving this problem. I am trying with the US915 parameters. First, I looked for the differences between the Au868 (which were implemented) and EU915 parameters in: https://lora-alliance.org/sites/default/files/2018-04/lorawantm_regional_parameters_v1.1rb_-_final.pdf So, I found many differences between the two patterns, the first was the number of channels, which US915 has much more than EU868. Could you help me make adjustments to the US915 pattern? Have you created the module EU868 standard using the document "lorawantm_regional_parameters_v1.1rb" too?

[DvdMgr]

Hi, I'm glad you are interested in adding this feature!

Yes, the EU868 was configured based on the Regional Parameters document you linked.

As for the US, I've taken a quick look at the regulation and at the configuration that is mandated by the standard. The main changes I've identified are the following, the mentioned sections refer to the standard:

• Define the Data Rate conversion table for the US, according to the table of section 2.3.3
• Define the Maximum App Payload table for the US, according to section 2.3.6
• Define the RX1DROffset table for the US, according to section 2.3.7
• Define the channel scheme. Here, I think we could use the one used by TTN

In order to do this, you can start by defining methods in lora-mac-helper.h/cc that essentially do the same the ConfigureForEuRegion and ApplyCommonEuConfigurations, but for the US region. Then, adding a case for the switches in the LoraMacHelper::Create to use the newly created methods should be enough to use them when the US region is selected in the network configuration phase.

Once this looks like it is working, you can open a pull request and I'll take a look.

Let me know if you have any questions!

[EduLima7]

After these changes in lora-mac-helper.cc and test with network-server-example the terminal shows:

terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check: __n (which is 5) >= this->size() (which is 5) Command ['/ns-3-dev/build/src/lorawan/examples/ns3-dev-network-server-example-debug'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run --command-template="gdb --args %s ").

I realized that the problem is caused by loraMac->SetMaxAppPayloadForDataRatedefinition. I tried add a last one element in this vector to resolve the out_of_range error, but the simulation stops before finished and returns:

Attempting to send a packet larger than the maximum allowed size at this DataRate (DR5). Transmission canceled.

EDIT: I commit changes I've did in lora-mac-helper.cc and lora-mac-helper.h. Note: in lora-mac-helper.h file I changed EU and US references to EU868 and US915, respectively, according to the pattern.

[DvdMgr]

Hi Eduardo, it looks like the error was caused by the SetSpreadingFactorsUp method in the network-server-example. This method was setting the Data Rate to 5, since it was created for the EU region. However, since in the US only DR 0-4 are defined, DR5 is undefined.

Commenting the SetSpreadingFactorsUp line makes the script work! Maybe we could re-define that method to use only the available range of Data Rates, according to the region - now that I look at it, the implementation is pretty ugly too, and it could use some work.

[EduLima7]

Hi Davide, It's working. My intention is do the SetSpreadingFactorsUp method works too, for now I will use without it. Thanks :+1:

[DvdMgr]

An update on this: I've taken the bulk of the work that Eduardo did, adapted some of our code in the current develop branch and pushed everything to the us915 branch. It compiles, but I expect errors should come up when the SetSpreadingFactorsUp method is called - if anyone is interested in testing/fixing this, let us know!

[gaurivn]

I would like to work on this issue.

[gaurivn]

Hi, I'm glad you are interested in adding this feature!

Yes, the EU868 was configured based on the Regional Parameters document you linked.

As for the US, I've taken a quick look at the regulation and at the configuration that is mandated by the standard. The main changes I've identified are the following, the mentioned sections refer to the standard:

• Define the Data Rate conversion table for the US, according to the table of section 2.3.3
• Define the Maximum App Payload table for the US, according to section 2.3.6
• Define the RX1DROffset table for the US, according to section 2.3.7
• Define the channel scheme. Here, I think we could use the one used by TTN

In order to do this, you can start by defining methods in lora-mac-helper.h/cc that essentially do the same the ConfigureForEuRegion and ApplyCommonEuConfigurations, but for the US region. Then, adding a case for the switches in the LoraMacHelper::Create to use the newly created methods should be enough to use them when the US region is selected in the network configuration phase.

Once this looks like it is working, you can open a pull request and I'll take a look.

Let me know if you have any questions!

Sir, on clicking 'the standard', it says page not found, could you please provide the working link

[DvdMgr]

Updated link here.

[DvdMgr]

Closing.